Текст книги "Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов"

Проведение планирования спринта

Планирование спринта обычно состоит из двух частей. В первой владелец продукта представляет пользовательские истории и объясняет, почему он хочет, чтобы они были реализованы в данном продукте (скажем, они так или иначе создают стоимость или решают какие-то проблемы). Кроме того, владелец продукта отвечает на уточняющие вопросы членов команды. Во второй части совещания команда разработчиков обсуждает подходы к решению проблем, задачи, распределение задач и другие тактические вопросы по выполнению работы.

Часть I – «что» и «зачем»

Начинайте, уже представляя себе конечный результат. У каждого спринта есть цель – создание потенциально реализуемого приращения (инкремента) продукта: это могут быть новые работающие фрагменты функциональности, новые возможности, которые пользователь может «пощупать». Планирование спринта определяет, как достичь этой цели.

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

● Есть ли дополнительные вопросы?

● Всем членам команды понятно, что представляет собой новая функциональность продукта?

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

● Есть ли у членов команды какое-то беспокойство по поводу новой функциональности?

● Хорошо ли члены команды представляют себе критерии приемки новой функциональности?

● Есть ли какие-то дополнительные идеи, как потребитель сможет воспользоваться новой функциональностью?

Дело даже не в том, что владелец продукта может иногда отсутствовать на совещании, а в том, что члены команды лучше спланируют спринт, если имеют как можно более ясное представление о пользовательских историях. В этом корень проблемы! Если команда не до конца представляет себе критерии приемки, она не сможет адекватно определить все рабочие задачи и в итоге сильно недооценит объем работы. Еще хуже несовпадение ожиданий: владельца продукта могут сильно разочаровать итоги спринта, поскольку он ожидал одних результатов, а команда выдала нечто совсем другое. В процессе планирования спринта обязательно добейтесь, чтобы и владелец продукта обращался к команде напрямую, и команда вела с ним открытый разговор. Помните: вы участвуете в совещаниях, чтобы помогать их проведению, а не мешать обсуждению. Если вы чувствуете, что участники действительно не до конца понимают представленные им пользовательские истории, начните задавать вышеприведенные вопросы, чтобы подтолкнуть диалог. В конце концов, ваша задача – попытаться создать условия для успешного спринта, а качественное обсуждение спринт-планов – необходимая составляющая конечного успеха.

Для каждого спринта очень важно либо правильно сформулировать критерии готовности, либо правильно выбрать уже существующие. Критерии готовности необходимо обсуждать открыто – владелец продукта и команда должны понимать их одинаково. Можно запустить такое обсуждение, задав простой вопрос: «Как мы поймем, что справились с работой?» Если в ходе каждого спринта команда пытается добиться максимально возможного качества (или, что одно и то же, «потенциально реализуемого инкремента»), это означает, что от разработки продукта до его производства – один шаг. Критерии готовности позволяют команде определиться со всей работой (не только с программированием), которую ей предстоит выполнить в процессе спринта. Сюда входит и тестирование, а иногда – и подготовка документации. Точные и понятные критерии готовности означают, что команда может при необходимости быстро вывести тот или иной фрагмент функциональности на рынок – а это в полной мере соответствует принципам аджайла.

Рассмотрим реальные критерии готовности из реального спринта.

Различные типы пользовательских историй

Несмотря на все наши старания, не каждая пользовательская история может превратиться в новую функцию в конце спринта. Иногда команде необходимо провести исследование, чтобы убедиться, что концепция верна, или быстро войти в систему продавца продукта, чтобы протестировать его АPI. Важно, чтобы команда и владелец продукта обсуждали пользовательские истории и достигали взаимопонимания и согласия: да, за спринт может быть создана только часть ценности нового продукта, и это нормально. Следует помнить, что задача скрама – подтолкнуть команду к созданию потенциально реализуемой функциональности, а не заставлять ее искать подтверждение своим концепциям и проводить глубокие исследования. Поэтому, во-первых, мы должны относиться к пользовательским историям, требующим исследования, как к аномалиям и понимать, почему в конечном счете они могут отличаться от «нормальных» историй, работа над которыми завершается созданием работающих функций. Во-вторых, какими бы «аномальными» ни были пользовательские истории, команда и владелец продукта все равно должны их обсуждать и находить критерии приемки, даже если окончательный результат будет отличаться от реальной истории. Например, если команда предлагает провести ряд исследований для Sell Stock (продажа акций) – а это очень большая история, по сути эпик, – она должна поставить перед собой вопросы, на которые нужно дать ответ: порог цены акций, принцип «купить дорого / продать дешево», временной лимит для исследований (восемь часов), форма конечного исследовательского продукта.

