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

Улучшаем планирование спринта

Вы всегда должны изыскивать способы (в том числе предложенные членами команды), чтобы сделать ваши совещания короче и продуктивнее. Ретроспектива спринта (см. главу 5) – отличный форум для адаптации процесса планирования спринта, равно как и других аспектов работы, нуждающихся в совершенствовании. Некоторые скрам-мастера осуществляют экспресс-анализ предшествовавшего спринта в начале планирования очередного – чтобы найти идеи для улучшения, пока проделанная работа еще свежа в памяти членов команды. Однажды меня пригласили поработать в качестве коуча с несколькими командами в одной компании. Особенно меня попросили обратить внимание на одну команду, которая умудрялась осуществлять планирование спринта за 15 минут. Менеджмент полагал, что команда относится к делу несерьезно, раз так быстро осуществляет планирование спринтов. После того как я поработала с командой на протяжении двух спринтов, мне стало понятно, что время, которая она затрачивала на планирование, было вполне адекватным. Им удавалось полностью выполнять свои обязательства, и владелец продукта был ими вполне доволен. Что еще нужно от команды? Как говорят у меня на родине, в Техасе, не сломано – не лезь чинить!

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

Заключение

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

Глава 4
Спринт! Видимая, совместная и наполненная значением работа

Однажды я проводила тренинг в большой компании, офис которой расположен во Франции, неподалеку от Ниццы. В перерыве – стоял чудесный ясный день – я решила поехать на своей арендованной «Пежо» в горы на Лазурном Берегу. По пути я заметила в ущелье живописный средневековый город и подумала: «Я должна туда заехать!» С помощью навигатора, настроенного на французский язык (а я по-французски не говорю, поэтому перестроить его на английский не смогла), я поехала в городок Туррет-сюр-Лу. Прогуливаясь по средневековым кривым улочкам, я влюбилась в этот городок: у меня было ощущение, что я совершила путешествие во времени. Любопытно, что этот тихий, красивый и мирный городок, полный художников, имел весьма бурную историю. Хорошо защищенный крутыми скалами и зданиями, вознесенными на верхушку холма, он представлял собой желанную добычу для различных завоевателей. В 262 г. до н. э. его населили римляне, а далее на протяжении веков он переживал нападения со стороны гуннов, франков и ломбардцев. Я никогда бы не подумала об этом, гуляя по его улочкам, мощенным булыжником, как будто плавая в облаках вкуснейшего запаха мягких круассанов.

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

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

Как должна работать скрам-команда

В книге «Новая, новая игра по разработке продукта» (The New New Product Development Game) Такэути и Нонака описывают команды как автономные, крепко связанные между собой группы людей, которые в случае постановки перед ними целей, вызывающих естественную нестабильность, должны самоорганизоваться вокруг новой директивы. В этих случаях менеджер не делает за них их работу, а скорее отходит в сторону и лишь обеспечивает команду всем необходимым для достижения успеха. Это не гипотетическая модель – статья этих ученых основывалась на исследовании конкретных примеров в компаниях, которые таким образом создавали новые продукты.

Джефф Сазерленд описывает скрам-команду как приверженную своему делу, кросс-функциональную и самоорганизующуюся группу с очень высоким уровнем автономности и ответственности. Это описание похоже на общее определение любой команды: группы людей со взаимно дополняющим набором навыков и общей целью. Чем же тогда отличаются скрам-команды? Здесь можно назвать три фактора: члены скрам-команды обладают полномочиями по самостоятельному менеджменту; они привязаны к одному проекту и остаются в составе той же команды после каждого спринта, от начала проекта до его завершения. Такие принципы – новые правила игры для тех организаций, которые используют более консервативные методы управления ресурсами. Если ваша команда не обладает приведенными выше тремя свойствами, это не скрам-команда.

Люди, которым доверяют полномочия, которые сконцентрированы на одном деле и которые вовлечены в него, раз за разом демонстрируют более высокую производительность и готовность к сотрудничеству. Каждый раз, когда я говорю это перед различными аудиториями – как перед командами и их членами, так и перед руководителями, я вижу кивки головами, горящие глаза и согласие. Слушатели могут вспомнить примеры проектов, в которых им и членам команды была предоставлена свобода в выполнении своих рабочих обязанностей, и они улыбаются, когда говорят об этом. «Никогда в жизни не работала в такой замечательной команде. Это было здорово!» И тем не менее все возвращаются к своей работе и делают ее таким же образом, что и всегда. Назад к скучным повторам, назад к работе над многими вещами сразу, назад к тяжело выполнимым обязательствам, которые кто-то формулирует за нас. Человека давит пресс организации. Разве они не помнят, для чего придуман скрам? Чтобы положить конец таким методам работы. А зачем скрам-мастера? Для того, чтобы изменить эту унылую практику. А всего и нужно-то – маленькая команда, члены которой работают сообща и делают свою работу в спринте наглядной.

Работа в спринте

