Что вы видели не так при представлении SCRUM?

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

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

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

Самая большая проблема - недоразумение. Общие сбои:

• Только команда занимается Scrum, но остальная часть компании (включая продажи, менеджмент, HR) все еще думает по-старому. Примеры:

  Постоянное взаимодействие с клиентом и вовлечение клиента очень важно.

  HR должен понимать, что эффективность команды важнее, чем производительность отдельных людей. КПИ должен измениться на это.

  Определение функции - это непрерывный процесс. Определение проекта будет развиваться в процессе разработки по отзывам клиентов. Из-за этого срока проекта требуемый бюджет или набор функций результата могут измениться (после утверждения заинтересованным лицом).

  Изменение является частью процесса.

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

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

  Спринт - безопасная зона для команды. Как только команда фиксирует некоторые определенные пользовательские истории, обязательство не может быть изменено вне группы.

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

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

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

Редактировать:

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

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

Я видел, что команды с scrum более успешны, когда они сначала что-то делают по книге, чем команды, которые меняют то, что они еще не «получают».

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

Что-то связанное с Шухари ( http://c2.com/cgi/wiki?ShuHaRi ).

Самая большая проблема всегда - бай-ин. Если какая-либо команда или ключевые лица не участвовали (управление проектом, контроль качества, разработка и т. Д.), То провал почти гарантирован.

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

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

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

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

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

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

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

В конце концов, просто запомните полужесткий проворный манифест .

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

• Сколько это будет стоить
• Как это будет выглядеть
• Когда это будет сделано

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

У меня было две большие проблемы на моем первом посещении SCRUM:

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

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

Основная проблема, с которой я сталкиваюсь в своем проекте, состоит в том, что сбор требований происходит после того, как мы оценили следующий спринт. Мы оцениваем на основе критериев приемлемости. Во время сбора требований мы обнаруживаем, что точно настроенный переменный ток намного больше, поэтому начальная задача, рассчитанная на 8 часов, теперь действительно составляет 24 часа! Итак, могу ли я изменить свое отставание в спринте и пересмотреть оценки и сократить свои истории? Нет, сэр! Agile требует, чтобы вы не могли изменить отставание спринта! Вот что говорит мой TL. Так что я не должен также кодировать в соответствии с первоначальными критериями принятия, для которых я оценил время в 8 часов! Бог! Нет! Вы не можете сделать это! Это не было бы Agile, не так ли!