Scrum и XP: заметки с передовой
Шрифт:
Для одного спринта может показаться хорошей идеей, создать команду, которая занимается клиентской частью приложения и включает в себя всех, кто хорошо знает код клиента. Для другого спринта хорошей идеей может быть создание двух универсальных команд и разделение специалистов по клиентской части между ними.
Одним из ключевых аспектов Scrum'а является «сработанность команды», т. е. если члены команды работают вместе в течение многих спринтов, они обычно становятся очень сплоченными. Они научатся входить в групповой поток, и достигнут невероятного уровня продуктивности. Но чтобы достичь этого требуется несколько
Поэтому, если вы решили изменить состав команды, учитывайте все последствия. Будут ли это долговременные или кратковременные изменения? Если кратковременные, стоит их пропустить. На долговременные изменения можно пойти.
Есть одно исключение: большая команда, которая только-только начала работать по Scrum’у В этом случае возможны некоторые эксперименты с разделением команды на подкоманды, пока не будет найден вариант, который полностью устраивал бы всех. Удостоверьтесь, что все понимают, что отрицательный результат — тоже результат, что первые несколько итераций могут быть комом — и это нормально, при условии, что вы работаете над улучшениями.
Участники команды с частичной занятостью
Могу только подтвердить то, что говорят книги, посвящённые Scrum’у наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.
Предположим, вы рассматриваете возможность взять Джо в свою команду как участника с частичной занятостью. Сначала хорошо всё обдумайте. Действительно ли Джо необходим вашей команде? Уверены, что не можете заполучить его на полный день? Какие у него ещё обязанности? Можно ли передать обязанности Джо кому-то другому и перевести его на роль консультанта? Можно ли заполучить Джо на полный день, начиная со следующего спринта, а пока передать его обязанности кому-то другому [6] ?
6
участнику вашей команды (прим. переводчика)
Но иногда просто нет выбора. Вам позарез нужен Джо потому, что он единственный администратор баз данных (DBA) во всём здании. Другим командам он нужен так же сильно, как и вам, поэтому он никак не может работать с полной занятостью в вашей команде. Кроме того, компания не может себе позволить нанять ещё одного DBA. Ну и ладно. Это аргументированный случай, чтобы взять его на неполную занятость (что, кстати, было у нас). Но прежде, чем сделать это, всегда проводите подобный анализ.
В обычной ситуации я бы предпочёл команду, состоящую из трёх участников с полной занятостью, чем из восьми, но с частичной.
Если у вас есть человек, являющийся участником нескольких команд, как, например вышеупомянутый DBA, всё равно неплохо бы его закрепить за одной командой. Определите, какая команда нуждается в нём больше всего, и назначьте её в качестве «домашней команды». Когда его никто не будет дёргать, он будет присутствовать на ежедневных Scrum'ах, планированиях спринтов, ретроспективах и т. д. этой команды.
Как мы проводим Scrum-of-Scrums
Scrum-of-scrums — это регулярные встречи, цель которых — обсуждение различных вопросов между Scrum-мастерами.
Как-то мы работали над четырьмя продуктами. Над тремя из них работало по одной Scrum-команде, а над четвёртым — 25 человек, которые были разделены на несколько Scrum-команд. Это
У нас было два уровня Scrum-of-Scrums: «уровня продукта», который проводился с участием команд продукта Д, и «уровня компании» для участников всех команд.
Scrum-of-Scrums уровня продукта
Эта встреча была очень важной. Мы проводили её не реже одного раза в неделю. Мы обсуждали проблемы интеграции, балансировки команд, подготовку к следующему планированию спринта и т. д. Мы выделяли на это 30 минут, но часто нам их не хватало. В качестве альтернативы можно было бы проводить ежедневный Scrum-of-Scrums, однако, мы так и не собрались опробовать его.
Наша повестка дня имела следующий вид:
1. Каждый по очереди рассказывал, что его команда сделала на прошлой неделе, что планирует закончить на этой недели, и с какими трудностями они столкнулись.
2. Любые другие проблемы, относящиеся к компетенции нескольких команд одновременно, которые нужно обсудить. Например, вопросы интеграции.
На самом деле повестка дня Scrum-of-Scrums не так уж и важна — важнее, чтобы эта встреча проводилась регулярно.
Scrum-of-Scrums уровня компании
Мы назвали эту встречу «Пульсом». Мы пробовали проводить её в разных форматах с разными участниками. В конце концов, мы отказались от всех остальных идей в пользу еженедельного собрания продолжительностью 15 минут, в котором участвует весь коллектив (вообще-то все те, кто участвуют в процессе разработки).
Чегооо? 15 минут? Весь коллектив? Все участники всех продуктовых команд? И это работает?
Да — работает, если вы (или ответственный за проведение этого собрания) очень строги относительно того, чтобы собрание было сжатым.
Формат собрания:
1. Новости и уточнения со стороны руководителя разработки. Например, информация о предстоящих мероприятиях, событиях.
2. «Карусель». Один человек из каждой продуктовой группы [7] отчитывается в том, что было сделано за прошлую неделю, что планируется сделать на этой неделе и о проблемах. Некоторые другие люди так же отчитываются (например, начальник отдела по работе с клиентами, начальник отдела контроля качества).
7
группы команд, вовлечённых в разработку одного продукта (прим. переводчика)
3. Все, кто хочет, могут свободно высказаться и задать любые вопросы.
Это собрание для подачи сжатой информации, а не для дискуссий или рефлексии. Если этим и ограничиться, то 15-ти минут вполне хватает. Иногда оно занимает больше времени, но очень редко больше 30ти минут. Если завязывается интересная дискуссия, я её приостанавливаю и предлагаю всем заинтересованным остаться и продолжить её после собрания.
Почему мы проводим «Пульс» всем коллективом? Потому, что мы заметили, что Scrum-of-Scrums уровня компании посвящен преимущественно отчётности. На нём очень редко возникали дискуссии. Кроме того, информация, озвучиваемая на Scrum-of-Scrum'е, очень интересна и многим из тех, кто на него не попадает. Обычно командам интересно, чем занимаются другие команды. И мы посчитали, если всё равно нужно тратить время на информирование друг друга, то почему бы не присутствовать всем.