Видео: https://www.youtube.com/watch?v=79Joxx6gTeU Используя имитационную модель на докладе мы проверим, что лучше работает: - Что делать если команда не сбалансирована - Может ли сбалансированная команда работать без ограничения WIP - Как подобрать оптимальные ограничения WIP - Помогает ли приоритезация бизнесу

1. Проверка гипотез Kanban
Method с помощью
имитационной модели
Денис Тучин
Тренер-консультант, ScrumTrek

2. Об авторе
С 2003 имитационное моделирование
C 2004 в разработке коммерческого ПО
С 2009 внедрение Agile практик
С 2011 руководство командами и
проектами
b2b и b2c, гос. проекты, стартапы,
банковские проекты, проекты для IBM.

3. Зачем моделировать Канбан?
Нет уверенности, что нам поможет Канбан
Непонятно, как подобрать команду и какие
ограничения выставить на WIP
Без статистики по команде практически не
возможно планировать релиз
? ? ?
?

4. Содержание доклада
Сбалансированность команды
Взаимопомощь между командами
Как подобрать ограничение WIP?
Вариативность задач
Эффект приоритезации

5. Имитационное моделирование
Используют если нет аналитической модели
(например, есть случайность)
Или если нет аналитического метода решения
Дорого или невозможно экспериментировать на
реальном объекте

6. О средстве моделирования
Первая версия вышла в 2000
Кросс-платформенное
Начиная с версии 7 на базе IDE Eclipse
Поддерживает Java для сложных и
нестандартных моделей

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

8. О модели

9. О модели
Агент модели
или
Analysis, Dev, Test

10. Трудозатраты на работу
triangular(0.70, 1.2, 2) /
agent.resource.testExperience

11. Трудозатраты на работу
triangular(0.70, 1.2, 2) /
agent.resource.testExperience

12. Трудозатраты на работу
triangular(0.70, 1.2, 2) /
agent.resource.testExperience

13. *Experience
Resource analysisExperience devExperience testExperience
Аналитик 1,0 0,1 0,5
Разработчик 0,2 1,0 0,3
Тестировщик 0,4 0,2 1,0

14. Допущения модели
(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 исполнитель

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

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

19. Несбалансированная команда
Время цикла растёт:

20. Несбалансированная команда
Время цикла растёт:
Задачи делаем всё дольше

21. Несбалансированная команда
Время цикла растёт:
Задачи делаем всё дольше
Разработчики и аналитики забывают контекст,
когда тестировщик берётся за старую задачу

22. Несбалансированная команда
Время цикла растёт:
Задачи делаем всё дольше
Разработчики и аналитики забывают контекст,
когда тестировщик берётся за старую задачу
Часто функционал приходится несколько раз
переделывать ещё до того, как она начнёт
приносить пользу пользователям и деньги нам

23. Несбалансированная команда
Время цикла растёт:
Задачи делаем всё дольше
Разработчики и аналитики забывают контекст,
когда тестировщик берётся за старую задачу
Часто функционал приходится несколько раз
переделывать ещё до того, как она начнёт
приносить пользу пользователям и деньги нам

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

26. Почему так?

27. Почему так?
У всех полно своих дел!

28. Что делать?

29. Попробуем ограничить WIP
Как выбрать WIP?

30. Попробуем ограничить WIP
Как выбрать WIP?
Попробуем
2n + 1

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

33. Вспомним методы оптимизации
Применим метод координатного спуска
PS: При желании можно использовать метод градиентного спуска
Analysis Dev Test Cycle Time Throughput
5 7 5 ~7,0 ~7,8
5 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,8
5 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

35. Выводы про взаимопомощь
Взаимопомощь не работает, когда все перегружены
Выход: установить ограничение WIP
Подобрать WIP можно экспериментально или с
помощью модели
PS: Не стоит забывать про Rework
(Cycle Time vs Throughput)

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

38. Сбалансированная команда
Небольшие задачи
Равномерное поступление
задач
Все задачи примерно
одного размера

39. Сбалансированная команда
Небольшие задачи
Равномерное поступление
задач
Все задачи примерно
одного размера

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

41. Вариативность задач
BA Dev QA
BA Dev QA
BA Dev QA

42. Поступление Трудозатраты
Δt,
дни
0,2 2 10
Pr
T,
ч.дни
0,5 2 30
Pr

44. WIP

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

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

50. Выводы про приоритезацию
Приоритезация обычно увеличивает
Lead Time

51. Какая от этого польза?
Вместо распределения можно задать реальную
статистику производительности, а также по
вариативности задач.
Поставить эксперименты с разными
ограничениями WIP
Смоделировать, что изменится при изменении
внешних условий

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

53. Спасибо за каверзные вопросы!
Денис Тучин, тренер-консультант ScrumTrek
dtuchin@scrumtrek.ru
Skype: denis.tuchin
https://www.facebook.com/denis.tuchin
https://ru.linkedin.com/in/denistuchin
https://twitter.com/denistuchin