Насколько я понимаю, владелец продукта, скрам-мастер и команда разработчиков являются основными ролями в скрам-команде. Мне нужно создать команду .Net Scrum из 5-8 человек. У меня недостаточно знаний о Scrum. Может ли кто-нибудь дать решение этой проблемы?
Какие ключевые роли должны быть в Scrum-команде?
Scrum определяет только три основные роли для фреймворка.
Владелец продукта, чья роль представляет собой нечто вроде объединения традиционного менеджера по продукту и спонсора проекта, но имеет гораздо больше взаимодействия с командой разработчиков, чем требуется для более традиционной роли.
Скрам-мастер, который является судьей процесса и следит за соблюдением методологии. Скрам-мастер также отвечает за обучение команды и организации тому, как максимально эффективно использовать процессы и артефакты Скрама.
Скрам-мастер действует как тренер, направляя команду на все более высокие уровни сплоченности, самоорганизации и производительности. В то время как результатом команды является продукт, результатом работы скрам-мастера является самоорганизующаяся команда.
Симс, Крис; Джонсон, Хиллари Луиза (15 февраля 2011 г.). Элементы Scrum (стр. 74). Димаксикон. Киндл издание.
Команда разработчиков, представляющая собой сплоченную, самоорганизующуюся, многофункциональную группу, обладающую всеми навыками, необходимыми для достижения целей проекта.
Scrum-команды очень сотрудничают; они также самоорганизуются. Члены команды имеют полную власть над тем, как выполняется работа. Только команда решает, какие инструменты и методы использовать, и какие члены команды будут работать над какими задачами.
Симс, Крис; Джонсон, Хиллари Луиза (15 февраля 2011 г.). Элементы Scrum (Местоположения Kindle 976-978). Димаксикон. Киндл издание.
Кто проводит проверку кода в Scrum-команде?
Код-ревью — это практика, а не требование фреймворка, и не то, что принято повсеместно. Например, см. Code Reviews, считается вредным .
Тем не менее, некоторые Скрам-команды проводят проверки кода либо потому, что они признаны полезными во время Ретроспективы Спринта, либо потому, что они требуются родительской организацией. Если родительская организация не дает мандата, то, как обрабатываются проверки кода, является проблемой для самоорганизующейся команды разработчиков, которая должна решать самостоятельно.
В конечном счете, цель — высококачественный, поддерживаемый код. Если команда разработчиков находит проверки кода полезными для соблюдения их принятого «определения готовности», это здорово. Если нет, то, возможно, разработка через тестирование или какой-то другой подход будет одинаково хорошо (или даже лучше!) работать для конкретной команды.
Ваша работа заключается не в том, чтобы поручить кому-то проверку кода; ваша работа заключается в том, чтобы судить о процессе, чтобы гарантировать, что команда постоянно проверяет и адаптирует свои методы.
Есть ли в Scrum-командах роли, называемые руководителем команды и техническим руководителем?
Фреймворк Scrum способствует коллективному владению кодом, и команда добивается успеха или терпит неудачу как группа. В результате названия, которые отличают членов команды, противоречат принципам Scrum, хотя они, тем не менее, используются головной организацией в должностных инструкциях и файлах отдела кадров.
Посмотрите на это так: если вы назначаете Боба руководителем группы, то вы возлагаете на Боба ответственность за конкретные результаты. Почему Алиса должна брать на себя обязанности Боба?
Точно так же, если вы формально назначаете Алису «специалистом по контролю качества», почему Алиса должна брать на себя коллективную ответственность за код или работать над историями об архитектуре? Несомненно, ее пригласили в команду, чтобы убедиться, что у команды есть некоторые специализированные знания по обеспечению качества, но «кросс-функциональность» не означает разрозненных обязанностей в рамках проекта.
Члены команды будут иметь должности в организации, которые иногда отражают навыки, которые они привносят в команду проекта. Однако самоорганизация и распределение ответственности внутри команды зависит от команды. Как скрам-мастер, вы должны вмешиваться только в том случае, если очевидно, что команда не может самоорганизоваться — что вы измеряете тем, достигает ли команда своих целей спринта и «определение готовности».
Распределение руководящих ролей в команде — это не agile-практика и уж точно не Scrum. Если вы окажетесь в ситуации, когда это необходимо, то вам обязательно следует пересмотреть весь процесс и попытаться определить, что мешает самоорганизации Команды Разработки.
Цитируя Руководство по Scrum : «Scrum не признает никаких титулов для членов Команды Разработки, кроме Разработчика, независимо от работы, выполняемой этим лицом; из этого правила нет исключений»; В связи с этим было бы контрпродуктивно ограничивать разработчиков конкретными обязанностями. Идея состоит в том, что команда разработчиков будет самоорганизовываться для выполнения задач и преодоления препятствий по мере возникновения потребностей (и по мере поступления ресурсов).
Что касается код-ревью, то существует множество методов его проведения (см. главу 3 книги « Самые сокровенные секреты коллегиального код- ревью»).). Вы и ваша команда должны проводить и оценивать методы проверки кода, которые лучше всего соответствуют культуре вашей команды (хотя отдельная ветвь обеспечения качества может собирать и анализировать метрики, которые могут помочь в оценке эффективности метода проверки кода). . Если у вас есть разработчики, которые лучше разбираются в клиентском коде, им может быть полезно просмотреть клиентский код для лучшего обнаружения дефектов. Разработчикам, не знакомым с клиентским кодом, также может быть полезно просмотреть его, чтобы они лучше ознакомились с клиентской частью на случай, если в будущем им потребуется вмешиваться и выполнять клиентское программирование. Преимущество agile и scrum заключается в том, что команда разработчиков может самоорганизоваться для проверки эффективности различных методов проверки кода. Несмотря на, команда разработчиков должна нести ответственность за проверку кода, созданного командой разработчиков. Также может быть внешняя команда обеспечения качества, которая дополнительно проверяет код, но это совсем не обязательно для базовой реализации проверки кода или схватки.
Какие ключевые роли должны быть в Scrum-команде?
Владельцы продукта, разработчики и специалисты по обеспечению качества являются ключом к успеху проектов на основе стека .NET. Обратите внимание, что я не упомянул роль Scrum Master. Я объясню это позже.
Если команда разрабатывает веб-API, веб-сайт ASP.NET MVC, настольное приложение или мобильное приложение .NET Xamarin, все, что вам нужно, — это владельцы продукта, разработчики и специалисты по обеспечению качества. Однако, если вы разрабатываете облачное решение .NET, вам также потребуется роль инженера DevOps, который будет управлять облаком. Если вы используете CICD, инженер DevOps еще более необходим для настройки конвейеров CICD.
Разработчики могут иметь человека с ролью архитектора (не менее 7 лет опыта работы с .NET). Архитектором будет человек, который поможет владельцам продукта правильно спроектировать функцию, поможет им в Story Points и поддержит разработчиков в дизайнерских решениях.
Точно так же отдел обеспечения качества может иметь сотрудников, квалифицированных для автоматизированного тестирования, таких как xUnit, Selenium и JUnit.
Роль скрам-мастера действительно бесполезна, если человек не является опытным менеджером по программным продуктам. Вместо того, чтобы нанимать Scrum Master, наймите Agile Coach, который поддерживает команду. Если все, что делает Scrum Master, чтобы собрать людей в определенное время в Zoom, Skype или в каком-то месте в офисе, то его лучше заменить оповещениями Google Calendar. Команды разработчиков программного обеспечения страдают больше всего, если руководитель не является опытным профессионалом в области программного обеспечения. Кто-то должен управлять JIRA или аналогичной системой продажи билетов. Скрам-мастера можно использовать в качестве последующей роли в тикетах, дорожной карте, релизах, вехах и результатах.
Кто проводит проверку кода в Scrum-команде?
Архитектор или обычно 2 других члена команды проверяют код.
Есть ли в Scrum-командах роли, называемые руководителем команды и техническим руководителем?
Разработчики должны состоять из стажеров, младших разработчиков, старших разработчиков, технических руководителей и архитекторов.
Обычно это небольшие команды из 1 стажера, 1 младшего разработчика, 2 старших разработчиков и 1 технического руководителя. Если у вас 2 таких команды, то 1 Архитектор будет посредником в обсуждении между этими двумя командами.
В каждой команде должен быть 1 владелец продукта. Если имеется более 1 владельца продукта, то один из них будет ведущим владельцем продукта. Владелец продукта — самая важная роль. Он создает истории и расставляет приоритеты в невыполненной работе. Если разработчики не получают истории, они не смогут развиваться, а QA не сможет их должным образом протестировать. Лучше иметь 2 стажеров по продукту с каждым из владельцев продукта, чтобы упростить написание истории.
Если работа интенсивная, то в каждой команде из 5 разработчиков должен быть 1 специалист по обеспечению качества и 1 инженер по надежности сайта или инженер DevOps.
Майк Робинсон