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

10

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

Аравинд А
источник
«Изменение требований» - это свободный термин. Это изменение, потому что клиент фактически изменил свое мнение об утвержденном требовании? Что вызвало это изменение? Если это будет продолжаться, то вам необходимо пересмотреть то, как вы собираете требования. Ни одна методология SE не может удовлетворить отсутствие надлежащего сбора требований.
NoChance
@Emmad Изменения требований происходят во время UAT, когда пользователи считают, что удобство использования может быть улучшено определенными средствами. Это вызывает нарастание проблем перед производством. Это конечно не Agile.
Аравинд А
@Aravind A: UAT происходит в конце спринта, не так ли? Тогда любые новые идеи / изменения, которые возникают во время UAT, обычно должны стать историями для следующего спринта (если вы используете спринты).
слеске
Возможно, то, что предлагает @sleske, работает для вас, но также, простота использования может быть прототипирована заранее, если у пользователя есть исключительные требования. Иногда в проектах, связанных с ресурсами, вам необходимо контролировать свои амбиции пользователя.
NoChance

Ответы:

9

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

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

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

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

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

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

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

sleske
источник
Не делает ли процесс открыто проворным? Я имею в виду, как далеко может пройти ловкость? Если разработчик выполняет требование в первый раз, оно обязательно будет в следующий раз. Я чувствую, что это одна из многих проблем, которая приводит к тому, что качество кода перебрасывается.
Аравинд А
@AravindA Качество кода должно быть предметом особой заботы, и независимо от того, сколько раз код изменяется, команда должна всегда ориентироваться на одни и те же стандарты качества кода. На самом деле качество кода важнее, потому что требования и код постоянно меняются.
maple_shaft
2
@maple_shaft правильно - качество (по крайней мере, в основном) ортогонально изменению требования. Дайте мне требование: я начинаю писать хороший код. Если я закончу и получу новый запрос, или наполовину сделанный и получу изменение, я начну (пере) писать хороший код. После выделения влияния на текущий график / обязательство / и т.д.
SDG
Изменения требований, которые оказывают большое влияние на архитектуру системы, приведут к значительным задержкам или ухудшению качества. Вот почему вы должны провести старый добрый анализ водопадов (может быть и итеративным), где вы пытаетесь уменьшить риск их «внезапного» появления.
MaR
@Sles Спасибо за объяснение. Я думаю, я понял это сейчас. Я думаю, мне нужно узнать Agile больше.
Аравинд А
12

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

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

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

nikie
источник
@nike Спасибо. Это именно то, что я думал. Ваш третий пункт вписывается в мой сценарий. Некоторые клиенты просто пользуются преимуществом гибкой работы, думая, что это серебряная пуля, чтобы сделать работу быстрее.
Аравинд А
9

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

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

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

Адам Яскевич
источник
+1 за более короткие спринты. Уменьшите до 2 недель и посмотрите, поможет ли это.
Джон
1
4 недели действительно звучат довольно долго для спринта, особенно для проекта, который страдает от нестабильности требований.
Carson63000
7

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

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

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

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

Стивен А. Лоу
источник
3

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

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

Ладислав Мрнка
источник