В продолжение к статье “Ваши Стори Поинты (Story Points/SP) не работают!” раскрываю дальше, почему же SP большинству не помогают, а чаще даже вредят. Я написал о том, чего не стоит делать с SP. Но это не значит, что во всём мире внезапно стало хорошо. Давайте копать Стори Поинты дальше.
На мой взгляд, фундаментальные и блокирующие полезные свойства SP сосредоточены буквально в 3 глобальных ошибках, встречающихся практически повсеместно. Самое забавное, что описанные мной ошибки разжевываются на конференциях, в кулуарах, на митапах и в индивидуальных коучинговых сессиях. Но как об стенку горох.
Продолжу верить в то, что не существует необучаемых, просто им недостаточно раз повторили необходимое.
Факт заключается в том, что тем, кто совершает эти ошибки, “и так норм”, потому что, получая и используя эти данные в своих интересах, они предоставляют “вождям” красивые картинки. А всё именно потому, что вместо того, чтобы учиться принимать реальность, большинство менеджеров с самого начала карьеры учатся показывать красивые данные в бесконечных презентациях, основанных на статистике.
На тему статистики есть крылатое выражение: “Существуют три вида лжи: ложь, наглая ложь и статистика.”.
Конечно, это не значит, что статистика вредна, она полезна, но, как и любой другой инструмент, им надо уметь пользоваться. А талантливые корпоративные менеджеры, похоже, учатся, как показать статистические данные так, чтобы правление любой корпорации “брызгало” кипятком при виде визуализированных в презентациях статистических данных.
Смертный грех №1 - корпорации пытаются натянуть всё на бабло
Как там Шнур поёт: “Я не спорю, бабки нужны всем и всегда, Но зачем так в…”, несомненно всё стоит денег, и, конечно, надо считать затраты, но натягивание ненатягиваемого приводит, в лучшем случае, просто к ошибкам.
Корпорации зачем-то пытаются избавиться от часов, перейдя на SP, а потом ещё конвертируют их в деньги.
Возможно, какой-то отбитый на всю голову менеджер даже в личных и домашних делах всё проецирует на деньги, но это не всегда разумно. Деньги, несомненно, важны, но иногда репутационные риски, надежность или забота о безопасности имеет большее значение, чем простое “а у них дешевле”.
В итоге на “отчетных концертах” часто слышим: “В таком-то квартале Команда 1 завершила историй на 125 SP и компания заработала на этом 500 млн, Команда 2 завершила историй на 85 SP и принесла компании 700 млн, а Команда 3 завершила историй на 325 SP и принесла компании 120 млн.”... где в конце квартального отчета главный босс говорит что-то типа “Команда 2 - красавчики! Команда 1 тоже молодцы, но есть к чему стремиться. А вот с Командой 3 надо что-то сделать. “Главный по KPI”, пожалуйста, разберись и предоставь мне отчет с предложениями об изменениях, чтобы улучшить показатели.”
Я сам был свидетелем похожей ситуации, после чего 70% инженеров “Команды 3” почти одномоментно уволились, и внезапно “Команды 1 и “2” в следующих кварталах показали колоссальные убытки, так как “Команда 3” в большей части занималась разработкой бэк офиса, который чудом приносил дополнительную косвенную прибыль, а основная работа была направлена на поддержание и совершенствование процессов в том числе “Команд 1 и 2”. Конечно, всё было сильно сложнее, но если даже не вдаваться в не очень качественную работу руководителей, попытка стандартизировать подход и натянуть всех по одинаковому лекалу с непониманием использования показателей привело к катастрофическим последствиям.
Практически ни в одной компании мира нет одинаковых SP в разных командах. И ни один зрелый Лидер не будет просить показать ему SP для того, чтобы впоследствии сравнить эти показатели между командами.
SP - это командная метрика! Не корпоративная, не соревновательная, не презентационная!
Если хотите как-то сравнивать команды и попытаться внедрить “спортивный дух”, сравнивайте план-факт. При этом перцентиль тоже не всегда может быть одинаковый для разных команд. Например, устоявшаяся команда разработки и начинающая должны иметь разный “зеленый коридор” хорошего соотношения план/факт, команду поддержки нельзя сравнивать с командой разработки и т.д. Но это отдельная тема статьи для командных метрик.
Смертный грех №2 - переоценка незавершенных стори от внедренцев SAFe
Независимо от того, что SAFe считаю замечательным “инструментом” масштабирования, подход к переоценке незавершенных задач в SP считаю совершенно бессмысленной тратой времени. Более того, это совершенно вредный инструмент как для команды, так и для компании в целом.
Сейчас на меня могут налететь толпы сертифицированных SAFe экспертов со словами: “А как же мы поймём утилизацию?”, “А как же нам по простому запланировать следующий спринт?”, “А как команда поймёт, сколько они сделали и сколько осталось?”... на всё на это хочется задать встречный вопрос: “А вы зачем таких несведущих нанимаете, что они могут как-то планироваться/утилизироваться только путем элементарных математических вычислений?”.
Переоценку эталонных Историй периодически делать действительно необходимо. Переоценку историй, которые в итоге делались сильно быстрее или сильно дольше, тоже можно. Это входит в классическую гигиену работы команд.
Но переоценку незавершенной истории, которая переехала в другой спринт, считаю категорически недопустимым.
Я всегда привожу следующий пример.
Задача: Преодолеть пропасть
Оценка SP: 8
Если вы за спринт преодолели пропасть на 75% (в теории выполнено 6 SP) и даже если вы при этом не разбились и зависли в четверти пути до её преодоления - это совершенно не значит, что вам реально осталось в следующем спринте 25% (в теории 2 SP).
Во-первых, на этом 25%ном отрезке пути может возникнуть неопределенность, которая может превратиться в дополнительные 75% работы.
Во-вторых, и это самое важное, для потребителя вы не принесли никакой ценности. Сделанные вами 75% потребитель никак не увидит, а готовый результат он увидит только когда вы завершите работу целиком на 100% и никак иначе.
И это не говоря о том, что “сверху” внезапно может прилететь директива о приостановке работы над этой уже почти завершенной на 75% функциональностью, и теперь задача звучит как “нам надо спустить слона на 13SP вниз”.
Таким образом, обещанные командой 8SP и псевдо сделанные ей на 6SP превращаются в абсолютный ноль. Так что я считаю, что вся незавершенная работа, даже сделанная на 99,99% = 0 до момента её полного завершения.
Можете возразить в классической форме: “Ну мы же потом вернемся к завершению приостановленной задачи и нам останется доделать всего 2 SP.”
Даже если такое произойдёт, а это обычно бывает крайне редко, то скорее всего у вас изменятся какие-то данные для ранее поставленной задачи, возможно поменяется команда, возможно изменится размер пропасти, может быть у вас появится какая-то специализированная технология или экспертиза и множество других параметров. Т.е. вам в любом случае придется анализировать задачу заново, оценивать её и реализовывать с нуля. Даже если не с нуля, то всё-равно работы будет больше, чем если бы команда сразу её доделала.
Даже если недоделанная история переезжает в следующий спринт, есть вероятность не завершить её, потому что кто-то может заболеть, уволиться и т.п.
Так что если история переезжает, то она как минимум должна переехать с той полной оценкой, которая была изначально.
А все эти попытки вычленить в SP, что сделано, но пока не завершено, это попытка прикрыть некомпетентность менеджеров, которые не смогли качественно запланировать бюджеты на недостаточно зрелые команды.
Меня совершенно не интересует, что ты делалЬ этот спринт, так как то, что ты обещал - не сделалЬ. При этом возможно уже никогда не сделаешь обещанного. Так что интересует и может быть “положена в копилку” только на 100% завершенная работа.
Кстати, частые встречаемые полумеры в стиле “Ну они же делали… давайте не будем команду демотивировать… ну они расстроятся…” тоже приводят к катастрофическим для компании последствиям и превращают любую разработку в вечно незавершенное творение. Такие ситуации, как правило, вместо готового результата и приводят к отмазкам “Ну мы же работали…”.
А в дополнение наброшу, что для исправления ситуации с незавершенными историями есть такие инструменты, которые помогают провести грамотную декомпозицию и решить 90% вечно кочующих историй. Также можно определить критерии завершенности историй, проанализировать флоу и непосредственно команду или использовать другие инструменты и практики, но о них в других статьях.
Смертный грех №3 - каждый специалист в команде делает сколько-то SP в спринт
Я недоумеваю, когда в разговорах слышу что-то типа: “Я делаю в спринт 13SP, Петя 10SP, Вася 15SP и т.п… и получается, что если никто не уйдёт в отпуск, то велосити нашей команды составит 85SP”.
НЕЕЕТ! Это так не работает!
И да! Каждый из членов команды точно влияет на велосити.
НО! SP используется для комплексной командной оценки истории.
Надо вспомнить про Аксиомы и принять, что Пользовательская История, оцененная в 3SP, включает в себя работу бэкенд и фронтенд разработчика, ручного тестировщика, автотестировщика. И только после завершения всего цикла эти 3SP кладутся в копилку командного результата.
Не может быть такой ситуации, что бэк с фронтом сделали свою часть и можно списать 2SP, так как во время проведения ручного или автоматизированного тестирования История может вернуться обратно разработчикам на любой этап и потребовать дополнительной работы неопределенного объёма. И при этом эта история всё также может остаться оцененной в 3SP… а может и превратиться в 8 :)
Давайте представим ситуацию:
Команда состоит из бэк и фронт разработчиков, плюс один тестировщик. Каждый из специалистов может решать только свои специфические задачи.
Каждый из специалистов считает, что он делает по 10SP в Спринт.
Таким образом можно вывести гипотезу, что велосити команды 30SP.
А теперь давайте представим, что любой из них заболел. И сколько тогда будет велосити команды, когда бэк и фронт завершили свою часть работы, но при этом заболевший тестировщик не сделал ничего?
Действительно считаешь, что 20SP можно считать завершенной работой?
Подумай ещё раз, если у тебя будет получаться результат больше 0, то думай, пока не получится 0.
Как всегда, конечно, есть исключения. Если инженер обладает всем набором экспертиз, сам может запилить бэк, фронт, протестировать и написать качественные автотесты, при этом залить всё это на прод, то вы и есть то самое исключение. И если вы такой, то вы и так со мной согласны и, скорее всего, работаете где-нибудь в яндексовкгугломейлфейсбуке.
Кроме чудо-разработчиков-фуллстэков есть ещё и понятие T-шейпности (T-Shaped). А также появились Пи, М и Комб -шейпности. Возможно когда-нибудь подробно раскрою суть темы, но если вкратце, это когда кроме основной специализации есть одна или несколько дополнительных. Т.е. у фронт-разработчика дополнительный скилл - ручное тестирование, а у бэкендера - дополнительные скилы автоматизированного тестирования и системного анализа. Если в команде с такими специалистами временно выбывает один из её участников, то команда будет продолжать полноценно функционировать, принося ценность, но, конечно, со значительно меньшей производительностью, чем полноценная команда.
Если бы большинство компаний не совершали этих 3 грехов, то им жилось бы намного комфортнее.
Описанные мной три глобальные ошибки ни в коем случае не говорят о том, что нет других, а для некоторых ситуаций даже более значимых. Но эти, по моему мнению, являются тремя Ангелами Апокалипсиса проблем с SP, из-за которых ваша трансформация скорее является профанацией, а не чем-то реальным.
Кстати, проверить то, насколько корректно используются собираемые статистические данные и в том числе по SP, достаточно просто. Надо провести аудит презентаций с различных мероприятий компании на сопоставление с используемыми трекинговыми системами, и если внезапно окажется, что трекинговая система не используется, а всё фиксируется руками, если данные из систем внезапно стали недоступными из-за переезда/обновления/итп, если в процессе аудита появятся фразы “Ну мы тут считаем немного по-своему, так что не обращайте внимания на цифры”. То это гарантирует проблемы в будущем, и необходимо как можно быстрее их фиксить.
А ещё на моей практике был случай, когда моя команда настроила небывалый до этого уровень прозрачности, на что получила от одного из ТОП-менеджеров такой вердикт: “Нет, такой уровень прозрачности - это для нас слишком. Нас же потом за это жестко накажут.”, но это уже другая история :))
P.S.
Если в вашей компании используется что-то из критикуемого мной, то это не обязательно должно гореть на костре святой инквизиции Agile, просто, возможно, вы используете какой-нибудь “<компанинейм>джайл” и/или работаете в компаниях, в названиях которых есть слова банк, нефть, газ, строй. В общем, не обращайте внимания, это не для вас, я просто вам завидую. Я точно это знаю, я в таких работал :)
P.P.S.
Сложность восприятия материала в этой статье 7 из 10.