Scrum и XP: заметки с передовой (Книберг) - страница 67

• Используйте ветвление для разделения кода разных стадий разработки. Вы можете создать для каждой Scrum команды отдельную ветку разработки. Но если вы смешаете краткосрочные изменения с долгосрочными изменениями в одной и той же ветке, вам очень сложно будет выпускать небольшие заплатки!

• Чаще синхронизируйтесь. Если вы работаете в отдельной ветке, синхронизируйтесь каждый раз, когда вы хотите что-либо построить. Каждый день, когда вы начинаете работу, синхронизируйтесь с главной ветвью разработки, так чтобы ваша ветка была в адекватном состоянии и учитывала все изменения, сделанные другими группами. Даже если это приведет к кошмару слияния (merge-hell), учтите, что все могло бы быть еще хуже, если бы вы затянули слияние.

Ретроспектива для нескольких команд

Как мы проводим ретроспективы в случае, если над одним продуктом работает сразу несколько команд?

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

А на планировании (где присутствуют все команды, так как мы стараемся синхронизировать спринты всех команд, которые работают над одним продуктом), мы первым делом выслушиваем представителей каждой команды, на тему наиболее важных моментов последней ретроспективы. Выходит примерно по 5 минут на команду. После этого проводим свободное обсуждение минут на 10–20. И, собственно, только потом начинается планирование спринта.

Мы не пробовали никаких других способов, потому что и такой подход работает достаточно хорошо. Однако, самый большой недостаток этого подхода, состоит в отсутствии возможности немного передохнуть между ретроспективой и началом планирования (см. стр. 55 «Отдых между спринтами»).

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

Как мы управляем географически распределёнными командами

Что же делать, если участники команды находятся в географически разнесённых местах? Большая часть «магии» Scrum'а и XP основана на совместном тесном взаимодействии участников команд, которые программируют парно и встречаются лицом к лицу каждый день.

У нас есть географически распределённые команды. Так же некоторые участники работают дома время от времени.

Наша политика относительно распределённых команд очень простая. Мы используем все возможные способы, чтобы максимизировать пропускную способность средств связи между физически разделёнными участниками команды. Под «пропускной способностью средств связи» я понимаю не только Mbit/sec (хотя это тоже важный показатель). Я имею в виду пропускную способность средств связи в более широком смысле: