Как вы применяете (или нет?) итеративный подход в разработке?
Про итеративную разработку сказано и написано много. Может даже слишком много. И это всё, конечно, хорошо, но сколько я не читал и не копал в сторону этой темы - мне не удалось на практике применить этот подход с нужным результатом.
К примеру, есть реальный проект. Ресурс для автоматизации работы некоторого отдела.
БД - MySQL
Beck - PHP (Yii)
Front - JS + JQuery + Backbone
Человекоресурс не ограничен. В компании есть все. (для упрощения)
Можете на этом или похожем примере объяснить, как спланировать итеративную разработку? Допустим, мы получили уже и ТЗ и дизайн и всё, что нужно. Как правильно сформировать команду для проекта? Как разбить всё на этапы? (и кто это должен делать?) Как оценить этапы, составив стек тасков? Как после этого вести проект по итеративной модели?
1) Бьете тз на задачки.
2) Каждую задачку оцениваете в часах/зайцах/стори-поинтах.
3) Вытаскиваете на спринт столько задач, сколько считаете, что успеете.
4) После 3-х, 4-х спринтов, начинаете считать velocity команды и получаете дату завершения проекта. Например, так: mnogosdelal.ru/slidecasts/project-estimation
5) Ужасаетесь, ищите методы увеличения velocity.
В принципе, ответ хороший. И наверное, в этом и проблема. Всё это я могу и сам сказать. Даже более: я могу расписать или озвучить большую теоритическую базу. Но увы, это не даёт реальной практики в итеративной разработке. И такие модели я применял в команде не раз. Но этих основ не хватает. Хотелось бы услышать более подробные стадии, что ли. Где находятся невидимые грабли и подводные камни... Не ужели нужно "еле дотащить" сотню проектов, чтобы анализ промахов дал реальный результат в освоении итеративной методики?
Тогда итеративный подход позволит понимать "мощность" команды. А накопленный стек решенных задачек обязательно нужно использовать при оценке каждой задачки из нового проекта. Как-то так. Ну, и использовать вероятностный подход, который описан по ссылке, которую я кидал, что даст Вам дату окончания проекта =)
