Привет, Хабр! Представляю вашему вниманию перевод статьи «Почему я не использую Story Points для планирования спринта» Майк Кон.
Как описано в разделе «Гибкая оценка и планирование», я большой поклонник Story Points для оценки невыполненной работы по продукту.
Однако я также рекомендую оценивать отставание по спринту в часах, а не в баллах.
Почему это кажущееся противоречие? О причинах я писал ранее.
Я рекомендую использовать разные единицы измерения (баллы и часы) для разных бэклогов.
Но мне часто задают сопутствующий вопрос, который я хочу задать здесь: Мне любопытно, почему вы не используете Story Points для планирования спринта.
Я думал, что смысл измерения скорости в сюжетных очках отчасти заключается в том, чтобы определить, сколько мы можем взять (или взять на себя) за спринт. Используете ли вы Story Points только для долгосрочного планирования (например, планирования выпуска)? Я не использую Story Points для планирования спринта, потому что Story Points — полезная долгосрочная мера.
Но очки бесполезны в краткосрочной перспективе.
Было бы уместно, если бы команда сказала: «Мы набираем в среднем 20 Story Points, и у нас осталось 6 спринтов, поэтому в итоге за эти шесть спринтов мы получим около 120 Story Points».
Было бы неуместно, если бы команда сказала: «У нас средняя скорость 20 стори-пойнтов, поэтому мы финишируем в следующем спринте».
Это не работает. Допустим, баскетбольная команда находится в середине сезона.
На данный момент они сыграли 41 игру и набирали в среднем 98 очков за игру.
Было бы уместно сказать: «Вероятно, до конца сезона мы будем набирать в среднем 98 очков за игру».
Но им не следует перед каждой конкретной игрой говорить: «У нас в среднем 98, поэтому сегодня возьмем 98».
Вот почему я говорю, что скорость является полезным долгосрочным предсказателем, но не полезным краткосрочным предсказателем.
Скорость будет меняться от спринта к спринту.
Вот почему я хочу, чтобы команды планировали свои спринты, просматривая бэклог продукта, выбирая одно из самых важных дел, которые они могут сделать, разбивая этот элемент бэклога продукта/пользовательскую историю на задачи и оценивая задачи, спрашивая себя, смогут ли они выполнить их.
при принятии решения о выпуске этого элемента невыполненной работы по продукту, а затем повторять, пока они не будут заполнены.
Никакого обсуждения сюжетных моментов.
Никаких разговоров о скорости.
Все дело в приверженности, и мы решаем, сколько мы можем выполнить, разбивая элементы невыполненного продукта на задачи и оценивая их.
Когда команда заканчивает планирование спринта таким образом, вполне вероятно, что количество пунктов истории, которые они неосознанно преследуют, должно быть близко к среднему значению, но оно будет варьироваться.
Также верно и то, что команда будет работать примерно одинаковое количество часов от одного спринта к другому.
Я использую термин «мощность» для обозначения этого количества часов, поскольку ставка зарезервирована для обозначения измерения объема запланированной или завершенной работы, как указано в единицах, используемых для оценки невыполненной работы по продукту (что я рекомендую делать с помощью истории точки ).
Об авторе: Майк Кон — один из авторов методологии Scrum для разработки программного обеспечения.
Он является одним из основателей Agile Alliance и Scrum Alliance. Специализируется на оказании помощи компаниям во внедрении и совершенствовании использования гибких процессов и методов для создания высокопроизводительных команд. Библиография: Гибкая оценка и планирование , Майк Кон, 2005. P.S. Вы оцениваете отставание в спринте в часах или баллах? Теги: #scrum #Управление проектами #agile
-
Как Создать Диск Восстановления Windows?
19 Oct, 24 -
Уметь Пользоваться Цифровой Видеокамерой
19 Oct, 24 -
Файлы Qvd — Что Внутри, Часть 3
19 Oct, 24 -
Немного О Сборке Мусора И Генерациях
19 Oct, 24 -
Краш-Тест Киевского Стартапа 19 Aka Kebabs
19 Oct, 24
