Как не разочароваться в Scrum?

Как не разочароваться в Scrum

Денис Тучин

Руководитель команды разработчиков

Интеллектуальный системы (i-sys.ru)

Кто я?

• С 9 лет начал кодить

• С 1998 занимаюсь web-разработкой

• С 2004 года работаю в коммерческих

проектах:

…

• С 2009 работаю в Agile проектах

• С 2009 года получил, как удачный, так и

неудачный опыт Scrum

• Кое-чему удалось научится

О чѐм расскажу:

• Когда стоит применять Scrum?

• Scrum-мастер:

– Сталин или Ганди?

– Scrum-мастер внутри команды и «резиновые» спринты

• Планирование:

– 100500 ошибок Planning Poker

– Планирование рисков: стоит ли говорить о них заказчику?

• Частые ошибки Daily Scrum Meeting

А стоит ли?

Когда стоит применять Scrum?

Scrum ради Scrum

Даже в учебных проектах

Негативные ассоциации

Когда стоит применять новую методологию?

Критерии

1. У вас есть проблемы

2. Методология/практика/процесс их решает

Когда стоит применять новую методологию?

Примеры

Меняются требования в процессе разработки

Agile

Феодальное владение кодом

Парное программирование и/или Code review

Когда хорош Scrum?

• Меняются требования, но не часто.

– Если часто, то укоротить итерацию или Kanban

• Стартап или новый продукт

– в каждый момент времени требований хватает примерно на

одну итерацию

• Доработка системы

– средние и крупные требования – не часто,

– критичные – редко

Самоорганизация!

Нет Команды – нет Scrum

True team

Команда — это небольшая группа людей, взаимодополняющих и

взаимозаменяющих друг друга в ходе достижения поставленных

целей. Организация команды строится на продуманном

позиционировании участников, имеющих общее видение ситуации и

стратегических целей и владеющих отработанными процедурами

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

создается для выполнения того или иного вида деятельности, до команды

высшего качества.

Ян Р.Катценбах и Дуглас К.Смит

Что делать, если…

• Сотрудники не любят:

– Собрания

– Общение с коллегами

– Совместное кодом

– Делать оценки трудозатрат

– …

• Воспитывать

• Выбирать другую методологию

• Выбирать других сотрудников

Если команда эффективно работает без Scrum

• НЕ ТРОГАЙТЕ!!!

• Иначе можно сделать хуже

• Если очень нужен Scrum,

применить его снаружи команды:

– Итерации

– Планирование Scrum мастер + Product owner

– Демонстрации

– Заказчик рядом

– И т.д.

Scrum-мастер

Scrum-мастер: Сталин или Ганди?

Диктатор:

«Всѐ будем делать по спецификации

Scrum!»

Советчик:

«Давайте так попробуем?..

Не хотите?..

Ну ладно»

Причины?

• У Scrum-мастера нет практического опыта

• Теоретические знания, тренинги и сертификации

не в счѐт

Кто же он – идеальный Scrum-мастер?

Золотой середины нет - есть серебряная пуля

Scrum-мастер должен досконально знать:

1. Цели проекта

2. Цели каждой практики выбранной методологии

Цели проекта всегда важнее методологии!

Практика должна приближать цель проекта!

Scrum-мастер внутри команды

• Само по себе это не плохо и не хорошо

– Есть много удачных примеров в российских компаниях

• Проблемы могут быть из-за неопытности SM

– «Резиновые» спринты

– Срыв сроков

– И т.д.

Scrum-мастер

• Создает атмосферу доверия,

• Участвует в митингах в качестве фасилитатора

• Устраняет препятствия

• Делает проблемы и открытые вопросы видимыми

• Отвечает за соблюдение практик и процесса в

команде

Начинающий Scrum-мастер внутри команды

• «Кодить не охота»

• «Daily scrum только отвлекает от работы»

• Фокус на отдельных задачах, а не на спринте в целом

• Использует служебное положение чтобы:

– Отменять митинги

– Замалчивать проблемы

и открытые вопросы

– Упразднять практики и процессы

– Демотивировать команду

Решения

• Постоянно напоминать себе «Ты – Scrum-мастер!»

– Стикеры

– Таймер с напоминалкой

– Выделить день посвящѐнный полностью Scrum-мастерингу

• Внешний Scrum-мастер

