исследуй
проектируй
Улучшай

Не стесняясь раскрыть мою oldscoolность или выдать себя флёром миллениальности, утверждаю, что проблема натягивания "землекопов на поинты" актуальна для многих компаний.
В учебниках математики прошлого века часто встречались задачки, главными героями которых были землекопы, часто требовалось вычислить время или количество тех самых землекопов, которое потребуется для выполнения задачи в определенных условиях.

Нередко несмотря на Agile/Scrum, 2 недельные спринты, в конечном итоге задачи измеряются в человеко-часах.

Что хорошего в стори-поинтах? Кажется, стори-поинты помогают решить проблему погрешности в оценках задач, когда оценку дает не тот, кто будет писать код.
Часто практика когда оценки задачам навешивает лид, исходя из собственного понимания как задачи, так и скиллов того, кому задача будет определена в разработку.
Однако, есть такая неизбежная штука, как искажение картинки, когда мы думаем, что мы хорошо понимаем другого человека, и знаем о его возможностях сколько-нибудь так же, как если бы мы говорили о себе самих.

Здесь важно понимать, редкий человек способен дать адекватную оценку даже самому себе, что говорить о других

Стори-поинты же позволяют сгладить эту погрешность, потому как они не про человеко-часы и не про часы вовсе - они про объем задачи.

Отчего же так сложно интегрировать Agile/Scrum идеологию в коммерческие компании, которые создают коммерческие продукты? Не номинально, а реально внедрить, пересадить все слои компании.

Если коротко, то проблема в том, что бухгалтер Лидия Ивановна выплачивает заработную плату, исходя из отработанных человеко-часов. И для того, чтобы ответить на вопрос финансового директора, например: "Сколько нам будет стоить распил монолита на микросервисы?" Тех лид дает оценку во временной шкале: 6 месяцев, 1 год и так далее; оценка в формате "40 полных спринтов" - не является понятной.

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

Дело в том, что Agile/Scrum не терпит задач ради задач, очень сложно уживается в контексте длинных релизов, когда поставка ценности на рынок происходит раз в год, например. В данных условиях целеполагание играет важную роль. Компания всегда руководствуется прибылью, продуктовая компания может рассчитывать на прибыль только в тому случае, когда продукт несет ценность, когда изменения в продукте усиливают позицию на рынке, в идеале дают ей несправедливое конкурентное преимущество.

Потому на каждом уровне решения задачи должна быть предельно понятна ценность: зачем мы это делаем, что должны получить в конце?
Ещё до написания первой строчки кода US, маркетинг и продажи знают, как реализованная ценность изменит профиль продаж.

В цикле приоритезации задач и целей компания должна придерживаться самурайской дискиплины.

Давайте вернёмся к стори-поинтам и объемам, и к пониманию того, что время-вода, а объем - это ценность, а ценность может быть поставлена по-разному - это про банальное: "вам шашечки или ехать?".

Представим себе условную продуктовую команду, которая пилит продукт, который, в свою очередь, уже представлен на рынке и продается.
Команда находится в планировании следующего 2 недельного спринта.
Команда подводит итоги, и, допустим, у команды нет длинного хвоста с прошлого периода: нормально спланировались - нормально сделали.
Продакт вкидывает цели и ценности на спринт, команда расслаивает их таким образом, чтобы найти возможности - происходит балансировка, в результате накидываются варианты решения. Таким образом, планирование спринта - это не одна формальная встреча, чтобы раскинуть "покер" и дать оценку - это серия встреч, благодаря которой команда находит возможности поставить ценности в планируемом спринте.

После того как будет свормирован список ценностей и примерно набросан скелет того, как ценность может быть поставлена, происходит напиливание задач на компетенции, и, главное - оценка объема каждой US. Команда оценивает в стори-поинтах. Если на шаге оценки мы слышим "невозможно оценить, очень много неизвестного" - это значит, что мы ошиблись на шаге до - ценность размыта, слишком обобщенно сформулирована, вроде всем понятна, но и непонятна тоже.

Хороший ценз для того, чтобы определить, ценность сформулирована достаточно или нет - попытаться продать воображаемому клиенту, или сформулировать концепцию продажи. Если сделать это не удается - значит, ценность не найдена, значит, скорее всего, деньги компании будут сначала потрачены на то, чтобы закодить что-то непонятное, а потом потрачены средства на маркетинг и продвижение чего-то непонятного, с вполне понятным финалом - подсчёт убытков.

Представим себе, что команда создала несколько US на спринт, нарезала задачи по компетенциям под каждой из них, для того, чтобы в конце спринта US была поставлена на PROD, и продукт приобрёл добавленную ценность.
Каждая US через оценку команды получила свое значение story-poins - это объем задачи, которую команда готова (aka способна) затащить за 2 недели.

Кажется вне зависимости от того, какой таск-трекер используется, в нем возможно установить как story-poins, так и трекать фактическое время, потраченное на решение вложенных в US задач.

Таким образом, таск-трекер при определенной гигиене и дисциплине ведения задач, может являться источником данных как для построения бухгалтерских или финансовых отчетов - про зарплатный бюджет "землекопов", так и про результативность команды: какой объем ценности команда может поставлять на 2 недельный спринт.

Объем ценности - это фичи, преобразованные в рыночные возможности.
То есть, не "Запилить API идентификации" - это решение, а "Реализовать инструмент идентификации пользователя", который стоит на рынке 30 000 рублей за лицензию, и весит в единицах объема разработки: "24 story-poins"

В формате, если все настроено, то результат измерим в деньгах - как это удобно коммерсам, в объемах - как это удобно разработке, в ценности - как выбирает клиент.