Отказ от Agile, переход на водопад-это правильно? [закрытый]

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

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

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

1. Если у вас плохая связь с клиентом, никакая методология разработки не спасет вас.
2. это не дело закусочной, как шеф-повар организует кухню, пока еда вкусная.

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

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

• в краткосрочной перспективе я бы отступил и дважды проверил ваши требования на этом этапе с ними. Пересмотрите и подтвердите свое текущее состояние по отношению к ним.

• среднесрочная перспектива, я бы открыл больше общение с клиентом - попробуйте вовлечь его в ежедневный scrum на некоторое время (пока вы не восстановите уверенность, тогда вы можете быть более гибкими).

• в долгосрочной перспективе, вы должны быть обеспокоены тем, как ваш премьер-министр и старшие разработчики сумели получить вас в эту позицию. Если клиент неразумен, это одно (но это все еще зависит от PM, чтобы управлять этим, поэтому вы не освобождены). Это не разумно жаловаться на слишком много изменений, что просто значит, вы напортачили в определении требований (что является диалогом, а не монологом) или что вам нужно иметь более многочисленные, но, вероятно, более короткие спринты.

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

предостережение: я действительно не способен к сбалансированному взгляду на водопад, так как я никогда не видел его работы эффективно и ИМХО это просто полностью устарело для корпоративных проектов.

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

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

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

см. книгу Стива Макконнелла: "Быстрая разработка программного обеспечения: укрощение дикого программного графика" для всех методов, которые работают.

гибкая разработка не избавит вас от бремени фактического придумывания дизайна, который вы и клиент понимаете одинаково. Agile просто позволяет придумать дизайн с меньшими шагами и не все сразу. И, в случае трудного клиента, придумать правильный дизайн занимает время.

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

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

Scrum-это своего рода" короткий водопад", и вы должны быть изолированы от изменения требований к продолжительности спринта. Кажется, что этого не происходит! Поэтому, не вижу, что вы получите что-нибудь от перехода на традиционные водопад, но вы должны придерживаться требований замораживания для продолжительности спринта. Может быть, ваши итерации слишком длинные? (Я предполагаю, что вы следуете Scrum, так как вы упоминаете спринты).

поговорите со своими клиентами и согласитесь со следующим:

- Shorter iterations, up to 3 weeks max.
- No changes in requirements during the iteration. 
- Features are planned at the beginning of the iteration 
- Every iteration ends with deliverable: fully functional software with all features that are fully operational
- Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind).
- Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity".
- Client decides what features (but not how many of them) are planned for the iteration 

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

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

о

"мы (разработчики) не смогли завершить в течение указанного ими времени."

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

для меня это звучит так, как будто в agile-проекте не было "большого плана[TM]". Использование гибкого процесса не означает, что нет долгосрочного плана, это скорее связано с растущей неопределенностью в более отдаленном будущем. Например, должен быть план выпуска с запланированными функциями для всех выпусков в ближайшие 2 месяца (и менее подробный план с функциями для выпусков после этого), поэтому клиенту ясно, когда ожидать функцию, и когда есть возможность изменяющиеся требования.

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

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

неясно, какие изменения дизайна вы имеете в виду. Графический дизайн? Дизайн пользовательского интерфейса? Дизайн кода?

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

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

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

пожар клиента. Даже если это ваша вина за то, что вы не понимаете, что они означают, waterfall даст им 1 шанс дать вам обратную связь вместо шанса в конце каждого спринта. Некоторые люди / клиенты буквально настолько глупы, что на них не стоит работать. Увольте их, или скажите им, что вы используете водопад без фактического переключения.

ваш клиент не знает о том, как разрабатывать программное обеспечение, или как управлять процессом разработки программного обеспечения. Не ожидайте, что клиент предоставит содержательные инструкции по этим вопросам. В частном случае клиент действительно не знает, что означают такие термины, как "водопад" и "гибкий"; не ожидайте, что они предоставят значимый вклад в вашу методологию разработки. Более того, клиент не будет действительно волнуют эти детали, поскольку требования удовлетворены в согласованный бюджет и сроки. Не ожидайте, что они будут заботиться, и не путайте их с большим количеством неадекватных построений и неуместной информации о вашем внутреннем процессе.

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

кто-то в вашей команде должен быть адвокат клиента, и сидеть на вершине проблем клиента и бороться за них. Этот адвокат не должен быть отстранен, и они не могут принять сторону команды против клиента; они должны быть прокси-боссом. Затем вы можете отделить внутреннюю коммуникацию процесса (команда для защиты) от внешней коммуникации (адвокат для клиента). Адвокат может в какой-то мере оградить клиента от болтовни и строений, которые они не ценят, без искусственного навязывания определенный вид управления или планирования вашего внутреннего процесса.

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

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

Я пишу это, потому что у меня аналогичная проблема в моем текущем проекте, но я знаю, где мы потерпели неудачу.

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

вы прокомментировали изменения от спринтов 6-7, которые начали вызывать переработку задач, достигнутых в более ранних спринтах. Эти изменения должны были быть обнаружены ранее-во время проверки Sprint.

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

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

вы доставляете программное обеспечение клиенту после каждого спринта, или вы просто его демо ?

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

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

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

одной из распространенных причин этого является позднее открытие/создание "всех" требований, вещей, которые должны быть правдой обо всем в рамках проекта. Это может быть довольно фатальным, если принимать всерьез: что-то такое простое, как "все диалоговые окна должны быть изменены", например, по-видимому, выходит за рамки возможностей Microsoft для модернизации до Windows.

классический счет такого рода сбоя (хотя и в не гибком проекте) можно найти здесь

например, по словам инженеров SAIC, после того, как восемь команд завершили около 25 процентов VCF, ФБР хотело, чтобы возможность" page crumb " была добавлена ко всем экраны. Также известный как "хлебные крошки", имя, вдохновленное сказкой Гензеля и Гретель, это навигационное устройство дает пользователям список URL-адресов, идентифицирующих путь, пройденный через VCF, чтобы добраться до текущего экрана. Эта новая возможность не только добавила больше сложности, сказали инженеры SAIC, но и задержала разработку, потому что завершенные потоки должны были быть модернизированы с помощью новой функции.

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

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

многие магазины добавляют гибкие обрезки, чтобы заставить себя "выглядеть гибкими" для клиентов, которые этого ожидают. Может быть, вам просто нужно добавить некоторые водопад обрезки, и показать им продукт один раз каждые 2 спринта.

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

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

Я бы посмотрел на такие методы, как сопоставление последствий, развитие, основанное на поведении (BDD) и история картографии для улучшения связи.