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 - успешный спринт, Канбан - успешная задача.
● Деплоймент и демо задачи - когда она готова.
● Команда не должна оценивать время на выполнение
задачи.
● Не получается одно - берешь другое
12. Время Обязательны ограниченные по Ограниченные по времени итерации
итерации времени итерации. необязательны. Событийно-
(Lead Time) управляемые итерации вместо
ограниченных по времени.
Обязательств Команда обязуется выполнить Обязательства опциональны.
а конкретный объем работы за
эту итерацию.
Метрики Как основная метрика для Как основная метрика для
планирования и улучшения планирования и улучшения
процессов используется процессов используется время
производительность. выполнения задачи.
Кросс- Кросс-функциональные Кросс-функциональные команды,
функциональ команды обязательны опциональны. Допустимы
ность
узкопрофильные команды.
Размеры задач Задачи должны быть Нет каких-либо определенных
разбиты на более мелкие размеров задач.
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.
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.
24. Заключение
● В данной магистерской диссертации был проведен
сравнительный анализ двух подходов к разработке
ПО — Scrum и Kanban, выявлены их достоинства и
недостатки.
● После исследования модели разработки ПО
по методологии Scrum на примере компании Envion
Software, были выявлены сложности и причины
недостаточной эффективности процесса
и предложено решение по повышению
эффективности процесса разработки, которое
заключается в применении Lean идеологии
и переходе на Kanban.
● Эффективность и целесообразность данного
● решения была оценена с помощью KPI показателей