Отказ от перехода, переход на водопад - Это правильно?

Ответ 1

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

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

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

В дополнение к вышеприведенной другой общей проблемой с "чистым" Agile является управление ожиданиями клиентов. Agile продается как эта замечательная вещь, которая означает, что клиент может отложить принятие решений, изменить свое мнение и добавить новые требования по своему усмотрению. ОДНАКО, это не означает, что конечная дата/бюджет/требуемые усилия остаются фиксированными, но люди всегда, кажется, пропустят эту часть.

Ответ 2

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

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

Ответ 3

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

• Если у вас плохое общение с клиентом, никакая методология разработки не спасет вас.
• Ни один из закусочных, как шеф-повар не организует кухню, пока еда вкусная.

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

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

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

Ответ 14

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

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

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

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

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

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

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

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

Ответ 15

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

Ответ 16

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

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

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