Хенрик Книберг - Scrum и XP: заметки с передовой
Ретроспектива для нескольких команд
Как мы проводим ретроспективы в случае, если над одним продуктом работает сразу несколько команд?
Сразу же после того как закончилась демонстрация спринта и отшумели бурные овации, команды расходятся по своим комнатам или отправляются в какое-то удобное местечко. И каждая команда проводит свою ретроспективу как это описано на странице 50 «Как мы проводим ретроспективы».
А на планировании (где присутствуют все команды, так как мы стараемся синхронизировать спринты всех команд, которые работают над одним продуктом), мы первым делом выслушиваем представителей каждой команды, на тему наиболее важных моментов последней ретроспективы. Выходит примерно по 5 минут на команду. После этого проводим свободное обсуждение минут на 10–20. И, собственно, только потом начинается планирование спринта.
Мы не пробовали никаких других способов, потому что и такой подход работает достаточно хорошо. Однако, самый большой недостаток этого подхода, состоит в отсутствии возможности немного передохнуть между ретроспективой и началом планирования (см. стр. 55 «Отдых между спринтами»).
В ходе планирования с одиночной командой мы не подводим итоги ретроспективы. В этом нет необходимости, ведь каждый член команды присутствовал на ретроспективе.
Как мы управляем географически распределёнными командами
Что же делать, если участники команды находятся в географически разнесённых местах? Большая часть «магии» Scrum'а и XP основана на совместном тесном взаимодействии участников команд, которые программируют парно и встречаются лицом к лицу каждый день.
У нас есть географически распределённые команды. Так же некоторые участники работают дома время от времени.
Наша политика относительно распределённых команд очень простая. Мы используем все возможные способы, чтобы максимизировать пропускную способность средств связи между физически разделёнными участниками команды. Под «пропускной способностью средств связи» я понимаю не только Mbit/sec (хотя это тоже важный показатель). Я имею в виду пропускную способность средств связи в более широком смысле:
1. Возможность практиковать парное программирование.
2. Возможность встречаться лицом к лицу в ходе ежедневного Scrum'а.
3. Возможность увидеть друг друга в любой момент.
4. Возможность личных встреч и живого общения.
5. Возможность проводить незапланированные совещания всей командой.
6. Возможность видеть одни и те же версии sprint backlog, sprint burndown, product backlog’а и других источников информации по проекту.
Вот некоторые меры, предпринятые нами (или предпринимаемые в настоящий момент) для достижения цели:
• Web-камера и наушники с микрофоном на каждой рабочей станции.
• Комната для проведения телеконференций, оборудованная web-камерами, микрофонами, компьютерами со всем необходимым ПО-для общего доступа к рабочему столу, проведения телеконференций и т. д.
• «Удалённые окна». Большие мониторы в каждом офисе, на которых постоянно можно видеть, что происходит в других офисах. Что-то типа виртуального окна между двумя отделами. Можно стоять перед ним и наблюдать. Например, кто на своём рабочем месте или кто с кем разговаривает. Всё для того, чтобы создать ощущение, что все находятся вместе.
Используя эти и другие техники, мы медленно, но уверенно начинаем понимать, как проводить планирование спринтов, демонстрации, ежедневные scrum'ы и пр. в географически распределённых командах.
Как обычно, главное — не прекращать экспериментировать. Обсуждение => адаптация => обсуждение => адаптация => обсуждение => адаптация => обсуждение => адаптация => обсуждение => адаптация.
Оффшорная разработка
У нас есть несколько оффшорных команд. Мы экспериментировали с тем, как эффективно ими управлять, используя Scrum.
Существуют две основных стратегии: удаленные команды и удаленные участники команд.
Первая стратегия — удалённые команды — очевидный выбор. И всё-таки, мы начали с использования второй стратегии — удалённые участники команд. На то существует несколько причин.
1. Мы хотим, чтобы участники команд лучше узнали друг друга.
2. Мы хотим, чтобы была налажена эффективная коммуникация, и чтобы команды поняли её важность.
3. На начальной стадии оффшорная команда слишком маленькая, чтобы самоорганизоваться в эффективную scrum-команду.
4. Мы хотим, чтобы был период интенсивного обмена знаниями, прежде чем задействовать независимые оффшорные команды.
В долгосрочной перспективе мы вполне можем перейти к стратегии «удалённые команды».
Члены команды, работающие дома
Работа дома иногда может быть действительно эффективной. Порой, за один день дома можно сделать больше, чем за всю неделю на работе. По крайней мере, если у вас нет детей: o)
Однако, усадить команду вместе — одна из основополагающих идей Scrum'а. И что же делать в этом случае?
Чаще всего мы позволяем команде решать, как часто и когда именно её члены могут работать дома. Некоторые люди регулярно работают дома, так как живут далеко. И всё-таки, мы стараемся делать так, чтобы большую часть времени команда проводила вместе.
Когда члены команды работают дома, они участвуют в ежедневном Scrum'е, используя Skype-конференции (иногда видео конференции). Они доступны в чате в течение всего дня. Не так хорошо, как находиться в той же комнате, но этого достаточно.
Как-то мы опробовали идею выделения среды, как специального дня для работы на дому. По сути это означало: «Хочется поработать дома? Нет проблем, но только по средам. И согласуйте это с командой». Для команды, на которой ставился эксперимент, это сработало отлично. По средам большая часть команды обычно оставалась дома и выполняла значительный объём работ, будучи при этом на связи друг с другом. Один такой день не сильно нарушал синхронизацию людей в команде. Но по каким-то причинам с другими командами этот подход не сработал.
В целом, люди, работающие дома, не стали для нас проблемой.
Памятка ScrumMaster’а
Напоследок я познакомлю вас с нашей памяткой ScrumMaster'а. Она содержит наиболее важные административные задачи, за которые отвечает ScrumMaster. Есть вещи, про которые очень легко забыть. Но есть и очевидные, такие как «устранять препятствия на пути команды», которые мы не включаем в наш список.
В начале спринта
• После планирования создать «страницу с информацией о спринте».
a) На стартовой странице wiki-портала поместить ссылку на созданную страницу.
b) Распечатать эту страницу и повесить её на стене, которая у всех на глазах.
• Разослать e-mail'ы с уведомлением о начале нового спринта. Не забыть указать цель спринта и дать ссылку на «страницу с информацией о спринте».
• Обновить статистику спринтов. Добавить оценку предварительной производительности, размера команды, длины спринта и т. д.
Каждый день
• Следить за тем, чтобы ежедневный Scrum начинался и заканчивался вовремя.
• Следить за тем, чтобы в случае добавления или удаления истории из sprint backlog’а все было сделано, как положено, чтобы эти изменения не сорвали график работ.
a) Следить за тем, чтобы product owner знал про эти изменения.
• Следить за тем, чтобы команда постоянно обновляла burndown-диаграмму.
• Следить за тем, чтобы все проблемы решались. Как вариант можно проинформировать о них Product owner’а и/или начальника отдела разработки.
В конце спринта
1. Провести открытую демонстрацию результатов спринта.
2. За несколько дней до демонстрации напомнить всем про её проведение.
3. Провести ретроспективу при участии всей команды и Product owner’а. Пригласить начальника отдела разработки, чтобы он помог найти оптимальное решение проблем.
4. Обновить статистику спринтов. Внести значение реальной производительности и основные тезисы прошедшей ретроспективы.
Заключительное слово
Фух! Вот уж не ожидал, что это займёт столько времени.
Надеюсь, эта книга навеяла вам несколько полезных идей, будь вы новичками или уже бывалыми специалистами.
Поскольку Scrum всё равно необходимо подстраивать под каждую конкретную среду, спор по поводу общих практик заведомо будет неконструктивен. Однако мне всё же интересно получить от вас отзывы и предложения. Расскажите мне, чем ваши подходы отличаются от наших. Поделитесь идеями, как стать лучше!
Пишите мне на[email protected]
Кроме того, я заглядываю сюда: [email protected]
Если вам понравилась эта книга, вы, вероятно, захотите иногда заглядывать на мой блог. Я надеюсь и впредь писать там заметки по Java и разработке софта:
