Основные особенности, которые наблюдаются в командах при использовании #StoryPoint ’ов (#SP).
1. SP конвертируются во время
Пожалуй, самая распространенная практика..
Я видел, как в команде было сверху спущено, что 1 SP = 1MD (человеко-день), когда 1 SP = 0,5MD и так далее.
Время у людей получается оценивать плохо (или очень плохо), кроме того есть и непредвиденные обстоятельства (например, отвлечения от работы), которые тоже не способствуют точности оценок во времени. SP были задуманы изначально как оценка идеальных человеко-дней, но со временем переросли в условные, ни к чему не привязанные попугаи. Так и нужно к ним относиться.
2. Оценка в SP junior разработчика отличаются от оценки в SP senior разработчика
SP — это относительная мера командной интегрально оценки, включающей в себя сложность реализации (complexity), усилия (effort) и риски (risks). Ребята иногда считают, что оценка выкапывания ямы зависит от того, каким инструментом ее копать, а это не так. Кроме того, команды иногда на планировании назначают ответственного за реализацию, и тут есть соблазн изменить оценку в зависимости от навыков и умений исполнителя.
В мире разработки масса неопределенности и кто по факту будет делать — никто гарантий не даст. Нет смысла на это закладываться.
3. SP по User Story = ∑ SP входящих в US подзадач
Когда команда по факту является группой людей с узкой специализацией, где взаимовыручка и помощь возможны только словом, каждый оценивает усилия, которые необходимо приложить для решения “своей” задачи. Командная оценка получается как сумма полученных оценок. В этом случае мы складываем условных попугаев с условными апельсинами и условными табуретками. Как дальше команде понимать, сколько еще можно запланировать, не понятно, так как профиль загрузки каждой компетенции от спринта к спринту - совершенно разный.
Если же давать командную оценку, то в истории реализованных задач содержится вся информация, связанная с отвлечениями, отпусками, болезни, профилями загрузки компетенций и про.
4. Переоценивать SP по ходу реализации задачи или уже после завершения
Иногда начиная делать задачу, команда понимает, что ошиблась. И хочется это показать, так как неявно, ребята думают, что их ценят за “сожженные” очки.
Если у менеджмента agile-mindset, то они должны ценить не усилия (по сути затраченные косты), а результат (полученная “прибыль”, выраженную в нужных бизнесу единицах).
5. Переоценивать US в SP, когда задача переносится в следующий спринт
Оценка сама по себе является формой потерь (waste), то есть вложение усилий в получение оценки — это в целом довольно бесполезное (а по факту еще и вредное) занятие. Вкладывать в переоценку — это дважды потери. Лучше в это время написать интеграционный или модульный тест :)
1. SP конвертируются во время
Пожалуй, самая распространенная практика..
Я видел, как в команде было сверху спущено, что 1 SP = 1MD (человеко-день), когда 1 SP = 0,5MD и так далее.
Время у людей получается оценивать плохо (или очень плохо), кроме того есть и непредвиденные обстоятельства (например, отвлечения от работы), которые тоже не способствуют точности оценок во времени. SP были задуманы изначально как оценка идеальных человеко-дней, но со временем переросли в условные, ни к чему не привязанные попугаи. Так и нужно к ним относиться.
2. Оценка в SP junior разработчика отличаются от оценки в SP senior разработчика
SP — это относительная мера командной интегрально оценки, включающей в себя сложность реализации (complexity), усилия (effort) и риски (risks). Ребята иногда считают, что оценка выкапывания ямы зависит от того, каким инструментом ее копать, а это не так. Кроме того, команды иногда на планировании назначают ответственного за реализацию, и тут есть соблазн изменить оценку в зависимости от навыков и умений исполнителя.
В мире разработки масса неопределенности и кто по факту будет делать — никто гарантий не даст. Нет смысла на это закладываться.
3. SP по User Story = ∑ SP входящих в US подзадач
Когда команда по факту является группой людей с узкой специализацией, где взаимовыручка и помощь возможны только словом, каждый оценивает усилия, которые необходимо приложить для решения “своей” задачи. Командная оценка получается как сумма полученных оценок. В этом случае мы складываем условных попугаев с условными апельсинами и условными табуретками. Как дальше команде понимать, сколько еще можно запланировать, не понятно, так как профиль загрузки каждой компетенции от спринта к спринту - совершенно разный.
Если же давать командную оценку, то в истории реализованных задач содержится вся информация, связанная с отвлечениями, отпусками, болезни, профилями загрузки компетенций и про.
4. Переоценивать SP по ходу реализации задачи или уже после завершения
Иногда начиная делать задачу, команда понимает, что ошиблась. И хочется это показать, так как неявно, ребята думают, что их ценят за “сожженные” очки.
Если у менеджмента agile-mindset, то они должны ценить не усилия (по сути затраченные косты), а результат (полученная “прибыль”, выраженную в нужных бизнесу единицах).
5. Переоценивать US в SP, когда задача переносится в следующий спринт
Оценка сама по себе является формой потерь (waste), то есть вложение усилий в получение оценки — это в целом довольно бесполезное (а по факту еще и вредное) занятие. Вкладывать в переоценку — это дважды потери. Лучше в это время написать интеграционный или модульный тест :)
Еще немного про story point и оценку в человеко-часах Мне кажется различие между двумя подходами, а точнее, почему человеко-часы — это не то, что нужно для ответа на вопрос «Когда?», демонстрируется шуткой, которая прошлась по пабликам в этих ваших интернетах:
#SP #StoryPoint