Еще один пример: скажем, команда хочет задействовать Selenium, чтобы добиться более высокой автоматизации тестов. В этом случае нужно составить пользовательскую историю следующим образом: «Мы хотим задействовать Selenium, чтобы тестирование у нас не отставало от разработки новых функциональностей». Это не настоящая пользовательская история. Ни один конечный пользователь не станет требовать этого от команды разработчиков – многие из них вообще ничего не знают о Selenium! Владелец продукта, возможно, и не сразу поймет, что просьба задействовать Selenium не пустой каприз, но команда сможет объяснить ему, что тестирование на ранней стадии выявляет проблемы с продуктом и в итоге позволяет команде быстрее осуществлять разработку. Владелец продукта, скорее всего, согласится с тем, что это важно, и даст добро на дополнительные инвестиции в спринт.

Помните, что отправная точка для всех обсуждений – бэклог продукта: пользовательские истории изложены в нем с точки зрения их оценки именно пользователем, в них может всплыть и другая информация. Вы как скрам-мастер всегда должны быть начеку: если вы видите, что реализация пользовательской истории явно не приведет к настоящей выгоде для потребителя, нужно убедить команду переписать такую историю, чтобы ее результат создавал новую ценность. Если это невозможно, считайте пользовательскую историю аномалией и помогите команде описать конечный вид продукта так, чтобы его владелец не был неприятно удивлен или разочарован. Другими словами, если что-нибудь в бэклоге продукта неспособно принести пользу потребителям или бизнесу, это должно считаться абсолютным исключением, а не правилом.

Часть II – «как»

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

Определение возможностей

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

Перед началом планирования спринта я люблю рассылать его участникам таблицы рабочих возможностей (см. пример ниже), чтобы они сами могли определить время для работы в рамках данного спринта. Рабочая таблица – неформальный документ. Она напоминает членам команды об их обязательствах, а также о другой работе, которая может отвлечь их от обязательств скрам-команды. Каждый член команды может заполнить эту таблицу до совещания и принести ее с собой на встречу. Таким образом, когда мы приступаем к планированию возможностей, участники уже к нему готовы (помимо прочего, это экономит время). После нескольких спринтов команде, возможно, уже не понадобятся рабочие таблицы: участники привыкнут смотреть на спринт исходя из имеющегося у них времени.

Как вы можете видеть, Джим составил таблицу своих возможностей до планирования спринта. Он обдумал как предстоящую работу, так и личные дела – и отразил все это в таблице: у него будет двухдневный отпуск, а 21 февраля он идет на прием к стоматологу. Всего Джим вычел из общего количества рабочих часов по данному спринту 20 единиц, в которых учтены его профессиональные обязательства (один день на повышение квалификации) и личные дела. Он принесет эту таблицу с собой на совещание – наряду с любыми вопросами и идеями, которые возникнут у него при изучении бэклога продукта.

Когда люди входят в состав более чем одной команды, у них появляются задачи по спринтам для этих команд и два набора совещаний (по планированию, ежедневному подведению итогов и т. д.). Они вынуждены постоянно приспосабливаться к другому контексту, а также к неизбежным помехам, которые не учитываются при распределении рабочего времени. В целом это не самый рациональный метод: сотрудник дезориентирован, его рабочее время тратится впустую. Лучше, когда члены скрам-команды «привязаны» к ней на время жизненного цикла проекта. Если ваша команда этого не добилась, вам следует сделать соответствующие пометки для последующего разбора и записать ситуацию в ваш «бэклог помех» (см. главу 5).

