Как Вы разграничиваете между “Гибкой разработкой” и “Расползанием границ проекта”? [закрытый]

Это довольно просто в подходе схватки. В Scrum вы устанавливаете время спринта, например, 2 недели, а затем вписываете в него элементы. Когда клиент хочет что-то добавить, это помещается в очередь и будет выполнено в следующей итерации. Если они захотят это сейчас, вам придется объяснить им, что что-то будет отброшено, чтобы это соответствовало итерации.

для меня расширение области видимости происходит, когда новая функция добавляется без явной корректировки расписания.

В гибких методах пользователь глубоко вовлечен в решение, какие истории имеют приоритет для реализации. Следовательно, обмен одной функции на другую гораздо яснее.

Я бы не назвал это ползанием области видимости для пользователей, чтобы получить функцию, которую они выбирают, в порядке, на который они влияют.

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

Почему вы должны сказать «нет»? Я не знаю, какой вариант гибкой разработки вы используете. Scrum является наиболее предписывающим / имеет определенные правила для этого сценария.

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

Снижение объема больше не должно происходить - если вы не нарушите правила. У вас есть грузовик, который будет перевозить 500 коробок (план выпуска). Чтобы добавить к плану 100 коробок (новые функции), заказчику нужно сначала удалить (удалить) 100 наименее востребованных коробок из своего первоначального набора.

Если клиент готов платить, почему вы должны сказать «нет»? Если за все это платит только один клиент, то он в значительной степени находится в полной власти над тем, что действительно разрабатывается («если вы этого не сделаете, я возьму свои деньги и скажу сделать это кому-то другому»). Но, конечно, если у продукта есть большая аудитория, вам необходимо четко определить, что продукт должен делать, поскольку добавление ненужных функций может снизить его удобство использования.

Мне приходят в голову некоторые ситуации, когда команда разработчиков может рекомендовать клиенту не реализовывать некоторые функции. После этого ответственность ложится на клиента, если он так или иначе захочет это реализовать. Если функция конфликтует с некоторыми другими, более важными функциями, было бы разумно не добавлять ее. Если функция не представляет особой ценности для клиента, по сравнению с затратами на его внедрение, тогда было бы неразумно тратить на это много денег. Также в некоторых случаях может иметь больше смысла реализовать некоторые функции в виде отдельной программы, если их цель сильно отличается от исходной программы - лучше иметь много небольших приложений, каждое из которых выполняет одно задание и делает это хорошо, чем одно огромное приложение, которое делает все, но ни на чем не специализируется.

Ответ на В какой момент вы говорите клиенту, что «Нет , мы не можем сделать это изменение, потому что? ' зависит от значения ? .

Обычно нет веской причины сказать «Мы не можем сделать это изменение». Некоторые вещи можно сказать:

1. Мы можем это сделать, но это будет означать, что X, Y и Z будут исключены из цели спринта.
2. Мы можем это сделать, но это будет означать отклонение графика выпуска.
3. Мы можем это сделать, но для этого потребуется дополнительное тестирование.
4. Мы можем это сделать, но сначала нам понадобится X часов рефакторинга.
5. Мы можем это сделать, но сначала нам нужно стабилизировать или отменить выполняющийся feature X.
6. Мы можем это сделать, но мы могли бы сделать X намного быстрее и при этом обеспечить большую часть той же ценности.
7. Мы могли бы это сделать, но нам нужно решить это, прежде чем мы сможем это оценить.
8. Мы могли бы это сделать, но нам нужно потратить X дней на спайк, прежде чем мы узнаем наверняка .

(1) - (5) просто сводятся к «Написание кода требует времени» - с разными уровнями детализации. Комбинация (2) / (3), вероятно, наиболее близка к традиционной идее «ползучести». (Теоретически программное обеспечение, разработанное гибкой командой, всегда находится в состоянии готовности к выпуску, но немногие команды настолько хороши.) Но смещение масштабов - проблема только в том случае, если это означает, что владельцы продукта предъявляют нереалистичные требования к команде разработчиков. Пока команда разработчиков предоставляет реалистичные оценки, а владельцы продуктов принимают их, разработчика не должно волновать, насколько далеко заходит область применения.

Если у команды разработчиков нездоровые отношения с владельцем продукта,

Я думаю, что есть два вида смещения объема работ:

1.) Расширение объема проекта без увеличения оплаты / бюджета / времени, доступных разработчикам. Это может произойти в гибком процессе, только у нас с любым другим процессом, когда мастер pm / scrum или что-то еще не придерживается цифр и втискивает другую функцию в проект / итерацию / спринт.

2.) Расширение объем программного обеспечения, сверх того, что он полезен. Я думаю, что гибкие процессы могут действительно помочь в решении этой проблемы, потому что стоимость функции напрямую сообщается владельцу проекта, поэтому затраты должны быть очень прозрачными. Но главный инструмент против такого рода сползания прицела везде один и тот же: с каждой функцией вы должны проверить: оно нам действительно нужно? Нужен ли он нам в этой программе? Или это место где-то еще? Или в управлении: сколько стоит построить, сколько стоит поддерживать (часто забывают), насколько это увеличивает доход.

Вот простая эвристика, независимо от того, работаете ли вы на итерации продолжительностью в месяц, 1-2 недели или даже в среде, подобной Канбану, где функции добавляются в непрерывном потоке. :

1. Если ваш заказ на поставку (или заказчик) добавляет функции, но ожидает, что крайний срок останется прежним - это расползание функций: если он соответственно изменит объем и свои ожидания, это может быть не «Scrum», но он гибкий.
2. Если ваш заказ на поставку добавляет функции, которые не приносят никакой пользы покупателю, то это расширение возможностей худшего вида - трата! Если функции приносят пользу, это гибкость.