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

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

Для команды размером 10, это практично?

Сколько времени это занимает?

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

Оценка должна проводиться людьми, которые будут выполнять работу, а не менеджером, который вынужден выполнять свои обязанности, однако ваш инстинкт верен в том, что более полдюжины человек будут часами спорить по этому поводу. В идеальном мире вам действительно нужно разбить команду так, чтобы в одной команде было не менее 4 и не более 7 - 5 идеально, ИМХО.

Если по какой-либо причине это абсолютно невозможно - и вам необходимо применить 5 причин по этой причине, прежде чем признать, что это невозможно, - то команда из 4-5 человек должна быть выбрана командой для проведения оценок от их имени.

На мой взгляд, вы НЕ должны заниматься планированием релизов как команда из 10 человек. Скорее всего, вы закончите гигантской встречей, на которой 6-8 человек будут чувствовать себя совершенно не связанными и скучающими. Добавьте к этому истощение 3-4 часов, запираемых в комнате вместе. И учтите, что если говорят 10 человек, у вас слишком много разговоров. Если они не говорят, вы можете не получить ценный вклад.

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

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

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

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

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

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

Я на самом деле являюсь частью нескольких проектов (и нескольких команд) в качестве лидера, и есть несколько, которые более 10. Практически во всех проектах, над которыми я работаю, планирование выпуска осуществляется ведущими и бизнес-аналитиками. Однако в нашей ситуации БА не являются менеджерами, поэтому менеджеры на самом деле не участвуют в планировании выпуска.

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

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

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

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

Как бы у меня ни было желание быть вовлеченным во все, это просто не продуктивно.