Неправильно ли использовать Agile, когда требования клиентов вообще не меняются?

12

В последнее время я видел много постов, в которых говорится, что одной из основных причин использования Agile является то, что клиенты часто меняют требования.

Однако, скажем, клиенты не часто меняют требования . На самом деле, у клиентов есть жесткие требования, хотя они могут быть немного расплывчатыми (но не слишком необоснованными), но я все равно использую Agile.

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

Мой вопрос: будет ли это плохо, ковбойское кодирование, анти-паттерн и т. Д.? Должны ли мы использовать водопад и планировать как можно больше в мельчайших деталях, прежде чем мы начнем кодировать, когда требования стабильны, а не в менталитете «давай сделаем» в Agile?

РЕДАКТИРОВАТЬ: Основным моментом здесь является то, что: мы не можем винить клиентов за изменение требований. Предположим, что клиенты указали нам на очень конкретную проблему, дайте нам список пожеланий в очень разумных деталях и оставьте нас в покое (т. Е. У клиентов есть свои собственные продуктивные дела, не надо их больше беспокоить. Только демонстрация для них рядом с конец, когда у вас есть минимальный рабочий прототип). Было бы неправильно использовать Agile в этом сценарии?

agile development-process

— InformedA
источник

2

@randomA: на самом деле, ИМХО, вы никогда не должны пробовать чистый водопад, только если вы хотите создать работающий продукт, который требует больше недели усилий.

— Док Браун

10

Пожалуйста, дайте мне ваши клиенты

— razethestray

7

Я дам в 2 раза больше для ваших клиентов, чем @razethestray

— Euphoric

2

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

— Док Браун

3

@randomA: вы можете порадовать своего клиента какое-то время, ничего не спрашивая, а затем, когда вы поставите последнее, сделаете его очень несчастным, поскольку оказывается, что вы настолько не выполнили требования, что можете выбросить программу и запустить с самого начала (который клиент не будет готов платить). Или вы сделаете его немного, но несчастным, когда попросите его достаточно между тем, чтобы построить правильную программу, но очень довольны в конце, когда программа действительно сделает то, что он хочет, и он получит то, за что заплатил. Выберите свой выбор.

— Док Браун

16

Будет ли это считаться плохим, ковбойским кодированием, анти-паттерном.

Краткий ответ: нет. Правильно делать «гибкие» не означает «не планировать», это значит не переоценивать вещи.

Одна из основных причин использования Agile - клиенты часто меняют требования.

Это упрощенное утверждение. «Изменение требований» также связано с тем, как меняется понимание требований командой. И речь идет о том, как приоритеты клиента относительно требований меняются, когда он фактически видит несколько выпусков программного обеспечения.

На самом деле, «agile» работает ИМХО лучше всего именно в той ситуации, которую вы описываете - клиент хорошо знает его общие требования, вы можете написать общий план, заполнить свой журнал большим количеством «пользовательских историй» и уже достаточно информации, чтобы выбрать правильную архитектуру системы. Короткие итерации стратегии гибкой разработки помогут сделать «неопределенные требования» более точными, с большим количеством отзывов, если вы все еще идете в правильном направлении. Это также даст вам раннюю обратную связь о реальных усилиях и затратах (это то, что вы все еще можете потерпеть неудачу в подходе с водопадом, даже если вы знаете каждый бит требования в деталях).

— Док Браун
источник

3

Правильное выполнение «водопада» не означает «все спланировать», это означает не анализировать вещи.

— Джорджио

1

@ Джорджио: правильно делать «водопад» означает не применять его, когда требования «немного расплывчаты» и «программное обеспечение достаточно сложное, чтобы в нем были детали, проблемы, которые я бы не узнал, пока не столкнулся с ними» (цитируйте Оригинальный вопрос).

— Док Браун

6

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

Одной из основных причин, по которой проекты с водопадами печально известны своими неудачами, является проблема «почти готово» - в конце тестируются созданные кучи ошибок, оставляя не подлежащий выпуску продукт, и не зная, нужны ли ему еще два дня или два года для устранения обнаруженных ошибок. Agile полностью устраняет этот риск. Если гибкий проект перезапускается, вы все равно можете предоставить рабочую версию, которая:

А) Доказывает клиенту, что вы на самом деле почти при помощи демо-версии («Все эти истории сделаны, мы можем сделать последние несколько, если вы хотите»), и еще некоторое время получит именно то, что они хотят.

Б) Потенциально достаточно хорош, чтобы они все равно были счастливы и отпустили.

Для меня устранение этого риска полного отказа - это достаточная причина для того, чтобы бизнес перешел к гибкому процессу разработки, а возможность создавать лучшее программное обеспечение, чем первоначально планировалось, не дает результатов. Как упоминалось в других ответах, эти «конкретные» требования часто все еще удивительно податливы.

— SpoonerNZ
источник

Я не понимаю, каким образом А) решает проблему, которую вы упомянули в начале вашего ответа: как вы узнаете, что последние несколько историй займут несколько дней или два года? Вы только действительно знаете, когда вы действительно делаете их, не так ли?

— Джорджио

1

Вы правы, но разница в том, что у вас есть выпускаемый продукт в его текущем состоянии, а не исправленный на 90% программный продукт, который не может быть выпущен. У вас также есть эмпирическое доказательство того, сколько времени вам потребовалось для предоставления функций, которые могут быть выпущены, и ваши оценки оставшейся работы, которые, скорее всего, дадут вам больше уверенности, чем доказательство того, что все, что вы сделали, действительно работает.

— SpoonerNZ

Это зависит: если все запланированные функции являются существенными, то продукт с 90% -ными характеристиками непригоден к использованию или недоступен: его можно использовать только для демонстрации того, что уже есть. По моему опыту Agile не является предпочтительным во всех ситуациях: есть проекты, для которых Agile больше подходит (меняющиеся требования, небольшие, автономные и независимые функции) и проекты, для которых он не подходит (стабильные требования, сложные и / или критически важные). функции).

— Джорджио

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

— SpoonerNZ

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

— Джорджио

3

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

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

— Барт ван Инген Шенау
источник

1

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

— user99561

@ user99561: вы правы, но в таких ситуациях требования в основном не расплывчаты, они кристально чисты - до тех пор, пока новая программа будет вести себя точно так же, как и старая. В такой ситуации «проворный» подход действительно не нужен. Итеративного, основанного на этапах подхода (без особого взаимодействия с клиентом) будет действительно достаточно.

— Док Браун

Кристально чистый? Удачи в выяснении, каково точное поведение и каковы исключения. В большинстве случаев даже деловые люди не понимают, что происходит в приложении. Мой совет: убегайте как можно быстрее от этих проектов. Потому что вы знаете, когда проект запускается, но вы не знаете, когда будет опубликована последняя ошибка, потому что приложения ведут себя по-другому.

— user99561

0

Вы всегда можете разделить большой релиз на более мелкие (спринты) и попросить вашего клиента оставить отзыв. Таким образом, вы уверены, что делаете все правильно, и клиент может отслеживать ваши успехи.

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

— Сильвиу Бурча
источник

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

— ИнформированоA