Идеальная разработка – это когда сказал что тебе нужно, разработчик все понял, и сделал проект, который легко и просто масштабируется и подстраивается под новые требования. Но чем сложнее сфера, и чем больше моментов нужно учесть при разработке, тем тяжелее добиться желаемого результата. Поэтому для больших проектов, на смену традиционной разработки пришла разработка поэтапная. Эта статья как раз про нее.
Почему же так хороша разработка продукта по этапам?
Благодаря поэтапной (или итеративной) разработке можно гораздо раньше предъявить миру свой продукт, а далее только наращивать на него функционал. И исходя из этого, корректировать остальные этапы до выхода продукта полностью.
Разработка небольшими итерациями всегда:
Быстрее
Реализация необходимого функционала всегда связана с подробным описанием требований. Если продумать каждый этап по отдельности , можно уделить внимание любой мелочи в процессе разработки, гораздо раньше запуститься, начать окупать разработку и вносить корректировки
Понятнее
При разработке любого большого проекта необходимо написание Технического Задания, разработка которого занимает около месяца. Если в ТЗ заложена разработка итерациями, это повысит шансы того, что оно будет прочитано и понято
Дешевле
Когда на оценку приходит большое ТЗ, то трудозатраты выставляются примерными, не всегда обдуманными и с запасом. Благодаря разработке по частям, оценка более детальная и тщательная
При стандартной разработке, для большого проекта пишется больше ТЗ. И если самые опытные аналитики могут держать весь проект в голове, то перенести его на бумагу, со всеми требованиями, мелочами и взаимосвязями можно уместить на 50-100 листах, что крайне тяжело для восприятия. Это если учесть, что требования к проекту не поменялись за время разработки, что встречается крайне редко.
Для этого у нас в компании применяется 2 технологии производства: традиционная для маленьких и коротких и поэтапная для больших и долгих проектов.
- На этапе аудита, когда собраны требования к проекту, мы обговариваем с заказчиком, в каком виде и с каким функционалом будет запущен первый этап. С учетом этого пишется ТЗ.
- После запуска первого этапа мы отмечаем, насколько поменялось видение проекта. Первый этап редко переделывается, поскольку в нем реализован самый базовый функционал. И с оглядкой на его запуск, могут корректироваться остальные этапы.
- На последующих этапах проект наращивает функционал и интеграции.
Единственное, что в этом методе может смущать, это то, что при запуске пользователи не получат продукт полностью, а будут получать кусками. Именно поэтому необходимо спроектировать запуск так, чтобы был готов
ключевой функционал.
Заключение
Традиционный подход для больших проектов безусловно возможен, но он не дает той уверенности и гибкости, которые дает поэтапная разработка. Благодаря ней вы раньше запустите проект и начнете получать прибыль и идеи для дальнейшего развития.