Текст книги "Скрам"

Артефакты скрама

Используемые в скраме артефакты описаны в следующих разделах.

Бэклог продукта

Требования к системе или продукту, разрабатываемому в рамках проекта или нескольких проектов, перечислены в бэклоге продукта. Владелец продукта несет ответственность за содержание, порядок расположения элементов и доступность бэклога продукта. Бэклог продукта никогда не полон и к моменту планирования проекта содержит лишь первичное представление о требованиях. Бэклог динамичен: по мере развития продукта, окружающей среды, понимания заинтересованными лицами того, каким должен быть полезный конкурентный продукт, изменяется и его бэклог. Пока существует продукт, существует и бэклог продукта. На рис. 1.4 показан пример бэклога «Система управления продуктом в скраме». Он оформлен в виде таблицы.

Эта таблица – бэклог «Система управления продуктом в скраме» по состоянию на март 2003 года. Я был владельцем этого продукта. Строки таблицы – элементы бэклога. Они разделены подзаголовками «Спринт» и «Релиз». Например, все строки выше «Спринта 1» представляют собой задачи, реализованные в первом спринте, а строки между подзаголовками «Спринт 1» и «Спринт 2» были реализованы во втором спринте. Обратите внимание, что строка «Отобразить древовидную структуру бэклога продукта, релизов, спринтов» дублируется в спринтах 1 и 2. Это потому, что задача в строке 10 не была завершена в спринте 1 и была перенесена в спринт 2. Если бы после завершения первого спринта я решил, что ценность этого требования ниже ценности задач второго, третьего или других спринтов, то я мог бы переместить эту строку еще ниже в списке задач.

Рассмотрим столбцы таблицы с бэклогом продукта:

1. Описание элемента бэклога продукта;

2. Начальная оценка;

3. Коэффициент сложности. Некоторые особенности проекта снижают производительность команды. Этот коэффициент позволяет учесть это в оценке;

4. Скорректированная оценка, получаемая применением коэффициента сложности к начальной оценке;

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

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

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

Бэклог спринта

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

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

Потенциально готовый к поставке инкремент продукта

Скрам требует, чтобы в результате каждого спринта появлялся инкремент продукта – чтобы команды создавали новую функциональность, а не только вносили исправления в существующую. Этот инкремент должен быть потенциально поставляемым в промышленную среду, поскольку владелец продукта может решить использовать новую функциональность сразу же. Это означает, что созданная функциональность должна:

■ состоять из хорошо написанного, логично и понятно структурированного программного кода, встроенного в исполняемый файл;

■ быть тщательно протестирована;

■ быть описана в пользовательской документации или в файлах справки.

Перечисленные требования – определение «готового» инкремента продукта.

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

Резюме

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

Глава 2
Новые управленческие роли

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

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

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

Скрам-мастер в MetaEco

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

Скрам определяет используемые практики, регулярные события, артефакты и терминологию. Скрам-мастер несет ответственность за их глубокое понимание и то, как их правильно применять. Как мы увидим далее, скрам можно применять неправильно. Но поскольку скрам-мастер имеет четкое представление о том, как работает скрам, и имеет опыт его применения, то знает, как провести скрам-проект через трясину комплексности.

Люди в проекте, как правило, бродят, будто овцы в открытом поле. Задачи скрам-мастера в том, чтобы поддерживать стадо вместе и отгонять волков. Поэтому я часто сравниваю его с пастушьей собакой.

Ситуация в MetaEco

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

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

Скрам-мастер в действии

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

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

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

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

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

Пол был связан. С одной стороны, он не хотел упускать ни единой возможности привлечь новых клиентов, а с другой – не хотел навредить проекту новостной службы. Том сочувствовал Полу, но также и понимал, что, если не будет твердо стоять на своем и придерживаться правил скрама, ничего не получится. Наконец Пол сказал: «Ладно! Хотя мне и не нравятся правила скрама, я их знаю, понимаю и буду им следовать. Но будь готов к крутым поворотам на планировании спринта!»