Во время совещания выпишите имена участников на доске и попросите каждого из них сообщить количество рабочих дней и часов, которое они могут уделить данному спринту. Если они еще не составили таблицы, пусть теперь вспомнят все, что касается их отпусков, учебы, обязательств перед другими командами и т. д. На этом этапе совещания я обычно спрашиваю у членов команды: «Есть ли другие обстоятельства, которые могут отвлечь вас от работы по спринту?» Записывайте ответы на доске. Часто случается, что другие члены команды напоминают коллегам об имеющихся у них обязательствах или необходимости отлучиться с работы: «Эй, Эдди, ты же на этой неделе выступаешь на встрече по новым технологиям! Подготовка доклада займет у тебя много времени. Стоит учесть это в рабочей таблице». Именно поэтому скрам-мастеру лучше не приходить на совещание с уже готовыми таблицами. Иногда члены команды вспоминают о чем-то важном в ходе самого обсуждения. Безусловно, рабочие таблицы – это отличный инструмент для обдумывания спринта, однако всегда старайтесь обсуждать их на совещании.

Пример, приведенный ниже, представляет собой рекомендацию, что вам следует написать на доске (или на листе ватмана, прикрепленном к стене). Вы собираете воедино резервы времени, имеющиеся у всей команды: Тони будет во Флориде в течение половины спринта, а Барбара должна закончить свою работу в другой команде перед переключением на данный спринт. Суреш и Крис могут посвятить работе на спринт 100 % своего рабочего времени.

Принимайте также во внимание реальную продолжительность рабочего дня. Члены команды рассчитывают свои возможности, исходя из восьмичасового рабочего дня? Или более реалистично рассматривать шестичасовой? Кроме того, помните: темп работы команды должен быть постоянным, и это тоже нужно с ней обсудить. Я как коуч рекомендую исходить из того, что у каждого члена команды есть шесть продуктивных часов в день, которые он может посвятить решению общекомандных задач (это, кстати, и отмечено в обеих вышеприведенных таблицах), и уже из этого количества вычитать другие затраты времени.

Сначала обсудите, а потом определите задачи спринта

После того как члены команды определили свои возможности, можно переходить к обсуждению содержания работы, которую нужно сделать, чтобы выполнить требования бэклога продукта. Как это обсуждение должно выглядеть и проходить в ходе совещания? Пусть члены команды берут поочередно по одной пользовательской истории, обсуждают ее, убеждаются, что все разделяют единый подход к проекту разработки, задают друг другу вопросы, немного спорят и в итоге совместно вырабатывают решение. Бэкенд-разработчик скажет: «Мне нужно создать новую таблицу и поле для этой истории и обновить теги XML». Фронтенд-разработчик скажет: «Мне нужно обновить CSS, чтобы фоновая картинка была одинаковой для всех страниц». Дизайнер скажет: «Я должен быть уверен в том, что под эту историю уже готова картинка, иначе придется использовать заглушку». Тестировщик добавит: «В последнем спринте я уже написал ряд тестов для этой пользовательской истории, а в ходе этого спринта я их автоматизирую». Каждый член команды смотрит на работу под своим углом, а другие слушают, стараясь понять, как чужое видение может повлиять на их подход к проекту.

У каждого члена команды должна быть пачка стикеров и ручка, чтобы записывать свои задачи и предположительное время их выполнения. Традиционный скрам-фреймворк приветствует, когда члены команды разбивают планируемую работу на задачи, каждая из которых требует от 4 до 16 часов индивидуальной работы. В ходе планирования спринта скрам-мастер должен вести суммарный подсчет часов на выполнение планируемых задач и время от времени сверяться с суммарными возможностями команды, чтобы она не перегрузила себя обязательствами. Когда суммарное время, необходимое для выполнения задач спринта, приближается к показателю суммарных возможностей команды, она должна прекратить отбор пользовательских историй из бэклога и перейти к составлению своих обязательств по спринту. Все члены команды должны заполнить таблицу с данными по всем задачам, рабочим часам на их выполнение и исполнителям, а затем суммировать задачи и начать отсчет их сгорания.

Таблица иллюстрирует этот традиционный подход.

Задачи для всех, задачи для экспертов и составление пар

