Мне нравится говорить, что я, возможно, изобрел стори поинты (story points) и если действительно изобрел, то сегодня мне жаль. Давайте рассмотрим подробнее, что я думаю о стори поинтах сейчас. По крайней мере один из нас точно заинтересован в моих мыслях.

Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога – очень распространенная в скраме практика.

Распространенная – хотя бы до той степени, в которой скрам-практики понимают истории. Ранее я уже писал о том, как правильно использовать пользовательские истории. Здесь мы обсудим стори поинты.

В экстремальном программировании (ХР), истории изначально оценивались во времени: времени, которое потребуется на завершение разработки истории. Мы быстро начали использовать то, что сейчас называется “идеальные дни”, которые неофициально означали “сколько дней потребуется паре до завершения, если их наконец-таки оставят в покое”. Мы перемножали идеальные дни и “фактор нагрузки”, чтобы получить реальное время до завершения разработки. Фактор нагрузки обычно составлял примерно три: три реальных дня тратилось, чтобы завершить работу одного идеального дня.

Мы называли наши оценки в днях, и обычно не произносили слово “идеальные” вслух. По этой причине, наши стейкхолдеры часто не могли понять, каким образом нам нужно три дня, чтобы завершить работу одного дня, или, с другой стороны, почему мы не могли выполнить 50 “дней” работы за три недели.

Так что, насколько я помню, мы начали называть наши “идеальные дни” обычными “поинтами”. Таким образом, оценка в три стори поинта означала, что историю завершат примерно за 9 дней. Так или иначе, мы использовали поинты только чтобы понять, какой объем работы мы можем взять в итерацию, поэтому когда мы говорили что это примерно 20 поинтов, никто особо не возражал.

Возможно это я предложил изменить название. Если я действительно сделал это, сейчас мне жаль. Вот некоторые из моих нынешних соображений на эту тему. Я писал их своему коллеге Саймону, который спросил:

Ты действительно сожалеешь, что стори поинты были изобретены, или ты просто осуждаешь их неправильное использование, когда люди не полностью понимают относительные размеры?

Я ответил, что:

Я точно осуждаю их неправильное использование
Я думаю, что использовать их для прогнозирования “когда работа будет сделана” – это в лучшем случае плохая идея
Я думаю, что сравнивать как реальные трудозатраты накладываются на оценки – это в лучшем случае пустая трата времени
Я думаю, что сравнивать команды на базе качества оценок или скорости (velocity) – это вредно
Давайте взглянем более подробно

Некоторые подходы к “Agile” действительно рекомендуют нормализовывать значения стори поинтов между командами преследуя упрощение процесса планирования. На первый взгляд это кажется достаточно разумным, в реальности оказывается слишком легко попасть в ловушку сравнения команд. И организации часто в эту ловушку попадают.

Сравнение

В первую очередь, даже если команды “почти одинаковые”, у каждой из них есть собственный набор компетенций и своя рабочая среда. Так что если они посмотрят на две истории, которые выглядят одинаково и одна команда скажет, что это двойка, а другая скажет, что это шестерка – это попросту бесполезная информация. И это точно не самый полезный способ сравнения команд.

Теперь попробуем разобраться в ситуации. Сначала посмотрим, а действительно ли обе ситуации сравнения были идентичными, а потом уточним, быть может команд с более высокой оценкой нуждалась в помощи, которую мы могли предоставить. Такой подход был бы отличным примером. Явно или неявно выносить вердикт, что “более медленная” команда неким образом хуже или менее профессиональна – вот это стало бы очень плохим примером, который в реальности, к сожалению, является нормой.

Я думаю, что когда есть две команды, производящие ценность, для менеджеров сравнить их – непреодолимое искушение. Я думаю, что оно настолько непреодолимое, что я готов отказаться от идеи стори поинтов и даже всей концепции оценки историй, где это возможно. Мы еще вернемся к вопросу как работать с меньшим количеством оценок. Кроме того, на эту тему есть другие статьи.

Отслеживание

Для многих менеджеров существование оценки подразумевает существование “реальных трудозатрат”, а значит нужно сравнить оценку и реальные трудозаты и убедиться, что они совпадают. Если не совпадают – значит нужно учиться оценивать лучше.

Для меня важная черта Реального Agile – выбрать несколько вещей в работу, а потом оперативно их сделать. Ключевой вопрос – это как найти самые ценные вещи и как сделать их быстро. Сделать быстро обычно превращается в поставку маленьких кусочков ценности и динамичное итерирование. Оценка стоимости историй не особо в этом помогает, если вообще помогает.

Так что если существование оценки заставляет менеджмент сместить фокус с поставки ценности на улучшение процесса оценки, значит оно забирает внимание с настоящей цели – быстро доставлять реальную ценность.

Из-за этого я прихожу к мысли о том, что оценок, будь то в поинтах или времени, стоит избегать.

Давление

Близко к отношениям оценок и реальных трудозатрат находится закономерное давление из-за желания менеджмента получить “больше”. Сколько бы команда ни поставила ценности, этого мало. Нужно больше, больше, больше.

Лучший способ поставлять ценность – это не больше, больше, больше. Лучший способ – это поставлять ценность часто и маленькими партиями. Если вместо оценивания историй мы поделим их на “достаточно маленькие” кусочки, тогда мы сможем прийти к равномерному потоку поставки ценности, доставляя без перерывов.

