Основные особенности, которые наблюдаются в командах при использовании #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), то есть вложение усилий в получение оценки — это в целом довольно бесполезное (а по факту еще и вредное) занятие. Вкладывать в переоценку — это дважды потери. Лучше в это время написать интеграционный или модульный тест :)
Один из наших скраммастеров (СМ) в школе СМ прислал свои заметки по вопросу #StoryPoint (если разрешит, опубликую тут). И сразу родилась ассоциация с замечательной статьей
"Velocity in Scrum, Actually" by Gunther Verheyen
1️⃣ Допустим, мы мерим velocity (скорость работы команды), но если это скорость — суть количество не полностью готовой работы (читай «не в пром», «не полезна пользователю), то ее надо признать нулевой.
2️⃣ И можно сколько угодно тешить себя иллюзией, что у нас-де «настоящий» #scrum, но пока нет жесткого DoD (definition of done, критериев "готовности" того или иного элемента продукта), все эти циферки, измеренные в чем угодно (хоть в часах, хоть в "попугаях") не более, чем метрики тщеславия, которые не позволяют получить от scrum то, для чего он был сделан!
Дяденька Гюнтер оч серьёзный. Читать - просто must.
"Velocity in Scrum, Actually" by Gunther Verheyen
1️⃣ Допустим, мы мерим velocity (скорость работы команды), но если это скорость — суть количество не полностью готовой работы (читай «не в пром», «не полезна пользователю), то ее надо признать нулевой.
2️⃣ И можно сколько угодно тешить себя иллюзией, что у нас-де «настоящий» #scrum, но пока нет жесткого DoD (definition of done, критериев "готовности" того или иного элемента продукта), все эти циферки, измеренные в чем угодно (хоть в часах, хоть в "попугаях") не более, чем метрики тщеславия, которые не позволяют получить от scrum то, для чего он был сделан!
Дяденька Гюнтер оч серьёзный. Читать - просто must.
Больше всего я люблю, когда появляются scrum master’а (SM), готовые выдавать хороший контент.
Ниже без правок заметки от Халецкого Валеры по поводу Story Point.
————————
“После каждой статьи про сторипоинты в комментариях первое сообщение примерно такое: «Отличная статья, только не понятно, чем сторипоинты лучше часов».
Вообще, это вопрос философский. Люди целые книги на эту тему пишут. Например, «Agile Estimating and Planning». Но я постараюсь коротко. Проблема еще состоит в том, что на каждый аргумент сторонника оценки в SP, найдется контраргумент сторонника оценки в часах. Спорить тут бесполезно, нужно почувствовать разницу в подходах.
Во первых, оценка в SP – это относительная оценка размера задач между собой. Это делать намного проще и есть масса исследований на тему того, как плохо люди оценивают абсолютные величины и как хорошо – относительные. Во вторых, оценка в часах и оценка в сторипоинтах - это не измерение одного и того же параметра с помощью разных шкал. Это измерение разных параметров. На сколько я понимаю, именно этот момент остается не раскрытым. Попробую это объяснить.
Для начала простой вопрос. В чем измеряется расстояние? Если первое, что пришло на ум, это световой год, то для вас SP противопоказаны. В жизни достаточно часто можно услышать «Наш офис находится в 5 минутах ходьбы от метро». В школе за такое ставили 2, так как любой учитель физики знает, что расстояние должно быть выражено в метрах. Однако, расстояние в минутах нам даже удобнее, когда нужно где-то оказаться к определенному времени.
Другой пример. Нужно наполнить бассейн на даче. В теории все просто: берем шланг; включаем воду; смотрим, сколько набралось за определенное время; оцениваем, сколько еще таких интервалов понадобится; забываем про бассейн на рассчитанное время.
Хотя расстояние и объем имеют свою единицу измерения, оказывается, что иногда эти величины удобно выражать через время. Но, это косвенная оценка со множеством допущений и ограничений. Те же 5 минут пешком
летом легко превращаются в 15 минут зимой в снегопад или гололед.
Первый вывод: оценка трудоемкости в часах – это косвенная оценка, зависящая от множества факторов.
Вернемся к бассейну. По факту оказалось, что шланга нет. Но есть пара ведер непонятного объема, которыми приходится носить воду самому. И тут давать оценку минутами как минимум странно, потому что мы считаем принесенные ведра. И то, что мы принесли 20 ведер за первые 10 минут совсем не гарантирует, что мы принесем еще 100 за следующие 50 минут. Однако, поработав час со всеми перекурами и причитаниями, мы сможем сделать достаточно точную оценку времени на заполнение бассейна.
Второй вывод: для измерения объема разработок нужно свое «ведро».
Отсюда и родился сторипоинт, как более естественная единица измерения объема работ на проекте. У метра есть свой эталон, у литра есть свой. А эталонный сторипоинт назначается для каждого проекта свой.
И на последок, тот самый «реальный плюс»: Сторипоинт позволяет делать очень быстро достаточно точную оценку. Как и за счет чего – это уже отдельная история и об этом очень много написано.”
————————
#StoryPoint
Ниже без правок заметки от Халецкого Валеры по поводу Story Point.
————————
“После каждой статьи про сторипоинты в комментариях первое сообщение примерно такое: «Отличная статья, только не понятно, чем сторипоинты лучше часов».
Вообще, это вопрос философский. Люди целые книги на эту тему пишут. Например, «Agile Estimating and Planning». Но я постараюсь коротко. Проблема еще состоит в том, что на каждый аргумент сторонника оценки в SP, найдется контраргумент сторонника оценки в часах. Спорить тут бесполезно, нужно почувствовать разницу в подходах.
Во первых, оценка в SP – это относительная оценка размера задач между собой. Это делать намного проще и есть масса исследований на тему того, как плохо люди оценивают абсолютные величины и как хорошо – относительные. Во вторых, оценка в часах и оценка в сторипоинтах - это не измерение одного и того же параметра с помощью разных шкал. Это измерение разных параметров. На сколько я понимаю, именно этот момент остается не раскрытым. Попробую это объяснить.
Для начала простой вопрос. В чем измеряется расстояние? Если первое, что пришло на ум, это световой год, то для вас SP противопоказаны. В жизни достаточно часто можно услышать «Наш офис находится в 5 минутах ходьбы от метро». В школе за такое ставили 2, так как любой учитель физики знает, что расстояние должно быть выражено в метрах. Однако, расстояние в минутах нам даже удобнее, когда нужно где-то оказаться к определенному времени.
Другой пример. Нужно наполнить бассейн на даче. В теории все просто: берем шланг; включаем воду; смотрим, сколько набралось за определенное время; оцениваем, сколько еще таких интервалов понадобится; забываем про бассейн на рассчитанное время.
Хотя расстояние и объем имеют свою единицу измерения, оказывается, что иногда эти величины удобно выражать через время. Но, это косвенная оценка со множеством допущений и ограничений. Те же 5 минут пешком
летом легко превращаются в 15 минут зимой в снегопад или гололед.
Первый вывод: оценка трудоемкости в часах – это косвенная оценка, зависящая от множества факторов.
Вернемся к бассейну. По факту оказалось, что шланга нет. Но есть пара ведер непонятного объема, которыми приходится носить воду самому. И тут давать оценку минутами как минимум странно, потому что мы считаем принесенные ведра. И то, что мы принесли 20 ведер за первые 10 минут совсем не гарантирует, что мы принесем еще 100 за следующие 50 минут. Однако, поработав час со всеми перекурами и причитаниями, мы сможем сделать достаточно точную оценку времени на заполнение бассейна.
Второй вывод: для измерения объема разработок нужно свое «ведро».
Отсюда и родился сторипоинт, как более естественная единица измерения объема работ на проекте. У метра есть свой эталон, у литра есть свой. А эталонный сторипоинт назначается для каждого проекта свой.
И на последок, тот самый «реальный плюс»: Сторипоинт позволяет делать очень быстро достаточно точную оценку. Как и за счет чего – это уже отдельная история и об этом очень много написано.”
————————
#StoryPoint
Еще немного про story point и оценку в человеко-часах Мне кажется различие между двумя подходами, а точнее, почему человеко-часы — это не то, что нужно для ответа на вопрос «Когда?», демонстрируется шуткой, которая прошлась по пабликам в этих ваших интернетах:
#SP #StoryPoint
Про #userstory и 8 способов их написания с примерами
User story вошли в жизнь очень многих продуктовых команд, у некоторых так сильно, что некоторые считают, что story есть в scrum (это слово чаще всего используют, когда отвечают на вопрос «как мы работаем?») 🤦♂️
🏛 Классика
Поэтому записью
никого не удивишь.
Но все же приведу пример,
Я как начинающий агент-изменений хочу регулярно читать статьи на канале 2%, чтобы расширять свою картину мира
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую:
Например,
[Читатель канала 2%] пишет комментарий к публикации, чтобы помочь автору исправить ошибки (фактические или орфографические)
🤏 Совсем короткая запись
Для особо ленивых, когда цель или ценность самоочевидна (или, возможно, прописана в epic), можно опустить последний блок — так мы получим самый краткий, но все еще "классический" формат записи.
Например,
Отключить уведомления в канале 2%
❓Метрический вопрос
То есть в требовании мы узнаем, случился ли некоторый <Факт>?
Например,
Сколько просмотров постов с картинками в сравнении постов без картинок в канале 2%?
⌨️ Утверждение, ввод данных
Например,
Отложенный пост в канале 2% изменил дату и/или время публикации
🔁 Изменение
Например,
Вместо того, чтобы писать писать все посты самому, в канале 2% будут писать несколько проверенных и резервированиях авторов
💡 Полезное изобретение
Например,
Увеличить количество подписчиков в канале 2% за счет публикации смешных мемасиков, которые будут шарить подписчики
🚧 История про работу
Например,
Когда скраммастер готовится к тренингу или к воркшопу, он может быстро найти все публикации по теме #StoryPoint
Презентацию по теме можно найти у Андрея Шапиро тут и на его сайте
User story вошли в жизнь очень многих продуктовых команд, у некоторых так сильно, что некоторые считают, что story есть в scrum (это слово чаще всего используют, когда отвечают на вопрос «как мы работаем?») 🤦♂️
🏛 Классика
Поэтому записью
Я как <Роль/Персона>, хочу <Действие/Функцию>, чтобы <Цель/Ценность>никого не удивишь.
Но все же приведу пример,
Я как начинающий агент-изменений хочу регулярно читать статьи на канале 2%, чтобы расширять свою картину мира
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую:
[Роль] <Действие в форме глагола от третьего лица>, чтобы <Цель/Ценность>Например,
[Читатель канала 2%] пишет комментарий к публикации, чтобы помочь автору исправить ошибки (фактические или орфографические)
🤏 Совсем короткая запись
Для особо ленивых, когда цель или ценность самоочевидна (или, возможно, прописана в epic), можно опустить последний блок — так мы получим самый краткий, но все еще "классический" формат записи.
Например,
Отключить уведомления в канале 2%
❓Метрический вопрос
<Вопросительное слово> <Объект> <Обстоятельство> То есть в требовании мы узнаем, случился ли некоторый <Факт>?
Например,
Сколько просмотров постов с картинками в сравнении постов без картинок в канале 2%?
⌨️ Утверждение, ввод данных
<Объекты> — <Новый статус>Например,
Отложенный пост в канале 2% изменил дату и/или время публикации
🔁 Изменение
Вместо <Старый способ действий>, <Новый способ действий>Например,
Вместо того, чтобы писать писать все посты самому, в канале 2% будут писать несколько проверенных и резервированиях авторов
💡 Полезное изобретение
<Полезное действие/Отрицание нежелательного эффекта> в <Контекст> за счет <Принцип работы>Например,
Увеличить количество подписчиков в канале 2% за счет публикации смешных мемасиков, которые будут шарить подписчики
🚧 История про работу
Когда <контекст>, я хочу <Мотивация>, так что <Ожидаемый результат>Например,
Когда скраммастер готовится к тренингу или к воркшопу, он может быстро найти все публикации по теме #StoryPoint
Презентацию по теме можно найти у Андрея Шапиро тут и на его сайте
#ШколаAgile #ВтораяСтупень #Оценка #ManDay #StoryPoint
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Абсолютная vs Относительная оценки»📏
Что такое оценка задач и для чего она нужна? Как правильный подход к оценке помогает в планировании, и какие могут возникнуть дисфункции при выборе неправильного подхода вы узнаете на этом воркшопе. На воркшопе предлагается предлагается освоить различные методы оценки задач.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, как вы оцениваете задачи: абсолютным или относительным методом и есть ли у вас команды, которые перешли на #NoEstimate?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Александром Гусевым в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Абсолютная vs Относительная оценки»📏
Что такое оценка задач и для чего она нужна? Как правильный подход к оценке помогает в планировании, и какие могут возникнуть дисфункции при выборе неправильного подхода вы узнаете на этом воркшопе. На воркшопе предлагается предлагается освоить различные методы оценки задач.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, как вы оцениваете задачи: абсолютным или относительным методом и есть ли у вас команды, которые перешли на #NoEstimate?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Александром Гусевым в рамках запроса о помощи community.