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