44 / 94
Scrum и XP: заметки с передовой
44
•
В пределах видимости
: каждый член команды может увидеть любого другого. Каждый может
видеть доску задач. Не обязательно быть достаточно близко, чтобы
читать
, но, по крайней мере,
видеть
.
•
Автономно
: если вдруг вся ваша команда поднимется и начнет внезапную и очень оживлённую
дискуссию об архитектуре системы, никого из не-членов команды не окажется достаточно близко,
чтобы ему это помешало. И наоборот.
"Автономно" не значит, что команда должна быть полностью изолирована. В пространстве, разделённом
на секции, вполне может хватить отдельной секции для команды, с достаточно высокими стенами, чтобы не
пропускать
большую часть
шума извне.
А как быть с распределённой командой? Ну, тогда вам не повезло. Чтобы уменьшить негативные
последствия, используйте как можно больше технических средств: видеоконференции, вебкамеры, средства
для совместного использования рабочего стола и т.п.
Не подпускайте product owner'а слишком близко
Product owner должен находиться настолько близк к команде, чтобы в случае возникновения вопросов,
команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач.
Но он не должен сидеть в одной комнате с командой. Почему? Потому что есть вероятность, что он не сможет
не вдаваться в подробности, а команда не сможет правильно сработаться (т.е. не достигнет состояния полной
автономности, самомотивации и сверхпродуктивности).
Если честно, то это всего лишь догадки: в действительности, я сам никогда не видел, чтобы product owner
сидел рядом с командой, а, значит, у меня нет оснований говорить, что это плохая идея. Мне это просто
подсказывает внутреннее чутьё и другие ScrumMaster'а.
Не подпускайте менеджеров и тренеров слишком близко
Эту главу мне писать немн го тяжело, ведь я был как менеджером, так и тренером ...
Тесная работа с командами входила в мои непосредственные обязанности. Я создавал команды,
переходил из одной команды в другую, программировал с ними в парах, тренировал ScrumMaster'ов,
организовывал планирования спринтов и т.д. Оглядываясь назад можно сказать, что я творил Хорошие Дела.
И это всё благодаря моему опыту в гибкой разработке программного обеспечения.
Но потом меня назначили (звучит тема Дарта Вейдера) руководителем отдела разработки. В общем, я
стал менеджером. Это означало, что моё присутствие автоматически делало команду менее
самоорганизующейся. "О! Шеф тут. У него, небось, есть куча идей о том, что надо сделать, и кто должен этим
заняться. Давай-ка послушаем".
Я придерживаюсь следующей точки зрения: Если вы Scrum-тренер (и возможно совмещаете эту роль с
ролью менеджера), не бойтесь очень плотно работать с командой. Но только в течение определённого
промежутка времени, а потом оставьте команду в покое и дайте ей возможность сработаться и
самоорганизоваться. Время от времени контролируйте её (однако не очень часто). Это можно делать,
посещая демо, изучая доску задач или принимая участие в ежедневном Scrum'е. Если вы увидите как можно
улучшить процесс, отведите ScrumMaster'а в сторонку и дайте ему дельный совет. Не стоит поучать его на
глазах у всей команды. Посещение ретроспективы (см. стр. 51 "Как мы проводим ретроспективы") тоже будет
не лишним. Если степень доверия к вам со стороны команды невелика, то сделайте доброе дело, не ходите
на ретроспективы, а то ваше присутствие заставит команду молчать о своих проблемах.
Если Scrum-команда работает хорошо, обеспечьте её всем необходимым, а потом оставьте в покое (за
исключением демо, разумеется).