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

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

Оценка в стори поинтах - это оценка не времени выполнения, а сложности и объёма задачи. Это меньший стресс.

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

Да, это как раз в описании скрама и описано. Только вот по факту комитмент всё равно остается. Иначе бы не меняли скорость разработки с количестве сторипоинтов в спринт. Да и дедлайн - это спринт, только если изначально объем задачи спринт не превышал, но это неправильно с точки зрения скрама.

А чтобы не было стресса надо учится работать с оценкой как исполнителям, так и менеджерам. Почему-то со сторипоинтами учатся, а с оценкой не хотят. :)

Более того, в компаниях встречаются квартальные и полугодовые планирования, на которых оцениваются какие задачи удастся реализовать в указанный период. Т.е. коммитмент и дедлайны есть на этом уровне. )

А еще не очень как-то копипастить свой ответ к разным комментариям на похожую тему. Еще хуже - использовать нейросеть для общения с реальными людьми.

Я как-то и не обратил внимание, что это нейронка ответила. :( Возможно и статьи генерирует бот.

Да еще ладно бы по делу. А то ерунда какая-то. У меня возникло подозрение насчет нейронки, когда я этот же ответ получил. Заглянул в соседний пост - а тут вот, слово в слово.

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

В любом случае - незачет 😁

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

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

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

И вот вы сами говорите про дедлайн в реальных днях. Если стейкхолдеру назвали срок 3 недели, то он ожидает задачу через три недели. Это дедлайн. Более того, для разработчика это ещё хуже, так как не он так оценил задачу, а ему просто сверху спустили этот дедлайн, но он есть. К тому же, без навыка самостоятельной оценки он не сможет понять реалистичный это срок или нет.

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

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

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

И идея спринтов в том, чтобы задачи были завершены к его концу, если задача в спринт не помещается, то её надо дробить на части и делать по частям в рамках спринта. Или увеличивать длительность спринтов, если, в среднем, задачи не удается сделать за один спринт. Как вариант, просто отказаться от спринтов.

Как много классных мыслей) давай попробую по порядку ответить.

Учиться оценивать задачи - надо всем, не вопрос. Вопрос в том, что оценка сложности (или трудозатратности) не то же самое, что оценка сроков.

Сложность оценить команда может и должна, но вот сроки это не только про сложность задачи, но и про процессы, ресурсы, зависимости, приоритеты.

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

Про дедлайны)

Стейкхолдеру срок называет тимлид и он же за сроки отвечает. Команда в этом случае концентрируется на задаче, про дедлайн даже не знает.

Про идею спринтов.

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

Неужели и правда для ответа используется ИИ бот )

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

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

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

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

Про спринты.

Конечно, можно не дробить задачу и делать её несколько спринтов подряд, но в чем тогда ценность спринтов?

А вот это, Алексей, очень хороший вопрос) его обсудим подробно чуть позднее.

Ценность спринтов в этом случае точно сомнительна. Но можно использовать их как условные циклы обратной связи. На них можно завязывать какие-то командные активности и что-то исключительно внутреннее. Кароч исходить из потребности и целесообразности.

Насчет оценки и сроков я всё же не стал бы завязываться на 100% ответственность менеджера. Считаю, что целесообразнее вовлекать в процесс планирования исполнителей, чтобы они были в контексте и видели картину чуть шире. Это помогает давать более точные прогнозы исходя из реальности и приоритетов, а не оценки в чистом виде. Ну и выше от бота было утверждение, что исполнитель не должен знать о дедлайне - это я отрицаю категорически. Страдать не должен, но знать обязан. Иначе снова потеря контекста.

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

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

К тому же, если в компании есть возможность текущему лиду команды расти дальше, то участие сотрудников в определении сроков и приоритетов, позволит подготовить нового лида.

Уже стало интересно, а почему думаете, что отвечает бот?

Форма построения фраз очень похожа на то как отвечает ИИ ассистент при рассуждениях. Ранее, при общении с людьми я подобного не встречал. :)

Ответ ваш веселит меня:) Зато, если выгонят с позиции CTO, то пойду ботом работать.