Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный. Вам нравится эта идея? Вижу, что нет. Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость? По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами. Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.

1. #NoEstimates:
безоценочная
разработка
Асхат Уразбаев
ScrumTrek

2. #NoEstimates: Безоценочная
разработка
Асхат Уразбаев
Ag;)e
Days 14

3. Асхат Уразбаев
• ScrumTrek
• Agile Coach
• Управляющий партнер
• В прошлом
• Программист, менеджер
проектов, методолог

4. Движение #NoEstimates
• Движение за разработку без
использования оценок
• Стартовало в твиттере
стараниями этого человека:
Woody Zuill

5. Как мы до этого докатились?

6. COCOMO
COnstructive COst MOdel
• Function Points
• Early Function
Points
• Use Case Points
• База: индустрия

7. Оценка «по аналогии»
ака по-простому
• Декомпозиция на задачи
• Оценка в часах/днях экспертами
• База — 8-часовой рабочий день
ТЗ план

8. Перестраховка
Оптимист - Сделаем если ничего не предвиденного не случится. Новички. 0%
Реалист - Наиболее вероятное значение. Оценка опытных разработчиков. (Вероятно
Fail по- прежнему ~70%)
Перестраховка - Если космос не рухнет, то точно уложимся.

9. Простое объяснение

10. В компаниях Кремниевой Долины
была самая жестокая
конкуренция за всю историю
планеты. … Время, отпущенное
на разработку, постоянно урезалос
ь. Сначала на разработку ново
й версии отводилось три года.
Потом этот срок сократили до
двух лет. Потом —
до восемнадцати месяцев.
Теперь на это отводится
двенадцать месяцев, новую
версию нужно выпускать каждый
год.

12. Scrum

13. Трудно оценить

14. Velocity
По ретроспективным данным

15. Стори-пойнты
• (с) Майк Кон

16. Velocity и регрессия к
среднему

17. Velocity падает
Стабильная скорость — признак перестраховки

18. Commitment Forecast

19. Оценка баклога
• Человеко-дни
– 1 день на оценку релиза
– Излишняя точность
• Стори-пойнты
– 4 часа
– Planning poker
• Стори-пойнты
– 1 час
– 1/2/4
• Порядок величины
– ~ 20 мин
– Good, Too big

20. Planning poker

21. Bucket estimation

22. Оценка
Часы
«Идеальные Дни»
Стори-пойнты
~40%
~20%
~10%
«Майки» SML ~1%

24. MVP & MMF
• Детальная декомпозиция

25. Оценка
ЗадачиФичи
1. Не оценивать. Просто посчитать.
2. Оценивать в T-shirt
1. Без задач
2. Не оценивать задачи, просто сосчитать
3. Оценить задачи в днях
1d
2d0.5d
4. Оценить задачи в часах
12h
8h4h
S M L
Часы?
Дни?
Недели?
S M
L
3. Оценивать в story-points
1sp
2sp
5sp
4. оценивать в идеальных человеко-днях
1d
3d
6d
”типичный”
Kanban
”типичный”
Scrum
By Henrik Kniberg

26. #NoEstimates означает ведение софтверного
проекта без оценки человеком. Если
заказчик спрашивает «Когда?» — это
оценивание. Если ему не приходится
спрашивать — это #NoEstimates
We'll define #NoEstimates as running a software project without any
human estimation process. If customers asks, "How long will it take?"
that's estimating. If they never have to ask, that's #NoEstimates.
Matthew Heusser (c)

27. ценность
доставлять
непрерывно

28. “Заказчик все-таки просил оценить сроки”

29. КАК СОХРАНИТЬ
ПРЕДСКАЗУЕМОСТЬ
НЕ ОЦЕНИВАЯ?

30. Что важнее для заказчика?
• Вы успеваете сделать все
запланированные задачи внутри
итерации
• Вы успеете сделать его задачу

31. Перестраховка
Оптимист - Сделаем если ничего не предвиденного не случится. Новички. 0%
Реалист - Наиболее вероятное значение. Оценка опытных разработчиков. (Вероятно
Fail по- прежнему ~70%)
Перестраховка - Если космос не рухнет, то точно уложимся.

32. Спектр времени цикла

33. Вероятностный подход к прогнозированию
Lead Time Distribution
0
0.5
1
1.5
2
2.5
3
3.5
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
113
120
127
134
141
148
Days
CRs&Bugs
SLA = 44 дня с 85%
Среднее =
31
SLA=105 дня с 98 %

34. Cycle Time < Время Изменения
Требований

35. Cumulative flow 1

36. Cumulative Flow 2

37. Пропускная способность

38. Потребность ~ Пропускная
способность

39. Фильтрация потребности
Фильтр

40. Ложная загрузка (Failure
Demand)

41. Идея
анализ
проектирование
разработка
тестирование
релиз
Failure Demand
• Непродуманные
требования
• Ошибки
проектирования
• Баги
• Нетестированный
функционал
• Ошибки выкладки

42. Внешние зависимости
• ы

43. Узкое место ли вы?

45. Асхат
Уразбаев
askhat@scrumtrek.r
u
F askhat.urazbaev
@zibsun
askhatu