Проверка гипотез KanbanMethod с помощью имитационной модели

Денис Тучин

Тренер-консультант, ScrumTrek

Об авторе

С 2003 имитационное моделирование

C 2004 в разработке коммерческого ПО

С 2009 внедрение Agile практик

С 2011 руководство командами и проектами

b2b и b2c, гос. проекты, стартапы, банковские проекты, проекты для IBM.

Зачем моделировать Канбан?

Нет уверенности, что нам поможет Канбан

Непонятно, как подобрать команду и какие

ограничения выставить на WIP

Без статистики по команде практически не

возможно планировать релиз

? ? ?

?

Содержание доклада

Сбалансированность команды

Взаимопомощь между командами

Как подобрать ограничение WIP?

Вариативность задач

Эффект приоритезации

Имитационное моделирование

Используют если нет аналитической модели (например, есть случайность)

Или если нет аналитического метода решения

Дорого или невозможно экспериментировать на реальном объекте

О средстве моделирования

Первая версия вышла в 2000

Кросс-платформенное

Начиная с версии 7 на базе IDE Eclipse

Поддерживает Java для сложных и нестандартных моделей

Области применения

О модели

О модели

Агент модели

или

Analysis, Dev, Test

Трудозатраты на работу

triangular(0.70, 1.2, 2) /

agent.resource.testExperience

Трудозатраты на работу

triangular(0.70, 1.2, 2) /

agent.resource.testExperience

Трудозатраты на работу

triangular(0.70, 1.2, 2) /

agent.resource.testExperience

*Experience

Resource analysisExperience devExperience testExperience

Аналитик 1,0 0,1 0,5

Разработчик 0,2 1,0 0,3

Тестировщик 0,4 0,2 1,0

Допущения модели

(unit instanceof Analyst)|| (unit instanceof Developer)

&& (development.seize.queue.size() == 0) && (analysts.idle() == 0)

|| (unit instanceof Tester) && (test.seize.queue.size() == 0) && (analysts.idle() == 0)

Многозадачность

1 задача – 1 исполнитель

Сбалансированная команда

Несбалансированная команда

Несбалансированная команда

Время цикла растёт:

Несбалансированная команда

Время цикла растёт:

Задачи делаем всё дольше

Несбалансированная команда

Время цикла растёт:

Задачи делаем всё дольше

Разработчики и аналитики забывают контекст, когда тестировщик берётся за старую задачу

Несбалансированная команда

Время цикла растёт:

Задачи делаем всё дольше

Разработчики и аналитики забывают контекст, когда тестировщик берётся за старую задачу

Часто функционал приходится несколько раз переделывать ещё до того, как она начнёт приносить пользу пользователям и деньги нам

Несбалансированная команда

Время цикла растёт:

Задачи делаем всё дольше

Разработчики и аналитики забывают контекст, когда тестировщик берётся за старую задачу

Часто функционал приходится несколько раз переделывать ещё до того, как она начнёт приносить пользу пользователям и деньги нам

А что если помочь тестировщикам?

Почему так?

Почему так?

У всех полно своих дел!

Что делать?

Попробуем ограничить WIP

Как выбрать WIP?

Попробуем ограничить WIP

Как выбрать WIP?

Попробуем

2n + 1

Как вы подбираете WIP?

Вспомним методы оптимизации

Применим метод координатного спуска

PS: При желании можно использовать метод градиентного спуска

Analysis Dev Test Cycle Time Throughput

5 7 5 ~7,0 ~7,85 7 7 ~7,0 ~8,0

5 7 3 ~6,5 ~7,9

5 7 2 ~6,5 ~7,0

5 7 4 ~7,0 ~7,0

3 7 7 ~5,5 ~7,0

5 5 3 ~6,0 ~7,85 3 3 ~6,0 ~7,0

5 6 3 ~6,5 ~7,5

5 4 3 ~6,0 ~7,5

3 5 3 ~5,5 ~7,0

7 5 3 ~6,0 ~7,8

6 5 3 ~6,0 ~7,8

Выводы про взаимопомощь

Взаимопомощь не работает, когда все перегружены

Выход: установить ограничение WIP

Подобрать WIP можно экспериментально или с помощью модели

PS: Не стоит забывать про Rework(Cycle Time vs Throughput)

Подробнее с про сбалансированные команды

Сбалансированная команда

Небольшие задачи

Равномерное поступлениезадач

Все задачи примерно одного размера

Сбалансированная команда

Небольшие задачи

Равномерное поступлениезадач

Все задачи примерно одного размера

Вариативность поступления задач

Вариативность задач

BA Dev QA

BA Dev QA

BA Dev QA

Поступление Трудозатраты

Δt,

дни

0,2 2 10

Pr

T,

ч.дни

0,5 2 30

Pr

WIP

Добавим багов

Заказчик (разработчики) предпочитает новый функционал багам

Выводы про приоритезацию

Приоритезация обычно увеличивает Lead Time

Какая от этого польза?

Вместо распределения можно задать реальную статистику производительности, а также по вариативности задач.

Поставить эксперименты с разными ограничениями WIP

Смоделировать, что изменится при изменении внешних условий

Планы по развитию модели

Спасибо за каверзные вопросы!

Денис Тучин, тренер-консультант ScrumTrek

dtuchin@scrumtrek.ru

Skype: denis.tuchin

https://www.facebook.com/denis.tuchin

https://ru.linkedin.com/in/denistuchin

https://twitter.com/denistuchin