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

20

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

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

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

пресмыкаться
источник

Ответы:

14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ладислав Мрнка
источник
Мне нравится ваш фокус на постоянное взаимодействие и общение . Некоторые из проблем, которые я слышу, касаются отсутствия деталей в историях или недокументированных решениях (даже о технических деталях), и люди хотят защититься от последствий неправильного решения (очень защитная точка зрения).
съеживаться
1
Документация и анализ заменены на постоянное взаимодействие и общение. Вы не можете удалить один и не вводить второй - это точно приведет к отсутствующим деталям и неправильным решениям.
Ладислав Мрнка
The most basic approach is including analysis and documentation in acceptance criteria for user stories.Это моя первоначальная реакция тоже. Если история имеет критерии приемлемости, это лучшая документация, которую вы можете иметь. Но если команда решит создать дополнительные документы (например, README в стволе или вики с полезной информацией), то я не вижу проблемы. Я думаю, что люди боятся, что SCRUM = ничего никогда не записывается.
съеживаться
10

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

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

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

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

Julio
источник
9

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

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

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

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

козырь в кармане
источник
1
Просто скажи Bad Back Boy стоять во время разговора. Если он все еще жалуется, сделайте объявление, что на кухне есть пончики.
JeffO
management has actually taken this as a ticket to come directly to developersЭто хороший пример ситуации, когда процесс SCRUM не понят, верно? Это команда не может принять новые истории в середине спринта.
съеживаться
@ шприц, да ... точно
aceinthehole
2
действительно ли имеет значение, что кто-то сидит вместо трибун? Шутки в сторону? Вот почему гибкие методы не работают - люди придерживаются более высоких правил, чем они использовали в старых методах, нагруженных процессом!
gbjbaanb
1
@gbjbaanb В конечном итоге это не имеет значения. Вы знаете, что мешает стоять, хотя? И если так, как вы пытаетесь предотвратить это? И это работает для вас?
Хулио
6

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

Кевин Д
источник
И вам нужен анализ, потому что история была без необходимых деталей? Или потому что код не был достаточно понятен и / или не документирован тестами?
съеживаться
1
Фактически, истории были невероятно высокого уровня до того момента, когда владелец продукта (моя терминология меня здесь подводит) даже не знал, чего хочет.
Кевин Д.
У нас тоже был этот. С тех пор мы выполнили большую часть анализа перед началом спринта.
Карра
4

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

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

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

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

gbjbaanb
источник
1
+1 за "схватку как 2-недельный процесс водопада". К сожалению, это кажется очень распространенным явлением
DPD
4

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

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

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

Ондржей Миртес
источник
1
Это абсолютно несовместимо с любой методологией разработки. Вы никогда не можете сказать это в начале. Вы должны выполнить анализ + некоторую часть проекта, чтобы иметь возможность точно указать это, но анализ + проектирование может занять половину времени / бюджета проекта, и даже после этого вы можете потерпеть неудачу, потому что анализ - это не то, что клиент полностью понимает.
Ладислав Мрнка
Но это одна из больших проблем, когда вы переключаетесь на SCRUM. Люди настолько привыкли к этим вопросам и ответам, что большинство из них уже не осознают, что в большинстве случаев ответы в конечном итоге неверны. Если клиент приходит с грубым видением продукта, он спросит, how much will it cost?и они ожидают подробного ответа прямо сейчас. Мой ответ на эту проблему всегда звучит так: «Если вы точно знаете, чего хотите, в конце концов, вам не нужна гибкость. Просто запишите ее». Но мы все знаем, что этого не произойдет. ;-)
съеживаться
2

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

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

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

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

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

DPD
источник
Как вы это исправили? Или это была причина, которая провалила все внедрение SCRUM? Я подумал, что если команда получит больше опыта, то покерный спринт по планированию и оценке покажет недостающие требования на ранней стадии, и оценки станут лучше и лучше.
съеживаться
мы еще не исправили это. И мы все еще используем SCRUM. Разница лишь в том, что если мы скажем, что дополнительная работа - это слишком много, и TL согласится, мы можем оставить историю в стороне. Мы заканчиваем тем, что вкладываем больше часов.
DPD