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

Автор: Харченко Алена Игоревна