Скрам для специалистов команд

Scrum лучше всего подходит для команд с членами общего профиля, то есть для команд, в которых минимум 2 человека могут выполнять одинаковые задачи. Моя главная задача - найти хорошие решения для адаптации схваток (что сохранить, что удалить, что улучшить) для команд, состоящих из специалистов?

Предположим, у вас есть команда из 5 разработчиков (не реально, только для примера):

1. Один математик с сильными навыками в Си;
2. Один разработчик БД;
3. Один веб-разработчик;
4. Один разработчик UX / GUI;
5. Один архитектор программного обеспечения;

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

1. Бесполезные весенние планы: действительно, когда математик говорит, что конкретное задание стоит 2 балла, никто не может голосовать против него;
2. Бесполезная метрика скорости команды: поскольку каждый может распределить любое количество баллов по своим задачам, скорость вычисления не имеет смысла;
3. Замените ежедневные скрам-встречи еженедельными (более длительными) схватками: поскольку каждый член команды работает над своими собственными задачами, ежедневные скрам-встречи должны быть действительно важны для поддержания «командного духа». Тем не менее, ежедневные схватки должны длиться около 15 минут. Этого явно недостаточно для понимания того, что другие делают и будут делать. Более того, математик в большинстве случаев будет отвечать на те же вопросы: «Я все еще делаю % & Lo (+? $$ + &)» ... Еженедельные встречи дадут больше времени. Чтобы сохранить одинаковое время встреч между «начальными» встречами Scrum и «еженедельными» встречами Scrum, каждое еженедельное собрание Scrum должно длиться (5 дней в неделю, с 4-недельными спринтами, со спринтерскими встречами продолжительностью 4 часа и ежедневными встречами продолжительностью 15 минут): (4 * 60 + 20 * 15) / 4 =>

Или схватка еще пригодна для использования? Может быть, следует использовать другую гибкую технику?

Скрам не серебряная пуля. Не каждый проект должен использовать Scrum, чтобы добиться успеха. Однако ситуация, которую вы описываете, звучит как идеально подходящая для Lean / Kanban. Вы можете проверить это.

Канбан в основном просит вас сделать только несколько вещей, ни одна из которых не противоречит типу команды, которую вы описываете:

• Визуализируйте поток ценностей, то есть доску Канбан. Доска Scrum - это конкретное приложение доски Kanban; Можно адаптировать его, чтобы учесть специализацию.
• Ограничьте незавершенную работу (WIP), чтобы объем работы, назначенный команде, был достаточным для поддержания непрерывной работы, т. Е. Без «блокировки» ни в начале потока (проектирование), ни в конце (развертывание) ,

Возможно, вы захотите проверить некоторые ссылки о Канбан:

• Один день в Канбан Лэнд
• Priming Kanban (бесплатная электронная книга)

Вы слишком много внимания уделяете механике scrum / agile, не смотря на то, что Agile должен обеспечить. Вы говорите, что если математик оценивает 2 балла, никто не может сказать, что он неправ. Это не цель. Цель состоит в том, чтобы согласовать достижимый набор целей для предстоящего спринта. Как эксперт по этой задаче он будет лучше знать, сколько времени это займет.

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

Ежедневная встреча по-прежнему дает преимущества. Существуют зависимости между членами команды, даже если каждый из них является специалистом. Пользователь UI может ждать на сервере, чтобы исправить ошибку уведомления. Парень на сервере может ждать от математика, чтобы выяснить, почему расчет неверен. Это также не только о том, как их работа влияет на вас. Если член команды постоянно задерживается из-за «Причины Х», но он не потратил время на смягчение будущих случаев «Причины Х», это может быть оспорено.

Если у вас есть специалист с квалификацией, подобной той, которую вы описали, ваше предположение о том, что каждый из них работает над своим собственным заданием, которому редко нужно общаться с остальными, ИМХО неверно. На самом деле, чтобы реализовать новую функцию («пользовательскую историю»), вам часто придется

• изменить вашу базу данных
• добавить или изменить графический интерфейс или веб-интерфейс
• объединить это с правильной бизнес-логикой (где, возможно, вы "математик" приходит)
• убедитесь, что все эти изменения хорошо работают вместе

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

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

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

Я также хотел бы затронуть некоторые конкретные темы, которые вы затронули:

Cross Functional команды команды А будет считаться кросс-функциональным , если он имеет все навыки , необходимые для доставки на цели спринта и / или товар задела. Это не значит, что на каждую работу есть 2 человека.

Определение размера Важно помнить, что мы оцениваем бизнес-проблему или потребность, а не решение или часть решения. Например, интеграция социальных сетей и Twitter в наш сайт электронной коммерции - это проблема, которая требует UX, дизайна пользовательского интерфейса, программирования, базы данных и знания API Twitter. Команда должна оценивать это как единое целое, поскольку они, как команда, будут предоставлять эту функциональность. Этот размер не будет на 100% точным, но мы находим, что в совокупности прогнозы, основанные на относительном размере, являются более точными. Это означает, что некоторые из них будут высокими, некоторые будут низкими, и вместе взятые рассчитанный прогноз будет более точным, чем предполагаемая продолжительность.

Бесполезное весеннее планирование. Планирование спринта - это время совместной работы Scrum Team (Команда разработчиков + Владелец продукта + Scrum Master), чтобы определить, что должно быть произведено, и разработать план того, как начать. Некоторые команды разбивают эти элементы журнала невыполненных работ на выбранные задачи, в то время как другие придумывают свой собственный путь к прогрессу, такой как тесты, которые должны пройти (например, XP).

Это двустороннее сотрудничество. Назначение команды набором PBI и высказывание «иди» - это роль диктатора. Команда ведет переговоры с владельцем продукта, чтобы максимизировать время в спринте.

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

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

Замените ежедневные скрам-встречи на еженедельные (более длительные) скрам-встречи . Ежедневная схватка предназначена для того, чтобы предоставить команде круглосуточный цикл обратной связи и возможность планировать на следующие 24 часа. Ни больше ни меньше. «Три вопроса» призваны помочь в этих усилиях.

Если у вас нет отзывов в течение 5 дней, я считаю, что ваши задачи недостаточно детальны. Это просто мое мнение, но оно основано на моем опыте тренера и члена команды. Команды должны чаще говорить, планировать и объединять свои усилия.

Заключение Scrum предназначен для того, чтобы облегчить обучение и сбалансировать это обучение с поставкой (там, где происходит реальное обучение). Экспериментируйте со своими процессами и инструментами с течением времени и используйте Scrum для проверки воздействия. Попробуйте перейти от ежедневного к еженедельному Scrums и посмотреть, помогает ли это командам или мешает им предоставлять правильную функциональность. Это может работать для вас.