– На ХХ% на проекте

– Из-за совместительства может временами забывать про проект

• Руководитель проекта

– Больше всех заинтересован в успехе проекта

– Обычно умеет «держать руку на пульсе» даже для нескольких

проектов

Планирование спринта

100500 ошибок Planning Poker

Наиболее формализованная практика, но…

• По очереди высказываются оценки

• Оценивают Team Lead и спрашивает, все ли согласны.

– Иногда «переубеждает» авторитетом несогласных.

• Выбирают:

– Среднее значение по «больнице»

– Максимальное значение

– Минимальное

– Мода

Planning Poker: Просто и эффективно

Оценка ОДНОВРЕМЕННО!!!

• Идеально – карты

• Можно на пальцах

Planning Poker: Результаты голосования

• Одна оценка сильно больше остальных:

– Кто-то знает о большем числе подводных камней

– Либо он не знает, то что знают все остальные

• Одна оценка сильно меньше остальных:

– Кто-то знает как сделать это проще или уже сделал это

– Либо он не знает, то что знают все остальные

• Кто-то проголосовал «?»

– Не понял/не слышал задачу

Нужно: уровнять знания в команде и переголосовать

Planning Poker: Сколько можно?

• Голосовать пока все оценки не совпадут?

– Утомительно

– Будет подгонка

• Если расхождение маленькое, можно договориться

– Быстрее

– Более адекватная оценка

Планирование рисков

• Agile – предельная честность с заказчиком

• Честно говорить заказчику, сколько часов в итерации

на незапланированные работы

• Статистика вам поможет:

– по заказчику

– по команде

• Если остаются часы брать «верхнюю»

задачу из Product backlog

Daily Scrum

Ошибки Daily Scrum Meeting

• Отсутствие daily scrum как таковых

• Формальные daily scrum

• Привычка давать «втык» за лень или просрочку

• Превращение daily scrum в многочасовое заседание

Daily Scrum Meeting (DSM)

Этот митинг проходит каждое утро в начале дня. Он

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

чем занимается в проекте. Длительность этого митинга строго

ограничена и не должна превышать 15 минут. Цель митинга –

поделиться информацией. Он не предназначен для решения

проблем в проекте. Все требующие специального обсуждения

вопросы должны быть вынесены за пределы митинга

http://agileguru.ru/AgileWiki/Daily_Scrum_Meeting

Daily Scrum Meeting нужен…

• если другие коммуникации в команде пока слабы

• в случае распределѐнной команды

• если в команде происходит накопление нерешѐнных

проблем

Если не проводить…

• Кто-то уже 3 дня «вот-вот» решит проблему

• Кто-то увлекся разработкой фреймворка

• Кто-то просто ни как не раскачается

• И т.д.

Когда же можно обойтись

без ежедневного Scrum?

• В команде хорошо налажены коммуникации именно в

контексте проекта

• Команда стабильно из спринта в спринт укладывается в

сроки

• В распределѐнной команде:

– все члены команды ответственные и результат-ориентированные

– все члены команды – близкие друзья

– все члены команды должны проводить деловые или не деловые

встречи, что хотя бы раз 1 или 2 недели

– Возможно, есть другие условия, но я пока не сталкивался)

Формализм Daily Scrum

• Каждый отвечает на 3 этих вопроса

– Что сделано вчера?

– Что будет сделано сегодня?

– С какими затруднениями столкнулся, что помешало?

• Про затруднение говорят все неохотно

• Не слушают, что говорят другие

– Хорошо, если scrum-мастер слушает :)

Лекартсва

• Глобально: воспитывать командный дух

• Здесь и сейчас: модерировать DSM

– Спрашивать других членов команды, как решить эту проблему

– Назначать после Daily Scrum обсуждение проблем, теми, кто

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

– Предлагать опережающим график сотрудникам помочь

отстающим

– И т.д.

Самые очевидные и самые частые ошибки

• Волшебные пендюли

– Убивают Scrum

• Углубление в детали

– Оптимальнее назначать отдельные митинги с

заинтересованными сотрудниками

Подробнее можно узнать…

в рассылке «100 ошибок применения Scrum»

на сайте dream-project.ru

по Skype Denis.Tuchin

по почте [email protected]

Автор: Денис Тучин

Доклад: Как не разочароваться в Scrum