Роли
Члены команды Scrum выполняют как минимум одну из трех ролей. Большинство участников выполняет роль "команда", которая отвечает за создание программного обеспечения. При этом владелец продукта представляет клиентов, а координатор помогает команде и владельцу продукта эффективно выполнять Scrum-процессы.
Содержание раздела
Команда
Команда состоит из лиц, ответственных за создание программного обеспечения. Команда выбирает пользовательские описания функциональности в начале спринта, проводит совместную работу для реализации и тестирования пользовательских описаний функциональности в течение спринта и представляет готовое программное обеспечение при анализе спринта. Команда является самоорганизуемой, поскольку самостоятельно управляет своей работой. Команда является универсальной, поскольку в нее входят специалисты с практическими навыками, необходимыми для реализации пользовательских описаний функциональности, запланированных для продукта. Платформа MSF для гибкой разработки программного обеспечения версии 5.0 не предусматривает разделения ролей в команде по таким признакам, как инженерная дисциплина или область специализации.
Какой должна быть команда
Собрать хорошую команду разработчиков нелегко, и нужно время, чтобы команда "сработалась". Примеры хороших команд можно встретить повсюду: баскетбольная команда, бригада хирургов, пастух и его собаки. У каждого участника команды может быть своя специализация, однако команда работает как единое целое и добивается успеха или терпит неудачу как единое целое.
Кроме того, хорошая команда разработчиков состоит из участников, которые вместе стремятся к достижению общей цели. Не следует рассматривать команду разработчиков как совокупность специалистов, каждый из которых поочередно выполняет только те задачи, на которых специализируется. Вместо этого команда должна рассматриваться как группа людей, чьи совокупные навыки и опыт превосходят навыки любого отдельного специалиста. Благодаря сотрудничеству, общению, доверию и открытости эта группа людей может результативно работать и "перерасти" способности отдельных ее участников, чтобы стать высокопроизводительной командой.
Хорошая команда располагает людьми и навыками, необходимыми для создания работоспособного программного обеспечения. Работающие с полной занятостью участники команды должны обладать большинством навыков или всеми навыками, необходимыми для реализации проекта. Участники команды с узкой специализацией — дизайнеры, менеджеры, архитекторы или эксперты по определенной технологии — могут работать в режиме частичной занятости. Команда может на кратковременной основе привлекать внешних специалистов. Однако навыки участников команды с полной занятостью должны охватывать большую часть спектра, необходимого для выполнения работ.
Основные сферы ответственности команды
Основная задача команды — создать программное обеспечение, соответствующее как требованиям заказчика, так и критериям, предъявляемым самой командой к готовому продукту. Обязанности команды начинаются с собрания по планированию спринта и заканчиваются на собрании по анализу завершенного спринта. На собрании по планированию спринта команда разделяет пользовательские описания функциональности на задачи. На собрании по анализу завершенного спринта команда представляет работающее программное обеспечение владельцу продукта (и, возможно, клиентам).
Кроме того, команда отвечает за свои собственные результаты. Команда самостоятельно управляет определением и исполнением выбранной ею работы, а также взаимодействием между участниками команды для оптимизации эффективности работы. Команде следует постоянно работать над улучшением своих результатов, в частности:
Определять свои критерии завершенности и завершать текущую задачу, прежде чем переходить к следующей.
Внедрять эффективные методики проектирования.
Дополнительные сведения см. в разделе Рекомендации по проектированию.
Помогать владельцу продукта в составлении эффективных описаний функциональности пользователей и назначать им приоритеты.
Выполнять оценку описаний функциональности пользователей.
Координатор
Координатор команды отвечает за создание эффективной команды и организацию ее работы в соответствии со спецификой Scrum-процессов. Он внедряет изменения и помогает команде преодолевать возникающие сложности.
Каким должен быть координатор
Координатор должен обладать отличными навыками общения, обсуждения и разрешения конфликтов, врожденными или приобретенными. Эти навыки требуются ежедневно для обеспечения работы команды. Необходимо не только внимательно слышать и читать слова, но и видеть отношение собеседника к передаваемой информации (язык тела, темп речи и другие невербальные аспекты общения). Необходимо задавать вопросы, выявляющие скрытые проблемы и проверяющие правильность понимания услышанного. Эти навыки необходимо использовать для выявления потенциальных трудностей в команде, не позволяя им перерасти в настоящие проблемы. Устранение неполадок на ранних этапах непосредственно после обнаружения требует меньших затрат, так и в команде — любую проблему проще решить, когда она еще назревает. Необходимо внушать уверенность членам команды, владельцу продукта и другим коммерчески заинтересованным лицам, повышая производительность команды. Необходимо собирать, анализировать и представлять данные, показывая рост и развитие команды. Например, если команда существенно повысила добавленную стоимость и число возникающих ошибок уменьшилось, это улучшение нужно показать коммерчески заинтересованным лицам.
Основные сферы ответственности координатора
Основная обязанность — обеспечить соблюдение Scrum-процессов командой и владельцем продукта. Например, нельзя допускать, чтобы ежедневное Scrum-собрание перерастало в 45-минутную открытую дискуссию. Нельзя допускать, чтобы владелец продукта просил команду добавить работу в спринт уже после его начала. Нельзя позволять участникам команды представлять на собраниях по анализу спринтов пользовательские описания функциональности, реализованные не полностью.
Необходимо помогать устранять блокирующие проблемы, с которыми может столкнуться команда. Иногда требуется выполнять мелкие задачи, такие как утверждение заказа на покупку нового компьютера построения, или более масштабные и сложные задачи, например разрешать конфликты между членами команды. Когда в команде возникают внутренние напряжения, необходимо помочь возрождению командного духа и обеспечить более эффективную работу в будущем.
Владелец продукта
Основная задача владельца продукта — действовать как посредник между клиентами и командой разработчиков. Владелец продукта контактирует с клиентами и коммерчески заинтересованными лицами, преследующими различные цели.
Правила успеха владельца продукта
Необходимо анализировать требования клиентов и формулировать их в виде пользовательских описаний функциональности. Требуются хорошие переговорные навыки, чтобы помочь клиентам понять компромисс между запрошенными функциями и влиянием, которое они оказывают на расписание. Необходимо совместно с клиентами назначать приоритеты по невыполненной работе по продукту так, чтобы команда работала над наиболее ценным продуктом или системой, постепенно наращивая функциональность на каждом этапе. Необходимо иметь опыт в отрасли, для которой создается система. Например, если команда создает систему здравоохранения для больницы, необходимы знания в области здравоохранения и медицинского страхования. Без таких знаний невозможно эффективно назначить приоритет невыполненной работе по продукту и объяснить команде рабочие элементы такой невыполненной работы. Также будут полезны базовые финансовые навыки, например понимание периода окупаемости системы, амортизации бюджета, планирования капитальных затрат и расходов. Понимание Scrum-процессов и приверженность им также важны для успеха команды.
Основные сферы ответственности владельца продукта
Основные обязанности — представлять команде требования клиентов и коммерчески заинтересованных лиц и отвечать на вопросы членов команды. Необходимо обновлять список невыполненных работ и задавать им приоритеты. Для ведения списка невыполненных работ по продукту необходимо регулярно общаться с клиентами, заинтересованными лицами и командой разработчиков. С заинтересованными лицами следует встречаться как минимум каждые две недели. Порядок, в котором реализуются описания функциональности пользователей, повлияет на период окупаемости и объем работы, которую должна выполнить команда. Команда помогает владельцу продукта понять, как последовательность реализации пользовательских описаний функциональности повлияет на работу. Необходимо помочь заинтересованным лицам понять влияние подобных решений по ранжированию. Кроме того, владелец продукта уменьшает потребность в подробных спецификациях, отвечая на вопросы членов команды о реализации функциональных возможностей. Чтобы команда продвигалась, у вас должны быть ответы на эти вопросы или возможность найти их очень быстро (за несколько часов). Если команда не может связываться с владельцем продукта, результаты ее работы ухудшаются.
Примечание
Уровень детализации спецификаций зависит от множества факторов, к которым относится тип приложения, разрабатываемого вашей командой.Для многих приложений самые эффективные спецификации — это тщательно продуманные описания функциональности пользователей и открытые каналы коммуникации.Однако приложение, которое обрабатывает лабораторные испытания, может требовать подробных спецификаций, чтобы команда смогла детально проанализировать влияние изменений, которые она вносит со временем.
Владелец продукта также участвует в разработке приемочных тестов совместно с членами команды и заинтересованными лицами. Приемочные тесты помогают определить, полностью ли реализовано пользовательское описание функциональности, и готово ли оно к рассмотрению на анализе завершенного спринта. Необходимо понять, идентифицировать и сформулировать риск как для команды, так и для заинтересованных лиц.