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

11

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 =>

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

Korchkidu
источник
Нравится вам это или нет, если вы берете все схватки из схватки, вы больше не делаете схватки. И кстати, ежедневные схватки должны быть больше 5 метров, чем 15 метров.
Jamiec
Итак, у SO есть тег scrum, поэтому я подумал, что могу задать вопрос, связанный с scrum ^^. Кроме того, все ссылки, которые у меня есть, используют ежедневные разборки 15 минут, а не 5.
Корчкиду
Да, я подозреваю, что схватки, гибкие теги предшествуют дате программистов. Но, конечно, в наше время это лучшее место, чтобы задавать такие вопросы.
Jamiec
Хорошо спасибо. Можете ли вы перенести этот вопрос в programmers.se или я должен удалить этот вопрос и перезапустить новый там?
Корчкиду
«У меня нет сил сдвинуть это. Сожалею.
Jamiec

Ответы:

7

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

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

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

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

Ассаф Камень
источник
Большая помощь! Я проверю Лин и Канбан! Как нам +2 на ЮВ? ..;)
Корчкиду
2

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

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

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

Ян
источник
Я полностью согласен с тем, что общение все еще должно происходить. Тем не менее, встречи по планированию спринта - это просто оценка основных моментов. Если один человек в истории может оценить свои ценности, тогда эта встреча бесполезна ... И я считаю, что механика в Scrum (не гибкая в целом) действительно важна.
Корчкиду
1

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

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

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

Док Браун
источник
«Так что я думаю, что им придется общаться гораздо больше, чем в команде универсалов»: на самом деле это именно моя точка зрения. Вот почему я считаю, что ежедневных скрам-встреч недостаточно, и их следует заменить еженедельными. Или ежедневные скрам-встречи продолжительностью 30 минут.
Корчкиду
@ Korchkidu: Нет, ежедневная встреча не является техническим совещанием, а является отчетом о ходе работы. Вы проводите 15 секунд на собрании, чтобы запланировать 15-минутное собрание позже в тот же день. Будучи мастером схватки, вы несете ответственность за то, чтобы сосредоточиться на стойке.
MSalters
Да, в самом деле. Таким образом, дополнительная техническая встреча 15 'standup + 15' может сделать это возможно. Благодаря!
Корчкиду
1

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

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

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

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

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

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

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

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

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

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

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

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

Райан Кромвель
источник
1
Несмотря на то, что ваш ответ является подробным и хорошо объясняет обоснование между этими строительными блоками Scrum, я не понимаю, где вы отвечаете на суть вопроса, описывая ситуацию специалистов и (возможно, беспричинный) страх перед ОП, который выиграл Scrum не очень хорошо для такой команды.
Док Браун
Справедливая. Моя попытка состояла в том, чтобы обратиться к каждому предмету проблемы непосредственно. Мой вывод был, безусловно, плохим. Ценю ответ.
Райан Кромвель