Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Effectivness analysis of moving from Scrum to Kanban

1,402 views

Published on

  • Be the first to comment

  • Be the first to like this

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-идеологии ианализ эффективности разработкиПО при реорганизации процессаразработки Автор: Харченко Алена Игоревна

×