Я обычно захожу чуть дальше, чем традиционный скрам-фреймворк. После того как члены команды обдумали всю предстоящую работу и записали свои задачи на доске или в блокноте, я даю каждому из них стикеры с крупными красными точками. Я прошу их еще раз посмотреть на выписанные задачи и пометить такими стикерами те из них, которые, по их мнению, может выполнить только один человек из команды (на рисунке ниже они обведены кружками). Я называю их задачами для экспертов. Такие задачи таят в себе определенную опасность – зачастую они представляют собой проблемное место команды. Если Эддисон, например, единственная, кто знает языки XML и SQL, а все пользовательские истории в этом спринте требуют интенсивной работы на языке XML, а также в этой базе данных, то Эддисон может оказаться перегруженной. Если она окажется перегруженной, то есть опасность того, что она не сможет закончить всю работу по бэкенду. Если она не закончит эту работу по данной программе, то программа не сможет считаться завершенной по окончании спринта. Если она не будет закончена, это будет означать потерю ценного времени, поскольку клиент не сможет дать отзыв по ней или начать ее использование. Таким образом, смысл идентификации задач для экспертов двоякий. Во-первых, мы делаем это для того, чтобы быть уверенным, что эксперт не будет перегружен работой в ходе спринта. Во-вторых, мы выделяем задачи для экспертов потому, что они предоставляют членам команды возможность учиться друг у друга. Во многих командах действует правило игры, заключающееся в том, что как только они выделяют какую-то экспертную задачу, то тут же один из членов команды добровольно входит в пару с экспертом, создавая условия для распространения знаний и навыков. Такая практика требует времени, но через 3–4 спринта ваша команда сможет заметить, что число экспертных задач, идентифицируемых в ходе планирования спринта, значительно уменьшается и легче поддается регулированию.

Всякая задача, которая не идентифицируется как задача для эксперта, становится задачей для всех. То есть над ней способен работать любой член команды, даже если она выходит за пределы его базовой профессиональной подготовки. Задачи для всех не поручаются кому попало – идея состоит в том, что такую задачу может взять в работу любой член команды, у которого имеется ресурс рабочего времени по данному спринту. Правилом является то, чтобы количество задач для всех не превышало свободный остаток временного ресурса команды. Такая практика приводит к существенной экономии времени, затрачиваемого на планирование спринта. Методика выделения экспертных задач и задач для всех обычно не упоминается в популярной литературе по скраму. Я разработала ее на основе собственной практики. Продолжайте совершенствовать и адаптировать к реальности вашу методику проведения планирования спринта, и, возможно, вы откроете какие-то новые замечательные приемы.

Типичная запись на доске по задачам спринта имеет следующие колонки: «Не начатые задачи», «В процессе» и «Выполненные». Члены команды передвигают стикеры на доске по ходу спринта, чтобы показать реальное состояние его выполнения. Есть разные способы настройки скрипки – и есть разные методики проведения планирования спринта и оформления досок (листов) с задачами.

Буферы спринта

Вы наверняка заметили, что в таблице выше я «сняла» 25 % временных возможностей с учетом адаптации новой команды, циклов обучения и рисков, приведя общий знаменатель коллектива примерно к 150 часам рабочего времени. Эта команда еще не применяла скрам: исходя из своего личного опыта, я могу сказать, что многие команды, непривычные к скраму, обычно перегружают свои обязательства по спринтам. Но, как только я разъясняю им пользу различных буферов и амортизаторов против тех проблем, с которыми они могут столкнуться, они признают разумность резервирования определенного времени для встреч с неизвестным. Один только факт того, что коллектив представляет собой новую команду, предполагает, что время от времени они должны будут брать определенные паузы для того, чтобы понять, как им работать вместе. Сначала команде может быть нелегко. Поэтому нужно соответствующим образом демпфировать трудности. Вы можете подумать: «Господи, она все время отводит на буферы и амортизаторы. Когда работать-то?» Хороший вопрос! Один из моих любимых аспектов скрама – команда видит свои возможности в каждый день спринта! (См. главу 4.) Если команда почувствует, что у нее слишком много «подушек безопасности», она может просто взять в проработку дополнительные пользовательские истории из бэклога для заполнения образовавшегося «пустого пространства». Со временем команда разовьет в себе чувство меры в отношении буферов. А до этого пусть ошибается и учится не брать лишних обязательств.

Чувство времени всегда помогает

Календари могут быть очень полезной штукой. В приведенном ниже примере с календарем члены команды помечают срок выполнения ими задач по продукту таким образом, чтобы иметь возможность видеть процесс решения этих задач на протяжении спринта. В дополнение к этому они добавили некоторые «вехи» вроде актуализации продавцом технологий и использование конференции пользователей в создании системы. По этим вехам они ориентируются в процессе спринта. Календарь помогает команде увидеть целое (вспоминаем концепцию бережливого производства) и может вызвать интересные обсуждения: как команда выстраивает приоритеты своей работы? Обычно в ходе планирования спринта я вывешиваю на стену пустой календарь. Иногда команда не использует его, но он есть на тот случай, если команда захочет визуализировать временные интервалы (см. таблицу ниже).

