Сравнительное исследование результатов применения Scrum- и Канбан-подходов на основе кейс-стади и моделирования

2014 год обещает быть насыщенным интересными тренингами и мастер-классами от учебного центра Luxoft Training. В первом квартале нового года Россию посетит с мастер-классом Микеле Маркезе профессор по Инженерии разработки ПО в Университете Кальяри, Италия.

Микеле Маркезе одним из первых занялся исследованиями в области объектно-ориентированной разработки ПО с использованием гибких методологий, в частности экстремального программирования. Сегодня он трудится над разработкой бережливых и гибких методологий разработки ПО (в частности над подходом Lean-Канбан) совместно с Дэвидом Андерсоном – «отцом» Канбан-методологии в инженерии ПО.
Предлагаем вам познакомиться с одной из статей, где Маркезе выступает соавтором, посвященной результатам применения Scrum- и Канбан-подходов на основе кейс-стади и моделирования.

Сравнительное исследование результатов применения Scrum- и Канбан-подходов на основе кейс-стади и моделирования

Авторы: David Anderson, Giulio Concas, Maria Ilaria Lunesu, Michele Marchesi и Hongyu Zhang

В статье проводится анализ перехода с традиционного подхода, основанного на индивидуальном процессе разработки SEI, к подходу бережливой разработки ПО, известному как Limited WIP. Данные, полученные в ходе анализа настоящего кейс-стади, используются для оценки пригодности разработанного нами симулятора процесса разработки, а также в качестве входных данных для моделирования Scrum-процесса с целью проверки возможности использования Scrum-подхода.

В кейс-стади рассматривается группа технического обслуживания (CMM level 5) компании Microsoft, базирующаяся в Индии и отвечающая за небольшие апгрейды и устранение производственных багов в 80 ИТ-приложениях, используемых персоналом Microsoft по всему миру. Это был первый случай применения подхода Limited WIP с использованием виртуальной системы Канбан. Успех нового процесса в отношении сниженных сроков поставки и более высокого уровня удовлетворения заказчика стал одним из основных факторов, разбудивших интерес к такому Канбан-подходу в инженерии ПО.

Группа технического обслуживания состояла из двух частей: группа разработки и команда тестирования, по три человека в каждой. Команды работали 12 месяцев в году, в среднем 22 дня в месяц. Запросы на обслуживание приходили вразброс, в среднем по 20-25 запросов в месяц. Каждый запрос проходил стадию оценки, решение «годен-негоден», стадию внесения в журнал задач, стадии разработки и тестирования. Несмотря на квалификацию команд, этот процесс не всегда проходил гладко. Количество выполненных запросов составляло 5-7 в месяц, а рост задолженностей происходил с интенсивностью 6 запросов в месяц. Когда в октябре 2004 г. команда внедрила виртуальную систему Канбан, в журнале невыполненных запросов было 80 запросов, и их число продолжало расти. Среднее время выполнения запросов с момента их получения составляло от 125 до 155 дней, что в корне не устраивало заинтересованных лиц.

Для решения проблем, связанных с производительностью команды, использовался типичный подход бережливой разработки (Lean). Вначале была четко обозначена политика процесса путем картирования потока создания ценностей с целью выяснить, на каких стадиях происходила потеря ценности. Было установлено, что основные потери происходили на стадии оценки, которая занимала около 33 процентов от общего времени. Помимо всего прочего, постоянные прерывания, необходимые для проведения оценок с более высоким приоритетом, тормозили решение проблем, поскольку отнимали время у разработчиков и тестировщиков.

На основе этого анализа был выработан новый процесс, способный устранить эти потери. Первым шагом стало сокращение работ, одновременно находящихся в процессе выполнения, и добавление новых задач из очереди на входе только по завершении текущей задачи. Число запросов, находящихся в разработке, было ограничено 8, так же как и число задач, находящихся в тестировании. В это число входит очередь на входе в разработку и тестирование и запросы, находящиеся в работе. Затем была полностью упразднена процедура оценки запросов. Взамен, владельцам бизнеса была предоставлена возможность встречаться раз в неделю и выбирать запросы для включения в очередь запросов на входе в разработку. Также им давались «гарантии» поставки решения в течение 25 дней, начиная от постановки в очередь на разработку.