Ценность скрам-мастера

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

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

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

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

Владелец продукта в MegaEnergy

Главная цель владельца продукта – возврат инвестиций (ROI). Бэклог продукта отлично помогает ему управлять проектом и спринт за спринтом направлять команду разработки к созданию наибольшей ценности для повышения рентабельности продукта. Бэклог продукта позволяет владельцу продукта:

■ упорядочить элементы, поместив наиболее ценные для бизнеса требования в самом начале списка;

■ добавить нефункциональные требования, которые облегчают дальнейшую разработку и выпуск новых релизов;

■ постоянно дорабатывать продукт в ответ на изменение бизнес-условий и появление новых конкурентных возможностей.

Ситуация в MegaEnergy

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

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

Компания уже предприняла две попытки автоматизировать процесс, и обе потерпели неудачу. Эти попытки были названы проектом «Участок». Поскольку в каждом штате и провинции свои процедуры, процессы и способы передачи информации о собственности на землю, у отдела учета земельных участков в MegaEnergy возникли проблемы с определением единого способа получения и обработки информации от различных правительственных учреждений. Руководство MegaEnergy решило объединить проект автоматизации с проектом по переносу данных по земельным участкам с мейнфреймов на менее дорогие серверы.

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

Владелец продукта в действии

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

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

На планировании спринта Джейн представила бэклог продукта команде. Просматривая его, команда увидела возможность оптимизации процесса и автоматизации некоторых этапов. База данных MegaEnergy содержала информацию обо всех земельных участках, по которым необходимо производить выплаты. Из Альберты можно было получить данные по изменениям прав собственности за последние 12 месяцев. Затем для каждого соответствия между полученными и имеющимися в базе данными можно было создать транзакции, которые проверит и подтвердит аналитик отдела учета земельных участков MegaEnergy и, в случае необходимости, обновит базу данных. Аналитику больше не придется проверять имя и адрес каждого отдельного участка. Автоматизация получения данных и экраны для их сверки с существующими помогли бы значительно сократить объем работы.

Команда была довольна этой находкой, ведь теперь она сможет, во-первых, доработать структуру базы данных по участкам для соответствия новым требованиям, во-вторых, изучить и проверить новые серверные технологии и, в-третьих, реализовать унифицированный формат обмена данными в формате XML[8]8
  eXtensible Markup Language – расширяемый язык разметки с простым формальным синтаксисом. Предназначен для удобного создания и обработки документов и программами, и человеком.


[Закрыть], который отдел учета земельных участков сможет использовать при взаимодействии с каждым госорганом.

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

Она попросила меня объяснить, что значат мои слова: «Продемонстрированная на обзоре спринта функциональность должна быть потенциально готова к поставке и использованию». Я ответил, что на следующем планировании спринта она может попросить команду разработки поставить этот инкремент пользователям. Джейн решила воспользоваться этой возможностью и провела внеочередной двухнедельный спринт поставки. Поскольку большинство трубопроводов MegaEnergy проходили через Альберту, созданная за этот спринт и предоставленная функциональность уменьшила нагрузку сотрудников отдела учета земельных участков более чем на 40 %.

Ценность владельца продукта

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

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

Наблюдая за демонстрацией во время обзора спринта, Джейн поняла, насколько полезным может оказаться для ее отдела этот единственный инкремент продукта. Джейн получила от команды разработки подтверждение, что внедрение этой функциональности не повлечет никаких осложнений, и поставила инкремент пользователям. Джейн не смогла предоставить какую-либо бизнес-ценность в течение первых двух попыток автоматизации, но смогла сделать это за 45 дней третьей попытки – MegaEnergy окупила затраты на проект почти сразу. Кроме того, поскольку Джейн грамотно выбирала состав и время релизов, компания смогла осознать, насколько быстро автоматизация может принести выгоды для бизнеса.