Члены команды должны говорить друг с другом

Обычно кажется, что это пустяк, но, поверьте, его бывает непросто заметить. Понаблюдайте, куда устремлены взгляды членов команды во время совещания. Если они устремлены на вас, это означает, что и разговор происходит с вами. А вы должны делать так, чтобы члены команды говорили друг с другом, а не с вами! Задавайте вопросы – «Почему ты не скажешь это именно ему?» или «Все это слышали?» – и обводите взглядом всех участников совещания, чтобы члены команды вовлекали друг друга в разговор. Или во время оживленного обсуждения очередного продукта просто скажите: «Продолжайте. Я сейчас вернусь» – и выйдите из комнаты совещаний на 5–10 минут, пока команда продолжает разговор. Помните, что на вас лежит ответственность по созданию продуктивной команды. Внимательно наблюдайте за ситуацией и научитесь распознавать моменты, когда команда использует вас как ключ для общения; в таких случаях убирайте этот ключ. Поначалу команда может растеряться, но вскоре найдет свою линию общения.

Не нужно «заорганизовывать» мероприятия

Однажды меня попросили понаблюдать за действиями нескольких скрам-мастеров на разных совещаниях в одной компании для того, чтобы объективно оценить их стили работы. На одно из совещаний я пришла пораньше, чтобы помочь скрам-мастеру его подготовить. Она прибыла за несколько минут до начала встречи с 20 большими перекидными листами, двумя досками, 10 пачками маркеров и коробкой стикеров. Скрам-мастер бегала по комнате, раскладывая и развешивая все это по местам, и я тоже взялась помогать ей, чтобы совещание началось вовремя. Создавалось впечатление, что она несколько перегрузила себя всяческими атрибутами, но я рассудила так: «слишком» лучше, чем «недостаточно». Когда члены команды и владелец продукта начали высказываться в части I совещания, я заметила, что скрам-мастер бросилась записывать на стикерах буквально каждое их слово. Перед ней лежали пачки стикеров шести разных цветов, и она пыталась разбить по темам сказанное участниками совещания. Через 10 минут перед ней лежало около 45 полностью исписанных стикеров разного цвета, а почерк стал таким неразборчивым, что она сама не могла прочитать, что написала. Во время первого перерыва она пыталась разместить эти стикеры на 20 больших листах, которые прикрепила к стенам. Получилась одна непонятная гора стикеров – всех типов, цветов и размеров. Cкрам-мастеру было явно не по себе, тем более что она попыталась подготовиться к совещанию, но слишком «заорганизовала» его, что закончилось путаницей и задержкой повестки дня. Во время самого первого перерыва я помогла ей убрать некоторые стикеры и раздать их участникам совещания, чтобы они сами записывали на них то важное, что они улавливали из обсуждения. Это помогло вернуть ход совещания в нормальное русло и упорядочило обсуждение между членами команды.

Отлично, когда в совещании хватает организации. «Заорганизованность» совещаний – это ужасно.

Пример проведения планирования спринта

Ниже приведен список пунктов проведения планирования спринта, который вы можете использовать для себя в качестве образца. Этот список весьма обширен и не оставляет ничего за рамками. Однако вам стоит применять его в соответствии с вашими потребностями и необходимостью организации экономичного совещания.

Принимайте на себя обязательства!

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

Цели не становятся реальными, пока вы не заявите кому-нибудь о них. До тех пор они остаются всего лишь идеями, как пустые мечтания

Крис Кармайкл, Bicycling Magazine, январь/февраль 2007 г.

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

Еще раз просмотрите пользовательские истории, по которым приняты обязательства, и сделайте эти обязательства наглядными. Это как еженедельная цель по сбросу веса в Weight Watchers. Теперь есть к чему стремиться и чего добиваться!

Следует подумать над двумя другими дополнительными вопросами: 1) все ли знают, над чем конкретно каждый будет работать после совещания; 2) нуждается ли кто-либо в чем-то еще, чтобы начать работу? Это настроит команду на рабочий лад и поможет вскрыть в самом начале имеющиеся помехи.