Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 2
Важно помнить, что все оценки являются прогнозами и могут быть неточными. Главное — это не точность, а то, как мы используем эти оценки для управления проектом и обеспечения его успешного выполнения. Надеюсь, это помогает вам лучше понять, как Story Points могут быть полезными даже в новых проектах.
Приведу приближенный к реальной ситуации пример:
Допустим, у вас есть новый проект по разработке мобильного приложения. Вы с командой провели сессию планирования и определили следующие основные задачи:
1️⃣ Дизайн пользовательского интерфейса
2️⃣ Разработка базы данных
3️⃣ Разработка API
4️⃣ Тестирование и отладка
Вы оценили каждую задачу в Story Points следующим образом:
1️⃣ Дизайн пользовательского интерфейса: 13 Story Points
2️⃣ Разработка базы данных: 8 Story Points
3️⃣ Разработка API: 5 Story Points
4️⃣ Тестирование и отладка: 20 Story Points
Общий объем работы составляет 46 Story Points.
Теперь, допустим, вы предполагаете, что ваша команда может выполнить около 10 Story Points за двухнедельную итерацию (это ваша начальная скорость). Используя эту оценку, вы можете предсказать, что проект будет завершен примерно за 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает вам и вашему заказчику общее представление о том, сколько времени может занять проект, и позволяет вам начать планирование.
После первой итерации у вас будет реальные данные о скорости команды, которые вы сможете использовать для корректировки вашего прогноза. Это одно из преимуществ использования Story Points и Agile методологии — они позволяют вам адаптироваться к изменениям и уточнять ваши прогнозы по мере продвижения проекта.
Окей, а как понять, сколько это будет в реальных единицах времени?
Для расчета времени выполнения проекта нам нужно знать скорость команды (velocity), то есть сколько Story Points команда обычно выполняет за итерацию. Допустим, скорость команды составляет 10 Story Points за двухнедельную итерацию (это пример, и реальная скорость команды может отличаться).
Тогда, если общий объем работы составляет 46 Story Points, мы можем вычислить количество итераций, разделив общий объем работы на скорость команды:
🔖 Количество итераций = Общий объем работы/Скорость команды = 46 SP/10 SP в итерацию = 4.6 итераций
Поскольку каждая итерация длится две недели, общее время выполнения проекта составит:
🔖 Время выполнения проекта = Количество итераций Х Длительность итерации = 4.6 Х 2 недели/итерацию = 9.2 недели
Итого: примерно 9 недель и 1 день. Учтите, что это приближенное значение, и на самом деле время выполнения проекта может варьироваться в зависимости от многих факторов, таких как, например, стабильность интернет-соединения и др; технические проблемы, человеческий фактор, экономический, политическикй, прочие риски.
Если в команде вы используете относительную оценку задач, то какие цифры окончания работ мне как ПМу нужно озвучить заказчикам и стейкхолдерам?
Я бы использовал данные о скорости команды (velocity), чтобы преобразовать Story Points в конкретные сроки для заказчиков и стейкхолдеров.
Например, если команда обычно выполняет 10 Story Points за двухнедельную итерацию, и у нас есть проект, оцененный в 50 Story Points, я бы сообщил заказчикам, что проект, вероятно, будет завершен примерно через 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает заказчикам и стейкхолдерам общее представление о том, сколько времени может занять проект, и позволяет им начать планирование.
Важно помнить, что все оценки являются прогнозами и могут быть неточными. Главное — это не точность, а то, как мы используем эти оценки для управления проектом и обеспечения его успешного выполнения.