Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Раз! Два! Левой! Правой!
Дважды два! Очень просто
Измеряются удавы –
Пятью пять – Любого роста!Григорий Остер, «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`ах. Тут опять же некоторая путаница в терминах, но да бог с ними! Что там дальше с сутью?
А сутью тоже не все так гладко. Наша цель – не «договориться, сколько задач человек может выполнить за спринт», а выснить, сколько задач команда реально выполняет за спринт с нужным качеством. Если статистика вас не устраивает, то именно для этого и существует цикл Постоянного Улучшения: на спринт-ревью вы обсуждаете, что можно улучшить. А «торговля» – это из другой оперы.
Так что, проблема все-таки не столько в инструменте, сколько в недопонимании, как его использовать. И на самом деле в исходной статье достаточно много таких заблуждений. Возможно, имеет все-таки смысл хотя бы кратко подсветить их и если уж не разобрать все, то хотя бы дать ориентир, куда копать, если вы наблюдаете подобные симптомы. Но это уже в следующей статье, так что если интересно – пишите в комментах и подписывайтесь.
