Лекция

Применение метода Системной динамики длямоделирования процессов Канбан, Скрам и

сравнение с Водопадной моделью

Первоисточник

РезюмеScrum является наиболее часто применяемой Agile методологией (AM), тогда как Lean-Kanban подход наиболее быстро набирает популярность среди AM. С другой стороны, традиционные водопадного типа подходы все еще используются в реальной жизни в программных проектах из-за понятного и простого планирования, которое однако почти никогда не соответствует проекту по его завершении. По-видимому необходимы дополнительные исследования и модели внутренней структуры и поведения в этих подходах, отражающие положительные и отрицательные обратные связи для стратегического понимая их особенностей и адаптации подходов. В этой работе мы проанализируем динамику поведения при применении Kanban и Scrum, в сравнении с традиционным процессом разработки программных систем, таким как Водопадная модель жизненного цикла. Мы используем модель Системной динамики, основанной на отношениях между системными переменными, для того чтобы выявить относительные достоинства изучаемых подходов. Моделирование осуществляется с использованием коммерческих средств. Предложенная модель визуализирует отношения между процессами разработки программных систем и может быть использована для изучения относительных достоинств и недостатков.

Методологии● Стандартная

Водопадная — упрощает предварительное планирование

● Гибкая– Scrum (https://www.scrumstudy.com/freeresources)– Kanban (

https://www.litres.ru/mayk-barrouz/kanban-metod-uluchshenie-sistemy-upravleniya/chitat-onlayn/ )

Цель проекта● Моделирование и сравнение методов

разработки:– Scrum– Kanban– Относительно Водопадной модели ЖЦ ИС

Метод Системной динамики● Анализ причинно-следственных связей и

циклов обратных связей в процессах:– Анализ требований– Итерации– Выпуск релизов

● Vensim

Модель● Парадигмы проекта:

1)фиксированные требования = заданное кол-во особенностей, требующих реализации в ИС

2)итерационная разработка постепенно увеличивающая кол-во реализованных особенностей.

Введение в Waterfall● Royce 1970 ● Это традиционная «тяжеловесная» методология,

выделяющая этапы:– Планирование/Анализ– Дизайн/Проектирование– Реализация/Программирование– Тестирование– Внедрение/Развертывание

Waterfall (прод.)● Завершение каждого этапа до начала следующего● Возврат возможен, но только к предыдущему этапу● Требуется стабильный набор требований,

создаваемый на стадии спецификации требований● Обратные связи с предыдущими стадиями трудно

реализовать

Гибкие методологии (AM = Agile Methodology)

● Agile Manifesto (https://agilemanifesto.org/iso/ru/principles.html )– Ранняя поставка релизов– Обеспечение конкурентного преимущества заказчику за счет постоянного изменения требований– 2 недели — 2 месяца новый релиз– Тесное взаимодействие постоянно– Профессионалы + условия работы – Работающий продукт = основной показатель успеха– Устойчивый процесс при взаимодействии всех стейкхолдеров– Постоянное совершенствование и повышение качества– Простота = бережливость (lean)– Самоорганизация– Повышение эффективности

Пример AM: Scrum● Takeuchi and Nonaka (1986)● Scrum — простой фреймвок реализации проекта, три роли:

– Владелец продукта– Scrum мастер– Команда

● Три церемонии– Планирование спринта (Planning Sprint)– Анализ спринта (Sprint Review)– Ежедневный митинг (Daily Scrum Meeting) 15 мин.

● Три артефакта:– Продукт (Product Backlog)– Спринт (Sprint Backlog)– Текущая карта (Burndown Chart)

Scrum: Product Owner

Продукт

Deliverable

Product

Deliverable

DeliverableВремя

Приоритеттребований

Scrum:- ежедневный- ежемесячный

Scrum:

Scrum:

Итерации

Ретроспективныймитинг

Ретроспективныймитинг

Scr

um M

aste

r

Team

Lean (бережливый) процесс● Taiichi Ohno of Toyota — lean methodology● Value Stream Analysis

– Value chain diagram = упрощенная BPMN модель с отметкой value factor для каждой задачи или waste

Kanban● Визуализация выполнения задач на доске в виде

карточек● Прогресс выполнения работ виден всем участникам● Work In Progress (WIP) отображает ограничения● Lean-Kanban минимизирует WIP — непрерывный

поток результатов работы предоставляется потребителю.

Фундаментальные принципы Канбан

ФП1: начните с того, что есть сейчас.

ФП2: договоритесь об эволюционном развитии.

ФП3: в качестве первого шага проявите уважение к существующим процессам, ролям, обязанностям и служебному положению.

ФП4: поощряйте проявления лидерства на всех уровнях организации – от отдельного работника до высшего руководства.

Основные практики КанбанОП1: визуализируйте.

ОП2: ограничивайте объем незавершенной работы (Work-in-Progress – WIP).

ОП3: управляйте потоком.

ОП4: сделайте правила работы явными.

ОП5: используйте циклы обратной связи.

ОП6: улучшайте совместно, эволюционируйте через экспериментирование (используя модели и научные методы).

9 ценностей Канбан1) прозрачность,

2) баланс,

3) сотрудничество,

4) клиент-ориентированность,

5) поток,

6) лидерство,

7) понимание,

