Скрам. Гибкое управление продуктом и бизнесом Швабер Кен
С компанией MegaFund вы познакомились в третьей главе. Там работал Джефф – менеджер продукта XFlow, который управляет всеми бизнес-процессами фирмы. Он был «теневым владельцем продукта», потому что использовал скрам, но никто в MegaFund не знал об этом. Вот что Джефф писал мне о своем опыте в роли тайного владельца продукта:
Большой причиной моего успеха в этом году стало применение скрама с помощью вас и Джека. Если я правильно помню, в ноябре прошлого года вы оба сказали мне встречаться с заказчиками каждый спринт. Эта ежемесячная встреча стала образцом для успешных подразделений MegaFund. Все заинтересованные лица XFlow восхищаются тем, насколько они вовлечены в работу инженеров и насколько точно в любой момент знают, над чем работают команды. Также заказчики довольны своевременностью наших поставок. Другие подразделения в настоящее время пытаются организовать аналогичные встречи, чтобы улучшить взаимодействие команд и заказчиков.
Как Джеффу удалось внедрить скрам, не сказав об этом никому? Да и зачем он это сделал? На оба вопроса я отвечу в этом разделе.
Будучи лицензионным коммерческим продуктом, XFlow был существенно доработан внутри компании MegaFund. По мере адаптации XFlow к потребностям MegaFund он стал артериальной системой рабочих процессов и передачи информации в компании. Команда инженеров XFlow из Солт-Лейк-Сити доработала, внедрила и сопровождала продукт для компаний MegaFund по всему миру. Воодушевленная своим успехом в MegaFund, команда инженеров XFlow планировала выпустить продукт на внешний рынок и начать продавать его другим компаниям. К сожалению, это решение вызвало напряженность между инженерами XFlow и внутренними заказчиками MegaFund: первые уделяли пристальное внимание усовершенствованиям коммерческой жизнеспособности продукта, а вторые – исправлениям ошибок, решающим операционные проблемы компании. В течение нескольких лет инженеры и заказчики недоверчиво относились друг к другу. Несколько крупных бизнес-подразделений MegaFund даже начали исследовать возможность замены XFlow новыми коммерческими продуктами. Эти внутренние заказчики надеялись, что новые внешние поставщики могут быть более восприимчивыми к их потребностям, чем внутренняя группа инженеров XFlow.
Это могло привести к катастрофе. Если внутренние заказчики начали бы внедрять другие системы документооборота, пришлось бы разработать соответствующие интерфейсы интеграции, и бизнес-процесс MegaFund стал бы менее гладким. Кроме того, потеря некоторых внутренних клиентов повредила бы оставшимся внутренним клиентам, сократив бюджет для улучшения и поддержания XFlow. Начались политические игры, разные группы выдвигали свою аргументацию. Казалось, что найти решение будет очень трудно.
Скрам-мастер Джек, я и Джефф встретились для мозгового штурма. Может ли скрам чем-то помочь и спасти XFlow? Мы сосредоточились на событиях по планированию и обзору спринта. Если Джефф организует такие встречи для инженеров и клиентов, это поможет? Ни инженеры, ни клиенты не предоставили ему право создавать или упорядочивать элементы бэклога продукта – и вряд ли предоставят, – но, вероятно, он сможет организовать рабочую сессию, на которой это произойдет само собой.
Джефф организовал однодневную встречу для руководителей инженеров и менеджеров по взаимодействию с внутренними клиентами XFlow, пояснив, что цель встречи состояла в том, чтобы озвучить проблемы и постараться найти общее решение. Он не упомянул скрам. Все были настолько подавлены, что скорее хотели найти козла отпущения, а не работающий процесс. Джефф задал повестку дня: сначала инженеры представят недавно доработанный продукт, затем внутренние заказчики поделятся своими наиболее насущными потребностями, потом инженеры расскажут о своих планах по разработке новой функциональности продукта и, наконец, обе группы сравнят потребности и текущие планы и постараются выявить общие интересы.
Внутренние заказчики наблюдали за демонстрацией обновлений продукта озлобленно, предполагая, что инженеры не сделали ничего, что было бы полезно для них. Они были удивлены, когда увидели, что некоторые обновления были не только полезными, но и запрошенными самими клиентами. Затем каждый заказчик представил свои самые насущные потребности. Джефф записал их на доске, сохранив оригинальные формулировки и устранив дубликаты. Аналогичным образом Джефф зафиксировал план улучшений, представленный инженерами. По ходу выступлений участников стало ясно, что существуют пересечения потребностей внутренних заказчиков и плана команды инженеров.
Джефф поделился, что не был уверен, возможна ли взаимовыгодная долгосрочная договоренность, поскольку казалось, что у двух групп слишком противоречивые интересы. Однако, отметил он, сейчас видно, что XFlow может стать коммерчески более жизнеспособным, если команда инженеров реализует некоторые потребности внутренних заказчиков. Более того, они смогли бы рекомендовать продукт внешним потенциальным клиентам. К тому же некоторые из представленных инженерами улучшений совпадают с важными функциональными возможностями, предлагаемыми компании MegaFund внешними конкурирующими разработчиками систем автоматизации бизнес-процессов.
Далее Джефф использовал ключевую тактику скрама. Он уточнил, состоит ли общий список из наиболее насущных задач и потребностей каждого участника. Он попросил сосредоточиться на ближайшем будущем и разработать краткосрочный план. Джефф предложил всем обсудить, что можно сделать в течение следующего месяца, чтобы максимально решить проблемы каждого. За час коллегиального обсуждения две группы совместно отобрали семь элементов списка для разработки и некоторые критические ошибки, которые нужно было исправить. Джефф поинтересовался, смогут ли все участники не просить о срочных доработках, а подождать один месяц, чтобы выяснить, действительно ли выбранные функции и исправленные дефекты улучшат ситуацию. Все согласились попробовать.
Через месяц инженеры представили результаты своей работы. Они перечислили технические проблемы, с которыми столкнулась команда, и способы их обхода для реализации желаемой функциональности и устранения дефектов. Заказчики были впечатлены тем, какой объем работы команда проделала всего за один месяц: создала работающую функциональность, а не только внутренние модели и другие вещи, не представляющие для клиентов интереса. Клиенты также были довольны тем, что создано было именно то, о чем они предварительно договорились, – клиенты чувствовали, что команда инженеров действительно их услышала. Инженеры были довольны тем, что клиенты довольны. Они создали нечто, что одновременно и продвинуло продукт с коммерческой точки зрения, и удовлетворило внутренних заказчиков MegaFund.
Джефф показал всем список наиболее срочных функций, созданный на предыдущей встрече, и попросил комментариев инженеров и заказчиков.
Изменились ли потребности кого-то из внутренних заказчиков?
Изменились ли требования внешнего рынка?
Найдены ли какие-то критические дефекты?
Джефф организовал дискуссию и помог двум группам определить порядок элементов списка наиболее ценных новых функциональных возможностей и ошибок к исправлению и выбрать задачи на следующий месяц для команды инженеров.
Классический владелец продукта по скраму должен как минимум:
вести бэклог продукта;
упорядочивать его элементы по важности;
встречаться с командой разработки на планировании спринта для создания бэклога спринта и выбора цели спринта.
Джефф не был классическим владельцем продукта, но усвоил девиз «Скрам – искусство возможностей» и помог наладить непосредственное общение между внутренними заказчиками и командой инженеров. Встретившись лицом к лицу, они выяснили, что их запросы и желания в значительной степени совпадали. Джефф всего лишь помог им собраться вместе для сопоставления запросов и желаний и разработать план действий. Благодаря ограничению в один месяц ни у кого не было сомнений в выборе самых важных задач: каждый видел, что элементы бэклога продукта последовательно реализуются, и поэтому понимал, что вскоре дойдет очередь и до его запроса. Поставка функциональности каждый месяц регулярно уверяла заказчиков в том, что их потребности не откладываются на неопределенный срок.
Применяя некоторые подходы и философию скрама, Джефф смог разрешить самую тяжелую ситуацию в MegaFund. После двухлетнего опыта применения этих методов в XFlow он высоко оценил скрам, подтвердив, насколько хорошо в MegaFund работал подход, основанный на здравом смысле.
Когда люди не собираются вместе лицом к лицу и не разговаривают друг с другом, они часто проецируют свои проблемы друг на друга. Группа инженеров и внутренние заказчики не встречались больше года, их общение становилось все более скудным и формальным и в итоге стало состоять только из электронных писем. Собравшись благодаря Джеффу, эти группы смогли оставить в стороне свои разногласия и найти общий язык. Элементарная вежливость и хорошие манеры помогают достигать соглашений в самых трудных ситуациях.
Цели компании TechCore
В этом разделе мы познакомимся с Майклом, исполнительным директором TechCore. Майкл настолько торопился добиться успеха для своей компании, что брался за все подряд, пока не начал использовать скрам. Он старался угнаться за каждым потенциальным клиентом, а когда создал упорядоченный по ценности бэклог продукта, увидел, что реальные деньги можно заработать, сосредоточив внимание на разработке. Внедрив скрам, за четыре месяца он достиг всех своих целей и даже больше: положение компании улучшилось настолько, что потенциальный покупатель компании TechCore предложил гораздо большую сумму.
В конце 1990-х годов в Бостоне было много стартапов в области телекоммуникаций, и TechCore – один из них. У всех этих компаний был один лозунг: «Чем выше пропускная способность каналов, тем выше скорость!» Работавшие в TechCore молодые кандидаты наук из Массачусетского технологического института знали, как добиться повышения скорости, и владели патентами на новые разработки. Используя спектральное уплотнение каналов и на стыках избегая переходов от световой волны к электрической, компания Майкла увеличила пропускную способность более чем на 4000 %.
Для развития продуктов фирмы Майкл нанял других одаренных кандидатов наук из MIT, а остальной частью компании были обычные сотрудники из микропроизводства, финансов, управления персоналом и кадров, закупок и администрирования.
Когда в TechCore поступило предложение о приобретении компании и ее новой технологии за $540 млн, Майкл и инвесторы TechCore сочли сумму недостаточной. Майкл намеревался создать на технологии TechCore подсистему, которая бы показала на конференции по телекоммуникациям, что технология стоит больше.
Конференция должна была состояться через четыре месяца. А пока доходы от производства составляли 1 к 1000, отдел кадров приводил в компанию не тех людей, финансисты были заняты планированием очередной экспансии, а Майкл старался лично заниматься всем и даже спроектировал помещение, в котором на предстоящей выставке будет продемонстрирована подсистема.
Мы с Майклом сформировали бэклог продукта. В верхней части поместили задачи, важные для предстоящей выставки, а все другие работы, включая повышение дохода от производства, оставили в нижней части. Обычно все наоборот, и компании стремятся иметь устойчивый доход, но не в случае, когда компанию готовят к продаже в ближайшее время.
Совместное формирование бэклога продукта оказалось очень полезным. Ранее Майкл считал, что может сделать все: и обеспечивать поставку нового продукта, и управлять остальными задачами компании. В результате его усилия распределялись между многочисленными объектами и ни один не получал должного внимания. Решив, что требования к разработке продукта сейчас важнее, чем производство, планирование пространства и подбор персонала, Майкл признал, что обладает ограниченным ресурсом энергии и должен выбирать, как ее использовать.
Раньше Майкл дни напролет участвовал в обзорных встречах, чтобы поделиться своей экспертизой и задать направление работы для инженеров-разработчиков. Эти встречи часто перерастали в совещания про разработку одной части подсистемы, помогая только небольшому сегменту команды и отнимая время у остальных.
Когда мы начали работать по-новому, я пригласил Майкла на ежедневные скрамы. После того как каждый инженер сообщил о статусе своей задачи, Майкл увидел широкие возможности для своего участия и оказания необходимой и критически важной помощи. Он понял, что может ускорить принятие проектных решений и убедиться, что выбран верный путь – фактически он может участвовать в смом важном проекте своей компании. После этого открытия Майкл сосредоточил свои усилия на оказании помощи команде в ее краткосрочных проблемах, связанных с подготовкой подсистемы к демонстрации на конференции. Кандидаты наук тоже начали помогать друг другу с решением некоторых проблем, хотя раньше не общались.
Ежедневные скрамы сделали видимой еще одну проблему, которую я не сразу заметил. Оказалось, что большинство инженеров тратили огромное количество времени на получение компонентов. Они запрашивали их у отдела закупок, а затем просто сидели и ждали. Когда компонент наконец прибывал, он часто был не тем, который нужен. После обсуждения этой проблемы с отделом закупок стало ясно, что его сотрудники тоже недовольны ситуацией.
Заказываемые компоненты и детали были новыми на рынке, часто новее доступных прототипов, их было трудно найти. К тому же сотрудникам отдела закупок часто приходилось описывать компоненты поставщику, не имея технических знаний, которые позволили бы им это сделать качественно. Результат – потерянное время и недовольство. Инженеры запрашивали компонент, закупщики старались найти его, поставщики старались предоставить альтернативу, закупщики возвращались к инженеру с альтернативным предложением, иногда инженеры соглашались на аналог, тогда закупщики возвращались к поставщику, но за это время компонент продавался кому-то другому. Такое происходило каждую неделю.
Чтобы решить проблему закупки компонентов, мы наняли в группу инженеров-разработчиков двух младших инженеров. Они были «младшими» только потому, что у них не было кандидатской степени MIT. Теперь старший инженер обращался с запросом компонента к младшему инженеру, а уже тот работал с отделом закупок и был уполномочен принимать решения по аналогам и идти на компромиссы. Чтобы повысить вероятность получения наиболее подходящей альтернативы, всех инженеров оснастили сотовыми телефонами. Решение по предлагаемому аналогу принималось в реальном времени поставщиком, отделом закупок, младшим инженером и, при необходимости, старшим инженером, который запросил эту деталь.
Вы можете подумать, что ускорение процесса закупки – тривиальное достижение. Тем не менее ежедневный скрам показал, что эта проблема приводила к самым большим потерям времени: не давала старшим инженерам работать друг с другом и с Майклом, деморализовала их, препятствовала получению заметных результатов.
Активное участие Майкла в разработке продукта существенно сфокусировало работу подразделения и привело к успешному решению критических проблем. Привлечение младших инженеров к закупкам освободило старших инженеров для работы над сложными проблемами и одновременно ускорило получение компонентов.
Результатом стала успешная демонстрация подсистемы на выставке, через месяц после которой BigTel купила TechCore за $1,43 млрд. Майкл помог команде сфокусироваться на наиболее ценных задачах, и это обеспечило рентабельность инвестиций в размере почти $1 млрд за шесть месяцев. Неплохо.
Цели компании MegaBank Funds Transfer System
Вместо того чтобы громко заявлять: «У нас будет новая роль – владелец продукта», можно просто предложить собраться вместе и обсудить, что делать дальше. Люди часто с подозрением относятся к новому жаргону и новым методологиям – и не без оснований. В этом разделе мы рассмотрим важность общения с бизнесом на простом языке или, по крайней мере, на деловом.
MegaBank – это один из крупнейших финансовых институтов Соединенных Штатов с филиалами по всей стране и достаточной капитализацией для влияния на финансовые рынки. За год компания MegaBank осуществила внутренние и внешние переводы на сумму $39,6 трлн. Эти переводы осуществлялись с помощью «Системы денежных переводов» (Fund Transfer System, FTS), которая успешно завершает все транзакции, обеспечивает их безопасность и ведет журналы для аудита.
Когда я присоединился, команда проекта FTS готовилась к началу работы над вторым релизом. Менеджер проекта Пэт хотела использовать скрам: она слышала, что он помогает активно вовлекать клиентов в развитие проекта. Проект FTS нуждался в подобной помощи.
С момента первого внедрения FTS заказчики от MegaBank поменялись. Менеджер первого релиза Генри получил повышение. Прямая подчиненная Генри, Мэри, заняла его позицию, но посчитала исправление ошибок и усовершенствование системы слишком трудоемкими и менее важными, чем другие ее обязанности. Она делегировала все коммуникации и координацию проекта следующему сотруднику в иерархии – Лори, резкому менеджеру с очень ограниченным пониманием функций FTS. Лори с трудом удавалось управлять задачами проекта.
Руководство MegaFund FTS назначило дату релиза на 15 октября. Шел май, а команда все еще не понимала, как FTS может добиться от заказчиков четкого направления развития и сотрудничать с ними для обсуждения возможных альтернативных вариантов достижения целей второй версии системы.
Пэт встретилась с Генри, Мэри и Лори и рассказала, что команда FTS собирается использовать скрам, который уже применяется для успешного управления другими проектами в MegaBank. Не понимая, что это для них значит и сколько времени на это потребуется, Генри, Мэри и Лори просто надеялись, что скрам поможет им более тесно сотрудничать с командой разработки FTS.
Меня попросили организовать встречу и представить скрам. Я выступил с краткой и взвешенной презентацией, в числе прочего сказав, что в других проектах компании мы используем упорядоченный список требований, которые заказчики ожидают увидеть готовыми через месяц. Каждый месяц команды демонстрируют заинтересованным лицам завершенную функциональность и все вместе рассматривают и обсуждают список того, что необходимо делать дальше. Затем команда выясняет, что сможет сделать за следующий цикл.
Генри, Мэри и Лори остались очень довольны: скрам казался им легким, понятным и требовал только одной официальной встречи в месяц (обзора спринта). С таким объемом они точно справятся, хотя до встречи опасались, что переход на новый процесс разработки потребует обучения, новых форм, новых отчетов и множества накладных расходов. Однако скрам показался им очень простым.
Мы провели первую половину дня с командой разработки. Просмотрев список запрошенных к реализации во втором релизе функций, мы приблизительно оценили время на разработку каждого элемента и предварительно сгруппировали их в спринты. «Спринт» оказался для Генри, Мэри и Лори новым термином, но они с облегчением вздохнули, узнав, что это всего лишь фиксированный повторяющийся интервал времени максимальной длительностью в один месяц.
После такой оценки и группировки все стали спокойнее и увереннее: Генри, Мэри, Лори и команда разработки чувствовали, что ситуация под контролем, объем работы понятен, задачи каждого спринта потенциально выполнимы за месяц. Вместе они договорились о предварительном плане релиза на общем для заинтересованных лиц и разработчиков языке. Мы освободили вторую половину дня для определения задач следующего спринта, но команде, работающей с Мэри и Лори, удалось выбрать элементы бэклога продукта всего за час. Затем команда приступила к работе над созданием бэклога спринта, а Генри, Мэри и Лори вернулись на рабочие места с чувством удовлетворенности от работы, проделанной для следующего релиза.
Я намеренно скупо рассказал о скраме команде разработки и руководству MegaFund FTS. Термины вроде «элементы бэклога продукта» вызвали бы лишние вопросы. Ни одна из сторон не испытывала потребности в изучении языка и процесса скрама, поэтому я начал знакомить их с конкретными подходами, которые они могли использовать для более эффективного взаимодействия. «Бэклогом продукта» был упорядоченный список требований. А забавное слово «спринт» для обозначения отрезка времени между встречами (обзорами спринта) мы вообще не использовали, это был просто месяц.
Команда FTS использует скрам уже более шести месяцев, поставляя релизы и взаимодействуя со смежными командами. Упрощение языка скрама облегчило его принятие, сократило накладные расходы на изучение и понимание необычного фреймворка и помогло наладить плодотворное сотрудничество.
Выводы
Мы рассмотрели четыре сценария, в которых заказчики начали управлять разработкой программного продукта. Благодаря использованию скрама каждый из них взял на себя роль владельца продукта. Кто-то сделал это сознательно, другие – неосознанно. В каждом случае заказчики научились сотрудничать с командой спринт за спринтом, чтобы контролировать развитие продукта и регулировать усилия команды.
В каждом случае скрам-мастер обеспечил сотрудничество владельца продукта и команды. Не важно, явное или завуалированное, во всех примерах оно было успешным. Ключевым элементом в каждом примере стала способность команды разработки и владельца продукта понимать друг друга.
Это может казаться мелочью, но зачастую до начала применения скрама команда и владелец продукта говорят на разных языках. Владелец продукта умеет говорить в терминах требований и целей бизнеса, а команда – в терминах технологий. Поскольку владелец продукта вряд ли освоит технологии, одна из основных задач скрам-мастера – научить команду говорить в терминах потребностей и целей бизнеса. Общий знаменатель для команды и владельца продукта в новом языке – бэклог продукта.
За последний год я провел несколько сертификационных тренингов для людей, которые хотят стать эффективными скрам-мастерами. На них мы подробно обсуждаем, как применять скрам в различных ситуациях, как скрам-мастер может помочь владельцу продукта и команде разработки говорить на одном языке, использовать единый лексикон для обсуждения проблем.
Для обучения новому языку участники тренинга объединяются в мини-группы, обсуждают бизнес-проблему, а затем презентуют результаты обсуждения и рекомендации владельцу продукта. И почти всегда в этих презентациях используется «техносленг», язык технологий, который непонятен владельцу продукта. Я указываю на эту ошибку и учу поступать иначе.
Такими безжалостными упражнениями я помогаю будущим скрам-мастерам понять величину языкового барьера, разделяющего заказчиков и разработчиков. Преодоление этого разрыва критически необходимо: если две стороны не могут говорить на одном языке, сотрудничество невозможно! Владелец продукта часто не заинтересован в преодолении разрыва, у него нет для этого ни образования, ни опыта. Для него это сложнее, чем для команды, поэтому остается один вариант – скрам-мастер должен помочь команде преодолеть этот разрыв.
В каждом примере этой главы владелец продукта и команда разработки сотрудничали, чтобы сделать все возможное для бизнеса компании. Каждое сотрудничество привело к повышению рентабельности инвестиций (ROI). Но в каком размере? Без измеримого индикатора такое достижение остается голословным. В следующей главе мы рассмотрим, как участники тренинга для скрам-мастеров отвечают на предложение оценивать рентабельность принимаемых решений.
Глава 6
Планирование проекта в скраме
К заинтересованным лицам проекта относятся:
те, кто финансирует проект;
те, кто намерен использовать создаваемую в рамках проекта функциональность;
те, на кого так или иначе повлияют ход или результаты проекта.
Процесс планирования в скраме позволяет синхронизировать ожидания заинтересованных лиц с ожиданиями команды. Для заинтересованных лиц, которые будут финансировать проект, в плане уточняется, в каком объеме и когда требуется финансирование, когда будут получены выгоды от проекта. Заинтересованным лицам, которые будут пользователями разрабатываемой системы, план помогает организовать работу так, чтобы они могли начать пользоваться функциональностью по мере ее реализации.
План также является основой отчетности по проекту. В конце спринта заинтересованные лица участвуют в обзоре спринта, где сравнивают фактически достигнутые результаты проекта с запланированными. Заинтересованным лицам разъясняют суть и детали изменений в ходе проекта и корректировок плана. Для тех, кто не может присутствовать на обзоре, в отчетах по проекту приводится сравнение фактических результатов с планом – как с первоначальным, созданным на старте проекта, так и с измененным.
Процесс планирования в скраме включает в себя поиск ответов на три серии вопросов:
Каких изменений могут ожидать те, кто финансирует проект? Когда он завершится?
Какие результаты будут достигнуты в конце каждого спринта?
Почему финансирующие проект должны считать его ценной инвестицией? Почему они должны считать, что команда сможет обеспечить достижение прогнозируемых выгод?
Планирование проектов с помощью диаграмм Ганта обычно требует больше усилий, чем планирование скрам-проектов, поскольку последние стремятся предоставить ожидаемые от них преимущества и осязаемый результат в конце каждого спринта. Эти проекты слишком комплексные, они не могут быть подробно описаны на старте, поэтому мы с самого начала контролируем и направляем их так, чтобы они достигли наилучших результатов.
В скраме план минимален: для запуска проекта необходимы только видение и бэклог продукта. Видение описывает, зачем проект стартует и каков желаемый конечный результат. Для системы, которая будет использоваться внутри организации, видение может описывать, как изменятся бизнес-процесс и работа сотрудников после установки системы. Для программного обеспечения, разрабатываемого для продажи, видение может описывать основные новые функции и характеристики системы, то, как они будут приносить пользу клиентам, каково предполагаемое влияние нового продукта на рынок. Бэклог продукта определяет функциональные и нефункциональные требования, которые система должна выполнять для реализации видения. Требования в бэклоге упорядочены по важности и предварительно оценены. Бэклог продукта делится на потенциальные релизы и спринты, как показано на рис. 6.1.
Одна из целей плана – убедить кого-то финансировать проект. В плане должны быть представлены сведения, достаточно подробные для объяснения источнику финансирования, что:
проект целесообразен;
в определенные моменты времени будут поставляться результаты;
выгоды перевешивают риски и издержки;
команда проекта достаточно компетентна для исполнения этого плана.
Скрам часто реализуется успешнее, если проект спланирован. Для всех рассмотренных в этой главе проектов уже ясны и понятны требования и получено финансирование. Теперь необходимо перепланировать проект в духе скрама, чтобы команда, владелец продукта и заинтересованные лица смогли увидеть проект как основанную на бэклоге продукта серию спринтов, приводящих к готовым к поставке инкрементам продукта. Бэклог продукта – артефакт скрама, который необходимо создать сразу после решения о старте проекта. В следующем разделе описывается пример такого проекта.
Управление денежными средствами в MegaBank
MegaBank является одним из крупнейших финансовых институтов в мире. Мы уже познакомились с ним в пятой главе и еще встретим в следующих главах. Спустя два года после первого рассказа о скраме представителям компании 20 % всех программных продуктов MegaBank используют его. Одна команда узнала об успехе скрама в других подразделениях MegaBank и захотела попробовать его в пилотном проекте по миграции с мейнфреймов в интернет приложения учета денежных переводов. Финансирование было одобрено, команда сформирована, план разработан. Команда проекта получила указание, предписывающее полную готовность к внедрению веб-версии приложения через пять месяцев. Других деталей не требовалось, поскольку новое приложение полностью должно было повторить функциональность своего мейнфрейм-предшественника без добавления каких бы то ни было новых функций.
Одномесячные спринты бычно начинаются с однодневного события планирования спринта. Тем не менее для подобных проектов я добавляю дополнительный день на создание бэклога проекта и обучение скраму новых скрам-мастера, владельца продукта и команды разработки. Я считаю, что эти двухдневные сессии особенно эффективны, потому что обсуждаемые темы носят прикладной характер – все концепции и подходы нужно будет применять в реальной работе сразу после обучения.
На этом собрании присутствовал владелец продукта Джули, скрам-мастер Том, менеджер по разработке систем Эд и команда разработки из пяти человек. За первые три часа встречи я рассказал основы скрама в объеме первой главы этой книги. Затем объявил, что мы почти готовы начать обычное событие по планированию спринта. Почти готовы, потому что нам не хватало только одного – бэклога продукта. Владельцу продукта нужен бэклог, чтобы идентифицировать элементы с наивысшим приоритетом. Команде нужен бэклог, чтобы из его верхней части выбрать элементы, которые она за один спринт сможет превратить в готовый к поставке инкремент продукта. Я заверил участников, что к концу дня мы сформируем бэклог продукта. Тем не менее все ныли, а команда разработки считала это упражнение пустой тратой времени. Они спросили: «Зачем нам создавать бэклог всего продукта, почему нельзя просто обсудить и договориться о составе работ следующего спринта? В конце концов, разве не в этом суть аджайла?» Я ответил, что всем нам нужно получить представление о проекте, а поскольку мы применяем скрам, то будем использовать бэклог продукта. Он нужен, чтобы определить базовый уровень ожиданий от проекта, относительно которого руководство MegaBank могло бы проследить прогресс.
Мы приклеили большой лист бумаги на стену и начали перечислять функции работающей на мейнфреймах системы. Их все предстояло повторить в веб-версии. Также мы рассмотрели некоторые нефункциональные требования, например, к тестированию, уровню качества, промышленной среде системы. За два часа мы перечислили практически все элементы бэклога и уж точно учли самые важные. Остальные могли появиться позже по мере разработки, а для начала работы команды функций и требований набралось более чем достаточно.
Оценка бэклога продукта
Следующим шагом нам предстояла оценка работы по реализации элементов бэклога. Участники команды снова застонали, считая, что эта задача займет слишком много времени. Они не верили, что могут предоставить оценки, достаточно точные для того, чтобы корректно сформировать ожидания заинтересованных лиц и определять набор элементов каждого следующего спринта. Поэтому я посчитал уместным обсудить природу, факторы и слагаемые комплексности задач, о которых писал в первой главе, а также их влияние на разработку программного обеспечения. Чтобы максимально точно оценить каждое требование, нужно четко понимать статические и динамические аспекты требования, разбираться в используемых для его реализации технологиях, а также знать навыки и настроение выполняющих работу людей. Пытаясь определить эти характеристики, мы потратили бы времени больше, чем на превращение этого требования в действующую функциональность. Хуже того, даже если бы мы произвели столь детальный анализ, природа комплексных проблем в конечном счете сделала бы наши усилия бесполезными. Характер этих проблем таков, что ничтожно малые вариации в любом аспекте проблемы могут вызывать чрезвычайно большие и непредсказуемые последствия в ее проявлении. Поэтому независимо от того, сколько времени мы потратили бы на повышение точности наших оценок, они все равно остались бы крайне неточными.
После этой дискуссии я попросил владельца продукта Джули и команду разработки дать оценки, держа в уме следующую рекомендацию: цель оценки состоит в получении представления о размере каждого элемента бэклога, как самого по себе, так и относительно других элементов. Оценки элементов бэклога помогут нам, во-первых, предварительно разделить бэклог продукта на спринты, а во-вторых, упорядочить их по приоритету, основываясь и на других характеристиках элементов. Я напомнил участникам планирования, что скрам – эмпирический процесс, который основан на «искусстве возможностей». Команда разработки должна в ходе каждого спринта делать все возможное, и тогда мы обновим ожидания относительно оставшейся части бэклога и состава будущих спринтов. Мы станем отслеживать фактический прогресс в ходе каждого спринта и общий прогресс проекта, чтобы предсказать, когда система будет готова к поставке. В ситуации с MegaBank руководство ожидало готовность системы через пять месяцев. Поэтому сейчас было бы уместным сделать первый шаг к определению того, насколько это ожидание реалистично. В конце каждого спринта мы будем обновлять ожидания, сравнивая фактическую поставку функциональности с ожидаемой.
Учитывая эти рекомендации, команда разработки смогла оценить весь бэклог продукта всего за час. При оценке команда основывалась на знаниях о существующей мейнфрейм-версии приложения, над которой работали все участники, и на понимании ранее использованных технологий J2EE и Java и планируемых к применению в веб-версии. Команда разработки, владелец продукта Джули, скрам-мастер Том и менеджер по разработке систем Эд были готовы сравнить данные оценки с ожиданиями руководства: подтверждают ли они, что проект будет выполнен через пять месяцев? Особенно заинтересованным был Эд, поскольку именно он предложил такой срок.
Что означает «готово»
Прежде чем разделять элементы бэклога на спринты для сравнения с ожиданием руководства в пять месяцев, я спросил у команды разработки, какие работы включены в их оценки. Учтены ли задачи по анализу, проектированию, написанию кода? Учтено ли время на модульное тестирование? Учтена ли автоматизация модульных тестов на чем-то вроде JUnit? Время на ревью кода другим разработчиком, его рефакторинг? Предполагалось ли при оценке, что код написан чисто и разборчиво, оформлен согласно командным правилам, удалены временные фрагменты, ненужный код, лишние комментарии? Важно, чтобы все участники команды разработки и заинтересованные лица точно понимали, какие работы учтены при оценке элемента бэклога, чтобы никто не называл и не считал требование «готовым», пока вся необходимая работа не выполнена полностью. Владелец продукта Джули поинтересовалась, почему это так важно обсудить. Я ответил, что состав пунктов этого соглашения влияет на то, насколько ценной будет разработанная функциональность. Например, если команда не выполнила модульное тестирование, мы, вероятно, должны принимать во внимание возможное обнаружение ошибок позже, а значит, выделять больше времени на тестирование приложения, последующее исправление ошибок и повторное тестирование перед внедрением. Если команда проводит рефакторинг кода в рамках реализации каждого требования, то легче исправить ошибки в будущем и приложение в целом легче поддерживать, оптимизировать и дорабатывать.
Джули не знала, что такое JUnit; тогда один из участников команды разработки пояснил ей, что это среда автоматического модульного тестирования, в которой команда может создать набор автоматизированных тестов для приложения. Всякий раз, когда добавляется новый фрагмент кода, команда сразу же узнает, ломает ли он разработанные ранее функции. Джули обрадовалась такой возможности, поскольку хотела получать проверенное и легко поддерживаемое приложение, а не что-то быстро состряпанное. Она всегда предполагала, что команда разработки должна поставлять приложение проверенным, и была рада, что может закрепить это в договоренностях. Я попросил команду переоценить элементы бэклога продукта с учетом услышанных ожиданий Джули. Проведя час за обсуждением влияния этого нового определения «готовности», команда обновила оценки. Затем Джули обсудила бэклог продукта с командой разработки. Какие требования следует взять в работу первыми? Поскольку тестировщики не были частью команды, какую работу пять разработчиков могут выполнить, чтобы передать функционал в тестирование в конце каждого спринта? Какие нефункциональные требования более приоритетны? Результатом этого обсуждения стал упорядоченный бэклог продукта.
Насколько трудно это изменить
Пришло время запланировать, что команда будет делать в течение первого и следующих спринтов. Мы подсчитали, сколько времени в среднем участники команды разработки были доступны каждый месяц, и сложили эти числа, чтобы понять, сколько времени команда могла посвятить каждому спринту. Затем, начиная с верхней части бэклога продукта, мы определили, сколько элементов может быть потенциально включено в первый спринт. Спускаясь вниз по бэклогу, мы оценивали потенциальное содержимое следующего спринта, пока весь бэклог продукта не оказался размечен на спринты. Поучилось семь спринтов.
Все откинулись на стульях. Менеджер по разработке систем Эд пообещал готовую систему через пять месяцев. Учитывая длину наших спринтов в один месяц, грубые расчеты показали, что система будет готова через семь. Никто не произнес вслух, но все знали, что дополнительные два месяца стали следствием нового определения готовности. Оставив первоначальные оценки команды разработки, мы, возможно, получили бы оценку в пять месяцев. Более того, команда, вероятно, реализовала бы в этот срок систему, однако она не соответствовала бы новому определению готовности. Но поскольку теперь Джули понимала, что означает «готово», она понимала и то, что требуется дополнительное время. Взглянув на Джули, я спросил, хочет ли она вернуться к старым оценкам. Джули была расстроена и поинтересовалась, почему мы пообещали срок в пять месяцев, заранее зная, что будем поставлять систему, не отвечающую требованиям. Я ответил, что мы не знали этого и не могли достоверно предсказать срок до сегодняшней сессии планирования.
Поскольку Эд согласовал с руководством, что проект будет завершен через пять месяцев, теперь он должен был ему объяснить, что ошибся. Я подбодрил его: это не должно стать проблемой, потому что именно Джули платила за систему и она понимала, почему оценка выросла с пяти месяцев до семи. Кроме того, насколько всем нам известно, команда может закончить и раньше пяти месяцев, и позднее. Сейчас это лишь непроверенный прогноз. На данный момент мы не можем быть уверены, но к концу первого спринта узнаем немного больше, когда появится представление о том, насколько быстро команда разработки может превращать элементы бэклога в рабочую «готовую» функциональность. Тогда мы сможем скорректировать количество спринтов, необходимое для реализации бэклога продукта. В качестве альтернативы для повышения скорости работы команды мы могли бы дополнительно привлечь людей, уже знакомых с существующей мейнфрейм-версией приложения. Эти и другие варианты Джули, команда разработки, Том и Эд смогут обсудить в конце каждого спринта.
Эд был крайне недоволен таким подходом. Раньше он всегда придерживался своих первоначальных оценок, и команда никогда его не подводила. И хотя он согласился, что теперь обладал более полной информацией о проекте, чем раньше, культура в MegaBank была такой, что, как только вы произносите «пять месяцев», именно это и запоминается. Эд повернулся к команде и сказал: «Послушайте, я знаю, что сейчас мы точнее понимаем объем работы, но это по-прежнему лишь оценка. Впереди у нас пять месяцев. Вы меня никогда не подводили, и я рассчитываю, что и в этот раз не подведете».
Последовало глубокое молчание. Позже один участник команды поделился со мной, что просьба Эда прозвучала так, будто все осталось по-прежнему, называем мы это скрамом или нет. Итеративно-инкрементальная разработка? Никаких возражений. Но по мере необходимости все равно придется халтурить и срезать углы. Эд не желал говорить своему руководству, что разработка программного обеспечения комплексна, а любая оценка – это просто оценка. Вместо этого в MegaBank будет преобладать культура веры в то, что можно предсказать будущее, и никогда не появится необходимость корректировать прогнозы. Планирование спринта выявило, что до сих пор команда жертвовала качеством, чтобы поддержать это убеждение. Джули услышала, как Эд сказал команде разработки, что дата важнее качества и что участники должны во что бы то ни стало уложиться в изначально озвученный срок, несмотря на ее просьбу предоставить качественный продукт.
Скрам прост в применении. Проект работы над приложением для учета денежных переводов начался с двухдневного события по планированию спринта, который я описал ранее. Тем не менее, чтобы получить все преимущества от использования, скрам требует от компании многочисленных организационных и культурных изменений. В этом проекте MegaBank мы столкнулись с культурой управления, воспринимающей предварительную оценку в качестве жесткого контракта. Эд не хотел бороться с этим заблуждением, но скрам предоставил ему, Тому, Джули и команде новые возможности для этого. Каждое событие по обзору спринта позволяет увидеть разницу между оценками и реальностью, а также между тем, что команда думала, что она может сделать, и тем, что она фактически сделала. На каждом обзоре спринта у руководства есть шанс уточнить свои ожидания.
Мы оценили стоимость повышения качества функциональности с уровня «работы как обычно» до чистого, прошедшего рефакторинг и оттестированного кода. У нас на руках была оценка стоимости создания более устойчивой и поддерживаемой системы, но не было количественной оценки этих характеристик. Эд поручил команде снизить качество ради повышения скорости. Какой будет стоимость последствий этого решения для организации? Насколько эта стоимость сопоставима со стоимостью создания качественного продукта сразу? Ответы на эти вопросы, возможно, убедили бы Эда пересмотреть свое обещание руководству.
Очень немногие проекты удается оценить количественно настолько, чтобы принимать действительно объективные решения. Владелец продукта несет ответственность за направление работы команды в сторону наибольшей ценности для организации. Эта работа заключается не только в том, чтобы превращать в готовую действующую функциональность наиболее приоритетные элементы бэклога, но и в применении передовых инженерных практик и соблюдении стандартов. Работа имеет два измерения: размер и качество. В следующем примере мы рассмотрим проект, содержащий количественные данные, необходимые для принятия наилучших возможных решений в конце каждого спринта. Обычно я обсуждаю его с группой на сертификационных тренингах для скрам-мастеров.
Профессиональные сертифицированные скрам-мастера берутся за рентабельность инвестиций
Люди, уже знакомые со скрамом и использующие его, проходят обучение и сертификацию, чтобы повысить эффективность фреймворка. Вместе мы смотрим, как они могут лучше выполнять роль скрам-мастера в своих организациях. Благодаря этому компании максимизируют выгоды от применения скрама.
Для более глубокого понимания скрама на сессии обучения и сертификации используются командные упражнения, основанные на кейсах – реальных или адаптированных ситуациях из опыта организаций. Один из таких кейсов описывает гипотетический запуск сайта Высшей лиги бейсбола (Major League Baseball, MLB). Мы рассмотрим его в следующих разделах этой главы. В одном из упражнений участники группы проверяют, могут ли они участвовать в осмысленном диалоге с по-настоящему жестким клиентом по имени Джордж Штайнбреннер. Им предстоит обсудить с ним несколько трудных решений. Типичные результаты команд представлены в конце кейса.
За последние 10 лет суммарная посещаемость бейсбольных матчей увеличилась. В некоторых городах, например в Бостоне, почти все билеты распроданы и достать их по обычным каналам распространения практически невозможно. Спекуляция билетами запрещена правилами MLB и законом и основным каналом сбыта является сайт онлайн-аукциона xAuction. Несмотря на то что цены билетов на xAuction должны быть ограничены розничной ценой с прибавлением расходов, лига MLB узнала, что благодаря множеству обходных путей билеты перепродаются по цене до 1000 % от розничной.
План проекта
Руководство лиги MLB наняло внешнюю консалтинговую организацию Denture для планирования проекта по управлению перепродажей билетов на бейсбол. Итоговый план был представлен компанией Denture 15 ноября и вскоре одобрен лигой. Выдержки из этого плана приведены далее.
История проекта
Согласно новому законодательству, в бейсбольном сезоне 2004 года все перепродажи билетов должны происходить через уполномоченный лигой MLB механизм – интернет-сайт MLBTix. Функционал подобен онлайн-аукциону xAuction, с возможностью покупать и продавать билеты MLB онлайн и некоторыми специфическими для MLB особенностями. Продавцы могут продавать билеты по самой высокой цене, установив первоначальную цену торгов по своему усмотрению без нижних или верхних границ со стороны MLBTix. Также продавцы могут ограничить продолжительность аукциона, установив даты и время начала и окончания. После того как продавец выбрал покупателя, последний оплачивает билеты кредитной картой через онлайн-кассу MLBTix, а продавец отправляет покупателю билеты по почте. Продавцы получают автоматические уведомления о получении билетов покупателями. После этого MLBTix отправляет продавцу чек на получение стоимости проданных билетов за вычетом 25 %-ной комиссии лиги MLB.
Лига планирует анонсировать MLBTix на пресс-конференции 15 января. Руководство надеется, что функциональность будет частично доступна ко дню открытия сайта 30 марта 2004 года, а полностью – к ежегодной летней игре звездных игроков двух лиг бейсбола, знаменующей середину сезона, которая состоится 18 июля 2004 года. Поэтому 30 марта 2004 года – дата релиза. 30 марта сайт MLBTix должен быть запущен, покупатели и продавцы могут зарегистрироваться. Продавцы могут выставлять билеты по фиксированной цене, а покупатели – оплачивать в полном объеме с помощью кредитной карты. MLBTix – посредник в сделке, и все билеты будут передавать непосредственно от продавцов покупателям. Уже 30 июня на сайт должна быть добавлена возможность аукциона. Наконец, с 30 августа покупатели могут приобретать комплекты билетов на расположенные рядом места, просматривать размещение мест и уточнять доступный остаток.
Средства для проекта достаточны и не должны рассматриваться в качестве ограничения. Результатами работы команды является функциональность в назначенные даты. Аппаратное и программное обеспечение для поддержки MLBTix может быть закуплено или разработано своими силами – в зависимости от того, какой вариант поможет успеть в срок. До планируемой пресс-конференции руководство ожидает информацию о вероятности поставки перечисленного функционала MLBTix в указанные даты.
Бэклог продукта
Функциональные требования к MLBTix:
клиенты могут зарегистрироваться в качестве потенциальных продавцов билетов и получить идентификатор пользователя и пароль;
клиенты могут зарегистрироваться в качестве потенциальных покупателей билетов и получить идентификатор пользователя и пароль;
клиенты могут редактировать профиль, войдя с помощью идентификатора пользователя, включая адрес электронной почты, адрес, предпочтения и информацию о кредитной карте;
клиенты могут размещать билеты на аукционе, объявляя нижний порог цены, дату/время начала и окончания аукциона. Должна быть предоставлена достаточная информация, чтобы покупатели могли убедиться, что билеты соответствуют их требованиям (на правильные даты, на правильные команды, правильное количество мест с номерами, и расположение по секторам на стадионе);
клиенты могут инициировать аукцион билетов для зарегистрированных покупателей;
клиент может успешно завершить аукцион, вручив билеты покупателю, предложившему самую высокую цену к дате окончания, и в то же время списав с его кредитной карты средства и разместив их на счете MLBTix;
MLBTix уведомляет продавца об успешной продаже билетов и предоставляет информацию об успешной доставке покупателю;
MLBTix предоставляет покупателю механизм указания того, что билеты не были получены в указанный срок с даты продажи (например, плюс одна неделя);
в случае успешного получения билетов покупателем и если он не указал иное, MLBTix перечисляет продавцу денежные средства в размере стоимости билетов за вычетом 25 %;
MLBTix автоматически перечисляет 25 % плюс любую комиссию со своего счета на расчетный счет MLB;
MLBTix предоставляет клиентам возможность просматривать остатки и искать билеты по командам, датам и местам;
MLBTix предоставляет возможность рекламных акций на сайте;
MLBTix может идентифицировать злоумышленников и блокировать их доступ на сайт.
Нефункциональные требования к MLBTix:
обработка 250 000 одновременных пользователей со временем отклика менее секунды;
обеспечение безопасности при ожидаемом уровне финансовой активности (2000 билетов в день при средней цене продажи $50 США);
возможность масштабирования до 1 000 000 одновременных пользователей при необходимости;
доступность сайта 99 % в течение 24 часов в сутки 7 дней в неделю.
Вот контекст разработки для участников торгов. Система будет разработана в среде с открытым исходным кодом, с использованием технологий и программного обеспечения Intel, работающих на сервере базы данных OpenSQL. В среде разработки используются инструменты с открытым исходным кодом, например Eclipse. Участники группы разработчиков будут работать в пределах легкой досягаемости, планировка помещения свободная. Среда разработки беспроводная, уже обеспечена электропитанием и сетевым доступом. Команда разработки должна использовать репозиторий исходного кода, проверять код после каждого изменения, собирать дистрибутив как минимум ежедневно, при каждой сборке проводить модульное и приемочное тестирование программного обеспечения. В качестве процесса разработки будет использоваться скрам. Использование стандартов кодирования и любых других инженерных практик, например из экстремального программирования (Extreme Programming), остается на усмотрение команды. Все разработчики команды должны обладать отличными инженерными навыками и быть хотя бы знакомыми со скрамом и экстремальным программированием. Команда должна состоять из инженеров-разработчиков с превосходными навыками проектирования и написания кода. Инженеры отвечают за все тестирование и пользовательскую документацию, однако могут нанимать подрядчиков в помощь. Инженеры команды должны в среднем иметь 10 лет передового опыта в проектах разработки систем с использованием комплексных технологий и программных продуктов с открытым исходным кодом. Все участники команды разработки должны быть поклонниками бейсбола.
Проект
Представьте себе, что в своей конкурсной заявке вы заверили лигу бейсбола, что сможете соответствовать расписанию релизов, и почти сразу руководство MLB выбрало для разработки сайта MLBTix именно вашу организацию. Первый спринт начался 7 декабря 2003 года, а через месяц, 7 января 2004 года, состоялся обзор спринта. На пресс-конференции 15 января лига анонсировала сайт MLBTix. Вы присутствовали там и продемонстрировали функциональность, реализованную за первый спринт.
Еще через два месяца, 7 марта 2004 года, ваша команда закончила третий спринт и продемонстрировала разработанную за него функциональность руководству MLB. Все необходимые для первого релиза функции успешно реализованы. Вы намерены развернуть систему MLBTix в промышленной среде до 30 марта – к началу бейсбольного сезона MLB 2004, как и было запланировано.
Ой-ой!
Во время события планирования четвертого спринта вы и команда обеспокоены способностью MLBTix обрабатывать потенциальный объем посетителей и запросов. Для продвижения MLBTix на рынке лига наняла рекламное агентство, которое отработало слишком хорошо: MLBTix был на каждой спортивной странице в интернете и в каждом спортивном журнале. Каждый любитель бейсбола знал, что аукцион MLBTix начнет работу 30 марта 2004 года в 12:00 по восточному времени[15] Вы предоставляете руководству лиги справочную информацию, приведенную далее. Команда связалась с несколькими розничными интернет-магазинами и выяснила, что каждой продаже предшествует в среднем 100 посещений. Команда не может оценить точное количество обращений в первое время после запуска сайта, но обеспокоена тем, что оно превышает пропускную способность системы. Исследование лиги MLB указывает на то, что сайт, скорее всего, будет продавать 2000 билетов в день в апреле 2004 года и 5000 в день в последующие месяцы сезона. Вы уже предупреждали лигу бейсбола о том, что рекомендованная к использованию консалтинговой компанией Denture технология базы данных ненадежна, а тесты показали, что база данных приложения будет нагружена. Даже при всех усилиях консультантов по настройке и запуску OpenSQL на самых быстрых массивах дисков, максимальное количество одновременных транзакций со временем отклика менее трех секунд составляет 100 операций. Ожидается, что нагрузка будет расти во время обеда и после ужина. Команда обеспокоена тем, что пиковые объемы могут перегружать сервер и что кривая роста производительности будет очень близка к 110 транзакциям в секунду. Вы выяснили, что база данных Miracle будет легко поддерживать требования к масштабированию, предъявленные руководством MLB, но потребуется еще один спринт, чтобы выторговать замену OpenSQL и на Miracle. Результат? Приложение будет готово только через месяц после открытия сезона. Что посоветуете? Вы все это говорите менеджменту лиги и замечаете, что руководитель начинает все больше беспокоиться: постукивает ногами, плюется на пол и бубнит ругательства себе под нос – кажется, он очень недоволен. Он просит вас опустить все эти технические детали и сказать ему, что нужно сделать. Интересуется, пора ли ему звонить в рекламное агентство и сообщать, что он хочет объявить о недоступности аукциона MLBTix к 30 марта. Учитывая упомянутые риски, механизм вознаграждения и личные инстинкты, что вы должны посоветовать руководителю лиги? Я использовал это упражнение больше десяти раз на сертификационных тренингах для скрам-мастеров, где обучаются люди, уже обладающие знаниями о скраме и разработке программного обеспечения. Я попросил 200 скрам-мастеров, сгруппированных в 40 команд, сформулировать совет руководителю MLB. Вот некоторые из ответов. Совет команды 1 Команда 1 говорит руководителю лиги, что проблема в масштабируемости. Из-за его агрессивной рекламной кампании инфраструктуре MLBTix придется обрабатывать больше транзакций, чем первоначально предполагалось. Команде велено использовать базу OpenSQL, которая просто не масштабируется до такого объема. В результате команда предлагает произвести замену OpenSQL на базу данных Miracle. Работа начнется сразу же, и, как только выяснится, займет она один или два месяца, руководство будет незамедлительно проинформировано о сроке. Тем временем команда советует комиссару отложить MLBTix на неопределенный срок – по крайней мере до поры, пока проблема масштабируемости не будет решена. Ответ руководителя лиги: «Из сказанного вами я не понял ни слова, кроме того, что подвергнусь публичному унижению. Я уже объявил всем, что сайт будет доступен 30 марта, а вы не только говорите мне, что это не случится к указанной дате, но и не можете сказать точно, когда он будет. Если бы агент Дерека Джитера[16] попробовал такое, ему пришлось бы иметь дело с моим руководством». Совет команды 2 Команда 2 предлагает руководителю лиги ни о чем не беспокоиться. Участники команды очень рады, что MLBTix добился такого успеха, и уверены, что рекомендованная Denture технология будет работать прекрасно, иначе компания не стала бы ее рекомендовать. Ответ руководителя лиги: «Вы хотите меня успокоить, я понял. Но я также заметил, что вы будете готовы покинуть корабль, обвиняя Denture, если технология не сработает. Мне нужен совет, а не обходительная формулировка». Совет команды 3 Команда 3 предлагает руководителю лиги подход, позволяющий обслужить любое количество посетителей MLBTix. Если на стадионе Yankee не будет достаточного количества открытых касс, образуются длинные очереди болельщиков. Поэтому команда реализует функцию, которая будет выводить посетителям сообщение: «Ввиду повышенного спроса на билеты просим вас подождать». Затем каждые 30 секунд будет выводиться сообщение: «Пожалуйста, оставайтесь в очереди. Ваш запрос важен, и мы хотим вам помочь». Команда считает, что при таком подходе MLBTix может обслуживать любое количество клиентов без каких-либо дополнительных затрат. Ответ руководителя лиги: «Очень ценю, что вы нашли способ не увеличивать бюджет, но ваша бережливость загнала меня в угол, поскольку я ненавижу такие сообщения. Я ненавижу и очереди, но, находясь в реальной очереди на стадионе Yankee, по крайней мере, вижу, что происходит вокруг. Ваше предложение приемлемо, но я не очень доволен». Совет команды 4 Команда 4 считает, что успех рекламной кампании повлек дополнительную работу для команды разработки. Выводить сайт в текущем состоянии рискованно – работать он, может, и будет, но первые несколько дней его функционирования будут плачевными. Команда подготовила несколько вариантов. Первый вариант – уже на следующей неделе позволить людям начать использовать сайт MLBTix для регистрации и посмотреть, что будет происходить. До 30 марта клиенты не смогут покупать и продавать билеты, но возможность зарегистрироваться и посетить сайт уже сейчас может снизить нагрузку в день открытия. Конечно, по-прежнему останется риск возникновения проблем, которые невозможно рассчитать количественно. Однако этот вариант не требует никаких дополнительных затрат. Второй вариант – усилить текущие аппаратные мощности системы для команд с самым высоким ожидаемым объемом обращений: Yankees, Red Sox, Mariners, Braves и Giants. Это аналогично открытию дополнительных касс по продаже билетов. Этот вариант обойдется в $3,4 млн и позволит сайту MLBTix выйти по графику с минимальным риском. Третий вариант – отложить релиз MLBTix на месяц, чтобы улучшить систему для обработки большего, чем ожидалось, объема клиентов. Стоимость этого варианта составляет $1,1 млн за дополнительный месяц работы и $425 000 в виде упущенной выгоды лиги MLB от 25 %-ной комиссии. Ответ руководителя лиги: «Я понимаю. Вы четко изложили альтернативы, и их нетрудно сравнить, потому что вы очень понятно все объяснили. Хм. С одной стороны имеем непредсказуемый риск потерять все, с другой – можем потратить $3,4 млн, чтобы продолжить работать по плану и свести риск к минимуму, а с третьей стороны – заплатить $1,525 млн, испытать смущение и стыд за месячное опоздание, но решить проблему наверняка. Мы не оценили, сколько клиентов мы потеряем, опоздав на месяц, но это не должно стать слишком большой проблемой, поскольку мы – монополисты. Куда еще могут пойти клиенты? Значит, мне следует решить, стоит ли моя гордость около $1,9 млн. Я горд, но не глуп. Действуем по третьему варианту!» Командам было очень трудно поговорить с владельцем продукта в лице руководителя лиги MLB на понятном ему языке. Скрам основан на сотрудничестве, которое требует понимания, а оно, в свою очередь, требует хорошей коммуникации. Если владелец продукта говорит только в деловых терминах, а команда – только в технических, то не будет продуктивного общения, а следовательно, и сотрудничества. Вспомните о проекте приложения для денежных переводов MegaBank. Когда менеджер по разработке заподозрил, что проект займет больше времени, чем он пообещал своему руководству, он поручил команде сделать все необходимое, чтобы успеть к назначенной дате. Будь у него адекватные количественные данные, он мог бы сравнить затраты на повышение качества системы в течение дополнительных двух месяцев с расходами на поддержание некачественно реализованной и запутанной системы в течение ее жизненного цикла. Он решил больше тратить на дальнейшее обслуживание, хотя и не знал, насколько дорогим окажется его выбор. Как сказал мне участник команды: «Несмотря на использование нами скрама, мы работаем так же, как раньше». Когда консультанты Denture запланировали создание аукциона MLBTix, они предоставили достаточно информации, чтобы обеспечить руководству лиги возможность идти на компромиссы. MLBTix был комплексным проектом и обязательно напоролся бы на рифы. Однако наличие финансовых данных позволило сравнить различные альтернативы и сделать рациональный выбор. Руководитель лиги оценил свою гордость и решил сохранить деньги в кошельке. Планы, содержащие достаточную информацию, облегчают принятие рациональных решений. Из четырех описанных здесь команд только одна использовала финансовые значения из плана и предложила варианты, понятные руководителю лиги бейсбола. Другие команды либо пытались обсудить проблему на языке, не имеющем для руководителя лиги смысла, либо полностью принимали на себя риски проекта, заявляя, что все в порядке. В большинстве групп проводимых мной тренингов многие команды принимают риск и не предоставляют альтернативы заказчику. К сожалению, это довольно типичная манера поведения в индустрии разработки программного обеспечения: мы до последнего не раскрываем карты, и только в конце проекта наши клиенты узнают, насколько все на самом деле плохо. Не намеренно. Скорее это естественное влияние среды, в которой разработчики понимают состояние проекта не лучше, чем руководство.
Выводы
Скрам предоставляет множество возможностей для инспекции проекта и необходимых адаптаций. Их цель – оптимизация выгоды, которую проект приносит организации. Тем не менее, чтобы принимать наилучшие решения, ответственный за адаптацию должен обладать адекватной информацией. В случае с MegaBank у владельца продукта Джули и менеджера по разработке Эда не хватило информации, чтобы решить, придерживаться созданного всей командой семимесячного графика или более короткого пятимесячного, первоначально обещанного руководству. При отсутствии данных о затратах и выгодах они согласились исполнять взятые на старте обязательства.
В отличие от Джули и Эда в распоряжении руководителя лиги MLB было достаточно данных для количественной оценки затрат и преимуществ альтернативных путей развития проекта. К сожалению, даже при наличии таких данных очень немногие используют их. Большинство команд настолько привыкли к отсутствию информации, что даже не задумываются использовать ее и в результате получают упреки от клиентов.
Как показал пример MegaBank, планирование в проекте по скраму не обязано быть длительным. Однако оно должно быть достаточно адекватным, чтобы использовать цикл инспекции и адаптации, жизненно важный для эмпирических процессов. В любом проекте четко сформулированные предположения, риски и наличие данных о выгодах и затратах позволяют производить более осмысленные адаптации.
Глава 7
Отчетность по проекту – поддержание прозрачности
Проект по скраму контролируется путем частых инспекций с последующими необходимыми адаптациями. Часть этой информации передается лично от человека к человеку. Например, ежедневный скрам открыт для всех: участники могут понять и оценить настроение, отношение к проекту и свой прогресс в спринте. Обзор спринта позволяет получать представление о том, какую функциональность создает проект, насколько она ценна, каков уровень качества, каким характеристикам соответствует.
Остальная информация передается в письменной форме. Например, бэклог продукта описывает требования проекта, перечисляя их в порядке приоритета. Любой участник проекта может посмотреть бэклог продукта, который хранится в общей папке в известном месте. В дополнение к динамической информации, которая представляется письменно и наглядно, в конце каждого спринта создаются официальные отчеты. Они позволяют каждому заинтересованному в проекте получать актуальную информацию в виде снимка текущего прогресса проекта. Вся эта информация, как динамическая, так и статическая, считается частью отчетности по скрам-проекту.
Давайте посмотрим, какую информацию о статусе проектов по скраму использовали разные компании. В MegaEnergy мы увидим переход от традиционного отслеживания исполнения работ к отчетности в духе скрама, хотя руководству были неудобны новые способы отслеживания прогресса. Руководителю MegaBank, финансирующему проект, не нравились периодические отчеты скрама. Он хотел получить обобщенное графическое представление о прогрессе проекта. Мы посмотрим, каким образом эта потребность была удовлетворена. В Service1st отчеты участников команды разработки во время ежедневного скрама были настолько общими и абстрактными, что это 15-минутное событие казалось практически бессмысленным. Мы рассмотрим, почему это произошло, и обсудим, как обеспечить достаточный объем информации и деталей в отчетах.
Новая отчетность в проекте MegaEnergy
Компания MegaEnergy познакомилась со скрамом через пилотный проект по учету земельных участков, который рассматривался во второй главе. Этот проект уже дважды стартовал и завершался без результатов. ИТ-директор узнал о скраме и убедил своих коллег-менеджеров попробовать. Они считали, что проект по учету земельных участков станет хорошей возможностью оценить применимость скрама в организации: если скрам поможет исправить ситуацию, то будет считаться достойным дальнейших проб в других проектах MegaEnergy.
Команда проекта в MegaEnergy создавала внутренние артефакты: технические задания, архитектуры, модели, код. Если проект не стопорился на разработке этих артефактов, то в самом конце они объединялись и превращались в рабочую систему. Только тогда заинтересованные лица могли увидеть то, что будут в дальнейшем использовать. Заинтересованные лица – это те, кто заинтересован в результатах проекта, включая тех, кто финансирует проект, и тех, кто будет пользоваться разрабатываемой системой.
Руководители проектов в MegaEnergy поддерживали осведомленность заинтересованных лиц и руководства, информируя их о ходе проекта с помощью периодических отчетов. Поскольку традиционные проекты управляются на уровне задач, в этих отчетах описывался процент завершенных задач, отставание от графика, возникшие проблемы и предлагаемые меры реагирования, текущие риски и рекомендуемые способы снижения их вероятности и влияния. Поскольку задачи имеют лишь косвенное отношение к желаемой пользователями функциональности, эти отчеты скорее расстраивали заинтересованных лиц, чем приносили пользу. Затем для отслеживания прогресса в MegaEnergy начали использовать отображение плана проекта в виде диаграммы Ганта. Это ключевой инструмент в управлении проектами на уровне задач. Выявив необходимые задачи, зависимости между ними, исполнителей и ресурсы, с его помощью можно определить итоговый срок завершения проекта и следить за его отклонениями от плана.
На протяжении многих лет в MegaEnergy применялся устоявшийся, очень традиционный и формальный процесс управления проектами, разработанный офисом управления программами, в котором работали высокопоставленные сотрудники, ранее руководившие проектом строительства трубопроводов. Диаграмма Ганта была для них святым Граалем для планирования и контроля над проектом. После первого провала проекта «Участок» они решили повысить степень детальности начального планирования и ужесточить процесс контроля изменений при второй попытке. Они полагали, что первый проект потерпел неудачу, потому что руководство допустило слишком много изменений в первоначальном плане. Услышав это, я вспомнил о данном Эйнштейном определении безумия: повторять одно и то же снова и снова и ожидать других результатов. Удивительно, но это очень распространенный подход. Если управляемый предопределенным подходом проект терпит неудачу, люди часто винят в этом недостаточно строгое следование этому же подходу и делают вывод, что для успеха очередной попытки необходимо лишь усилить контроль и повысить четкость артефактов проекта.
Высшее руководство, в том числе управляющий комитет проекта «Участок» и офис управления проектами, знали, что во время третьей попытки будет опробовано что-то новое. При этом работающие в офисе управления программами люди не были знакомы ни с управлением эмпирическим процессом, ни со скрамом. Однако они не возражали против нового подхода, если проект будет контролироваться принятым в MegaEnergy способом – с помощью диаграмм Ганта.
Это подкинуло нам задачку. Должны ли мы проводить обучение высшего руководства скраму, включая сотрудников офиса управления программами? Должны ли мы сообщить им о радикально ином подходе, который мы собрались использовать в проекте «Участок»? Должны ли мы вступить с ними в долгую дискуссию о различиях в управлении предопределенным и эмпирическим процессами? Мы знали, что эта дискуссия будет эмоциональной, ведь офис управления программами имел большую историю успеха в MegaEnergy. Их подход использовался для управления гораздо более массивными проектами, чем проект «Участок», а причиной неудач предыдущих двух попыток называли человеческие ошибки, а не недостатки процесса. Как убедить их в обратном?
В скраме менеджеры измеряют и отслеживают требования, а не задачи. Требования перечислены в порядке приоритета в бэклоге продукта и сгруппированы в предполагаемые спринты и релизы. Бэклог продукта в начале спринта отличается от бэклога продукта в начале следующего спринта, поскольку окружающие бизнес-условия могут привести к его изменению или переупорядочению. Некоторые элементы бэклога могут быть не завершены в ходе спринта и перенесены в следующий спринт. Первоначально запланированный состав релиза продукта может быть изменен: владелец продукта вправе добавить, перегруппировать, изменить или удалить требования из состава релиза. Предварительно запланированные спринты могут изменить свой состав: элементы могут быть добавлены или удалены из бэклогов спринтов, поскольку появляются новые сведения о размерах отдельных элементов, их приоритетах или о производительности команд разработки.
Для большинства заинтересованных лиц и руководителей отчеты в скраме сдвигают привычную парадигму. Обычно базовый план фиксируется, а любые отклонения от плана рассматриваются как нежелательные. Периодические отчеты руководству показывают, насколько фактическое состояние проекта соответствует базовому плану. Вместо этого скрам сообщает о несоответствиях плану, реакциях на эти несоответствия и влиянии на план проекта. Скрам приветствует изменения и предоставляет отчеты, отслеживающие изменения и их влияние на проект.
Скрам-мастер Рут была опытным менеджером проектов в MegaEnergy. Она знала культуру MegaEnergy изнутри и снаружи, знала директоров, которые получали отчеты о прогрессе проекта «Участок». Она работала с сотрудниками из офиса управления программами и точно знала, чего они хотят и почему. Она знала, что отчеты с диаграммами Ганта являются основой их системы отчетности. Рут умела создавать и поддерживать в актуальном состоянии календарный и ресурсный планы проекта в Microsoft Project, который был стандартным инструментом управления проектами в MegaEnergy.
Рут и я решили обсудить, как мы можем убедить людей из офиса управления программами позволить нам продолжить работу со скрамом. Они инвестировали время в текущий метод планирования и управления проектами, хорошо понимают его. Если мы предложим им попробовать новую форму управления проектами, например скрам, они не будут заинтересованы в успехе этой инициативы. В этом случае отчетность вызовет затруднения, потому что нам придется согласовывать любые изменения. Слова «эмпирический», «самоорганизующиеся» и «эмергентность» были практически неизвестны в офисе управления программами и, вероятно, вызвали бы отторжение.
Подход, который мы решили применить для представления скрама высшему руководству и офису управления программами, напоминает мне старую шутку. Джон видит, как Хэнк тянет длинную веревку вверх по узкой, извилистой горной дороге. Джон спрашивает Хэнка, зачем он тянет веревку. «Потому что это проще, чем толкать ее!» – отвечает Хэнк.
Наш подход был проще и понятнее, чем стандартный скрам. Зато нам не нужно было пытаться убедить всех в том, что управление эмпирическим процессом, воплощенное в скраме, станет приемлемой альтернативой их нынешнему подходу. Мы решили предоставить руководству планы и отчеты в виде диаграмм Ганта, но не на основе задач, а на основе требований бэклога.
В скраме существует четыре отчета, которые владелец продукта и скрам-мастер создают в конце каждого спринта. Первым делом я познакомил с ними Рут:
1. Старый бэклог – содержит элементы бэклога по состоянию на начало предыдущего спринта;
2. Новый бэклог – содержит бэклог продукта в начале следующего спринта;
3. Отчет об изменениях – описывает все различия между бэклогами продукта в первых двух отчетах;
4. График сгорания элементов бэклога продукта.
В отчете об изменениях содержится краткое описание того, что произошло во время спринта, что было замечено на обзоре спринта и какие адаптации были произведены в ответ на инспекцию при обзоре спринта. Отчет об изменениях отвечает на все эти вопросы:
Почему содержание будущих спринтов было изменено?
Почему дата или содержание релиза были изменены?
Почему во время спринта команда реализовала меньше требований, чем ожидалось?
Куда помещена невыполненная в спринте работа?
Почему команда разработки была менее или более эффективной, чем ожидалось?
Отчеты со старым и новым бэклогами продукта представляют собой снимки проекта между двумя спринтами. В отчете об изменениях отражены различия бэклогов и их причины. Набор этих отчетов документирует изменения, инспекции и адаптации, произведенные за определенный период времени.
Дальше мы постарались преобразовать бэклог продукта в диаграмму Ганта. Изображенный на рис. 7.1 бэклог хранился в электронной таблице в виде простого упорядоченного списка требований. Зависимые требования следовали в списке после требований, от которых они зависели. Таким простым способом разрешались зависимости между требованиями. Сами требования сегментировались в спринты и реализовывались уникальными строками.
Как видно по рис. 7.2, диаграмма Ганта намного более впечатляющая и запутанная, чем список элементов бэклога продукта. В графическом виде она линиями показывает зависимости между задачами и обозначает их разными цветами. Но внешность бывает обманчивой: если диаграмма Ганта содержит требования вместо задач, она становится просто графическим представлением бэклога продукта.
Рут открыла файл с электронной таблицей бэклога проекта в Microsoft Excel и создала новый проект в Microsoft Project. Она скопировала и вставила весь список элементов бэклога из Excel в Project в столбец «Название задачи», а оценки – в колонку «Длительность». Это был прямой перенос из одного продукта Microsoft в другой. Она сгруппировала требования (MS Project считал их задачами) в спринты, как показано на рис. 7.3.
Затем Рут заполнила представления «Задачи» и «Отслеживание», для каждого элемента бэклога указав длительность работы, а для каждого спринта – дату его начала. Столбец «% завершения» обычно содержал значение 100 почти для каждой строки в конце спринта. Мы договорились, что, если где-то будет не 100 %, она разделит элементы и поместит невыполненную работу в будущие спринты.
Единственный отчет, который мы не смогли легко преобразовать в существующие отчеты MegaEnergy, – график сгорания бэклога продукта, изображенный на рис. 7.4. Он показывает прогноз оставшейся работы по проекту. В начале каждого спринта оставшийся объем работы измеряется путем суммирования оценок всех незакрытых элементов бэклога продукта. От спринта к сринту увеличение или уменьшение этой суммы можно использовать для оценки прогресса в завершении работы релиза.
По горизонтальной оси размечена шкала времени, а по вертикальной оси владелец продукта в начале каждого спринта отмечает объем оставшейся работы по элементам бэклога продукта. Соединяя точки всех завершенных спринтов, мы получим ломаную линию, отображающую прогресс выполнения всей работы. Определив по последним нескольким спринтам средний наклон, можно нарисовать линию тренда. Пересечение линии тренда и горизонтальной оси указывает время, когда вся работа будет выполнена. Рут и я считали, что это важный отчет. Он графически покажет руководству взаимосвязь функциональности и времени, поэтому мы решили включить его в перечень отчетов в качестве приложения.
В конце первого спринта руководство получило новые отчеты. Они были во многом похожи на старые отчеты, за исключением того, что Рут отслеживала не завершение задач, а создание функциональности. Написав об этом в предисловии к отчетам, она пришла с ними к управляющему комитету. На графике сгорания бэклога продукта Рут показала влияние реализованных элементов бэклога продукта на весь релиз. Затем она показала разницу между бэклогами продукта в начале и конце спринта. В этом конкретном случае разница была большой. Владелец продукта повысил значение первого инкремента, приняв решение о поставке его в промышленную среду. Это означает, что функциональность инкремента продукта была готовой к поставке, пользователи отдела учета земельных участков прошли обучение и начали использовать эту функциональность в своей повседневной работе. Решение о поставке повлекло добавление в бэклог релизного спринта длительностью в две недели – половину стандартного спринта MegaEnergy. Обсуждая его, управляющий комитет осознал основную выгоду скрама: инкремент каждого спринта потенциально может быть поставлен пользователям. В рассматриваемом случае владелец продукта Джейн решила, что ранняя поставка была оправданна. Владелец продукта инспектировала ситуацию и адаптировала план. Управляющий комитет увидел инкрементальную природу скрама и преимущества частых инспекций и адаптаций.
Рут правильно предположила, что высшее руководство не хочет говорить о процессе – ему нужны результаты. Но внедрение нового формата отчета о прогрессе проекта требовало обучения руководителей скраму, а для этого было нужно, чтобы офис управления программами рассмотрел совершенно новый и непривычный для его сотрудников подход к управлению проектами. При этом высшему руководству не было никакого дела до скрама – его волновали вложенные в проект инвестиции.
Рут могла продолжить составление традиционных для MegaEnergy отчетов по задачам. Для этого ей пришлось бы предварительно разработать ожидаемый план по задачам, а затем подгонять под него бэклог каждого спринта. У нее не было ни времени, ни желания так поступать, но она не хотела менять формат отчетности. Рут решила сохранить формат и сообщить о прогрессе в реализации требований и функциональности, а не в завершении задач. Оформив бэклог продукта в Microsoft Project, она смогла представить его в привычном руководству форме.
Читать бесплатно другие книги:
