Забудьте об Story Points и используйте их вместо этого

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

Мой бывший менеджер был убежден, что нужно просто установить крайний срок (не только день, но и час дня), а все остальное приложится само собой. Люди будут тянуть дополнительные часы. У него не было более высокого коэффициента успеха; его люди научились скрывать от него неприглядные факты.

Agile ввел Story Points, абстрактную меру работы, которая ничего не говорит вам о том, когда она будет сделана. Все, что вы знаете, это то, что 8 сюжетных пунктов потребуют в два раза больше времени, чем 5. Это не та математика, которую вы изучали в начальной школе. Это передовая наука с щепоткой искусства, и удачливые звезды тоже играют свою роль.

Со временем agile-команды становятся более предсказуемыми. Каждую неделю они приносят одно и то же количество очков, плюс-минус 20 процентов.

Но эта модель по-прежнему ориентирована на работу, на тяжелую работу. Он подсчитывает, сколько раз вы поднимаете молоток и ударяете по гвоздю. Образно говоря, конечно, мы программисты. Мы подсчитываем, сколько веб-форм нам нужно создать и сколько моделей подвергнуть рефакторингу.

Жизнь задачи

Что меня всегда озадачивало, так это жизнь задачи. Это другая форма жизни, чем люди, жирафы или нарциссы. Это не вписывается в нашу модель «родиться, жить и умереть». (Тем не менее, жесткие доски Канбан пытаются втиснуть это в свои столбцы «сделать, в процессе, сделать», которые представляют ту же концепцию этапов жизни.) Вы выбираете задачу, которая выглядит свежей и вкусной. Вы уже видите, что заканчиваете это за день. Подтвердите, нажмите и сдвиньте его на Готово.

Задача встряхивается и вызывает в воображении детскую задачу из-под своего плаща. Он пинается и кричит и требует внимания. Вы должны покормить его и сменить подгузник, прежде чем снова сможете полностью сосредоточиться на его родителях. Задания невероятно хороши тем, что появляются в самый неожиданный момент. Почти готовая задача не является исключением; это может удивить вас в последнюю минуту. (Рассказывал ли я вам историю моего мерж-реквеста, который прошел тесты и уже был одобрен? Я выбрал «сквош-коммиты». Вместо слияния моей ветки Gitlab сказал: «не удалось слить». Надеюсь, это вызвало некоторое сожаление.)

В счастливые дни задача оказывается тривиальной; это занимает половину усилий, которые вы оценили. В счастливые дни, я говорю, однажды в голубой луне. В другие дни вы просто упираетесь в стену, которой еще минуту назад не было. (Говорил ли я вам о докеризации PHP-приложения, которое работало на одном ноутбуке и не работало на другом? Мы изо всех сил пытались найти разницу; это были почти идентичные Макбуки. Я до сих пор озадачен тем, что мы обнаружили: у них были разные чипы. дважды, прежде чем вы выберете Mac на базе M1.)

Обычные старые истории игнорируют эти драматические элементы. Они не отражают вашу победу, когда вы, наконец, идентифицируете чип, являющийся виновником дела Докера. Вы не увеличиваете оценку, когда застреваете на задаче. Мы считаем, что существует объективная мера сложности любой работы. Человеческий фактор не играет в этом роли. Ненавидите ли вы писать десятую веб-форму такого же типа или вам нравится писать для нее генератор кода, это считается неважным.

Как бесчеловечно, можете вы воскликнуть. Или, если вам случится быть менеджером, вы можете найти это профессионально. Но такой подход совершенно ошибочен. Не по моральным соображениям, а по практическим соображениям. Программы пишут люди, у которых есть настроения, желания и навязчивые идеи. Раздражающие факторы, которые мы все еще должны учитывать. Было бы здорово просто ввести вашу IDE

```java

// Это приложение для электронной коммерции, поддерживающее несколько валют

а Github Copilot сгенерирует остальные. Время может быть близко, но мы еще не совсем там.

Победные очки

Вот мое предложение. Используйте победные очки. Когда вы выбираете новое задание, вы указываете, сколько победных очков оно принесет после завершения. Мы можем превратить это в игру с игровыми деньгами. Представьте себе богатого дядю или тетю, у которых есть неограниченный источник Fixbux. Сколько из них вы заслужили бы, если бы выполнили задание?

Каждый раз, когда вы достигаете небольшой подцели, вы можете претендовать на определенное количество победных очков (или Fixbux, в зависимости от того, какой валютой вы предпочитаете играть). Это зависит от вас, сколько вы требуете. Будь честным. Если вы думаете, что это был арахис, требуйте один. Если действительно больно, требуйте десять или сто. Не будь робким. Вычтите свою претензию из «цены», которую вы установили, и продолжайте работу.

Что происходит, когда вы натыкаетесь на стену или просто понимаете, что все идет не так гладко, как вы предсказывали? Простой. Вы поднимаете ставки. Вы претендуете на большее. Вы пишете небольшую записку своему воображаемому дяде или тете: «Я требую 5 дополнительных Fixbux для этой задачи, потому что Gitlab squash не удалось выполнить коммит. Это заноза в пите». Помните, что у них неограниченные ресурсы. Они дадут вам все, что вы требуете.

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

В конце периода времени вы смотрите на свои транзакции и видите, что вся история разворачивается в цифрах. Маленькие победы и блокирующие. Вы можете отслеживать, сколько Fixbux ежедневно попадает в ваш кошелек. Что такое среднее и насколько велико отклонение? Ваша первоначальная оценка задачи в Fixbux или победных очках со временем улучшится.

Чем этот подход отличается от традиционных историй? Он субъективен и гордится этим. Мы не ожидаем, что два разработчика будут выделять на задачу одинаковое количество Fixbux. Мы хотим видеть представленные личные различия. DevOps вызывает у Алисы мурашки по коже, в то время как Бобу это до смерти надоедает? Цифры должны это показать.