Сразу же после планирования спринта члены команды приступают к задачам, которые они определили в ходе собрания. Обычно программисты начинают писать коды и тесты, а тестировщики – тестовые сценарии. В идеале все они пишут это на основе одних и тех же предложений, обговоренных с владельцем продукта, часть из которых отражена в критериях приемки пользовательской истории (см. главу 7). Однако помните, что конструкция спринтов предполагает другую работу. В оригинальной литературе по скраму Кен считает членов команды разработчиками, независимо от того, как официально называется их должность. Другими словами, предполагается, что в работе должны участвовать все, вне зависимости от профессиональной подготовки и опыта, – чтобы обеспечить достижение целей, на которые команда «подписалась» при планировании. Это означает, что разработчики могут выполнять задачи тестирования, тестировщики могут писать документацию пользователя или изменения в единой схеме, если команда примет эту форму работы. Следует учитывать, что в современных условиях в большинстве случаев члены команды не могут освоить отдельные навыки до экспертного уровня, но могут приобрести по ним какие-то знания. А новые знания, набор навыков и т. д., полученные со временем отдельными членами команды, в конечном счете помогут команде быстрее продвигаться к цели. Кроме того, команды должны быть уполномочены на совершение любых действий, необходимых для достижения их целей. К сожалению, пока многие команды полагают, что такие полномочия – подарок, который кто-то должен им преподнести, а не способ существования. Освоение дополнительных навыков и принятие коллективных полномочий требует усилий. Я не раз слышала от некоторых членов команд высказывания: «Работать в спринте трудно. Это кажется контрпродуктивным. Это означает, что я должна по-иному относиться к своей работе». Именно так!

Спринты не должны быть просто спринтами

Я должна признать, что когда я слышу слово «спринт», то в моей голове сразу возникает проблема. При слове «спринт» мое воображение сразу рисует взмокшего бегуна с красным лицом, на последнем издыхании, с трясущимися от усталости ногами… Мы не хотим, чтобы спринт для наших скрам-команд превращался в нечто подобное. Однако все время наблюдаем похожую картину. Почему?

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

Видимо, вы уже слышали это раньше: спринты нужно бежать с марафонским темпом. Серьезно. Команды должны беречь энергию, потому что, когда один спринт завершается, сразу же начинается другой. Это означает, что при планировании спринта и его исполнении нужно учитывать буквально все: совещания, составление бэклога продукта, перерывы на кофе и ланчи, устранение дефектов и рефакторинг. Время, когда руки членов команды лежат на клавиатуре компьютеров, очень важно. Но столь же важно и время, когда пальцы не касаются клавиш. Если разработчики не пишут код, это еще не значит, что не осуществляется работа. Наоборот, последние исследования показывают, что, когда наш мозг отдыхает, качество работы улучшается. Так что, когда команды планируют спринты, они должны брать в расчет тот объем работы, который может быть выполнен при условии работы каждого работника в течение разумного по продолжительности рабочего дня. Такое планирование, о котором мы говорили в главе 3, позволяет членам команды работать с постоянным ритмом, что означает, что их мозг получает определенный отдых и что они будут приходить на работу, заряженными энергией и готовыми к максимально эффективной деятельности каждый день.

Прежний образ мыслей в новой парадигме

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

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

Как-то члены одной команды мне сказали: «Мы пишем код по всем пользовательским историям, завершаем работу и интегрируем их для начала контроля качества за два дня до конца спринта». Я спросила их, как тогда смогут они устранить все дефекты за оставшиеся два дня. Они самодовольно ответили: «Мы просто прибавляем дефекты к списку требований бэклога продукта и работаем над их устранением в ходе следующего спринта». Обратите внимание: их ответ приравнивал то, как они вообще привыкли работать, к их работе на более коротком отрезке, называемом спринтом. Я спросила их, возможно ли вообще раньше приступать к начальному тестированию по ходу спринта. Другими словами, могут ли тестировщики на более раннем этапе спринта начинать тестирование, так сказать, отщипывать по кусочку еды еще до того, как будет готово все блюдо? Разработчики посмотрели на меня и сказали: «Конечно, мы могли бы это делать, но для этого потребуется больше, чем обычно, говорить друг с другом и синхронизировать усилия». Однако с течением времени разработчики в этой команде перестали видеть себя только в качестве разработчиков, но начали рассматривать себя как мастеров, которые наполняют качеством все, что они делают. Разработчики работают с тестировщиками, чтобы сразу написать тесты и чтобы все полностью понимали требования. Это предотвратит повторное кодирование. Часто разработчики используют практики парного программирования, а также разработчики и тестировщики работают в парах, что обеспечивает реализацию пользовательских историй с первого раза. Со временем тестировщики начинают лучше разбираться в архитектуре, а тестировщик, который всегда работал в языке Java, становится способным решать некоторые несложные задачи по написанию кода. Медленно, но уверенно – по мере того, как люди начинают доверять друг другу и учатся друг у друга, – команда становится кросс-функциональной и самоуправляемой. Индивидуальные обязанности и ролевые функции становятся размытыми, и команда начинает представлять собой группу ее членов, несущих общую ответственность перед клиентом. В качестве скрам-мастера вы должны зорко следить за симптомами существования старого мышления и помогать команде бороться с ним. Многие команды находят в этом ответ с помощью применения практики Extreme Programming (экстремального программирования).