Фокусировка на “больше” мешает увеличению ценности. Продавливание увеличенных поставок практически без вариантов приводит к плохому результату: команда пытается ускориться и делает это в ущерб качеству кода или тестированию. Вскоре они начинают поставлять больше дефектов, замедляются из-за увеличенного количества переделок чтобы починить дефекты, замедляются еще сильнее из-за того что качество кода стремительно ухудшается. Положение становится хуже и хуже, давление увеличивается и всё превращается в погоню за провальными ситуациями.

Поскольку оценки связаны с применением чрезмерного давления, я предпочитаю избегать их.

Я скажу больше: я предпочитаю вовсе отказываться от планирования спринтов или итераций. Мы работаем не для того, чтобы освоить бюджет предстоящих недель: мы работаем, чтобы составить короткий список важных вещей для ближайшей поставки.

Предсказывая готовность

Обычная практика – составить список необходимых фич, обдумать их и решить, что они составят следующий релиз нашего продукта. Конечно же, следующий вопрос – “когда всё это будет готово?”.

Ответ на него – никто не знает. Мы можем проделать большую работу над своим незнанием. Иногда этим действительно стоит заняться, например, когда на кону большой контракт, ожидающий оценки. Однако, когда мы работаем в сфере разработки решений для внутренних или внешних заказчиков, лучший вариант – поставлять небольшое количество ценности очень часто, а не ждать монструозных релизов, которые бесконечно отодвигаются на потом.

Намного лучше выбрать для следующего релиза недалёкую дату и включить в этот релиз максимальное количество ценности. Оценка мешает этой задаче, будь она в стори поинтах, Мишках Гамми или даже времени. Если оценки возможно избежать, по моему мнению, надо это сделать.

Декомпозиция

Появляется вопрос, если мне не нравится оценка историй, то что же мне нравится? Отвечаю – мне нравится декомпозиция историй. Это практика нарезания больших историй на маленькие кусочки. Главное – чтобы эти маленькие части несли как можно больше ценности, но требовали минимум времени на реализацию – в идеале, меньше дня или всего пару часов.

Я не буду препираться с читателями на тему оценивания в процессе декомпозиции. Если ваша команда в тайне проводит оценку и никому об этом не говорить – тогда проблем с этой оценкой скорее всего не возникнет, в стори поинтах она или во времени. И конечно же, знать разницу между “наверное достаточно маленькая” и “наверное недостаточно маленькая” и знать как различаются “три дня” и “один день” – это совершенно непохожие вещи.

Кроме того, есть одна хитрость. Я упоминал ее в Getting Small Stories и в Slicing, Estimating, Trimming. Я выучил ее у Нила Киллика (Neil Killick): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.

Конечно же, на тему оценки есть много других статей. Просто пройдите по ссылке, которую я оставил выше – там больше информации, чем вы можете представить.

Предсказывая будущее

Но … разве не существует вполне закономерной необходимости знать, сколько займет релиз продукта, и разве не нужно для этого оценивать? Возможно оценка и нужна, только не оценка историй. Вероятно, у вас даже не будет требований, проработанных до уровня историй. А если и будут – то наверняка они получатся громоздкими и в основном бесполезными.

Конечно же, если оценки нужно делать, то нужно их делать. То, что я делаю или как я представляю, что вам нужно делать – это всё мои теории. В конце концов – вам решать, как действовать, чтобы достичь успеха в вашей конкретной ситуации. Тем не менее, я думаю, что есть более хороший путь.

Во-первых, подумайте о нескольких самых важных качествах следующего релиза. Обсудите проблемы, которые они решают и как ваше ПО может помочь решить эти проблемы. Обсудите простейшие решения, которые могут хотя бы немного помочь. Нам не нужно решать сразу всё: зачастую, даже небольшая помощь может привести всё в движение.

Во-вторых, подумайте о ближайшем дедлайне, к которому вы могли бы поставить что-то из хороших решений. Установите этот дедлайн и приступайте к работе.

В-третьих, декомпозируйте важные решения на маленькие части и реализуйте их. Наверняка у вас легко получится сделать эти части размером в один день, или меньше. Работайте только над самыми важными частями: не пытайтесь реализовать все решение до упора. Ваша цель – начать думать в ключе “Если мы сделаем вот эту небольшую функцию, то наш Пользователь Джек уже сможет этим пользоваться”. Потом завершите эту функцию и дайте Пользователю Джеку попробовать. Наша цель – максимально приблизиться к непрерывной поставке ценности. И делать это нужно быстро.

Нам важно сделать поставляемую ценность настолько осязаемой, чтобы наш Владелец Продукта или другие стейкхолдеры спешили поскорее вывести это в релиз. Тогда … тогда мы будем на правильном пути, с оценкой историй или без нее.

Подытожим

Что ж, если я и изобрел стори поинты, наверное, мне немного жаль. Но не сильно жаль. Я действительно думаю, что их часто используют неправильно и мы избежим многих проблем, если вообще откажемся от оценок историй. Если в вашей компании стори поинты не несут ценности – я бы предложил от них отказаться, потому что это пустая трата усилий. С другой стороны, если они вам очень нравятся, то, что ж, полный вперёд!

За перевод огромное спасибо Максиму Фролову.

Обдумывая стори поинты