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

1. Как не разочароваться в Scrum
Денис Тучин
Руководитель команды разработчиков
Интеллектуальный системы (i-sys.ru)

2. Кто я?
• С 9 лет начал кодить
• С 1998 занимаюсь web-разработкой
• С 2004 года работаю в коммерческих
проектах:
…
• С 2009 работаю в Agile проектах
• С 2009 года получил, как удачный, так и
неудачный опыт Scrum
• Кое-чему удалось научится 

3. О чѐм расскажу:
• Когда стоит применять Scrum?
• Scrum-мастер:
– Сталин или Ганди?
– Scrum-мастер внутри команды и «резиновые» спринты
• Планирование:
– 100500 ошибок Planning Poker
– Планирование рисков: стоит ли говорить о них заказчику?
• Частые ошибки Daily Scrum Meeting

4. А стоит ли?

5. Когда стоит применять Scrum?
Scrum ради Scrum
Даже в учебных проектах
Негативные ассоциации

6. Когда стоит применять новую методологию?
Критерии
1. У вас есть проблемы
2. Методология/практика/процесс их решает

7. Когда стоит применять новую методологию?
Примеры
Меняются требования в процессе разработки
Agile
Феодальное владение кодом
Парное программирование и/или Code review

8. Когда хорош Scrum?
• Меняются требования, но не часто.
– Если часто, то укоротить итерацию или Kanban
• Стартап или новый продукт
– в каждый момент времени требований хватает примерно на
одну итерацию
• Доработка системы
– средние и крупные требования – не часто,
– критичные – редко

9. Самоорганизация!
Нет Команды – нет Scrum

10. True team
Команда — это небольшая группа людей, взаимодополняющих и
взаимозаменяющих друг друга в ходе достижения поставленных
целей. Организация команды строится на продуманном
позиционировании участников, имеющих общее видение ситуации и
стратегических целей и владеющих отработанными процедурами
взаимодействия. Команда проходит эволюцию от рабочей группы, которая
создается для выполнения того или иного вида деятельности, до команды
высшего качества.
Ян Р.Катценбах и Дуглас К.Смит

11. Что делать, если…
• Сотрудники не любят:
– Собрания
– Общение с коллегами
– Совместное кодом
– Делать оценки трудозатрат
– …
• Воспитывать
• Выбирать другую методологию
• Выбирать других сотрудников

12. Если команда эффективно работает без Scrum
• НЕ ТРОГАЙТЕ!!!
• Иначе можно сделать хуже
• Если очень нужен Scrum,
применить его снаружи команды:
– Итерации
– Планирование Scrum мастер + Product owner
– Демонстрации
– Заказчик рядом
– И т.д.

13. Scrum-мастер

14. Scrum-мастер: Сталин или Ганди?
Диктатор:
«Всѐ будем делать по спецификации
Scrum!»
Советчик:
«Давайте так попробуем?..
Не хотите?..
Ну ладно»

15. Причины?
• У Scrum-мастера нет практического опыта
• Теоретические знания, тренинги и сертификации
не в счѐт

16. Кто же он – идеальный Scrum-мастер?
Золотой середины нет - есть серебряная пуля 
Scrum-мастер должен досконально знать:
1. Цели проекта
2. Цели каждой практики выбранной методологии
Цели проекта всегда важнее методологии!
Практика должна приближать цель проекта!

17. Scrum-мастер внутри команды
• Само по себе это не плохо и не хорошо
– Есть много удачных примеров в российских компаниях
• Проблемы могут быть из-за неопытности SM
– «Резиновые» спринты
– Срыв сроков
– И т.д.

18. Scrum-мастер
• Создает атмосферу доверия,
• Участвует в митингах в качестве фасилитатора
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в
команде

19. Начинающий Scrum-мастер внутри команды
• «Кодить не охота»
• «Daily scrum только отвлекает от работы»
• Фокус на отдельных задачах, а не на спринте в целом
• Использует служебное положение чтобы:
– Отменять митинги
– Замалчивать проблемы
и открытые вопросы
– Упразднять практики и процессы
– Демотивировать команду

20. Решения
• Постоянно напоминать себе «Ты – Scrum-мастер!»
– Стикеры
– Таймер с напоминалкой
– Выделить день посвящѐнный полностью Scrum-мастерингу
• Внешний Scrum-мастер
– На ХХ% на проекте
– Из-за совместительства может временами забывать про проект
• Руководитель проекта
– Больше всех заинтересован в успехе проекта
– Обычно умеет «держать руку на пульсе» даже для нескольких
проектов

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