Как вы можете понять из рисунка ниже, новая скрам-команда, скорее всего, примет на вооружение вариант Б, который в каждом спринте представляет собой фрактальный вариант расширенного водопада. Хотя клиент полагает, что вариант Б даст результат быстрее, чем вариант А, «производство ценности» стоит здесь под вопросом, так как финальный код имеет дефекты (и ошибки переносятся в очередной спринт).

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

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

В этом варианте команда работает над самой важной функцией, заканчивает ее и доводит до эксплуатации – и только потом берется за новое требование из бэклога продукта. Этот постоянный поток характерен для канбана – метода бережливой разработки ПО, который фокусируется на создании ценности, планировании по модели «точно в срок» и командной работе.

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

Оценка объема работы

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

Когда скрам-команда только начинает работать по этому методу, она сосредотачивает свое внимание на очень детальном планировании спринта для того, чтобы избежать взятия на себя излишних обязательств, а также для того, чтобы начать вести диаграмму сгорания (см. главу 6). Частично из-за повторяющегося и становящегося даже скучным планирования спринта за спринтом, а также благодаря эффективности этого процесса с учетом установки командой скорости своей работы, правил игры и т. д. сработавшиеся скрам-команды начинают тратить меньше времени на планирование. Некоторые команды приходят к выводу, что перспективные оценки могут быть ошибочными: в действительности зачастую задачи выполняются гораздо быстрее, когда не производится их перспективная оценка. Закон Паркинсона, который часто называют также «синдром студентов» (Элияху Голдратт «Критическая цепочка» (Critical Chain)), гласит: «Объем работы увеличивается, стремясь занять все время, доступное для ее завершения». Вспомните свои студенческие годы, когда профессор давал вам месяц на написание реферата. В момент получения задания вы не испытывали никакого ощущения его срочности. Вы думали: «Ну, у меня еще есть целый месяц. Займусь работой в конце недели. Торопиться некуда». И вот в течение первой недели вас отвлекли новые задания, вечеринки в кампусе, свидания с родителями на выходных и футбол. Не успели вы и глазом моргнуть, как пролетели две недели! Наконец-то вы нашли время и взглянули на задание. Вы по-прежнему не испытываете никакой срочности. И так до времени, когда до сдачи работы остается два–три дня. Накануне дедлайна вы уже в панике. И отгадайте, кто будет поглощать кофе ведрами, судорожно печатая реферат вплоть до самого утра того дня, когда нужно его сдавать. Да, это будете вы! Так вы испытали «синдром студентов». Если бы ваш профессор сказал вам, что точного срока сдачи работы нет, поскольку вы должны выполнить еще 12 таких работ за семестр, тогда, возможно, вы взялись бы за нее с самого начала. Вы были в состоянии завершить работу – от начала до конца – всего за 4–5 дней. А вот установленный профессором срок 30 дней в действительности и создал задержку в выполнении задания.

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

Рисунок ниже представляет собой изображение типичной канбан-доски в производстве программных продуктов. В отличие от нашей доски планирования спринта, о которой говорилось в главе 3, канбан-доска демонстрирует только истории, а не задачи. Так что вместо того, чтобы разбивать и до одури оценивать задачи, команда берет по одной самые приоритетные позиции из колонки «Готово к работе» и работает над ними до их завершения как кросс-функциональная команда. Во время спринта они перемещают взятые на себя истории по колонкам «В разработке», «Готовы к тестированию», «В процессе тестирования», «Готовы к приемке» и т. д., чтобы отразить статус выполнения истории, и встречаются на ежедневных совещаниях, на которых отвечают на три вопроса. Недавно я работала с командой, участники которой сообщили мне новые сведения по канбану, заявив, что с помощью этого метода удвоили свою производительность. И такие результаты не редки.

Канбан – это японское слово, означающее «графическая доска» или «таблица». Идея была разработана Тайити Оно и применена на сборочных конвейерах компании Toyota в 1950-х гг. Карточки канбан означают необходимость перемещения материалов – или кода в нашем случае – из одной стадии процесса в другую. Канбан помогает работникам зрительно представлять себе, когда какая-то задача находится в очереди и готова к работе над ней. Канбан-метод используется в производстве программных продуктов на протяжении вот уже как минимум десятилетия и за последние годы приобрел значительную популярность. Канбан в создании ПО облегчает достижение результатов тем, что требует от команд работать по степени приоритетности задач. Этот метод повышает продуктивность за счет того, что ограничивает объем работы, которую команда должна выполнить за один раз. У метода канбан имеется много других характеристик и правил. В конце главы я привожу пару ссылок на дополнительную литературу, которую вы можете посмотреть. Рекомендую вам познакомиться с канбан-методом поближе, чтобы вы могли взять из него что-то полезное для своих команд.