Мне повезло, ведь я познал силу story points всего лишь на 7 году работы в ИТ, когда работал в компании SoftServe. Команда, в которой я работал была шикарна, от проектного менеджера до всех остальных, ведь в ИТ проектах структура горизонтальная 🙂

Я не помню точной даты или момента, когда мы начали использовать story points, но могу предположить, что это было с самого начала проекта, поскольку мы работали по scrum с двух недельными итерациями.

Скажу сразу, лично я использую в проектах модель двухэтапного планирования, в которой используются story points и часы.

  • Story points – для высокоуровневого понимания объема scope в проекте и сложности user stories в вашем backlog. Присваиваются на grooming сессиях каждой story, которая прошла отбор.
  • Часы – для более точного планирования работы. Используются на планировании спринта, во время разбивки user story на sub-tasks.

Что же такое story point?

Денис Гобов на одной из конференций – это единица измерения, которая помогает сравнить трудоемкость задач. 

Я с ним вполне солидарен.

Давайте рассмотрим компоненты, которые формируют story points

Количество работы:

Представьте, что у вас есть две user story, которые говорят о том, что надо добавить поля на идентичные landing page. На первый landing page 1 поле, а на второй 100 полей с одинаковыми типами и требованиями. Так вот в момент оценки данных stories кол-во полей как раз и будет учитываться в головах разработчиков как «кол-во работы». Сложность одинаковая, а рутины больше.

Сложность:

Давайте возьмем все тот же пример с двумя страницами и полями, только теперь еще на вторую страницу добавлять не просто однотипные поля, а с разными типами. Вот теперь сложность задачи вырастит, как и с разработки так и с тестирования.

Риск и неопределённость:

Если мы возьмем простой пример имплементации функциональности «Sign in / Sign up» используя соц. Сеть «Line». Как раз это яркий пример того, где люди могут закладывать какие-то риски из-за того, что никогда не работали с данным сервисом.

У вас может возникнуть логический вопрос, а в каких же единицах необходимо вести все это? Многие используют для этого Числа Фибоначчи с разной градацией. Я предпочитаю следующую:

  • 1 – небольшие истории, для того чтобы сделать быстрые фиксы в приложении
  • 3 – базовый размер юзер стори, приравнивается к 2-3 дням имплементации (BE/FE/QA)
  • 5 – приравнивается к 3-5 дням имплементации (BE/FE/QA)
  • 8 – критический размер. Стоит задуматься о декомпозиции story на более мелкие
  • 13 – может включать в себя очень много зависимостей и ее необходимо разбить если возможно.
  • 21 – история, у которой 3-5 основных процессов связанных с фичей. Надо разбивать.
  • 50 – команда кое-что знает о требованиях к фиче
  • 100 – команда ничего не знает о требованиях к фиче

Мои рекомендации вам:

  • Максимально разбивайте user story, чтобы в вашем backlog на разработку были числа 3-5
  • Работайте с вашей командой над улучшением оценок
  • Спрашивайте помощи у ваших коллег
прочли: 600

Получай сообщения о новых видео, статьях, документах и событиях раз в неделю!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

LAMPOVOE IT: сообщество не программистов will use the information you provide on this form to be in touch with you and to provide updates and marketing.