Недавно прочёл небольшую статейку на тему оценки трудо-затрат — dou.ua/…​stimate-development-time. Советую прочесть, особенно тем кто отправляет сводную таблицу заказчику, в статье всего на 1 странице засвечено большинство подводных камней процесса планирования.

Словил себя на мысли что наблюдаю один проект на котором команда просто упорно топчется по всем этим граблям только благодаря упёртости одного молодого и очень горячего менеджера, который стремясь увеличить в глазах заказчика скорость работы команды, накидывает в каждый спринт всё больше и больше стори-поинтов. Причём некоторые стори даже не обсуждаются вовсе на планировании. Он выставляет их по своему наитию. Тут нужно сказать что мененджер из разработчиков, причём довольно хороших и талантливых. Обычно, со временем, из таких и получаются толковые менеджеры. Но далеко не каждый хороший разработчик это хороший менеджер. Особенно в молодости. Не отрицаю, что я могу быть не прав со своей колокольни. Проект то не мой. Потому интересна социологическая выборка как у кого обстоят дела на проектах.

Опишу вкратце модель работы этой команды — скажем, некий видеоплеер разрабатываемый под windows 10 (телефон/планшет/ПК) на внешнего заказчика. Команда ещё не устоялась, появляются новые люди, выпадают... Накануне двухнедельного спринта Аналитики и Бизнес накидывают стори в бэк-лог (причём бывает не очень детально описанные или копи-паст с других платформ). Презентуют их вкратце и потом начинается покер стандартного ряда Фибоначчи. Причем разработчики и тестировщики делают оценку за общим столом. Стандартная такса у них, даже для самой простейшей с моей точки зрения фичи, скажем переименование кнопки — это 5 поинтов, с приблизительной аргументацией: 3 на имплементацию, 2 на тестинг. С фичами которые явно сложнее дела обстоят иначе. Допустим организация списка воспроизведения с плавным переключением и фильтрацией по жанрам. Причём описание стори на этом может и заканчиваться, ну пару картинок ещё может быть, если дизайнеры успели отрисовать. Когда начинается разброс в оценках, тестировщики уже видя бесконечное количество вариантов одних только UI-ных тестов на всех 3-х платформах, разработчики даже предположить боятся о количестве коммуникаций и выяснений что имелось в виду — включается авторитет менеджера и начинается аргументация вида — да ну ребята, вы же в прошлом спринте почти на такую-же задачу сошлись на мнении не больше 8 СП и вы её сделали! Вот если б я её кодил — то мне б от силы понадобилось 5 СП, но я то уже не пишу код... А вам и 8 должно хватить, с головой! Вот эти 3 стори-поинта вам на как раз на коммуникацию. Естественно, предыдущий спринт был оценён тоже похожим образом. Бывает что команде общим напором удаётся отвоевать все 13 стори-поинтов, при этом как правило идут в зачёт только аргументы разработчиков, но не отдела качества. Менеджер то из разработчиков — как бывает сложно поднять инфраструктуру он понимает, а тестерам что — поклацаете что б главное всё работало. После чего этот самый менеджер засылает письмо на заказчика, где в этом спринте на целых 3 стори поинта больше! К слову, процесс организован так, что команда сама закрывает задачи, даже с критикал багами по любой фиче и даже с блокерами. Тестеры просто переносят баги в следующий спринт, а на демо перед заказчиком даётся торжественное обещание: всё починим — чесслово!

Вобщем Best Practices, во всей красе)

PS После появления достаточного количества результатов добавлю графики.
PPS Добавил пункт часто ли приходиться овертаймить. И добавил возможность переголосовать. Интересна корреляция графиков между подходами к планированию и переработкой.
PPPS Уже есть небольшое количество данных, что уже позволяет сделать некоторые выводы. Все роли типа ПМ, скрам-мастер, деливери-менеджер и прочее я слил в одну — менеджер, так как это всё по сути организация разработки
— Есть классические Agile команды, в которых тестируют сами разработчики.
— Есть представитель, который работает в крутой команде которая пока никогда не ошибалась.
— Анализ неверных оценок делается в 50%
— Периодически овертаймящих и не овертаймящих вовсе — пополам
— Какой либо зависимости между работой над ошибками и овертаймами пока не обнаружено
На красивые графики меня пока не хватило, предоставил общий доступ на просмотр результатов в табличном виде.

docs.google.com/…​Rb_VEkoo/edit?usp=sharing