Раз! Два! Левой! Правой!Дважды два! Очень простоИзмеряются удавы –Пятью пять – Любого роста! Григорий Остер,  «38 попугаев» Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile». У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum. При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений». Обычно, термин Story Points не переводят на русский, а используют английский оригинал. Вероятно потому, что не удается подобрать удачное русское слово, хорошо описывающее суть явления. Например в переводе вышеуказанной книги Сазерленда используется термин «баллы» – звучит по-русски, но суть от этого не сильно понятнее. Английский вариант хотя бы идентифицируется легко. В общем, пока никакого русского перевода не прижилось. Но что же услышит простой, непросвещенный agile-коучем человек, и какой диалог у вас получится, если вы ему скажете: – Мы провели Planning Poker [??]: первая задача – 38 Story Point`ов [???], вторая – 10 и третья – 5.– Пиииип Простите, что вы сказали?Как-то так, вероятно. С другой стороны, большинство русскоязычных людей воспитывалось на советских мультиках. Зная это, мы можем попытаться вместо заумных англицких терминов использовать записанные на подкорку шаблоны. Например, если вы скажете кому-нибудь: «У нас есть три задачи: 38 “попугаев”, 10 и 5», то даже без дополнительных пояснений, человек скорее всего поймет вас именно так, как и должен: «У нас есть три “удава”. Сколько метров  –  непонятно, но очевидно, что первый – самый длинный, второй почти в четыре раза короче, а третий короче еще в два раза». И это именно то, что нужно. Так что же это за «птица» такая? «Теперь нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Как я уже говорил, люди довольно плохо справляются с такого рода расчетами, но мы хорошо умеем делать другое  –  сравнивать один размер с другим, то есть определять относительную оценку.»   Джефф Сазерленд, «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  –  это маленькая задача («попугай»).В процессе Оценки мы сравниваем остальные задачи с ней (и между собой)  –  «всех: удава, мартышку, слоненка  –  измеряем в попугаях».Во время планирования спринта мы берем на себя обязательства. После спринта мы смотрим сколько Story Point`ов («попугаев») мы реально выполнили. Среднее значение за последние пару-тройку спринтов  –  это и есть Velocity. Теперь давайте сравним это с алгоритмом из статьи: Обычно это происходит так:  - Тимлид: Сколько времени потребуется для реализации X?  - Разработчик: Предполагаю, дня три.  - Тимлид: Как думаешь, что сможешь завершить за оставшиеся два дня? Иногда оценку задач проводили в условных единицах (Story Point), а иногда в относительных (с помощью техники Planning Poker). Но в любом случае цель состояла в том, чтобы договориться, сколько задач человек может выполнить за спринт. Т.е. «Обычный» вариант  –  это классический подход к оценке в человеко-днях и такая же классическая «торговля». Scrum тут совершенно ни при чём.  Но даже когда появляются Story Point`ы, коментарии только возрастают: Во-первых, Story Point  –  это не абстрактная единица, а вполне конкретная: это наша задача, в нашем проекте, и сравнивать мы ее будем с другими нашими задачами.  Возможно, что проблема в терминологии. Возможно, это какие-то другие Story Point`ы, другая интерпретация того же термина. Возможно. Но учитывая, что у людей они не сработали, разбираться в них не вижу смысла. Далее появляются относительные оценки и Planning Poker. Это уже значительно ближе к тому, о чем писал я. Действительно, обычно для организации процесса оценки используется именно «Покер планирования». Т.е. во время Planning Poker`а команда определяет оценки в Story Point`ах. Тут опять же некоторая путаница в терминах, но да  бог с ними! Что там дальше с сутью?  А сутью тоже не все так гладко. Наша цель  –  не «договориться, сколько задач человек может выполнить за спринт», а выснить, сколько задач команда реально выполняет за спринт с нужным качеством. Если статистика вас не устраивает, то именно для этого и существует цикл Постоянного Улучшения: на спринт-ревью вы обсуждаете, что можно улучшить. А «торговля»  –  это из другой оперы. Так что, проблема все-таки не столько в инструменте, сколько в недопонимании, как его использовать. И на самом деле в исходной статье достаточно много таких заблуждений. Возможно, имеет все-таки смысл хотя бы кратко подсветить их и если уж не разобрать все, то хотя бы дать ориентир, куда копать, если вы наблюдаете подобные симптомы. Но это уже в следующей статье, так что если интересно – пишите в комментах и подписывайтесь.