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