Agile, Waterfall и изменения требований

Кто-нибудь сталкивался с тем, что проект, определяемый как Agile, был переполнен изменениями требований? Я работаю над проектом разработки, который запускается через 4 недели Sprint, но между этими Sprints всегда есть изменения. Это все еще определено как Agile тогда? Я чувствую, что это что-то вроде гибкого процесса. Требования Agile-процесса должны быть определены в начале спринта и пересмотрены до конца. Я прав в этом? Пожалуйста, дайте мне знать ваш опыт в этом.

Требования Agile-процесса должны быть определены в начале спринта и пересмотрены в его отношении. Я прав в этом?

Нет, это зависит от характера проекта (и процесса).

Существуют модели быстрой разработки, в которых требования должны быть зафиксированы во время спринта и должны изменяться только для следующего спринта (ярким примером является Scrum).

Однако существуют также процессы, в которых изменения могут происходить практически в любое время (при условии, что клиент принимает задержки и дополнительную работу, вызванную изменением). Kanban часто используется для управления этими рабочими процессами (хотя Kanban также можно комбинировать со Scrum).

Какую модель вы придерживаетесь, зависит от деталей каждого проекта.

Так что да, если клиент чувствует, что ему нужна возможность постоянно менять требования, то гибкий процесс может это удовлетворить. Однако заказчик должен знать о последствиях постоянных изменений и понимать, что они замедлят проект.

Это сводится к принципам гибкого манифеста - «Индивидуумы и взаимодействия над процессами и инструментами» и «Реагирование на изменения в соответствии с планом».

Я думаю, что вопрос, который вы должны задать, таков: почему вас переполняют изменения требований? Общие причины включают в себя:

• Разработчики не имеют (достаточно) контактов с конечными пользователями, поэтому они не могут понять потребности пользователей. Вместо этого они рассматривают требования как абстрактный кубик Рубика - они следуют буквам требований, даже не пытаясь понять их дух
• Кто-то (например, из маркетинга) добавляет требования, которые не имеют никакого смысла для конечного пользователя (но, например, звучат хорошо в брошюре). Таким образом, существует битва между «реальными» требованиями и «другими» требованиями, за которые боролись разработчики
• Масштаб проекта не определен («Ну, а если вы все-таки внедрите текстовый процессор, не могли бы вы просто добавить небольшой модуль, который ведет учет заработной платы?», И Билл из другой команды разработчиков спросил, насколько это сложно чтобы текстовый процессор тоже компилировал код на С ++? ")

Какова бы ни была коренная проблема, вам нужно это исправить. Утопление под слоями Agile (или любой другой методологии) не сработает.

По крайней мере, в Scrum, который, как кажется, является гибким процессом, наиболее популярным в наши дни среди типов управления, сфера Sprint является фиксированной. Если во время спринта меняется ваш Журнал Спринта, это не Scrum, а хаос. Журнал ожидания в спринте должен быть создан в начале спринта и оставаться неизменным до конца спринта (после чего вы создаете новое отставание в спринте для следующего спринта).

Если ваш бэклог продукта меняется во время спринта, это не страшно. Изменения просто становятся новой работой, которая расставлена ​​по приоритетам, оценена и выбрана, как и любое другое требование для следующего спринта. Если требования меняются настолько сильно, что Владельцу продукта приходится регулярно отменять спринт, у вас возникла проблема с большой буквы «Т».

Может быть, вам нужны короткие спринты?

Для здравомыслия программистов лучше всего, если требования не меняются во время пересмотра / спринта.

В вашей ситуации есть два очевидных варианта:

1. короткие спринты
2. Получите от клиента согласие не изменять требования во время пересмотра / спринта, если только вся редакция / спринт не будет отменена и перепланирована

Я настоятельно рекомендую оба .

Основная проблема заключается в том, что вы считаете, что используете Scrum, но это не так. Особенно ваш владелец продукта не следует за ним. В Scrum спринт является безопасной зоной, и никакие изменения в зафиксированных пользовательских историях не могут быть внесены, если текущий спринт не отменен. Ответственность за соблюдение этого лежит на мастере Scrum. Если это не работает в вашей среде, тогда это проблема процесса = вы не используете Scrum.

Самое простое изменение, которое вы можете сделать (если вы хотите следовать Scrum), это сделать ваш спринт короче - например, на одну неделю. Спринт на 4 недели рассматривался как вариант в первые дни Scrum, но сегодня обычно 1 - 2 недели, а 3 недели считается верхней границей. 4 недели - это очень много времени в меняющейся среде.