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