Вкратце новый процесс заключался в следующем:
• Все входящие запросы помещались в журнал запросов без предварительного оценивания.
• Каждую неделю владельцы бизнеса решали, какой запрос включить в очередь на разработку.
• Число обрабатываемых запросов было ограничено, как в разработке, так и в тестировании.
• Разработчики брали запросы в работу из очереди на входе и фокусировались лишь на одном запросе или очень небольшом количестве запросов. Выполненные запросы переводились в статус «Выполнено».
• Тестировщики включали запросы со статусом «Выполнено» в свою очередь на входе (соблюдая лимиты) и работали с ними, фокусируясь на одном запросе или очень небольшом количестве запросов. Запросы, прошедшие тестирование, немедленно передавались заказчикам.

Данный подход помог значительно повысить продуктивность команд, существенно снизив время выполнения запросов с момента их приемки в работу до 25 или менее дней в 98% случаев. Необходимо отметить, что обязательства по выполнению работы в срок давались только после перевода запроса из журнала запросов в очередь на входе. Следующие улучшения стали результатом наблюдения, что большую часть работ выполняли разработчики, в то время как тестировщики были загружены лишь частично, в результате чего рабочая сила использовалась нерационально. Было решено переместить одного тестировщика в команду разработки и повысить количество одновременно выполняемых задач до 9, что повысило производительность. Команда смогла очистить журнал невыполненных запросов и снизить средний цикл поставки до 14 дней.
Для моделирования процессов сопровождения программного обеспечения мы использовали подход, который может быть описан как управляемый событиями, или агентский. Действие системы представлено как хронологическая последовательность событий. Каждое событие наступает в какой-то момент времени и отмечает собой изменение в состоянии системы. Агентским этот подход является потому что моделирует разработчиков как автономных агентов. Базовыми сущностями предложенной модели, общими для всех моделируемых процессов, являются запросы, выполняемые работы и члены команд.

Используя симулятор, мы сумели смоделировать начальный процесс, процесс Lean-Kanban и Scrum-процесс. Для моделирования Scrum-процесса потребовалось ввести в симулятор понятие итерации. Это было выполнено с использованием события НачалоИтерации, которое происходит в начале дня начала итерации.

Поскольку Scrum-команда обладает способностью к самоорганизации и поскольку основную проблему в потоке работ представляет кодирование, Scrum-команде пришлось организоваться таким образом, чтобы справится с данной ситуацией. В Scrum-модели мы позволили одному тестировщику играть роль разработчика, создавая код. Таким образом, удалось устранить проблемы, связанные с написанием кода, и ускорить рабочий процесс.

Мы смоделировали все три представленные модели, используя данные, имитирующие запросы на обслуживание, поданные в описанную выше команду Microsoft. Нами было сгенерировано два набора запросов, покрывающих временной период продолжительностью четыре года каждый (1056 дней, 22 дня в месяц). Распределение усилий, требуемых для выполнения запросов, является нормальным: 8,5 дней в среднем со стандартным отклонением в 2,5 дня. Для каждого из трех изученных процессов мы выполнили ряд симуляций с одними входными данными. После нескольких прогонов с различными начальными числами, сгенерированными генератором случайных чисел, были получены довольно устойчивые результаты для каждого процесса и каждого массива входных данных.

Симулятор практически точно воспроизвел начальный процесс, в том числе и его неспособность поспевать за поступающими запросами, а также среднее время ответа на запрос, которое составляло порядка 150-160 дней – значения, очень схожие с реальными данными. В случае Канбан-процесса, смоделированная производительность значительно увеличилась, а среднее время ответа уменьшилось по сравнению с начальной ситуацией до среднего значения в 25 дней. Результаты моделирования продемонстрировали существенные улучшения по сравнению с начальным процессом, но значительно меньшие результаты, чем те, что были получены в реальной практике, где производительность оказалась на 50% выше, чем в смоделированной ситуации. Данный факт требует дальнейшего изучения, поскольку на практике данное повышение производительности объяснялось повышением производительности инженеров в команде. Повышение личной производительности является параметром, который априори трудно использовать в моделировании, не рискуя быть обвиненным в предвзятости и желании представить процесс в выгодном свете.

Мы также смоделировали использование Scrum-процесса для работы с тем же массивом входных данных с итерациями продолжительностью 3 недели. В целом Scrum-процесс показал хорошие результаты, сравнимые с результатам Канбан-процесса. На практике Scrum не был реализован, поскольку в то время он противоречил политике Microsoft в области разработки ПО, которая строилась на Индивидуальном процессе разработки SEI.

Источник: Резюме статьи, опубликованной в Proceedings of XP2012 Conference ^[1]

Предстоящий мастер-класс Микеле Маркезе “Lean vs Kanban” посвящен методологиям разработки ПО. Подробная информация о мастер-классе ^[2] на сайте учебного центра.

Автор: Evgenia_s5

Источник ^[3]