Книга: Scrum и XP: заметки с передовой
Участники команды с частичной занятостью
Участники команды с частичной занятостью
Могу только подтвердить то, что говорят книги, посвящённые Scrum’у наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.
Предположим, вы рассматриваете возможность взять Джо в свою команду как участника с частичной занятостью. Сначала хорошо всё обдумайте. Действительно ли Джо необходим вашей команде? Уверены, что не можете заполучить его на полный день? Какие у него ещё обязанности? Можно ли передать обязанности Джо кому-то другому и перевести его на роль консультанта? Можно ли заполучить Джо на полный день, начиная со следующего спринта, а пока передать его обязанности кому-то другому [6]?
Но иногда просто нет выбора. Вам позарез нужен Джо потому, что он единственный администратор баз данных (DBA) во всём здании. Другим командам он нужен так же сильно, как и вам, поэтому он никак не может работать с полной занятостью в вашей команде. Кроме того, компания не может себе позволить нанять ещё одного DBA. Ну и ладно. Это аргументированный случай, чтобы взять его на неполную занятость (что, кстати, было у нас). Но прежде, чем сделать это, всегда проводите подобный анализ.
В обычной ситуации я бы предпочёл команду, состоящую из трёх участников с полной занятостью, чем из восьми, но с частичной.
Если у вас есть человек, являющийся участником нескольких команд, как, например вышеупомянутый DBA, всё равно неплохо бы его закрепить за одной командой. Определите, какая команда нуждается в нём больше всего, и назначьте её в качестве «домашней команды». Когда его никто не будет дёргать, он будет присутствовать на ежедневных Scrum'ах, планированиях спринтов, ретроспективах и т. д. этой команды.
- Сколько сформировать команд
- Синхронизировать спринты или нет?
- Почему мы ввели роль «тимлида»
- Как мы распределяем людей по командам
- Нужны ли узкоспециализированные команды?
- Стоит ли изменять состав команды между спринтами?
- Участники команды с частичной занятостью
- Как мы проводим Scrum-of-Scrums
- Чередование ежедневных Scrum'ов
- «Пожарные» команды
- Разбивать product backlog или нет?
- Подход третий: Несколько product owner’ов — несколько backlog’ов
- Параллельная работа с кодом
- Ретроспектива для нескольких команд
- 3. Участники разработки экспертных систем
- Команды и формирование культуры по инициативе сверху
- Как удалить ненужные команды из контекстного меню?
- Приложение 1 Команды FTP-протокола
- 3.1.1. Основные команды
- 5.1. Полезные команды
- 5.1.6. r-команды
- 8.3. Полезные команды
- 8.4.4. Лишние команды
- 10.1.1. Команды FTP-протокола
- 12.5.1. Основные команды
- Листинг 12.1. Результат выполнения команды lastlog