привет всем!
есть некий вырожденный случай разработки: заказчик-руководитель-проектировщик-девелопер-тестер одно лицо
, разрабатывается проект (для себя) распределённый(клиент-сервер), т.е. объём всё-таки есть, посему вопрос насколько имеет смысл придерживаться методологий, документирований и прочего, у кого какой опыт есть? с одной стороны надо, с другой это сильно тормозит проект. если у кого есть какие мысли — welcome!
В данной ситуации нужно использовать только то, что относится к планированию — выбор наиболее важного, оценка сроков, контроль. Документировать стоит только то, что трудно запомнить. А вот всё, что связано с коммуникацией между членами проекта — можно смело выбрасывать...
Здравствуйте, Denis, Вы писали:
D>привет всем!
D>есть некий вырожденный случай разработки: заказчик-руководитель-проектировщик-девелопер-тестер одно лицо , разрабатывается проект (для себя) распределённый(клиент-сервер), т.е. объём всё-таки есть, посему вопрос насколько имеет смысл придерживаться методологий, документирований и прочего, у кого какой опыт есть? с одной стороны надо, с другой это сильно тормозит проект. если у кого есть какие мысли — welcome!
Нужен bugtracking и управление требованиями. В данном случае и то и другое можно реализовать на стикерах прилепленных к монитору.
Планирование не нужно если ты только ты сам не хочешь точно знать когда закончишь.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
> привет всем!
> есть некий вырожденный случай разработки: заказчик-руководитель-проектировщик-девелопер-тестер одно лицо , разрабатывается проект (для себя) распределённый(клиент-сервер), т.е. объём всё-таки есть, посему вопрос насколько имеет смысл придерживаться методологий, документирований и прочего, у кого какой опыт есть? с одной стороны надо, с другой это сильно тормозит проект. если у кого есть какие мысли — welcome!
Мне в "теории" XP, несмотря на всю мою к ней нелюбовь, очень нравится подход: do the simplest thing that could possibly work. Или, как говорили в старину, когда XP ещё не придумали, KISS (Keep It Simple, Stupid). Не стоит усложнять систему сверх необходимого минимума.
Определитесь с целями. Идентифицируйте и измерьте риски. Определите концепцию системы. Определите бюджет, сориентируйтесь в отношении плана. Нужны ли вам при этом артефакты (а в предыдущих четырёх предложениях можно "разглядеть" как минимум пять артефактов)?
Определитесь и с этим.
Posted via RSDN NNTP Server 1.9 delta
Здравствуйте, Denis, Вы писали:
D>привет всем!
D>есть некий вырожденный случай разработки: заказчик-руководитель-проектировщик-девелопер-тестер одно лицо , разрабатывается проект (для себя) распределённый(клиент-сервер), т.е. объём всё-таки есть, посему вопрос насколько имеет смысл придерживаться методологий, документирований и прочего, у кого какой опыт есть? с одной стороны надо, с другой это сильно тормозит проект. если у кого есть какие мысли — welcome!
ИМХО выбирать XP явно не стоит
А по сути — процесс может быть любым, главное, чтобы он был и чтобы его можно было придерживаться. Можете сами себе его придумать (взяв самое простое и понятное отовсюду, что хватит времени прочитать). Это упростит разработку, особенно, если предполагается работать несколько месяцев. Что касается документирования — представьте, что вы несколько месяцев делали проект, а потом на пару месяцев уехали отдыхать. Прикиньте, что вам будет нужно после возвращения и это задокументируйте.
... << RSDN@Home 1.1.4 @@subversion >>
Здравствуйте, Anatolix, Вы писали:
A>Нужен bugtracking и управление требованиями.
+1.
Попытаюсь "расшифровать" эти два пункта. Скорее даже для себя
Имху, главное, чтобы сначасла было управление требованиями. Четко определи, что ты хочешь получить и что бцудет критерием успешного завершения. Раздели требования на обязательные, важные и желательные. Для того, чтобы не увязнуть в желательных (котрых обычно бексонечно много
), не сделав обязательные. После этого определись, как ты это будешь делать.
Раздели задачи на те, которые ты точно знаешь, как делать и те, в которых еще надо будет разобраться. Вторые являются рисками, с которыми лучше разделаться как можно быстрее. Они — один из основных источников багов. К тому же, информация, которую ты получишь при решении этих задач может изменить другие задачи.
По каждой задачи и каждому требованию определись, когда ты можешь считать ее или его приемлемо выполненным. Имху лучше сначала добиться приемлемого выполнения всех основных требований, так как это тебе даст представление и "тестовый стенд" для заточки этих и выполнения других требований.
Теперь о багах.
Багтрекинг в классическом понимании не столько нужен, так как ошибки в основном будут фиксится в момент проявления. Очень желательно иметь regression тесты чтобы не бояться рефакторить код при необходимости и сразу видеть ошибки.
Всегда письменно в коде помечай те места, где использовал "не совсем правильное" решение. Например, не обработал исключительные случаи. Иначе потом трудно будет их отлавливать. Баги, которые не ошибки, в основном будут проявлятся именно в виде "недоделанных" или "не совсем корректно сделанных" задач.
В общем, если ты можешь точно сказать, что уже сделано, что осталось сделать, в каком порядке ты это будешь делать и какие у тебя при этом могут возникнуть проблемы (обычно — неправильно выбранная архитектура или инструмент), то все идет как надо.
Здравствуйте, Anatolix, Вы писали:
A>Нужен bugtracking и управление требованиями. В данном случае и то и другое можно реализовать на стикерах прилепленных к монитору.
A>Планирование не нужно если ты только ты сам не хочешь точно знать когда закончишь.
бедный монитор, а я свой тряпочкой каждый день протираю
а на него оказывается стикеры надо клеить
... << RSDN@Home 1.1.3 stable >>