8) согласие

9) уважение

Scrum vs Kanban

Scrum Kanban

Релиз В конце спринта В любое время

Итерации спринт нет

Изменения требований Нет внутри спринта Всегда

Модель Системной динамики

Три варианта● Scrum — работа делится на набор спринтов, каждый из

которых обрабатывает случайное число (15-20) требований из Гауссова распределения, эти задачи решаются за итерации фиксированной длительности в 2 недели.

● Lean-Kanban — работа делится на множество итераций, в которых удовлетворяются от 6 до 10 требований, выбранных из Гауссова распределения.

● Waterfall — в работе не делятся требования, а все 210 помещаются в «Selected Requirements»

Общие характеристики● Команда 10 чел.● Начальное кол-во требований = размер проекта = 210 требований ● Все фазы планирование, дизайн, кодирование, тестирование сливаются в одну фазу

«разработки» и определяются скоростью «requirements development rate»● В моделях Scrum и Waterfall фаза планирования учитывается введением задержки на

время затраченное на планирование● Средняя производительность 0.025 требований в час (1 требование за 5 дней)● Чем меньше ошибок, тем быстрее завершается проект● Скорость разработки «requirements development rate» определяет значение уровня

«Fraction Work Done» и зависит от производительности, количества разработчиков, и скорости выявления ошибок (см. след. слайд)

Формула для «requirements development rate»

requirements development rate = IF THEN ELSE (switch=1, IF THEN ELSE ( Selected Requirements > 0.05:AND:Selected Requirements productivity no developers,(productivity no developers) (1-error in Kanban), IF THEN ELSE ( Selected Requirements >0.05:AND:Selected Requirements < productivity no developers,Selected Requirements (1-error in Kanban), Selected Requirements)),IF THEN ELSE( Selected Requirements > 0.05:AND: Selected Requirements productivity no developers, (productivity no developers) (1-error in sprint Scrum or in Waterfall), IF THEN ELSE ( Selected Requirements > 0.05:AND: Selected Requirements < productivity no developers, Selected Requirements (1-error in sprint Scrum or in Waterfall), Selected Requirements)))

Причины Ошибок● Нечеткие требования заказчика● Проблемы дизайна программной системы● Ошибки при разработке

Приемный тест● «Acceptance testing» представляет обратную

связь с заказчиком/пользователем.● Моделирует еще одну задержку процесса, т. к.

если тест не прошел, то работа отправляется на переделку «Rework»

● При успехе требования перемещаются в уровень Live

Исходные параметрыWaterfall Scrum Lean-Kanban

Кол-во особенностей в Scrum

- Integer[Random Normal (15 , 21)]

-

Кол-во выбранных особенностей в Kanban

- - Integer[Random Normal (6 , 10)]

Задержка в Scrum - 2 часа -

Задержка в Waterfall 120 часов - -

Задержка в собрании по планированию спринта

- Integer[Random Normal (4 , 8)]

-

Задержка в ретроспективном собрании

- 1 час -

Ошибки при разработке Random Normal (0.0071, 0.0095) Random Normal (0.0071, 0.0095) Random Normal (0.0071, 0.0095)

Проблемы дизайна - Random Normal [0.001, 0.0014] Random Normal [0.001, 0.0014]

Влияние неопределенности требований

- Random Normal (0.0047, 0.0071) Random Normal (0.0047, 0.0071)

Причинно-следственная диаграмма для error rate

Причинно-следственная диаграмма для error rate

Три типа ошибок● Ошибки вследствие неопределенности

требований заказчика● Ошибки проектирования/дизайна● Ошибки при разработке

Замечание: в Канбан все три ошибки учтены в requirements development rate.

А другие две — только в конце итерации.

rework discovery in Scrum or in Waterfall = IF THEN ELSE(switch=0:OR:switch=2,IF THEN ELSE(Selected Requirements < 0.05, Fraction work done (error at the end of the Scrum sprint or in Waterfall), 0),0)

Ошибки при разработке в Scrum и Waterfall учитываются только через (исправление)

Исправления в Scrum

Исправления в Waterfall

Задержки

Выбранные требования для реализации

Выбранные требования для реализации

Завершенная работа

Внедрение

Оригинальная работа

Simulating Kanban and Scrum vs Waterfall withSystem DynamicsLuisanna Cocco, Katiuscia Mannaro, Giulio Concas, and Michele MarchesiUniversity of Cagliari, DIEE - Dipartimento di Ingegneria Elettrica ed Elettronica,Piazza D'Armi, 09123 Cagliari, Italy,{luisanna.cocco,mannaro,concas,michele}@diee.unica.itUniversity of Cagliari

Литература● Lean Software Development: An Agile Toolkit / Mary Poppendieck,

Tom Poppendieck / Addison Wesley 2003 ISBN: 0-321-15078-3● Kanban in Action/ MARCUS HAMMARBERG, JOAKIM SUNDÉN

/2014 by Manning Publications Co.● Agile Project Management with Kanban / Eric Brechner,with a

contribution from James Waletzky/ Microsoft Press 2015● Lean: An Essential Guide to Lean Startup, Lean Six Sigma, Lean

Analytics, Lean Enterprise, Lean Manufacturing, Agile Project Management, Kanban and Scrum/ James Edge 2018