Downloaded 41 times
Uploaded byAskhat Urazbaev
#No estimate. Безоценочная разработка
Документ обсуждает концепцию безоценочной разработки, утверждая, что оценка времени и усилий в проектировании приводит к искажению ожиданий и высокой вероятности неудач. Основной акцент сделан на методах оценки задач в контексте Agile и Scrum, а также на важности непрерывной доставки и предсказуемости без традиционного оценивания. Приводятся примеры и статистические данные, подчеркивающие проблемы, возникающие из-за попыток точно оценить время разработки.
More Related Content
#No estimate. Безоценочная разработка
- 1.
- 2.
- 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.
- 13.
- 14.
- 15.
- 16. Velocity и регрессияк среднему
- 17. Velocity падает Стабильная скорость— признак перестраховки
- 18.
- 19. Оценка баклога • Человеко-дни –1 день на оценку релиза – Излишняя точность • Стори-пойнты – 4 часа – Planning poker • Стори-пойнты – 1 час – 1/2/4 • Порядок величины – ~ 20 мин – Good, Too big
- 20.
- 21.
- 22.
- 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.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. Идея анализ проектирование разработка тестирование релиз Failure Demand • Непродуманные требования •Ошибки проектирования • Баги • Нетестированный функционал • Ошибки выкладки
- 42.
- 43.
- 45.