Каталог решений - Стыд и Скрам, часть вторая

Стыд и Скрам, часть вторая

Стыд и Скрам, часть вторая

В наличии

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

Категория:

Описание

Продолжение публикации: Стыд и скрам — Чему нас учит Scream Guide. 

За время, прошедшее с публикации на Инфостарте моей статьи “Стыд и Скрам”, хороший человек Владимир Меркушев не поленился и перевел Scream Guide-целиком. За что спасибо ему большое. Говорят, многие руководители проектов, читая это руководство, даже всплакнули — настолько больные темы. 

Сегодня я хочу поговорить про команду разработчиков и планирование спринта, как его описывает Scream Guide — опять же, под лозунгом "в каждой шутке есть доля шутки, а все остальное — правда…" Слева приведены цитаты из первоисточника (Scrum Guide), справа — из пародии (Scream Guide), а снизу — мои комментарии.

Команды Разработки обладают рядом характеристик:Команды Разработки обладают рядом характеристик:

• Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты. 

• Они кросс-функциональны: команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта. 

• Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика). Это правило не имеет исключений. 

• Команда Разработки несет коллективную ответственность за создание Инкремента Продукта. При этом отдельные члены Команды Разработки могут обладать различными специализированными навыками и экспертизой. 

 

  • Они называются «самоорганизующимися». Любой (даже уборщик) может рассказать команде разработчиков, как они должны делать свою работу;

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

  • Команды разработчиков называются «кросс-функциональными» и обладают практически всеми необходимыми навыками для создания «почти готового» продукта;

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

 

 

Если серьезно…

KPI проекта
 Во-первых, про игры с метриками — увы, часто больная тема, особенно в крупных компаниях. Могу только процитировать Максима Дорофеева: 
Для любой системы KPI существует такая стратегия B, что показатели KPI при следовании этой стратегии находятся в зеленой зоне, но при этом сам проект через **пу идет в неизвестность. 

 

Во-вторых, про "почти готово". Я думаю, что всем автоматизаторам знакома ситуация “почти готового” продукта, пребывающего в таком состоянии длительное время… У меня над столом даже висит один из моих любимых афоризмов: “Не так страшны первые 90% работы, как ее вторые 90%…”
По моему опыту, один из бонусов Agile — это фокус внимания именно на доделывании до конца. Потому что именно при выпуске в продакшн мы понимаем, будет ли тот или иной инструмент рабочим. Потому что гибкие методы — они в первую очередь про умение учиться на своих ошибках. И когда мы не видим законченный результат, не видим те проблемы и сложности, с которыми столкнулись реальные пользователи при практическом применении продукта — вот эта возможность учиться на ошибках как раз уходит…

 

Стадии реакции на проблему

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

  • Первая стадия — Отрицание. “Ничего не было, я в домике!!! Нет никакой проблемы, всё работает, это вам просто показалось”.
  • Вторая стадия — Обвинение. “Мне сказал (менеджер, тимлид, пользователь, аналитик — нужное подчеркнуть, недостающее вписать) так сделать, он и виноват, я-то тут причем?
  • Третья стадия — Оправдание. “Ну я же хотел как лучше!” (а по другому и быть не могло)
  • Четвертая стадия — Самообвинение. "Ну вот я такой фиговый разработчик. Увольте меня.”
  • Пятая стадия — Обязательства. “Обещаю больше никогда таких ошибок не совершать!”
  • И только шестая стадия — Ответственность. Как чувство собственности за результат, и искреннего желания исправить то, что произошло. 

(Вспомните притчу про Орлов, Устриц и Уток от Бодо Шефера — вот шестая стадия — это как раз и поведение Орла, который стремится достичь цели, а не Утки, которая только крякает).

Поэтому если проблему легко свалить на менеджера или еще кого-то — то стадия Ответственности заведомо не наступит, незачем, хватит Обвинения!
 

 

 

 

Отмена спринта 

