×Закрыть

Опрос по процессу планирования трудозатрат на проекте

Недавно прочёл небольшую статейку на тему оценки трудо-затрат — 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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ну нормальная такая история, только если таких спринтов большинство — не четкие требования, не сильно точная оценка затрат и отсуствие в прошлом похожих тасков то нада в каждом следуещем спринте процентов 20 времени оставлять на баг фиксинг и один спринт через три делать полный фикс. Это позволяет проекту двигаться вперед и со временем таки выкатить готовый продукт.

Оценка в часах — ололо. Таск: запилить немного UI, контроллер, базу, DTO, тесты, такой норм девелоперский таск.
Вася (матюкается, переводя стори поинты в часы по курсу 1 к 8): ну 32 часа.
Шамсудин: я сделаю за 2,5 часа.
Мы: О_о
......
Скрам-мастер: таск будет делать Шамсудин! он же меньше загадал.
Мы: О_О
.....
Куда такие «методологии» писать?

автора интересует конкретная методология.
Так что просто проходить стороной.
Так что просто проходить стороной.
Вы ж сами оффтопер 80 левела — в каждой ветке каждого топика отписываетесь. Бревно в глазу не жмёт ?

Попросить аргументацию уважаемого Василия, затем уважаемого Шамсудина. Затем обсудить всей командой. Это и называется торг. Или вам сертифицированный скрам-мастер не позволяет?

Т.е. других вариантов, кроме спиринтов не предполагается?

А зачем? Все ж по аджайлу работают и в покер играют. Без вариантов, мастхев!

Пишите варианты, добавлю. Возможно ещё есть многолетние водопады с многотомными ТЗ.

От древнего водопада, что еще в советском ГОСТе был отражен, до современного «срама». Их много и разных. Открываешь литературу и читаешь.

ну, положим, автора интересует конкретная методология.
если хотите — можете устроить обобщенный опросник, но как он будет выглядеть — ума не приложу.

Подписаться на комментарии