При отказе Гибкий, Переключении на водопад - действительно ли это правильно? [закрытый]

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

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

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

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

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, но базовая архитектура и дизайн не изменяются.

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

Относительно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Как только они увидят продукт написанного нами кода, они скажут:« О, мы должны это изменить. Я не это имел в виду », - сказал Рейнольдс из SAIC. «И именно тогда мы начали регистрировать запрос на изменение после запроса на изменение после запроса на изменение».

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

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

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

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

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