Downloaded 40 times
Uploaded byVyacheslav Moskalenko
Kanban vs scrum_v3
Документ обсуждает выбор методологии разработки Agile, акцентируя внимание на сравнении Скрам и Канбан. Он описывает преимущества и недостатки каждой методологии, а также факторы, которые нужно учитывать при выборе, такие как размер команды и специфика бизнеса. Также упоминаются примеры успешного применения обеих методик в различных организациях.
Kanban vs scrum_v3
- 1. Масштабирование гибких процессов. Выбираем Скрам или Канбан? 26 September, 2014 www.luxoft.com
- 2. Момент принятия решенияо методологии Запуск новой инициативы (проект, программа) Увеличение потока требований Изменение характера работы www.luxoft.com Канбан Скрам
- 3. Наиболее частые проблемыклиентов Оплата ненужной функциональности Слишком высокая стоимость внесения даже небольших изменений Сложно понять текущий статус Задержка поставки необходимой функциональности www.luxoft.com Никогда 45% Редко 19% Иногда 16% Часто 13% Постоянно 7% Реальное использование запрошенной функциональности Источник: The CHAOS Manifesto, The Standish Group, 2011
- 4. Пример («Скептики») Клиент настаивал на внедрении методологии Скрам для команды L3-поддержки Быстрая реакция на проблемы в production-среде (максимум – несколько дней) Возможность делать небольшие изменения функциональности чаще основного цикла релиза Аргументы от заказчика: Есть итерации с прогнозируемым объемом Команда дает «комитмент» У Скрам-команды есть скорость (velocity), которую можно применять в долгосрочном планировании Последние отчеты Forrester Research показывают, что Скрам – самая применяемая Agile-методология Мы предложили Канбан (удачно!) www.luxoft.com
- 5. Еще примеры, или«как мы набирали опыт» Банкиры - Пришли в проект с «недо-Скрамом» - Попробовали Канбан - Разделили на несколько Скрам-команд Авиаторы - Скрам на 10 команд - Много специфических ролей и надстроек - Ожидаемый fail www.luxoft.com Айтишники - Начали с Канбана - Делаем проектные работы по Скраму Альфа и Гагарин - Успешный Скрам на 12 команд - Прозрачная структура и управление - Успешный проект с бюджетом $60M
- 6. Проблема выбора www.luxoft.com Неудачный выбор методологии планомерно ведет к Epic Fail Как правильно оценить что нам подойдет ?
- 7. www.luxoft.com Проблема Идея Деньги и ресурсы Неуверенность Предположения У трансформации есть заказчик РЕШЕНИЕ
- 8. Техника сравнения KanbanScrum www.luxoft.com Выбираем 10 самых важных оценочных критериев Для каждого оценочного критерия отмечаем преимущества одного или двух подходов с точки зрения контекста организации
- 9. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков www.luxoft.com
- 10. Новая инициатива www.luxoft.com Канбан Скрам Ускорение поставки фич (ориентируемся на поток задач) Увеличение функциональности, добавляемой в рамках итерации (ориентируемся на уменьшение неопределенности бэклога) Чего хочет бизнес? Как мы будем масштабироваться в рамках цели?
- 11. Канбан: Ограничение незавершеннойработы («Скептики») 4 7 3 5 Backlog Analysis Design & Dev QA UAT Done www.luxoft.com In Process Done In Process Done In Process Done In Process Done
- 12. Канбан: Детализация процесса(«Скептики») 3 2 5 3 3 2 Analysis Test Case Design & Dev Automation QA UAT www.luxoft.com In Process Done In Process Done In Process Done In Process Done Done
- 13. Использование burn-down диаграмм(«Альфа и Гагарин») 700 600 500 400 300 200 100 0 www.luxoft.com Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec В первом квартале стало очевидно, что скорости одной команды мало Во втором квартале добавили еще одну команду, чтобы увеличить скорость «сжигания» Владельцы продукта постепенно удаляли малозначимые фичи
- 14. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды www.luxoft.com
- 15. Команда из 15+человек Нет ограничений на размер www.luxoft.com Канбан Скрам Типичная команда – 5-9 человек Как будем делить команду? команды Как мы будем координировать две и более команды?
- 16. Скрам-доска у командыиз 15 человек («Банкиры») Много незавершенной работы в конце итерации Нереалистичность выполнение плана на итерацию Соотношение сделаноне сделано – 13:3 www.luxoft.com
- 17. Канбан-доска у командыиз 15-ти человек («Скептики») www.luxoft.com WIP LIMITS
- 18. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами www.luxoft.com
- 19. Бэклог из 50-тибизнес задач Накладываются WIP limits на количество незавершенной www.luxoft.com Канбан Скрам работы Фиксируется объем на итерацию в рамках поставленной цели Как часто мы будем изменять приоритеты? Как бизнес реагирует на скорость доставки?
- 20. Недоканбан (еще «Банкиры») 4 2 3 3 www.luxoft.com Done – Мы после QA сразу идем в Прод ? – Нет Backlog Analysis Design & Dev QA In Process Done In Process Done
- 21. Корпоративные правила (иеще «Банкиры») Backlog Analysis Design & Dev QA UAT Release www.luxoft.com In Process Done In Process Done In Process Done In Process Done DONE 2 3 3 15 15
- 22. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес- задач www.luxoft.com
- 23. От 4 часовк 4 месяцам работы скорости доставки ценности www.luxoft.com Канбан Скрам Фокус на постоянном улучшении метрик по В конце итерации должен получиться работающий инкремент продукта Какой средний размер бизнес задач? Есть ли возможность разделять крупные бизнес задачи?
- 24. Еще пример («Айтишники») www.luxoft.com Более 10 незавершенных задач, которые обозначены как крупные проекты Проекты декомпозируются на 20-30 подзадач Общая Канбан-доска не справляется с таким объемом задач
- 25. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com
- 26. Владельцы продукта иСкрам/Канбан-мастера www.luxoft.com Канбан Скрам Не имеет ограничений В каждой команде должен быть скрам-мастер и владелец продукта Есть ли ресурсы на масштабирование ролей ?
- 27. Владелец продукта надесять команд («Авиаторы») www.luxoft.com
- 28. Скрам Мастер начетыре команды («Банкиры») www.luxoft.com
- 29. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com 6. Масштабирование требований
- 30. Раздельные потоки требованийдля команд www.luxoft.com Канбан Скрам Хорошо, но не критично Скрам не запрещает двум командам работать над одним бэклогом, хотя это нежелательно Мы можем разделить требования по областям? Есть ли необходимость дробить на мелкие подзадачи?
- 31. Swimlanes в Канбане(«Скептики») www.luxoft.com
- 32. Два бэклога вСкрам («Альфа» и «Гагарин») www.luxoft.com В рамках одной инициативы или программы есть возможность разделить потоки требований Потоки требований могут независимо поставляться в производство
- 33. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com 6. Масштабирование требований 7. Распределенные команды
- 34. Команда разделена географически программных инструментов www.luxoft.com Канбан Скрам Просто настраивается с использованием Команде нужно вместе проводить обязательные встречи. В Скрам это – правило! Какие есть возможности инвестиций в телеприсутствие?
- 35. Пример электронной Канбан-доски(«Айтишники») www.luxoft.com
- 36. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com 6. Масштабирование требований 7. Распределенные команды 8. Организационные роли
- 37. Chief Architects, QAManagers, Project Managers... www.luxoft.com Канбан Скрам Все роли органично встраиваются в процесс Chief Architects, QA Managers, Project Managers – В скраме они Stakeholders Есть ли возможность встраивать Chief Architect в команду?
- 38. Скрам-надстройки (ох ужэти «Авиаторы»...) www.luxoft.com Core team Solution Architect Senior Business Analyst UX Lead Technical Architect Program Manager QA Manager Scrum team Scrum Master Business Analyst Team Scrum team Scrum Master Business Analyst Team Scrum team Scrum Master Business Analyst Team
- 39. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com 6. Масштабирование требований 7. Распределенные команды 8. Организационные роли 9. Снижение зависимости от уникальных навыков
- 40. Много уникальных специализаций Как мы будем решать зависимость от уникальных специалистов? www.luxoft.com Канбан Скрам Канбан метод не имеет четких предписаний к командной работе Скрам поощряет коллективную работу над сложными задачами
- 41. Факторы выбора 1.Главная метрика производительности для бизнес-заказчиков 2. Размер команды 3. Организация работы с задачами 4. Ожидаемый размер бизнес-задач 5. Командные роли www.luxoft.com 6. Масштабирование требований 7. Распределенные команды 8. Организационные роли 9. Снижение зависимости от уникальных навыков 10.Мартини по вкусу
- 42. Ваши варианты? организационнаяструктура www.luxoft.com скорость реакции бизнеса сложность логики самоорганизация разработка или поддержка зрелость команды
- 43. Что дальше? Пересматривайте выбранный подход регулярно Не ограничивайте себя уже сделанным выбором Канбан и Скрам могут трансформироваться или работать вместе Делайте выбор осознанно, на основании бизнес-целей www.luxoft.com Канбан Скрам
- 44. Контакты www.luxoft.com СЕРГЕЙПРОХОРЕНКО Руководитель Agile Practice, Luxoft sprokhorenko@luxoft.com ВЯЧЕСЛАВ МОСКАЛЕНКО Agile/Lean-коуч, Luxoft vmoskalenko@luxoft.com www.luxoft.com/blog/agile LuxAgile@luxoft.com
- 45.
Editor's Notes
- #3 В скрам команде специалисты более органично растут как мультиспециалисты. Скрам Мастер более проактивно влияет на команду. В Канбан процессе барьеры между специализациями могут сохраняться долгое время, если не все время.
- #4 Оплата ненужного функционала > 50% ресурсов уходит на разработку функциональности, практически не используемой пользователями Задержка поставки необходимого функционала Инженеры стремятся «изобретать велосипед» и решать интересные технические задачи вместо бизнес-проблем Слишком высокая стоимость внесения даже небольших изменений Длинные циклы изменений из-за сложной процедуры управления изменениями, отнимающей время и деньги Сложно понять текущий статус Заказчик перегружен отчетами, но не видит актуального состояния проекта с точки зрения работающей функциональности
- #5 Часто бывает, что клиент настаивает на определенной методологии, часто руководствуясь мифами и стереотипами. Наша задача предоставить более зрелые критерии оценки.
- #7 Очень часто заказчики приходят с желанием внедрять ту или иную методологию, до конца не понимая все риски. Не всегда идеи клиента совпадают с идеями консультантов, т.е. нами. Очень часто клиенты также противопоставляют скрам и канбан как противоположные методологии, хотя это не так. Мы будем делиться нашим опытом консультирования клиентов при выборе той или иной методологии как основы для дальнейшего развития и масштабирования.
- #8 Не всегда гибкие методологии приносят положительный результат. Например для внедрения скрам методологии практически всегда требуется подходящий контекст, который нужно формировать. Канбан менее требовательный в этом плане. Также как и внедрение Канбан метода может принести меньшую эффективность, если контекст располагает к внедрению Скрама. Как не попасть в ловушку желания побыстрее внедрить скрам или Канбан ? Ведь если выбор окажется неуместным – это приведет к серъезным финансовым и репутационным потерям. Также мы сталкиваемся с тем что выбор может быть удачным по отношению к текущей ситуации, но не всегда учитывает возможный рост, который ведет к масштабированию Какие есть объективные критерии оценки выбора той или иной методологии ?
- #9 Иногда желание трансформироваться зарождается снизу, как инициатива самих разработчиков. Мы будем рассматривать случаи когда у трансформации есть заказчик, у которого есть проблема, сформированная бизнесом, есть деньги и ресурсы, есть идея и неуверенность. Неуверенность ведет к привлечению консультантов, которые предлагают решение и коучей, которые помагают внедрению решения.
- #10 Для этого подойдет самая простая техника оценочного сравнения. Мы выбираем 10 самых важных оценочных критериев. Для каждого оценочного критерия синим пишем преимущества, красным недостатки двух сравниваемых методологий. Критерии могут иметь разный вес. Дальше мы будем использовать эту табличку для принятия решений
- #12 Мы можем выбрать скрам, но бизнес может просить доставлять быстрее, соглашаясь на меньше В Канбане мы будем уменьшать количество одновременно взятой работы, увеличивать пропускную способность и скорость прохождения задачи за счет добавления ресурсов в проблемные точки В Скраме при масштабировании мы будем увеличивать количество команд, одновременно взятых задач, укрупняя инкремент
- #13 Показываем как канбан доска помагает увидеть узкие горлышки в процессе. Команда из 12 человек Средняя скорость доставки 283 часа Количество элементов в процессе 15 Какие есть варианты для масштабирования ?
- #14 При масштабировании в Канбане можна применить алгоритм из Теории Ограничений Сначала перестраиваем (переподчиняем) систему для выравнивания потока Добавляем ресурс в узкое горлышко
- #15 Release burn-down показывает нам необходимость добавлять новые команды.
- #17 Примеры почему деление может быть нежелательным: Много уникальной экспертизы. 4-5 человек эксперты в своей области будут задействованы в двух командах. Они ключевые люди, а количество встреч умножается на 2. Команда из 6-х человек, где у каждого есть уникальная экспертиза Тип задач. Критические задачи, которые не терпят эксперементов или инновационная разработка ?
- #19 В Канбан системе нет надобности дробить бизнес-задачи на мелкие подзадачки. Мы знаем среднюю скорость доставки задачи по классу сервиса. На картинке их 2.
- #21 Примеры почему деление может быть нежелательным: Много уникальной экспертизы. 4-5 человек эксперты в своей области будут задействованы в двух командах. Они ключевые люди, а количество встреч умножается на 2. Команда из 6-х человек, где у каждого есть уникальная экспертиза Тип задач. Критические задачи, которые не терпят эксперементов или инновационная разработка ?
- #22 Бывают нарушения в построении какнбан систем. Например точкой доставки является не производство, а выдача на UAT. В этом случае наши возможности по улучшению цепочки доставки весьма ограничены. Мы не имеем возможности улучшать скорость доставки, так как локальная оптимизация может дать обратный эффект на всю цепочку.
- #23 Бывают случаи, когда корпоративные правила сильно влияют на организацию задач. Мы, внедряя канбан, не учли что выход в UAT раз в месяц строго по графику. Скрам позволяет месячные спринты.
- #25 Размер задач также вносит корректировки и является важным показателем. Канбан особенно хорош для задач небольшого размера Не всегда бизнес умеет декомпозировать свои задачи на более мелкие Не всегда технологически получается быстро реализовывать мелкие задачи Для сервисных задач, как запуск нового офиса невозможна в принципе вертикальная декомпозиция Скрам лучше подходит для работы с большими бизнес-задачами с возможностью технической декомпозиции на множество подзадач, ежедневного отслеживания статуса по графику сжигания. Есть возможность эмпирическим путем готовить контекст для сокращения размера бизнес-задач. Т.е. Скрамом мы готовим почву для Канбан процесса.
- #26 Канбан доска показывает что в течении недели на 10 задачах не наблюдается прогрес.
- #28 При добавлении новых скрам команд, нам нужно добавлять не только разработчиков, но также скрам-мастеров и продакт-оунеров.
- #29 Продак оунеру на 4-ре команды нужно посещать в 4-ре раза больше встречь
- #32 Также учитываем возможность масштабировать требования. Это более критично для Скрама.
- #36 Канбан лучше работает для распределенных команд
- #37 В канбане достаточно учитывать статус и работать с приоритизацией очереди. В распределенном скраме команда каждый день в телефонном режиме проверяют прогрес по отношению к цели спринта.
- #39 Скрам вносит революционные изменения в организационную структуру Канбан уважает текущие роли и обязанности
- #40 К чему приводит внедрение и масштабирование скрам процессов, если не менять организационную структуру
- #42 В скрам команде специалисты более органично растут как мультиспециалисты. Скрам Мастер более проактивно влияет на команду. В Канбан процессе барьеры между специализациями могут сохраняться долгое время, если не все время.
- #46 В скрам команде специалисты более органично растут как мультиспециалисты. Скрам Мастер более проактивно влияет на команду. В Канбан процессе барьеры между специализациями могут сохраняться долгое время, если не все время.