Это вещь появилась не как изначальная часть SDLC, она абсолютная искусственная и в тоже ничего не означает. Это поразительно. Она с одной стороны обязательно (чуть ли не на уровне стандарта) и призвана решать одну проблему, а с другой стороны — создает кучу других.

Как вы, наверное, догадались я собрался говорить о Story Points (SPs) в скраме. Пару хороших слов об очередной "серебряной пули" в создании ПО (этому меня научили, ибо нельзя в говне находить одно только говно, надо "взвешенно и тщательно" отыскать и положительные моменты).

pros

Самый жирный плюс. Проблемы вашей команды закончились, теперь никто не дергает вас "давайте перейдем, давайте перейдем на SPs". Все окончено, вы повержены и днище пробито, и вы уже перешли. Теперь только PROFIT.

Никто не будет отрицать, что если команда использовала SPs, то Scrum Master будут козырять графиками в Jira, показывать как член velocity команды растет квартал к кварталу. Итак, зафиксировали — красивые графики от Jira (будем честными с часами таких не выйдет).

Третья вещь — теперь можно занять команду игрой в карты в конференсе (это если офис открыт и нет COVID-а с заменой электронной подделкой неповторимого оригинала).

cons

Зачастую, никто в команде не понимает, какая "та самая маленькая задача", которую стоит оценивать как "минимум". Даже если ты задокументируешь в виде wiki-страницы с четким описанием и изъятиями, что это типовая(-вые) задача(-и) на 1 это (допустим) SQL-процедура с базовым SQL, в сопровождении и поставкой как минимум на тестовые стенды. Или какой-то базовый "фиксик" ETL-ки. В нее не входит то-то и то-то. Так вот, проблема в том, что понятие минимальной задачи меняется со временем (потому что команда растет, продукты развиваются, процессы усовершенствуются итд). И этот факт вносит такую корреляцию между фактом и ожиданием, что даже ведущие инженеры охреневают. Но терпят, чтоб только отьестали. И главное — все понимают это ничего не решает.

Второе, зачастую только какие-то примитивные команды работают сами с собой. Да есть какие-то проекты, которые завязаны только во внутрь (типа работы по техдолгу или внутренние проекты). Но, обычно тебе нужны два QA с команды А по проекту А, нужны аналитик с команды Б, и допустим, какие-то работы по В и Г из таких-же команд. И вот вторая проблема — SPs не всеобъемлющая процедура. То есть можем применять только внутри команды и то только с ограниченным списком ролей (ниже напишу). И по старинке все также "Когда ресурс Васи даст нам, то о чем мы договорились? — До пятницы обещает дать"

Третье (и пожалуй закончу, ибо выходит много текста). А вы никогда не замечали что эта хрень индифферентна для дизайнеров, аналитиков, аниматоров, devOps, QA-ев итд. Не, когда это было в часах всех все устраивало, но со SPs .

---

Задайте вопрос — что изменится в команде, если просто отказаться от SPs и банально перейти на время в днях (нравится покер — нет проблем каждая карта в днях) без этой наносной дичи типа маечки, трусики, "фибоначчи" (Какой еще фибоначчи? Половина твоей команды вайтишники и вышку для них учить в западло. какой еще "фибоначчи"?) Ничего не изменится, ведь художников, иллюстраторов, аниматоров, итд вы не занимаете этой х..й фибоначчи? Правда ж?