22. 100500 ошибок Planning Poker
Наиболее формализованная практика, но…
• По очереди высказываются оценки
• Оценивают Team Lead и спрашивает, все ли согласны.
– Иногда «переубеждает» авторитетом несогласных.
• Выбирают:
– Среднее значение по «больнице»
– Максимальное значение
– Минимальное
– Мода

23. Planning Poker: Просто и эффективно
Оценка ОДНОВРЕМЕННО!!!
• Идеально – карты
• Можно на пальцах

24. Planning Poker: Результаты голосования
• Одна оценка сильно больше остальных:
– Кто-то знает о большем числе подводных камней
– Либо он не знает, то что знают все остальные
• Одна оценка сильно меньше остальных:
– Кто-то знает как сделать это проще или уже сделал это
– Либо он не знает, то что знают все остальные 
• Кто-то проголосовал «?»
– Не понял/не слышал задачу
Нужно: уровнять знания в команде и переголосовать

25. Planning Poker: Сколько можно?
• Голосовать пока все оценки не совпадут?
– Утомительно
– Будет подгонка
• Если расхождение маленькое, можно договориться
– Быстрее
– Более адекватная оценка

26. Планирование рисков
• Agile – предельная честность с заказчиком
• Честно говорить заказчику, сколько часов в итерации
на незапланированные работы
• Статистика вам поможет:
– по заказчику
– по команде
• Если остаются часы брать «верхнюю»
задачу из Product backlog

27. Daily Scrum

28. Ошибки Daily Scrum Meeting
• Отсутствие daily scrum как таковых
• Формальные daily scrum
• Привычка давать «втык» за лень или просрочку
• Превращение daily scrum в многочасовое заседание

29. Daily Scrum Meeting (DSM)
Этот митинг проходит каждое утро в начале дня. Он
предназначен для того, чтобы все члены команды знали, кто и
чем занимается в проекте. Длительность этого митинга строго
ограничена и не должна превышать 15 минут. Цель митинга –
поделиться информацией. Он не предназначен для решения
проблем в проекте. Все требующие специального обсуждения
вопросы должны быть вынесены за пределы митинга
http://agileguru.ru/AgileWiki/Daily_Scrum_Meeting

30. Daily Scrum Meeting нужен…
• если другие коммуникации в команде пока слабы
• в случае распределѐнной команды
• если в команде происходит накопление нерешѐнных
проблем

31. Если не проводить…
• Кто-то уже 3 дня «вот-вот» решит проблему
• Кто-то увлекся разработкой фреймворка
• Кто-то просто ни как не раскачается
• И т.д.

32. Когда же можно обойтись
без ежедневного Scrum?
• В команде хорошо налажены коммуникации именно в
контексте проекта
• Команда стабильно из спринта в спринт укладывается в
сроки
• В распределѐнной команде:
– все члены команды ответственные и результат-ориентированные
– все члены команды – близкие друзья
– все члены команды должны проводить деловые или не деловые
встречи, что хотя бы раз 1 или 2 недели
– Возможно, есть другие условия, но я пока не сталкивался)

33. Формализм Daily Scrum
• Каждый отвечает на 3 этих вопроса
– Что сделано вчера?
– Что будет сделано сегодня?
– С какими затруднениями столкнулся, что помешало?
• Про затруднение говорят все неохотно
• Не слушают, что говорят другие
– Хорошо, если scrum-мастер слушает :)

34. Лекартсва
• Глобально: воспитывать командный дух
• Здесь и сейчас: модерировать DSM
– Спрашивать других членов команды, как решить эту проблему
– Назначать после Daily Scrum обсуждение проблем, теми, кто
может помочь решении (не обязательно всей командой).
– Предлагать опережающим график сотрудникам помочь
отстающим
– И т.д.

35. Самые очевидные и самые частые ошибки
• Волшебные пендюли
– Убивают Scrum
• Углубление в детали
– Оптимальнее назначать отдельные митинги с
заинтересованными сотрудниками

36. Подробнее можно узнать…
в рассылке «100 ошибок применения Scrum»
на сайте dream-project.ru
по Skype Denis.Tuchin
по почте info@dream-project.ru
Автор: Денис Тучин
Доклад: Как не разочароваться в Scrum