Effectivness analysis of moving from Scrum to Kanban

1,353 views
1,220 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,353
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Effectivness analysis of moving from Scrum to Kanban

  1. 1. Оценка целесообразностиприменения Lean-идеологиии анализ эффективностиразработки ПО приреорганизации процессаразработки Автор: Харченко Алена Игоревна
  2. 2. Актуальность● Правильная постановка процесса разработки ПО ------ > повышение производительности и минимизация затрат.● Agile технологии ---> более упрощенный и эффективный вариант - Lean● Недостаточная эффективность Scrum● Почти полное отсутствие информации в научных источниках
  3. 3. Цель и задачи магистерской диссертацииЦель работы:Проведение анализа процесса разработки программногообеспечения на примере копании «Envion Software» иреинжиниринг процесса при помощи идеологии LeanЗадачи: ● Исследование текущей модели разработки в компании Envion Software ● Выявление сложностей, возникших в текущей Scrum модели ● Решение по реинжинирингу процесса, с целью повышения его эффективности ● Внедрение Lean-идеологии и переход на Kanban ● Формирование KPI показателей перехода и экономическое обоснование повышения эффективности процесса
  4. 4. Обзор предметной области.Организация процесса разработки ПО ● Правильно выбранная модель ----> основа достижения бизнес-цели ● У каждого проекта должна быть своя модель процесса разработки. ● У каждой модели — свое время. ● Модель подстраивается под людей, а не люди под модель. ●
  5. 5. 7 потерь при разработке ПО1. Частично выполненная работа2. Избыточные функциональные возможности3. Повторное приобретение знания4. Передача работы5. Переключение между задачами6. Задержки7. Потери из-за дефектов ПО
  6. 6. Некоторые из причин провалов проектов посозданию ПО● Часто и неожиданно изменяющиеся требования заказчика● Централизованное принятие решений● Жесткое управление объёмом работ по проекту● Традиционный (линейный) подход к разработке
  7. 7. Agile и Scrum ● Минимизация рисков и гибкость ● Итерация - включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование, документирование.Scrum - наиболее распространенная методология Agile: ● 3 роли - Product Owner, Scrum Master, Team ● Product Backlog --> Sprint Backlog -->Daily Scrum ● Демо и ретроспективы
  8. 8. Недостатки Agile и Scrum● Большая вовлечённость пользователя в процесс разработки● Требования создаются минимально достаточными● Накладность "Частых поставок" (Frequent delivery)● Agile-подходы напряжённы по отношению к разработчикам● Более высокая стоимость разработки● Невозможно точно определить сроки окончания проекта● Плохо работает для распределенных команд● Большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов
  9. 9. Lean Software Development ● Бережливое производство — концепция Toyota для устранение всех видов потерь. ● С недавнего времени применяется в разработке ПО ● Цель Lean - 1/3 от времени, бюджета и дефектовПринципы: ● Исключение затрат ● Акцент на обучении ● Предельно отсроченное принятие решений ● Предельно быстрая доставка заказчику ● Мотивация команды ● Внедрение целостности
  10. 10. Одна из Lean-практик - Kanban.Канбан: “Кан” - видимый, визуальный + “бан” - карточкаили доска. ● Основная задача - уменьшать количество “выполняющейся в данный момент работы” (WIP). ● Это более “гибкая” методология, чем SCRUM. Она не подойдет всем командам и для всех проектов. ● Scrum - успешный спринт, Канбан - успешная задача. ● Деплоймент и демо задачи - когда она готова. ● Команда не должна оценивать время на выполнение задачи. ● Не получается одно - берешь другое
  11. 11. Одна из Lean-практик - Kanban.
  12. 12. Время Обязательны ограниченные по Ограниченные по времени итерацииитерации времени итерации. необязательны. Событийно-(Lead Time) управляемые итерации вместо ограниченных по времени.Обязательств Команда обязуется выполнить Обязательства опциональны.а конкретный объем работы за эту итерацию.Метрики Как основная метрика для Как основная метрика для планирования и улучшения планирования и улучшения процессов используется процессов используется время производительность. выполнения задачи.Кросс- Кросс-функциональные Кросс-функциональные команды,функциональ команды обязательны опциональны. Допустимыность узкопрофильные команды.Размеры задач Задачи должны быть Нет каких-либо определенных разбиты на более мелкие размеров задач.
  13. 13. Модель Scrum
  14. 14. Модель Scrum
  15. 15. Риски Scrum.● Сложности в достижении бизнес-цели● Технические риски● Риск уменьшения качества продукта● Риск сложности осуществления коммуникаций
  16. 16. KPI показатели текущей модели Scrum● Показатели хода разработки продукта● Статистические данные мониторинга проекта● Показатели качества● Временные показатели производительности● Показатели удовлетворенности и следования стандартам
  17. 17. Трудности, возникшие в текущей Scrum-модели● Языковой барьер и часовые пояса● Программисты перегружаются тестировщиками● Недостаточно опыта длянастройки Scrum● Отсутствие полной кросс функциональности● Ретроспектива зачастую вырождается в формальность или вообще не проводится.● Недостаточная вовлеченность отдела тестирования● Договоренность, работающая в нормальных условиях, в экстремальных ситуациях перестает соблюдаться. Текучесть кадров● Переобучение● Задержки по срокам
  18. 18. Внедрение Lean подхода.● Инструментом управления процесса - LeanKit Kanban вместо Jira● Совместная деятельность отдела тестирования и разработчиков распределена равномерно по всем 3 командам● Нет фиксированного Product Backlog, как в Scrum ---> самостоятельно модифицировать backlog по ходу Development time и брать требования к реализации, которая возможна в данный Lead Time● Время на тестирование уменьшается, а разработка увеличивается● Повышается количество реализуемых требований за Lead Time. Период разработки сокращается примерно в 1,4 раза.
  19. 19. Преимущества Lean Kit Kanban● Пробная версия на 5 пользователей - Free● Более простой и понятный API, чем у Jira● Экспорт данных из Jira, импорта в Bugzilla, и интеграция с SVN.● Хорошо реализована совместная работа, уведомления, статистика, диаграммы.● Отсутствие лишней функциональности● Самый существенный фактор — стоимость лицензии Lean Kit Kanban значительно ниже стоимости лицензии на Jira - $990 против $3300.
  20. 20. Модель Kanban
  21. 21. Lean Kit KanbanУправление процессом производится спомощью Kanban доски
  22. 22. KPI показатели перехода со Scrum на KanbanМинимизация Lead Time в Kanban 28,00%Повышение качества - % снижения неудачных сборок 20,00%Повышение скорости наращивания функциональности В 1,4 раза(Velocity)Изменение Development time за Cycle Time Увеличилось на 3 дняИзменение Testing time за Cycle Time Уменьшилось на 3 дняУдовлетворенность заказчиков Тенденция к повышениюУдовлетворенность непосредственных участников процесса Тенденция к повышениюПроцент снижения затрат на инструменты поддержки процесса 33,00%Процент снижения полной стоимости проекта примерно 10 %
  23. 23. Заключение● В данной магистерской диссертации был проведен сравнительный анализ двух подходов к разработке ПО — Scrum и Kanban, выявлены их достоинства и недостатки.● После исследования модели разработки ПО по методологии Scrum на примере компании Envion Software, были выявлены сложности и причины недостаточной эффективности процесса и предложено решение по повышению эффективности процесса разработки, которое заключается в применении Lean идеологии и переходе на Kanban.● Эффективность и целесообразность данного● решения была оценена с помощью KPI показателей
  24. 24. Оценка целесообразностиприменения Lean-идеологии ианализ эффективности разработкиПО при реорганизации процессаразработки Автор: Харченко Алена Игоревна

×