Коллеги, всем привет! В сегодняшней статье мне бы хотелось рассказать о нескольких наиболее «популярных» ошибках при переходе на Scrum, в результате которых члены команды разочаровываются в этом фреймворке и теряют веру в его эффективность.
Эти ошибки уже давно вошли в «золотой фонд» антипаттернов скрама, но совершаются они с завидной регулярностью, поэтому думаю, есть смысл рассмотреть их еще раз.
Способ №0. Внедрить Scrum там, где он вообще не нужен.
На практике часто бывает, что идея перехода на Scrum приходит «сверху» — кто-то из руководства компании хочет повысить эффективность разработки, узнает об Agile и Scrum, после чего начинается гибкая оптимизация всего.
В то же время качество гибкой трансформации часто определяется просто количеством работающих Scrum-команд. 
Но стоит ли использовать Scrum везде, где только можно? Scrum — это фреймворк для решения сложных задач, где много неопределенности — мы строим гипотезы, проверяем результат, адаптируемся и шаг за шагом движемся к цели, каждый раз получая обратную связь.
Этот метод хорошо подходит для разработки нового продукта или проекта, где ожидания в начале пути могут сильно отличаться от конечного результата, который действительно понадобится конечным пользователям.
Предположим, у вас нет продукта как такового, ценность которого вы постепенно увеличиваете, а есть просто некий поток разрозненных «хотел» от совершенно не связанных между собой стейкхолдеров, и ваша задача — быстро и эффективно закрыть эти «хочу».
.
Или предположим, что вы внедряете и развертываете стандартное решение, и это внедрение всегда состоит из одних и тех же шагов фиксированной продолжительности.
В принципе, при желании вы можете разбить такие «хотелки» и задачи на спринты, но сможете ли вы определить продуктовую цель и цель спринта, которые не будут выглядеть искусственными или «составленными из воздуха»? И как определить роль Владельца Продукта в этом процессе? И насколько велика будет польза самоорганизации команды в решении этих задач? Если ответ на эти вопросы «нет», то следующий вопрос, который следует задать: «Зачем вам нужен Scrum»? И если вы не найдете другого ответа, кроме «нам сделали предложение, от которого мы не можем отказаться», то стоит задуматься, нужно ли оно вам еще? Зачем «насиловать» людей чем-то, что не принесет пользы им и бизнесу? Вполне возможно, что вам будет достаточно просто оптимизировать управление потоком задач, а для этого достаточно настроить процесс Канбан.
Способ №1. Внедрить Scrum, не наделяя команду необходимыми полномочиями .
Допустим, вы взяли группу разработчиков, назначили их scrum-мастером и владельцем продукта, после чего торжественно объявили команде, что теперь они каждый день собираются у доски с стикерами и раз в две недели должны «сделать ретроспектива», планирование и уточнение бэклога продукции.
Достаточно ли этого, чтобы сказать, что вы запустили scrum-команду? 
Прежде чем ответить на этот вопрос, давайте посмотрим на него под другим углом.
Основой Scrum является Scrum-команда:
- Владелец продукта – отвечает за добавление ценности продукта и имеет право решать, какие изменения принесут наибольшую ценность.
- Разработчики — отвечают за создание инкремента продукта, соответствующего принятым критериям качества, при этом имеют полномочия выбирать путь достижения цели спринта и совместно с ЗП формировать эту цель.
Команда также обладает всеми навыками, необходимыми для решения поставленных задач.
- Скрам-мастер — имеет полномочия организовывать работу по Scrum в соответствии с принципами руководства Scrum.
- самостоятельно организовать свою работу таким образом, чтобы повысить эффективность и устранить препятствия в работе по результатам регулярных проверок и адаптаций,
- нести ответственность за последствия принятых решений и вносить коррективы, если принятые решения оказались неудачными.
Теперь рассмотрим следующую ситуацию:
- Владелец продукта — не может самостоятельно решить, что полезно для продукта, а в команде имеется большое количество задач от разных стейкхолдеров с «первым» приоритетом, которые нужно сделать «вчера».
- Разработчики — набор разработчиков, которые сами не имеют права ничего решать, делают не то, что выгодно, а то, что попросил начальник с «самым громким голосом» или «самыми большими погонами».
Причем все это тоже нужно было сделать «вчера», потому что так решил «самый большой» начальник.
- Скрам-мастер - «секретарь», который планирует кучу разных встреч, на которых люди будут говорить о вещах, которые они никогда не смогут сделать, и каждый участник встречи будет ждать, пока она закончится, потому что.
у него есть еще 5 задач, которые должно было быть сделано «вчера».
члены команды особо ничего не решают, а просто делают то, что им говорят, пытаясь «осчастливить» тех, кому пришла в голову идея перейти на Scrum. Насколько эффективна эта команда? Можно ли считать, что по Scrum это действительно работает? Ответ на первый вопрос – «Не знаю, но она точно могла бы лучше», на второй – «нет».
Но члены команды и ее лидеры будут думать, что у них есть Scrum (у них есть доска с наклейками), а Srcum не работает в «наших» реалиях.
Поэтому, прежде чем внедрять Scrum, вам нужно понять, готовы ли вы предоставить людям соответствующие полномочия и независимость (и, что немаловажно, готовы ли люди принять эти полномочия).
Если по каким-то причинам вы не готовы, то снова возникает вопрос: «Нужен ли вам ScrumЭ» Если ваша цель — просто сделать поток создания ценности прозрачным и эффективным, то, возможно, вам просто необходимо организовать правильный процесс Канбан.
Способ №2. Организуйте ежедневный отчет о статусе из ежедневного скрама на 60+ минут. В моей практике один из самых частых комментариев на тему негативного отношения к Скраму звучит так: «Как скучны эти ежедневные встречи, когда каждый день приходится по часу стоять у доски, вместо того, чтобы сделать что-то полезное».
Это знакомая картина? :)? 
Что это может означать? Ответ очевиден – такие встречи не приносят никакой практической пользы, и команде жаль потраченного времени.
В руководстве Scrum четко указано, что ежедневная встреча должна длиться 15 минут, и этого достаточно для достижения основных целей ежедневного Scrum — члены команды узнают, кто из них над чем работает, у кого какие проблемы и как.
команда продвигается к целям спринта.
И ничего более – все остальные вопросы решаются отдельно.
На практике такие встречи часто превращаются в то, что все говорят обо всем сразу, где в ходе встречи участники пытаются решить производственные вопросы, для эффективной проработки которых может потребоваться больше времени.
Часто в этих обсуждениях участвует не вся команда, а всего 2-3 человека, и что еще хуже, эти вопросы можно было решить до встречи.
В результате встреча затягивается и вопросы не решаются, потому что.
с другими людьми всё равно приходится встречаться отдельно, а участники уходят с встречи с ощущением потраченного времени.
Что может быть сделано:
- Однозначно договоритесь о том, какова цель Ежедневного Скрама и какие вопросы следует решить на этой встрече (в руководстве по Скраму четко указано, что это за вопросы).
- Если во время встречи возникает вопрос, который невозможно полностью решить за 2-3 минуты обсуждения (а в идеале – всего за минуту), то вынесите такой вопрос на «стоянку» после собрания, где только те, кого он непосредственно затрагивает. по вопросу приму участие в обсуждении.
- Если в ходе ежедневной схватки возникает вопрос, который на самом деле возник вчера, то «выделите» такие ситуации отдельно и прямо спросите команду, почему такие проблемы не решаются немедленно.
Возможно, причина в какой-то сложной проблеме (например, члены команды взаимодействуют друг с другом только в ежедневных Scrum).
- Предложите команде заранее подумать, о чем рассказывать на Daily Scrum. В то же время важно помнить, что Daily Scrum — это не история обо всем, что вы делал шаг за шагом, но о том, что вы делал в конце концов.
Как показывает практика, рассказ о конечном результате занимает меньше времени, чем рассказ о том, как вы к этому результату пришли.
- Если команду не устраивает продолжительность Daily Scrum, предложите ей подумать о том, как сделать такие встречи более эффективными, и взять на себя ответственность за реализацию этих идей.
Реальная история из жизни:
- Когда слова Agile и Scrum стали звучать из каждого «ИТ-утюга», в одной компании решили, что разработка большого и важного проекта обязательно должна вестись в ногу со временем, т.е.
по Scrum, потому что это «модно».
стильный и молодежный».
- Перед началом спринта команда оценивала объем работы, который можно выполнить за спринт, и на основе оценки формировала спринтовый бэклог.
- После этого пришел «большой начальник» (человек, кстати, хороший и умный) и сказал, что нам нужно «подтолкнуться» и взять на себя еще несколько задач в спринте помимо уже запланированных, потому что одна очень уважаемый человек пообещал другому, еще более уважаемому человеку сделать это еще в последнем спринте.
- Ситуация из пункта 3 могла повториться несколько раз за один спринт :)
Думаю, нетрудно догадаться, насколько эффективен был этот процесс и насколько команда была довольна таким подходом :) Кстати, когда обещания «уважаемым людям» не были выполнены, все свалилось на Scrum, с которым невозможно нормально работать.
в российских реалиях, т.е.
У нас «другой менталитет».
Какие выводы можно сделать из этой истории? Довольно просто:
- В Scrum-мире «здорового человека» Product Owner формулирует задачи на спринт исходя из Product-цели, а затем вместе с командой определяет, в какой форме и в каком объёме эти задачи можно реализовать в ходе спринта.
с учетом скорости команды.
- В ходе этого обсуждения команда определяет цели спринта и наиболее ценный инкремент продукта, на основе этого формируется бэклог спринта.
- Нет смысла пытаться делать вид, что команда может добиться за спринт больше, чем ее реальная скорость — в первую очередь это самообман, а также обман ожиданий всех заинтересованных сторон.
- По ходу спринта в бэклог спринта вносятся те и только те изменения, которые помогают достичь согласованных целей спринта.
- Недопустимо расширять объем работ, жертвуя качеством.
- Команда должна иметь полномочия для выполнения вышеуказанных шагов.
Владельцы продукта или стейкхолдеры не доверяют команде и считают, что «любой нормальный человек» постарается недооценить свои возможности, чтобы меньше напрягаться и не переутомляться.
Могут ли такие опасения иметь реальную основу? - конечно, более того.
Будет ли этот риск покрыт постоянным «раздуванием» отставания по спринту, чтобы загрузить команду в соответствии с ее «реальными» возможностями? - это не факт. Но, скорее всего, это создаст дополнительную нервозность и недоверие друг к другу и к Scrum как процессу.
Если есть риск того, что команда искусственно занижает свою скорость, то нет смысла закрывать ее, нарушая базовые принципы Scrum — в этом случае риск не уйдет, и Scrum не будет работать.
Что делать в этом случае – тема для отдельного разговора.
Вот и все.
На самом деле, количество анти-шаблонов Scrum гораздо больше; в этой статье я описал наиболее частые и критичные из них, которые наблюдал на практике.
Надеюсь, мысли и идеи, изложенные в этой статье, помогут вам их избежать.
Теги: #Управление разработкой #Управление проектами #agile #scrum
-
Файл Humans.txt От Google
19 Oct, 24 -
Программисты Демотиваторы
19 Oct, 24
