Раз! Два! Левой! Правой!
Дважды два! Очень просто
Измеряются удавы –
Пятью пять – Любого роста!Григорий Остер, «38 попугаев»
Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи «Почему оценка задач сломала Agile».
У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.
При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».
Story Points
Обычно, термин Story Points не переводят на русский, а используют английский оригинал. Вероятно потому, что не удается подобрать удачное русское слово, хорошо описывающее суть явления. Например в переводе вышеуказанной книги Сазерленда используется термин «баллы» – звучит по-русски, но суть от этого не сильно понятнее. Английский вариант хотя бы идентифицируется легко. В общем, пока никакого русского перевода не прижилось.
Но что же услышит простой, непросвещенный agile-коучем человек, и какой диалог у вас получится, если вы ему скажете:
– Мы провели Planning Poker [??]: первая задача – 38 Story Point`ов [???], вторая – 10 и третья – 5.
– Пиииип Простите, что вы сказали?
Как-то так, вероятно.
С другой стороны, большинство русскоязычных людей воспитывалось на советских мультиках. Зная это, мы можем попытаться вместо заумных англицких терминов использовать записанные на подкорку шаблоны. Например, если вы скажете кому-нибудь: «У нас есть три задачи: 38 “попугаев”, 10 и 5», то даже без дополнительных пояснений, человек скорее всего поймет вас именно так, как и должен: «У нас есть три “удава”. Сколько метров – непонятно, но очевидно, что первый – самый длинный, второй почти в четыре раза короче, а третий короче еще в два раза». И это именно то, что нужно.
Так что же это за «птица» такая?
Метод «38 попугаев»
«Теперь нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Как я уже говорил, люди довольно плохо справляются с такого рода расчетами, но мы хорошо умеем делать другое – сравнивать один размер с другим, то есть определять относительную оценку.»
Джефф Сазерленд, «Scrum. Революционный метод управления проектами» (МИФ, 2015)
Итак, оценить длину удава трудоемкость задачи в Попугаях достаточно просто:
Для начала нужно выбрать нашего Попугая. Тут все просто: им назначается самая маленькая (по нашим ощущениям) задача.
-
Далее, мы сравниваем с ней остальные задачи: Если вот это задача – 1 Попугай, то вон та побольше («мартышка») – 2 Попугая, вон тот «слоненок» – 5, а «удав» – 38.
Подчеркну: мы не пытаемся угадать, сколько часов нам понадобится на выполнение этих задач – мы их просто сравниваем!
-
Первая итерация (первый Спринт):
Мы прикидываем, какие из оцененных задач мы сможем выполнить в течение Спринта.
По его окончании мы смотрим, сколько из них мы в действительности сумели выполнить.
Сумма Попугаев по этим задачам (полностью готовым) – это производительность нашей команды (за Спринт). На нее мы и будем ориентироваться при следующем планировании.
Через пару-тройку итераций вы будете хорошо понимать вашу производительность – сколько в среднем Попугаев вы можете выполнить за спринт. Это и будет ваше Velocity (скорость).
Понятно, что это упрощенная схема, но сейчас моя цель – объяснить суть.
Что же дает нам производительность команды, измеренная в абстрактных единицах?
Планирование
Очевидно, что имея численную оценку задач в Попугаях, и зная, сколько этих самых Попугаев мы можем сделать за спринт, мы можем составить план реализации. Причем это будут не догадки, а статистические данные по работе конкретной команды над конкретным проектом в конкретных условиях.
Постоянное улучшение
Не стоит также забывать, что в Scrum`е помимо основного (производственного) цикла, есть еще и цикл Постоянного Улучшения. Когда на Ретроспективе вы решаете, что нужно что-либо улучшить в процессе, то неплохо бы иметь критерий эффективности. И изменение Velocity – это прекрасный индикатор. Очевидно, что полезные изменения должны приводить к увеличению это показателя. Причем вы прямо в процентах можете посчитать, насколько увеличилась продуктивность команды.
Плюшки
Все это, в свою очередь, дает дополнительные бонусы:
Для бизнеса – это предсказуемость и контролируемость процесса,
-
Для команды:
Неплохой аргумент попросить премию :)
Мотивация: нормальные люди хотят гордиться своей работой, поэтому если ваша команда будет видеть, что из недели в неделю они работают лучше, то это крайне позитивно повлияет на рабочий настрой.
Аргументация для Scrum-энтузиастов: открывается возможность рассматривать внедрение Scrum в организации как инвестиционный проект. Например, если в команде 5 человек, и мы добавляем выделенного Скрам-мастера (со средним по команде окладом), то увеличение Velocity хотя бы на 20% (и поддержание такого темпа), по сути окупит для компании дополнительную ЗП. Если же вам удастся со временем выйти на завет Джеффа Сазерленда и делать двойную работу за половину времени*, то рентабельность такой затеи улетит в небеса.
* – В оригинале книга Сазерленда называется «Scrum: The Art of Doing Twice the Work in Half the Time», что можно перевести как «Скрам: искусство “деланья” двойной работы за половину времени»
Отвечая на критику
Прежде чем двинуться дальше ещё раз кратко:
В процессе Оценки мы сравниваем остальные задачи с ней (и между собой) – «всех: удава, мартышку, слоненка – измеряем в попугаях».
Во время планирования спринта мы берем на себя обязательства.
После спринта мы смотрим сколько Story Point`ов («попугаев») мы реально выполнили.
Среднее значение за последние пару-тройку спринтов – это и есть Velocity.
Теперь давайте сравним это с алгоритмом из статьи:
Обычно это происходит так:
- Тимлид: Сколько времени потребуется для реализации X?
- Разработчик: Предполагаю, дня три.
- Тимлид: Как думаешь, что сможешь завершить за оставшиеся два дня?
Иногда оценку задач проводили в условных единицах (Story Point), а иногда в относительных (с помощью техники Planning Poker). Но в любом случае цель состояла в том, чтобы договориться, сколько задач человек может выполнить за спринт.
Т.е. «Обычный» вариант – это классический подход к оценке в человеко-днях и такая же классическая «торговля». Scrum тут совершенно ни при чём.
Но даже когда появляются Story Point`ы, коментарии только возрастают:
Во-первых, Story Point – это не абстрактная единица, а вполне конкретная: это наша задача, в нашем проекте, и сравнивать мы ее будем с другими нашими задачами.
Hidden text
Возможно, что проблема в терминологии. Возможно, это какие-то другие Story Point`ы, другая интерпретация того же термина. Возможно. Но учитывая, что у людей они не сработали, разбираться в них не вижу смысла.
Далее появляются относительные оценки и Planning Poker. Это уже значительно ближе к тому, о чем писал я. Действительно, обычно для организации процесса оценки используется именно «Покер планирования». Т.е. во время Planning Poker`а команда определяет оценки в Story Point`ах. Тут опять же некоторая путаница в терминах, но да бог с ними! Что там дальше с сутью?
А сутью тоже не все так гладко. Наша цель – не «договориться, сколько задач человек может выполнить за спринт», а выснить, сколько задач команда реально выполняет за спринт с нужным качеством. Если статистика вас не устраивает, то именно для этого и существует цикл Постоянного Улучшения: на спринт-ревью вы обсуждаете, что можно улучшить. А «торговля» – это из другой оперы.
Так что, проблема все-таки не столько в инструменте, сколько в недопонимании, как его использовать. И на самом деле в исходной статье достаточно много таких заблуждений. Возможно, имеет все-таки смысл хотя бы кратко подсветить их и если уж не разобрать все, то хотя бы дать ориентир, куда копать, если вы наблюдаете подобные симптомы. Но это уже в следующей статье, так что если интересно – пишите в комментах и подписывайтесь.
Комментарии (12)
infund
00.00.0000 00:00+2Заранее прошу прощения.
mgvoronin Автор
00.00.0000 00:00Ну, кстати, да. Вариант. Вот только часы убрать, а вместо них в первом спринте выбрать тот самый "изъян" или "изи", и все остальное мерять относительно них.
Ну и второе (это уже вкусовщина, но все же), если следовать рекомендациям того же Сазерленда (хотя есть и другие), то числа следует взять из ряда Фибоначчи. Так проще выбирать, потому что между 8 и 12 разница ещё заметная, а вот между 20 и 24 – уже не столь очевидная. А так у вас будет 8, 13, 21, 34. В командном "покере" выбор будет проще, дискуссий меньше, а среднее число – хорошим результатом.
Но так, вообще, идея (обозначения) мне нравится. Утащу-ка к себе. Спасибо! :)
Ares_ekb
00.00.0000 00:00+4TL;DR Я не спец по скраму, но у меня ощущение, что он ориентирован на специфические проекты и компании, что в нём делается большой акцент на совершенно вторичных и ритуальных вещах. И мне ближе организация проекта, когда есть один техлид, который видит проект целиком, сам за 5 секунд оценивает любую задачу и основное внимание уделяет тому, чтобы не было проблем с декомпозицией задач, оценкой результат/усилия. А не тому во сколько попугаев какой разработчик какую задачу оценил.
Поток сознания, который раскрывает идею немного полнее:
У нас всё как-то проще: 8ч, 16ч, 24ч, 32ч, 40ч. Меньше оценок нет, потому что даже в самой простой задаче могут возникнуть неожиданные сложности, да и смысла на столько дробить задачи нет. Больше оценок тоже нет, потому что такие задачи нужно точно декомпозировать.
Если требуется более долгосрочное планирование на годы, то делается оно точно так же, только шкала другая: 1 неделя, 2 недели, 1 мес., 2 мес., 4 мес., 6 мес., 12 мес., 24 мес., ... Если такая грубая оценка не устраивает, то можно разбить задачу на более мелкие и оценить их.
Никаких "попугаев", "покера", "торговли", длительных обсуждений и т.п. нет, потому что техлид хорошо представляет кто с какой скоростью работает, сколько обычно времени на такие задачи требуется. И ему достаточно 5 секунд, чтобы оценить большинство задач. Если задача сложная и в неделю не укладывается, то ставится задача сначала провести исследование, рассмотреть разные варианты решения, оценить их и завести уже более конкретные задачи. Такая исследовательская задача обычно легко оценивается и укладывается в неделю.
Если и исследовательская задача не укладывается в неделю, значит заводим ещё более высокоуровневую задачу типа "определить направления для исследования". И так до бесконечности, чтобы люди не уходили на месяц в себя и не впадали в депрессию. Во всех этих скрамах почему-то делается большой акцент на то, что разработчик сам оценивает задачу и типа зуб даёт выполнить её в срок. А если "пацан" слово не сдержал, то можно "предъявить" ему за это и т.д. Я конечно утрирую, нагоняю жути и всё искажаю. Но для меня всё это выглядит как перекладывание ответственности за планирование с менеджмента на разработчиков. Или на худой конец как геймификация, типа чтобы разработчикам не было скучно давайте поиграем в попугаев.
А по моим личным ощущениям проблемы обычно связаны с совершенно другим:
неумение декомпозировать задачи, когда люди пытаются в рамках одной задачи сделать всё, не могут её разбить на простые небольшие шаги, завязают в этом болоте и выгорают, срываются сроки,
неумение соотносить важность задачи и усилия на её решение, типа месяц потратить на безуспешное исправление бага, который ни на что не влияет, а потом не успеть сделать гораздо более важные и при этом простые задачи.
Короче, если на проекте всё хорошо с декомпозицей и оценкой результат/усилия, то это уже путь к успеху. На мой взгляд, например, задача техлида следить за этими вещами и помогать разработчикам советами типа "давай разобьем эту задачу на шаги, иначе ты тут закопаешься", "давай сначала проведем исследование, оценим какие вообще есть варианты решения", "забей на этот бред, мы тут потратим месяц, а профита ноль" и т.д.
Это всё моё личное мнение, я безусловно ошибаюсь и я не спец по скрамам, аджайлам и т.д. Но у меня (наверняка ошибочное) ощущение, что там большой акцент делается на каких-то ритуалах. И что вообще всё это ориентировано на проекты, где есть карикатурный менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу, карикатурные разработчики, которые ничего не умеют кроме кода, и при этом у каждого из них ещё десять параллельных проектов, которые меняются каждый месяц и вообще все эти люди только неделя как познакомились.
Блин, вызывайте срочно бригаду, у автора этого комментария тяжелейший приступ графомании :) Просто немного накипело. Я сталкивался с ситуациями, когда люди приходят с проектов, на которых как-раз практикуется скрам и остальное. И начинают наводить хаос в проекте.
Например, спрашивают у разработчика сколько нужно времени на решение такой-то задачи. Разработчик отвечает, да, это полная ерунда, одну строчку поправить, я бы за полдня сделал. Потом эта задача отдаётся другому разработчику и каждый день его спрашивают, ну, что когда, почему так долго, задача же простейшая. А задача вообще не простейшая, если получится её сделать за пару недель, то это просто отлично. Очевидно разработчик не очень рад такой ситуации. Да, да, конечно просить оценить задачу нужно было второго разработчика, а не первого. Но фишка в том, что первый дольше на проекте и ему доверия у менеджера больше. Но другая фишка в том, что даже этот опытный разработчик не видит картину в целом и если бы задачу попросили оценить техлида, то он бы оценил её адекватно. Но менеджер техлиду не верит, он привык работать по скраму и обсуждать сроки с разработчиками напрямую. Потом возникают идеи, раз человек не справляется, давайте отдадим эту задачу первому разработчику, он же обещал за полдня сделать. А если не сделает, то уже с него спросить можно. Ради чего всё это?
В общем, по моим ощущениям разработчики могут или сильно недооценивать сложность/важность задачи или наоборот сильно переоценивать. И когда менеджер как на рынке ходит между прилавками и у разных разработчиков узнаёт стоимость задач, то ничего хорошего в этом нет. А если это делает техлид, то и время не тратится на оценку, и никакой аукцион не проводится между разработчиками типа я это сделаю за 5 попугаев, а я работаю быстрее и лучше и сделаю за 2 попугая, и потом разработчики не испытывают никакого стресса, если задача оказалась сложнее и они не успели в срок (это скорее провал техлида).
mgvoronin Автор
00.00.0000 00:00+1В принципе, вы описали вполне разумные процессы, но вот в этом суждении:
у меня (наверняка ошибочное) ощущение, что там большой акцент делается на каких-то ритуалах. И что вообще всё это ориентировано на проекты, где есть карикатурный менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу, карикатурные разработчики, которые ничего не умеют кроме кода, и при этом у каждого из них ещё десять параллельных проектов, которые меняются каждый месяц и вообще все эти люди только неделя как познакомились.
вы, на мой взгляд, не попали практически нигде ????
большой акцент делается на каких-то ритуалах – Да, ритуалы в Скраме есть, но суть-то все-таки не в них. Как говорится в гайде: “Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum”.
менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу – В терминах Скрам – это скорее про Владельца продукта, но даже если он не особо технически прошаренный человек, то при использовании именно “попугаев”, а не часов, он вполне себе будет способен оценить масштаб задачи. У меня есть даже положительный опыт, когда Владелец продукта участвовал в голосовании по оценке вместе с командой. И хотя это не канонично, но это позволило ему синхронизироваться с командой. Через некоторое время мы отказались от этой практики, но на начальном этапе это было полезно, на мой взгляд.
разработчики, которые ничего не умеют кроме кода – Тут вообще все ровным счетом наоборот! Есть даже такой принцип T-shaped people – т.е. люди, у которых есть основная специализация, но подхватить могут много где. И чем фулстековее у вас члены команды, тем большего вы сможете добиться.
у каждого из них ещё десять параллельных проектов – опять же все наоборот: крайне не рекомендуется работать более, чем над одним проектом. Сазерленд, по крайней мере, на своих курсах ссылался на исследования, о том, что переключение контекстов для Каждого дополнительного (параллельного) проекта снижает продуктивность команды на 20%.
меняются каждый месяц и вообще все эти люди только неделя как познакомились – и снова нет :) Стабильная команда – это важный принцип.
mgvoronin Автор
00.00.0000 00:00+1Я сталкивался с ситуациями, когда люди приходят с проектов, на которых как-раз практикуется скрам и остальное. И начинают наводить хаос в проекте.
Например, спрашивают у разработчика сколько нужно времени на решение такой-то задачи.
Я не знаю, у кого какие цели были, но с точки зрения теории
Оценка должна быть не абсолютная (в часах), а относительная (в попугаепоинтах), и время при этом определяется по статистике выполнения обязательств (с необходимым качеством!)
Спрашивать нужно не у разработчика, а у команды (3-9 человек)
Спрашивать нужно не у абы какой команды, а у той, которая будет выполнять задачу.
AntonCtrannik
00.00.0000 00:00Ненавижу эти стори пойнты :) у нас в проекте сейчас как раз их внедрили - и вот 4 или 5 спринтов мы не факапили сроки.
Думаю подход оценки подойдёт когда делают однообразные задачи. Например мы решили что стропойнт - создать новый метод для обращения по http и получить из БД набор данных, теперь давайте на основе этой задачи оценим сколько времени займет написание алгоритма для обработки 5 петабайтов данных в HDFS :)
В итоге мы решили что один стори пойнт = создать метод для обращения по http = 2 дня, и уже когда появилась привязка к дням - стали более-менее укладваться в спринт :)
Но это лишь моё мнение молодого лида :)mgvoronin Автор
00.00.0000 00:00мы решили что стропойнт - создать новый метод для обращения по http и получить из БД набор данных, теперь давайте на основе этой задачи оценим сколько времени займет написание алгоритма для обработки 5 петабайтов данных в HDFS
Конечно комфортнее, когда сравниваемые задачи различаются в разы, а не в десятки и сотни раз. И на практике так обычно и происходит: вы выбираете поинт, потом оцениваете 2-3, 10, 15 и потом уже 25. Но даже если разброс очень большой, то ряд Фибоначчи вам поможет. В этом случае, вам надо выбрать между 13, 21, 34, 55 и 89. Это существенный разброс, так что выбор не такой уж и сложный, даже если у вы ещё не оценивали промежуточные размеры. А далее работает "покер": каждый член команды дает свою оценку, и если разброс небольшой (не более двух ступеней), то берется среднее, в противном случае – те, кто поставил крайние оценки, обосновывают свою точку зрения – без дискуссии! – и переголосовываете. Если разброс все ещё большой, то повторяете (один раз, т.е. максимум три голосования) и берете среднюю оценку.
Это не занимает много времени, а работает обычно лучше, чем экспертная оценка в часах. Мне сложно сказать, что пошло не так именно у вас, но для этого и существует Спринт-ревью: вы обсуждаете, что не получилось, и исправляете. Если ошиблись в оценке, то это повод чему-то научиться…
mgvoronin Автор
00.00.0000 00:00и уже когда появилась привязка к дням - стали более-менее укладваться в спринт :)
Тут хочется вспомнить фразу Сазерленда, которую он на своих курсах повторял наверное каждые полчаса: “Teams that Finish Early Accelerate Faster”. Имеется в виду, что команда должна выполнять свои обязательства до конца спринта (всегда, а не “более-менее”). Если не получилось, то в следующий раз следует брать меньше. И только поняв, сколько реально вы можете выполнять работы с нужным качеством, вы сможете расти быстрее, используя спринт-ревью и постоянное улучшение.
Но опять же, я не знаю, как у вас все устроено. Вам на месте, конечно, виднее.
oleko
00.00.0000 00:00А мы свой покер планирования пилим. Можно попробовать пооценивать. Пока у нас только Фибоначчи, но может и 38 попугаев сделаем))))
Ivnika
Признаться думал что в статье какие-то секреты раскрыты… А так кто пользуется Agile — тот знает. Было бы интереснее узнать о методах улучшения качества оценки задач.
mgvoronin Автор
Как показывает изначальная статья, это не так. При этом она (статья) ведь не старая: оригинал - конца 22 года. Так что до сих пор люди пользуются Agile и Scrum, но толком не понимают, что такое Story Points - в голове каша. Соответственно, моя статья – это попытка объяснить Суть, используя знакомые для многих образы. Поэтому и уровень сложности указан «Простой».