Comments 13
Если не привязывать поинты к часам, то как понять сколько успеется за спринт? Ведь так или иначе сколько именно поинтов закинуть зависит от доступного времени каждого участника команды
1) Тут не стоит забывать что в Story Points измеряются Пользовательские Истории(User Story), которые являются результатом совместного творчества.
2) Попытка измерить в часах приведет к необходисоти указать время всех специалистов, участвующих в реализации:
2ч - разработчик
2ч - Тестировщик
1ч - аналитик
30 мин - Архитектор - и т. д.
Также такие точные оценки приведет к большому расходу времени всей команды и не желанию чтото оценивать в дальнейшем.
И потом - Можем ли мы приравнять 30 мин Архитектора к 2ч тестировщика?
3) В общем - Story Point - это быстрая, относительная, командная оценка Историй, необходимая только для нужд Команды в планировании.
1) SP - Это командная оценка, а не индивидуальная. Оценивать отдельные независимые задачи конкретного разработчика в SP - неработоспособная история. Часы - выглядят логичнее в этом случае - согласен.
2) Сравнивать часы по разным компетенциям - ценности не имеет.
3) Стоимость = Стоимость команды за спринт (часто - фикс) x Количество спринтов.
А вот количество спринтов = Суммарная оценка всего беклога продукта / средняя производительность команды.
Минус подхода в том что примерную оценку в $ можно получить после 2-4 спринтов.
4) Теоретически, все в команде должны быть взаимозаменяемы - нет, команда должна быть просто кросс-функциональной, те в внутри команды достаточно навыков для работы над этим Проектом/Продуктом, и да - очень желательно иметь задублированные компетенции
1) Понять можно при условии стабильности состава команды, пусть даже участники будут выделены не на 100%. Имею ввиду, у менеджмента должна быть возможность выделять людей, т.е. - управлять составом команды. И да - с менеджментом бывают проблемы. Их стори поинты не решают.
2) Потом - заранее, без накопления статистики по 2-4 спринтам, понять сколько брать на 1 спринт - невозможно.
3) Имея показатели производительности за 4+ спринта и стабильно выделенную на 80%+ команду - мы можем довольно точно определять сколько можно взять на Спринт.
Это верно только если:
1) состав команды за 4 спринта не менялся (никто не уходил в отпуск, не болел и так далее)
2) все задачи за эти спринты практически одинаковые и не содержат никакой новизны
3) никто в команде не меняется (ни у кого нет личных причин снижать производительность, никто ничему не учиться - и так далее).
В реальности, конечно, эти критерии не срабатывают - поэтому оценка в SP не работает.
Собственно, даже автор идеи SP в твиттере извинялся за свою идею, так как ничего хорошего из нее не получилось.
1) да, точность снижается, при отпусках, болезнях и прочих пропусках, но не критично, обычно просто надо больше Спринтов и команда находит свой уровень скорости в SP.
2) Наооборот - имеет смысл использовать SP если задачи сложные, имеют большую неопределенность. При простых задачах - SP часто вообще использовать не требуется.
3) Разделять цели команды\продукта - действительно надо. Тут у меня встречный вопрос - зачем работать на проекте если тебе кается не важным то что ты делаешь, и тебе все равно на общий результат. Это же IT, выбор есть.
3) Обучение - часть работы, оно конечно в SP не оценивается, но сам факт что команда учится 10-20% времени всегда - учитывается при планировании.
4) Оценки в SP не везде работают, это не универсальная пуля.
1) Что значит "снижается"? Если в команде было 5 человек, а стало 4, при этом этот пятый - единственный сеньор, то производительность команды упадет раза в полтора.
Впрочем, это беда не только идеи SP, а всех практик планирования вокруг Scram - они бесполезны.
2) Для сложных задач вообще нельзя выдать хоть какую-то оценку, они потому и сложные. Впрочем, весь Scram - для простых одинаковых задач, а SP - это в первую очередь инструмент для Scram, больше он, насколько знаю, нигде не используется.
3) При чем тут цели команды? Личное снижение производительности происходит из-за кучи причин - выгорание, личные проблемы, влюбленности или ремонта. Это нормальная динамика.
4) Нормально SP нигде не работают. Как и любое подобное планирование.
1) У меня для вас плохие новости, у вас проблема с дизайном команды, у вас будет провал в принципе в случае отпуска сеньера. А это как бы - ежегодное событие.
2.1)Давай с простого. Оценивать надо. Иначе команда не сможет планировать в принципе. Не важно в какой системе оценок. Не умеющая оценивать команда менее ценна бизнесу > бизнес меньше готов платить за такую команду.
2.2) Scrum и SP подходят только для сложных и комплексных Продуктов.
2.3) В Scrum Guide нет ни строчки про Story Points
2.4) Story Points - это одна из Agile практик
3) Про Цели - скорее всего на другой вопрос посмотрел.
4) Если SP не работает, то что тогда работает в сложных проектах? Как вы в команде планируете работу?
1) Хм, а в чем проблема? При любом отпуске будет падение производительности команды, с этим ничего нельзя делать. Производительность команды - не является какой-то константой, потому все попытки исходить в планировании - не работают. Это, вообще говоря, довольно очевидное заключение.
2.1) Это набор очень сомнительных утверждений. Оценка примерной трудоемкости - это одно. Планирование - это другое (и вообще не относится к зоне ответственности команды). Планирование нельзя делать на оценках трудоемкости (так как планирование - про даты, а они очень плохо связаны с трудоемкостью). Планирование возможно и без точных оценок. Собственно без них и обходится. И бизнес обычно (если там не совсем уж безграмотные сидят) понимает и стоимость получения точных оценок и осмысленность точных планов в неточной области.
Да, кстати, более-менее вменяемое планирование на основании оценок возможно только для простых задач.
2.2) Нет, это не так. Скрам подходит только для очень простых задач, ни в коем случае не для сложных проектов. Это достаточно очевидно просто из его дизайна. Не стоит верить маркетинговым заявлениям, нужно смотреть на практики - а они все про поток одинаковых простых задач, которые нужно перемалывать заточенной под эти (и только) задачи командой. Т.е. бригадная сборка автомашин, а не проектирование космического корабля (или даже новой модели автомашины).
2.3) В SG уже вообще почти ничего обязательного нет, стало совсем бессмысленным документом.
2.4) Ни разу не встречал SP нигде, кроме больных скрамом компаний.
Собственно, нигде больше и не требуются подобные оценки.
4) В сложных проектах работает стандартный набор подходов - экспертные оценки задач на высоком уровне (т.е. уровне много выше одного спринта на команду), оценки по аналогии (впрочем, это те же экспертные оценки), работа с рисками оценок (благо тут тоже много подходов). SP к оценкам в сложных проектов вообще никак не подходят, этот инструмент - для оценки небольших и одинаковых задач, но оценки на этом уровне - не аддитивны.
Не так давно ходила теория, что проджект менеджер, особенно с сертификатом PMP, может управлять любым проектом.
С SP похоже та же история.
Методология начисления Story Points. Инструкция из 10 пунктов