Чередуйте право направлять работу команды
В проекте нет единственного «хранителя плана» или одного наиболее значимого человека. Очевидно, что некоторые разработчики опытнее других. Но хорошие идеи могут прийти в голову даже самому неопытному сотруднику, и не стоит отметать их только на этом основании. Свежий человек иногда находит серьезную проблему в задачах, с которыми предстоит иметь дело команде. Чтобы люди внимательнее слушали друг друга и не пропускали мимо ушей ценные предложения, можно привлекать члена другой команды, чтобы он начал ежедневную планерку.
Не воспринимайте это как ритуал
Хотя мы и проводим эти встречи каждый день (и оттого некоторые scrum-команды считают их «церемониалом»), каждый должен присутствовать и активно участвовать. Довольно легко считать ответы на три вопроса (что я сделал с момента последнего scrum-митинга? что я буду делать дальше? какие есть препятствия на моем пути?) ритуалом, который просто нужно соблюдать, не задумываясь о причинах. Со временем ритуалы обычно исчезают, потому что приобретают формальный характер. Но три упомянутых выше вопроса – это основа ежедневных митингов. Они нужны, чтобы выявить проблемы на ранних этапах проекта. Например, эффективный способ определить узкие места, вызванные слишком большим количеством задач, возложенных на одного человека, – это выслушать его ответ на вопрос о том, что мешает его успеху. Потому что он способен обнаружить это узкое место раньше, чем другие.
Каждый принимает участие
Каждый – это значит и тестировщики, и бизнес-аналитики, и остальные члены команды, и владелец продукта. Все они действительно имеют обязательства. Владелец продукта выполняет особенно важную работу, потому что держит всех в курсе задач бэклога, наиболее существенных для пользователей и компании. Чем лучше команда понимает значимость поставляемого продукта, тем точнее она может удовлетворить запросы пользователей. Владелец продукта вместе с остальной командой также должен ответить на три вопроса, потому что он может забыть о важности своей задачи, а ответы напомнят об этом. (Оказывается, что посвящать все свое рабочее время переговорам с пользователями, разбираться в их бизнесе и руководить бэклогом – это занятие, достойное уважения разработчиков, если они видят это воочию!)
Не относитесь к этому как к статус-митингу
Типичный статус-митинг – это отличный пример «ритуала», который мы должны совершать каждую неделю. Все мы знакомы с ритуалами и совершаем их, не задавая лишних вопросов. Предполагалось, что совещание служит двум целям: информировать команду и администрацию. Но для большинства команд это действительно всего лишь односторонняя связь, связка двух человек – члена команды и руководителя проекта. Вы можете избежать этого убедившись, что каждый присутствующий на ежедневных scrum-планерках действительно слушает выступающих. (Это означает, что не нужно проверять электронную почту, мобильный телефон и контролировать выполнение работы!) Как только члены команды начинают понимать, что ежедневные scrum-митинги реально помогают выявлять проблемы на раннем этапе и сохранять время разработчика, они признают: в этих встречах нет бюрократической волокиты, они похожи на ориентированный на разработчика инструмент, который можно использовать, чтобы сделать код лучше.
Проверьте каждую задачу
Когда вы ищете препятствия, анализируйте не только текущую работу. Просчитывайте ситуацию на несколько ходов вперед, исследуя каждый элемент в колонке «сделать», чтобы выяснить, повлекут ли они последствия. Если есть потенциальная проблема, то лучше обсудить это с командой. Иначе впоследствии можно «обжечься». Поэтому проверка задач требует доверия между всеми участниками команды. Если кто-то – намеренно или случайно – недостаточно точно описывает то, над чем работает и что планирует сделать, то остальные члены команды могут не заметить вовремя потенциальное препятствие, которое может привести к серьезным проблемам.
Измените план, если это необходимо
Адаптация как часть цикла «обзор-контроль-адаптация» – это эффективный способ самоорганизации. Допустим, команда выявляет препятствие во время ежедневного scrum-митинга и на следующей встрече понимает, что допустила серьезный просчет и не в состоянии выполнить поставку обещанной главной функции. Есть ли смысл продолжать придерживаться прежнего плана, который явно не будет работать? Конечно, нет. Бэклог и доска задач должны отражать реальный проект. Если проблема обнаружена, то вся команда должна работать вместе, чтобы исправить ситуацию. В этом случае очень кстати придется владелец продукта – «свинья». Именно он способен немедленно внести изменения в ожидания остальных людей. Помните: если люди негативно отреагируют на изменения, о которых узнали сегодня, то изменения, обнаруженные позже, они воспримут гораздо хуже.
Во время ежедневных scrum-митингов каждый член команды отвечает на три вопроса: что я сделал с момента последнего митинга? Что я буду делать, начиная с сегодняшнего дня и до следующего митинга? Какие есть препятствия на моем пути?
Команда использует эти вопросы, чтобы каждый день совместно проверять план проекта и адаптироваться к изменениям, а также для получения постоянной обратной связи на протяжении всего проекта.
Успешные scrum-команды принимают решения в последний ответственный момент, поэтому они не делают лишнюю работу и легко адаптируются к изменениям.
Ежедневные scrum-митинги принадлежат всей команде, а не только scrum-мастеру или владельцу продукта, и все в равной степени в них участвуют.
Роджер – руководитель команды, пытающийся использовать Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Акт III. Спринтерский забег в тупик
После затянувшегося обеда Эрик, Роджер и Ави разговорились о том, как использовать ежедневные scrum-митинги, и у Роджера появилась идея. На следующем митинге он попросил девушку – младшего разработчика начать встречу с ответов на три вопроса. Когда она спросила Роджера о следующей задаче, он промолчал. Молчание длилось приблизительно полминуты и вызвало всеобщее замешательство. Роджер уже засомневался, была ли эта идея действительно удачной, но тут один из старших разработчиков заговорил. После краткого совместного обсуждения младшая разработчица уже знала, что делать дальше. Она сняла с доски задач карточку, которая находилась в колонке «сделать», написала на ней свое имя и прикрепила ее в колонку «в процессе выполнения».
Последующие scrum-митинги прошли еще удачнее. Казалось, что для этого потребовалась всего одна дискуссия, и у команды вдруг начало получаться – все заговорили о задачах друг друга, и понадобилось лишь запланировать еще два обсуждения, чтобы определить, кто чем должен заниматься. Роджер был приятно удивлен, что ему придется принимать участие только в одном из них. Теперь ему предстояло заняться разработчиком, который регулярно выполнял задачи на 95 %. Оказалось, что этому разработчику требовалась серьезная помощь, но он не решался попросить о ней, чтобы не занимать время коллег (кроме того, вероятно, стеснялся признаться, что у него проблемы).
После нескольких планерок Эрику удалось порадовать Роджера: члены команды начали привыкать работать вместе. В течение следующей недели стало очевидно, что идея самоорганизации реализовалась – и они сделали это вместе как команда. Ежедневно все члены команды определяли объем работы на следующий день, помогали друг другу придерживаться выбранной стратегии и решать проблемы. Они использовали scrum-митинги для корректировки курса как команда, которая берет за основу планирования ежедневный обзор выполняемой работы.
Казалось, все шло отлично. Так было вплоть до конца спринта. Команда представила новую версию работающего программного обеспечения, точно так же как это было после предыдущих шести спринтов.
Это была катастрофа.
Ави вернулся с очередного совещания стейкхолдеров крайне разочарованный. Он ожидал, что менеджеры по обслуживанию клиентов будут в восторге от возможностей новой версии редактора Lolleaderz.com, который позволял пользователям создавать записи о собственных достижениях и делиться ими в социальных сетях. Кроме того, команда обновила функционал рекламного баннера, чтобы любой аккаунт-менеджер имел индивидуальную страницу для каждого аккаунта, показывающую самую последнюю информацию о просмотрах и расходах на рекламу.
Вместо этого большинство менеджеров выразили крайнее недоумение. Их не проинформировали, что будет столько изменений. Неожиданно каждый из них получил десятки голосовых сообщений от клиентов, в которых те интересовались новыми функциями. Раньше они пользовались графиками Роджера, где было много предварительной информации, помогающей им продавать новый функционал. Но мир вокруг менялся слишком быстро, и они почувствовали, что не успевают за ним.
У Ави новости были еще хуже. Некоторые стейкхолдеры попросили вернуть старые графики и поинтересовались, не может ли команда перенести выпуск части опций на следующий квартал. Все выглядело так, будто компания решила полностью прекратить использовать Scrum и вернуться к водопадному процессу.
Но так ли это на самом деле? Эрик слышал те же новости, что и Роджер, но выказывал необычайный оптимизм. Как вы думаете почему?
Спринты, планирование и ретроспективы
Для некоторых проектов планирование спринта – это легко. Например, когда нужно в итоге создать то, о чем люди просят на протяжении нескольких месяцев. Если есть функция, которую требуют пользователи, и вы сделаете ее высокоприоритетной, то это легкая победа. В этом случае планирование спринта – это просто следование здравому смыслу.