Руководство по скраму | 13. Команда разработчиков в Scrum

Команда Разработки в Scrum — это междисциплинарная группа, состоящая из всех людей, вовлеченных в создание Продукта. В сегодняшней статье мы рассмотрим, какими характеристиками он должен обладать. Мы также рассмотрим состав и обязанности Команды Разработки, способной эффективно достигать своих Целей.

Команда разработчиков в Scrum — оглавление:

1. Особенности команды разработчиков
2. Команда разработчиков
3. Обязанности команды разработчиков
4. Резюме

Особенности команды разработчиков

Команда Разработки, работающая по принципам Scrum, является независимой группой специалистов. Не использует поддержку внешних специалистов или субподрядчиков. Но что определяет, что Команда хорошо подобрана для достижения Цели? И какие обязанности входят в задачи Команды Разработки — вне зависимости от ее специализации?

Чтобы быть эффективной, Команда Разработки должна обладать как минимум тремя характеристиками: способностью к самоорганизации, стремлением к росту и междисциплинарностью.

Самоорганизация

Когда мы говорим о Scrum Team, частью которой является Команда Разработки, мы используем термин «самоуправление». Это означает самоуправление на уровне организации. Скрам-команда в целом решает не только, кто и как будет выполнять работу, но и над чем они будут работать. В Scrum-команде большая часть управленческих задач принадлежит владельцу продукта и Scrum-мастеру.

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

Стремление к развитию

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

Междисциплинарность

Междисциплинарность Команды означает, что ее члены вместе должны обладать всеми навыками, необходимыми для создания ценного Инкремента в каждом Спринте. Это также означает, что каждый член Команды выполняет задачи, необходимые для этого Спринта. Каждый делает то, что необходимо для достижения Цели. Даже если это означает выполнение новых задач, выходящих за рамки компетенции Разработчика. Ошибочно жестко придерживаться своих профессиональных компетенций или роли.

Команда разработчиков

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

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

Среди разработчиков нет иерархии. Вот почему они не используют профессиональные или научные звания.

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

Обязанности команды разработчиков

Обязанности Команды Разработки можно разделить на три области. Это:

• Задачи планирования
• Работа над продуктом
• Улучшение сотрудничества внутри Команды

Задачи планирования

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

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

Работа над продуктом

Формы работы над Продуктом могут сильно различаться в зависимости от области, в которой работает данная Команда Разработки. Вообще говоря, целью каждого Спринта является создание Инкремента, т. е. полезной для бизнеса функции Продукта.

Здесь полезно говорить прямо и применять следующее правило:

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

Применение этого принципа означает, что Команда в целом берет на себя ответственность за Инкремент. Если Разработчик небрежно выполняет задачи, что приводит к ухудшению качества Продукта, работу за него должен будет сделать кто-то другой. С другой стороны, если какой-либо Разработчик обнаруживает ошибки в Продукте, он должен исправить их самостоятельно или передать информацию об ошибках тому, кто может это сделать. Подробнее о работе над Инкрементом Продукта в рамках Спринта мы напишем в отдельной статье.

Улучшение сотрудничества в команде

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

Однако это также, а может быть, прежде всего, работа над коммуникацией между Разработчиками. Улучшение заключается в разработке решений, позволяющих эффективно и точно распределять задачи. А также отработка навыков:

• критикуйте решения, а не людей — изменение языка, который мы используем для описания работы, приводит к изменению отношения и улучшению сотрудничества
• дистанцироваться от своих идей — это позволяет юморить и более честную обратную связь
• построение доверия – благодаря доверию Девелоперы могут предлагать гораздо больше инновационных идей, не опасаясь негативной реакции окружения

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

Резюме

В сегодняшней статье мы представляем характеристики, состав и обязанности команды разработчиков Scrum. Междисциплинарность, самоорганизация и стремление к развитию характеризуют эту небольшую команду. А постоянное совершенствование командной работы и эффективная работа над Продуктом — задачи, которые должна выполнять каждая Команда Разработки.

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в Facebook, Twitter, LinkedIn, Instagram, YouTube.

Автор: Кэролайн Беккер.

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

Просмотреть все сообщения

Руководство по скраму:

1. Глоссарий основных терминов, ролей и понятий
2. Что такое Скрам?
3. Скрам-ценности
4. Как внедрить Scrum в вашей компании?
5. Скрам-команда — что это такое и как она работает?
6. Кто такой владелец продукта?
7. Самые распространенные ошибки владельца продукта
8. Кто такой скрам-мастер?
9. Характеристики хорошего скрам-мастера
10. Самые распространенные ошибки скрам-мастера
11. Какую статистику и показатели должен отслеживать скрам-мастер?
12. Сотрудничество между владельцем продукта и скрам-мастером
13. Команда разработчиков в Scrum
14. Самые распространенные ошибки разработчиков
15. Скрам артефакты
16. Масштабирование Скрама
17. Бэклог спринта
18. Что такое бэклог продукта?
19. Что такое пользовательские истории?
20. Создание лучшей пользовательской истории с INVEST
21. Самые распространенные ошибки User Story
22. Критерии приемлемости пользовательской истории
23. Оценка и баллы в Scrum
24. Планирование покера
25. Игра на оценку команды
26. Определение приращения
27. Скрам-события
28. Что такое спринт в Scrum?
29. Обязательства команды Scrum — цель продукта, цель спринта и определение завершения
30. Что такое диаграмма выгорания?
31. Как создать и интерпретировать диаграмму выгорания?
32. Преимущества и недостатки диаграммы выгорания
33. Канбан-доски в Scrum и Scrumban
34. Скорость в Scrum — скорость команды разработчиков
35. Ежедневный Скрам
36. Планирование спринта
37. Обзор спринта
38. Что такое ретроспектива спринта?
39. Распространенные ошибки во время ретроспективы спринта
40. Развитие бэклога продукта