• Like
Асхат Уразбаев (ScrumTrek/GameTrek)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Асхат Уразбаев (ScrumTrek/GameTrek)

  • 151 views
Published

 

Published in Internet
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
151
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. #NoEstimates: Безоценочная разработка Асхат Уразбаев
  • 2. Асхат Уразбаев • ScrumTrek • Agile Coach • Управляющий партнер • В прошлом • Программист, менеджер проектов, методолог
  • 3. Движение #NoEstimates • Движение за разработку без использования оценок • Стартовало в твиттере стараниями этого человека: Woody Zuill
  • 4. Как мы до этого докатились?
  • 5. COCOMO COnstructive COst MOdel • Function Points • Early Function Points • Use Case Points • База: индустрия
  • 6. Оценка «по аналогии» ака по-простому • Декомпозиция на задачи • Оценка в часах/днях экспертами • База — 8-часовой рабочий день ТЗ план
  • 7. Перестраховка Оптимист - Сделаем если ничего не предвиденного не случится. Новички. 0% Реалист - Наиболее вероятное значение. Оценка опытных разработчиков. (Вероятно Fail по- прежнему ~70%) Перестраховка - Если космос не рухнет, то точно уложимся.
  • 8. Простое объяснение
  • 9. В компаниях Кремниевой Долины была самая жестокая конкуренция за всю историю планеты. … Время, отпущенное на разработку, постоянно урезалос ь. Сначала на разработку ново й версии отводилось три года. Потом этот срок сократили до двух лет. Потом — до восемнадцати месяцев. Теперь на это отводится двенадцать месяцев, новую версию нужно выпускать каждый год.
  • 10. Scrum
  • 11. Трудно оценить
  • 12. Velocity По ретроспективным данным
  • 13. Стори-пойнты • (с) Майк Кон
  • 14. Velocity и регрессия к среднему
  • 15. Velocity падает Стабильная скорость — признак перестраховки
  • 16. Commitment Forecast
  • 17. Оценка баклога • Человеко-дни – 1 день на оценку релиза – Излишняя точность • Стори-пойнты – 4 часа – Planning poker • Стори-пойнты – 1 час – 1/2/4 • Порядок величины – ~ 20 мин – Good, Too big
  • 18. Planning poker
  • 19. Bucket estimation
  • 20. Оценка Часы «Идеальные Дни» Стори-пойнты ~40% ~20% ~10% «Майки» SML ~1%
  • 21. MVP & MMF • Детальная декомпозиция
  • 22. Оценка ЗадачиФичи 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
  • 23. #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)
  • 24. ценность доставлять непрерывно
  • 25. “Заказчик все-таки просил оценить сроки”
  • 26. КАК СОХРАНИТЬ ПРЕДСКАЗУЕМОСТЬ НЕ ОЦЕНИВАЯ?
  • 27. Что важнее для заказчика? • Вы успеваете сделать все запланированные задачи внутри итерации • Вы успеете сделать его задачу
  • 28. Перестраховка Оптимист - Сделаем если ничего не предвиденного не случится. Новички. 0% Реалист - Наиболее вероятное значение. Оценка опытных разработчиков. (Вероятно Fail по- прежнему ~70%) Перестраховка - Если космос не рухнет, то точно уложимся.
  • 29. Спектр времени цикла
  • 30. Вероятностный подход к прогнозированию 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 %
  • 31. Cycle Time < Время Изменения Требований
  • 32. Cumulative flow 1
  • 33. Cumulative Flow 2
  • 34. Пропускная способность
  • 35. Потребность ~ Пропускная способность
  • 36. Фильтрация потребности Фильтр
  • 37. Ложная загрузка (Failure Demand)
  • 38. Идея анализ проектирование разработка тестирование релиз Failure Demand • Непродуманные требования • Ошибки проектирования • Баги • Нетестированный функционал • Ошибки выкладки
  • 39. Внешние зависимости • ы
  • 40. Узкое место ли вы?
  • 41. Асхат Уразбаев askhat@scrumtrek.r u F askhat.urazbaev @zibsun askhatu