Comments 2
Спасибо, что поделились опытом. Могли бы вы прояснить такой момент. Вы написали, что результатом 1го этапа является ТЗ с требованиями и описанием технического решения и что в это же время определяется концепция проекта.
Мне хочется понять, какую пользу вы извлекаете от Agile подхода на последующих этапах, если все требования уже зафиксированы в начале? Ведь основное преимущество Agile — на основе результата итерации получить обратную связь от заказчика и при необходимости скорректировать «курс» разработки.
Мне хочется понять, какую пользу вы извлекаете от Agile подхода на последующих этапах, если все требования уже зафиксированы в начале? Ведь основное преимущество Agile — на основе результата итерации получить обратную связь от заказчика и при необходимости скорректировать «курс» разработки.
Получить профит от применения гибкой методологии в общении с госзаказчиком сложно. Для него основная модель — жёстко заданные, согласованные в нескольких ведомствах требования по срокам, бюджету и качеству. Пересматривать эти параметры он физически и юридически не может. Потому мы должны подстраиваться под эти внешние обстоятельства, что, однако, не отменяет возможность применения гибкой методологии внутри нашего процесса разработки.
Тут надо вспомнить, что кроме требований заказчика в рамках конкретной работы всегда есть требования других заинтересованных сторон. И хотя заказчик фиксирует свои требования, подписывая ТЗ, требования других сторон остаются плавающими. Последний пример. Делаем вторую версию нашей системы. Первая находится в проме, и на ней возникает сбой. Исправления нужно учесть в новой версии, но модель предметной области в ней поменялась, и простой мерж двух веток кода не проходит. Возникает дополнительная задача с высоким приоритетом, и она возникает вне проекта разработки второй версии. Т.к. интересы заказчика представляет в нашем процессе архитектор, то с ним и идёт согласование каждой итерации. И именно он вносит новую задачу, меняя требования.
Тут надо вспомнить, что кроме требований заказчика в рамках конкретной работы всегда есть требования других заинтересованных сторон. И хотя заказчик фиксирует свои требования, подписывая ТЗ, требования других сторон остаются плавающими. Последний пример. Делаем вторую версию нашей системы. Первая находится в проме, и на ней возникает сбой. Исправления нужно учесть в новой версии, но модель предметной области в ней поменялась, и простой мерж двух веток кода не проходит. Возникает дополнительная задача с высоким приоритетом, и она возникает вне проекта разработки второй версии. Т.к. интересы заказчика представляет в нашем процессе архитектор, то с ним и идёт согласование каждой итерации. И именно он вносит новую задачу, меняя требования.
Sign up to leave a comment.
Применение agile при разработке проекта для государственного заказчика