Данная презентация призвана уменьшить непонимание между менеджерами и разработчиками в вопросе создания и предоставления различных оценок.
Видео доступно по ссылке: https://vk.com/video-160231148_456239029
4. Что нужно на самом деле?
1. Перечень работ
2. Последовательность их выполнения
3. Оценка длительности выполнения
каждого пункта
4. Расписание работ
5. Как составить перечень работ
1. Надо понять, что делаем.
○ Не понимаешь? Cпроси!
2. Можем декомпозировать отдельно взятую задачу/фичу?
○ Что главное, а что второстепенное.
○ Что делаем, а что нет.
○ От чего еще зависит выполнение задачи, каков Definition of Done.
3. Кто еще в компании обладает необходимыми знаниями
(Expert Judgment)?
6. Минималистичный пример DoD:
1. Код компилится или проверяется статическим
анализатором (linter) без предупреждений.
2. Код покрыт unit-test’ами, и все тесты проходят.
3. Документация обновлена.
4. Сборка задеплоена на тестовый сервер.
5. Все изменения протестированы вручную на различных
девайсах/браузерах и соответствуют требованиям.
А еще подумайте о релизах отдельных функций, фичей и всего приложения.
7. Activity list
● Описание фичи (feature
description).
● Предположения как и что будет
сделано (Assumptions).
10. Оцениваем продолжительность работ
1. Экспертное мнение
2. Оценка по аналогу
3. Техники группового принятия решений
(brainstorm, planning poker, ...)
4. Анализ необходимых резервов (в частности,
технические риски)
5. Оценка по трем точкам
11. Оценка по трем точкам
1. Пессимистичная оценка (tP)
2. Наиболее вероятная оценка (tM)
3. Оптимистичная оценка (tO)