Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•
•
Denis Tuchin
Denis Tuchin

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

1 of 36
Download to read offline
Как не разочароваться в 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 по почте info@dream-project.ru Автор: Денис Тучин Доклад: Как не разочароваться в Scrum

More Related Content

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

  • 1. Как не разочароваться в Scrum Денис Тучин Руководитель команды разработчиков Интеллектуальный системы (i-sys.ru)
  • 2. Кто я? • С 9 лет начал кодить • С 1998 занимаюсь web-разработкой • С 2004 года работаю в коммерческих проектах: … • С 2009 работаю в Agile проектах • С 2009 года получил, как удачный, так и неудачный опыт Scrum • Кое-чему удалось научится 
  • 3. О чѐм расскажу: • Когда стоит применять Scrum? • Scrum-мастер: – Сталин или Ганди? – Scrum-мастер внутри команды и «резиновые» спринты • Планирование: – 100500 ошибок Planning Poker – Планирование рисков: стоит ли говорить о них заказчику? • Частые ошибки Daily Scrum Meeting
  • 5. Когда стоит применять Scrum? Scrum ради Scrum Даже в учебных проектах Негативные ассоциации
  • 6. Когда стоит применять новую методологию? Критерии 1. У вас есть проблемы 2. Методология/практика/процесс их решает
  • 7. Когда стоит применять новую методологию? Примеры Меняются требования в процессе разработки Agile Феодальное владение кодом Парное программирование и/или Code review
  • 8. Когда хорош Scrum? • Меняются требования, но не часто. – Если часто, то укоротить итерацию или Kanban • Стартап или новый продукт – в каждый момент времени требований хватает примерно на одну итерацию • Доработка системы – средние и крупные требования – не часто, – критичные – редко
  • 10. True team Команда — это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга в ходе достижения поставленных целей. Организация команды строится на продуманном позиционировании участников, имеющих общее видение ситуации и стратегических целей и владеющих отработанными процедурами взаимодействия. Команда проходит эволюцию от рабочей группы, которая создается для выполнения того или иного вида деятельности, до команды высшего качества. Ян Р.Катценбах и Дуглас К.Смит
  • 11. Что делать, если… • Сотрудники не любят: – Собрания – Общение с коллегами – Совместное кодом – Делать оценки трудозатрат – … • Воспитывать • Выбирать другую методологию • Выбирать других сотрудников
  • 12. Если команда эффективно работает без Scrum • НЕ ТРОГАЙТЕ!!! • Иначе можно сделать хуже • Если очень нужен Scrum, применить его снаружи команды: – Итерации – Планирование Scrum мастер + Product owner – Демонстрации – Заказчик рядом – И т.д.
  • 14. Scrum-мастер: Сталин или Ганди? Диктатор: «Всѐ будем делать по спецификации Scrum!» Советчик: «Давайте так попробуем?.. Не хотите?.. Ну ладно»
  • 15. Причины? • У Scrum-мастера нет практического опыта • Теоретические знания, тренинги и сертификации не в счѐт
  • 16. Кто же он – идеальный Scrum-мастер? Золотой середины нет - есть серебряная пуля  Scrum-мастер должен досконально знать: 1. Цели проекта 2. Цели каждой практики выбранной методологии Цели проекта всегда важнее методологии! Практика должна приближать цель проекта!
  • 17. Scrum-мастер внутри команды • Само по себе это не плохо и не хорошо – Есть много удачных примеров в российских компаниях • Проблемы могут быть из-за неопытности SM – «Резиновые» спринты – Срыв сроков – И т.д.
  • 18. Scrum-мастер • Создает атмосферу доверия, • Участвует в митингах в качестве фасилитатора • Устраняет препятствия • Делает проблемы и открытые вопросы видимыми • Отвечает за соблюдение практик и процесса в команде
  • 19. Начинающий Scrum-мастер внутри команды • «Кодить не охота» • «Daily scrum только отвлекает от работы» • Фокус на отдельных задачах, а не на спринте в целом • Использует служебное положение чтобы: – Отменять митинги – Замалчивать проблемы и открытые вопросы – Упразднять практики и процессы – Демотивировать команду
  • 20. Решения • Постоянно напоминать себе «Ты – Scrum-мастер!» – Стикеры – Таймер с напоминалкой – Выделить день посвящѐнный полностью Scrum-мастерингу • Внешний Scrum-мастер – На ХХ% на проекте – Из-за совместительства может временами забывать про проект • Руководитель проекта – Больше всех заинтересован в успехе проекта – Обычно умеет «держать руку на пульсе» даже для нескольких проектов
  • 22. 100500 ошибок Planning Poker Наиболее формализованная практика, но… • По очереди высказываются оценки • Оценивают Team Lead и спрашивает, все ли согласны. – Иногда «переубеждает» авторитетом несогласных. • Выбирают: – Среднее значение по «больнице» – Максимальное значение – Минимальное – Мода
  • 23. Planning Poker: Просто и эффективно Оценка ОДНОВРЕМЕННО!!! • Идеально – карты • Можно на пальцах
  • 24. Planning Poker: Результаты голосования • Одна оценка сильно больше остальных: – Кто-то знает о большем числе подводных камней – Либо он не знает, то что знают все остальные • Одна оценка сильно меньше остальных: – Кто-то знает как сделать это проще или уже сделал это – Либо он не знает, то что знают все остальные  • Кто-то проголосовал «?» – Не понял/не слышал задачу Нужно: уровнять знания в команде и переголосовать
  • 25. Planning Poker: Сколько можно? • Голосовать пока все оценки не совпадут? – Утомительно – Будет подгонка • Если расхождение маленькое, можно договориться – Быстрее – Более адекватная оценка
  • 26. Планирование рисков • Agile – предельная честность с заказчиком • Честно говорить заказчику, сколько часов в итерации на незапланированные работы • Статистика вам поможет: – по заказчику – по команде • Если остаются часы брать «верхнюю» задачу из Product backlog
  • 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