Отмена спринта
  • Спринт может быть отменен досрочно. Право на отмену Спринта имеет только Владелец Продукта, хотя на данное решение могут повлиять заинтересованные лица, Команда Разработки или Скрам-мастер. 
  • Существует единственное основание для отмены Спринта — потеря актуальности Цели Спринта. Причиной этому могут быть смена направления работы компании, изменения рыночных условии или технологии. То есть Спринт может быть отменен, если он потерял смысл в контексте сложившихся обстоятельств. Но подобные отмены происходят крайне редко благодаря короткой длительности Спринтов. 
  • Отмена Спринта требует много усилий и ресурсов, так как предполагает переориентацию всех участников, чтобы начать новый Спринт и его Планирование. Отмены Спринта болезненны для Скрам-Команды, поэтому к ним прибегают крайне редко. 
  • Спринт может быть отменен до истечения временного интервала Спринта. Только менеджер имеет право отменить спринт, даже если команда и владелец продукта уже знают, что они не добьются успеха. Владелец продукта может быть козлом отпущения за это решение, принятое их менеджером или менеджером этого менеджера — или менеджером менеджера этого менеджера — ну, вы поняли идею. 
  • Спринт отменяется, если менеджер чувствует, что команда не выполняет его указания. Это может произойти, если разработчики начнут думать самостоятельно или если менеджер изменит свое мнение. В общем, Спринт должен быть отменен всякий раз, когда менеджер чувствует себя неуверенно. Из-за короткой продолжительности Спринтов, отмена является эффективным механизмом для создания неуверенности и беспорядка в команде.
  • Когда Спринт отменяется, все выполненные и «готовые» элементы бэклога отправляются в корзину. Частично «готовые» элементы возвращаются в случайном порядке в бэклог. Частично выполненную работу лучше оставить в ветках разработчиков и задокументировать в вики, чтобы возобновить её когда-нибудь.
  • Отмена Спринта — отличный способ держать команды занятыми, так как все собираются и начинают планирование следующего Спринта. Отмена спринта часто задевает команду за живое, что делает её отличным инструментом для снижения самооценки и доверия внутри команды.

Если серьезно…

 

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

 

Планирование СпринтаПланирование Спринта
  • Задачи, над которыми будет трудиться Команда Разработки во время Спринта, определяются на Планировании Спринта. План создается совместными усилиями всей Скрам-Команды. 
  • Планирование Спринта ограничено по времени. Для Спринта длительностью один месяц Планирование не должно занимать более 8 часов. Если Спринт короче, то и Планирование проводится быстрее. 
  • Скрам-мастер убеждается, что событие состоялось, а участники понимали его цель. Скрам-мастер обучает Скрам-Команду соблюдать временное ограничение. 
  • По результатам Планирования Спринта Скрам-команда решает: 
    • каким будет Инкремент в конце Спринта; 
    • как организовать работу, чтобы получить готовый Инкремент Продукта. 
  • План командной работы в течение Спринта создается на Планировании Спринта. Этот жесткий план создается заранее владельцем продукта или руководством, не привлекая команду, чтобы не отвлекать её от выполнения работы. Максимальное время для планирование Спринта длиною в месяц — 8 часов. Этого времени вполне достаточно, чтобы успокоить команду и убедить в реальности абсолютно нереального плана.

  • Задача Scream мастера гарантировать проведение Планирования, и убедиться что каждому будет назначено достаточно работы. Также он учит Scream команду не задавать слишком много вопросов при представлении работы.
  • Присутствие менеджера во время Планирования Спринта очень важно, чтобы гарантировать, что получены ответы на следующие критические вопросы:
    • Сколько заданий назначено каждому человеку?
    • Что займет сколько времени?
    • Все ли ресурсы полностью использованы?
    • Если дела пойдут неожиданно хорошо, какую дополнительную работу вы можете ещё сделать?
  • По мере необходимости менеджер прекращает бессмысленные дискуссии о сути задач бэклога и их технической реализации и переориентирует членов команды разработки на задачи, которые им необходимо взять в работу. Менеджер может передать эту ответственность Scream мастеру.
  • В конце планирования спринта Scream мастер должен заставить членов команды взять на себя обязательство выполнить все свои задачи, даже если все знают, что дополнительные задачи будут добавляться на протяжении всего Спринта.

Если серьезно…

В ходе онлайн “Базового курса для руководителей ИТ-проектов” который я веду сейчас на Инфостарте, мы собрали основные преимущества от привлечения команды к планированию. Получился вот такой список (дополняйте, у кого еще есть что сказать?) 

  • Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)
  • Уровень владения информации по проекту повышается у членов команды
  • Разные взгляды позволяют получить более объективную картину
  • Конечный Исполнитель должен взять на себя ответственность за результат и затраты — это достигается совместным планированием

В моей практике работы и консультирования самых разных компаний, довольно явным маркером того, что что-то в команде/организации идет не так являлся фокус внимания не на результат, а на занятость и использование ресурсов. Настоящий Scrum как раз призывает от этого уходить. Нам не важно, сколько времени мы затратили на “почти готовый” продукт — важно, какой результат мы получили!

 

Scream

 

 

Поделитесь вашим опытом! С какими проблемами сталкиваетесь на практике?
 

В статье цитирую перевод Владимира Меркушева Scream Guide. Как быть Agile и не меняться и текст Scrum Guide с официального сайта.

 

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

has been added to your cart:
Оформление заказа