Как не разочароваться в Scrum?
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 899 views

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

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

Statistics

Views

Total Views
899
Views on SlideShare
899
Embed Views
0

Actions

Likes
0
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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