Написание софта напоминает пошив платья на заказ, который длится полгода и больше. За это время может немного измениться фигура, в следующем сезоне будут другие тренды в силуэтах, и ваш личный вкус может претерпеть некоторые изменения: вы начнете предпочитать другую цветовую гамму.
Но если пошив платья не позволяет вносить модификации на лету без критических издержек, то современные гибкие методики разработки программных решений, как раз адаптированы к быстрому внесению изменений.
И это позволяет стартовать проект с четким видением целей, которые хочется достичь, и понимаем всех функциональных блоков, но без доскональной прорисовки всех структур до старта проекта.
Если вы писали полгода детальное техзадание (с помощью вашего аналитика или аналитика подрядчика), то есть риск, что к моменту выпуска софт уже идеологически устареет и не будет решать актуальных задач.
Собственно, такие вот “устаревшие до запуска” проекты были одной из причин появления гибких методик управления проектами, цель которых - постоянная аккумуляция изменений, происходящих в видении клиента и во внешней среде - в разрабатываемый софт.
Как именно это происходит, я расскажу в следующем посте. И очень рекомендую почитать манифест гибкой разработки и его ценности. Именно эти ценности дают возможность хорошим компаниям создать для своих клиентов открытую и максимально понятную и дружественную среду взаимодействия.