Скрам. Гибкое управление продуктом и бизнесом Швабер Кен

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

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

как ограничение по времени помогает постичь «искусство возможностей» и избежать перфекционизма;

как инкрементальная поставка продукта помогает повысить уровень инженерных практик;

как наделения полномочиями и самоорганизация помогают развить креативность и повысить удовлетворенность сотрудников.

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

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

Третья фирма– научно-исследовательская организация Lapsec, которая проверяет реалистичность идей программных приложений для правительства США. После событий 11 сентября компании было поручено быстро разработать новую систему для анализа информации о потенциальных террористических угрозах. Этот проект требовал объединения нескольких технологий, включая одну новую и непроверенную. Она называлась «слияние данных» (data fusion) и представляла собой усовершенствованную форму глубинного анализа данных (data mining).

Ситуация в Service1st

Длительность цикла разработки новой версии программного обеспечения в Service1st составляла 12 месяцев. Последние два месяца каждого цикла всегда были похожи на тушение пожара. После каждого такого «выталкивания» нового релиза в боевую среду сотрудники были выжаты, а ПО оказывалось нестабильным. Чтобы избавиться от переработок и повысить качество релизов, руководство компании решило равномернее распределить интенсивность усилий по более короткому отрезку времени в шесть месяцев.

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

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

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

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

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

У каждого сотрудника было много задач. Так почему же почти все подразделение в 9 утра еще не приступило к работе? Вице-президент отметил, что команды обычно не испытывали никакого давления в течение первых трех из шести месяцев цикла создания релиза и что участники принимались за разработку всерьез лишь в течение последних двух месяцев.

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

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

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

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

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

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

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

1. Вход в систему для инициирования кредита;

2. Запуск процесса инициирования кредита;

3. Унифицированный внешний вид продукта;

4. Унифицированная для обоих продуктов безопасность;

5. Бесшовное и масштабируемое исполнение процесса.

После составления списка я объяснил команде разработки концепцию трассирующей пули, представленную Эндрю Хантом и Дэвидом Томасом в книге «Программист-прагматик. Путь от подмастерья к мастеру»[13]. Концепция заключается в следующем: стреляя из автоматического оружия в темноте, трудно поразить цель, но каждая 50-я пуля оставляет видимый след, его можно использовать для корректировки прицела. Я попросил команду создать трассирующую функциональность, проходящую через все слои системы, чтобы проложить и показать путь для всех других функций. Такую функциональность, чтобы вход в систему и бизнес-процесс инициирования кредита частично или целиком задействовали оба продукта и отвечали всем перечисленным в бэклоге нефункциональным требованиям.

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

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

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

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

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

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

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

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

Ситуация в издательстве Tree Business Publishing

Издательство Tree Business Publishing (Tree) – подразделение холдинга Tree Holdings, публикует профессиональные журналы в самых разных отраслях. Прошло почти 10 лет с тех пор, как Tree решило публиковать свои журналы не только в печатном виде, но и в интернете. Редакторы Tree распорядились как можно скорее опубликовать электронные версии, однако за два года в сети оказался только один журнал. Причиной промедления стало открытие, что веб-публикация не похожа на печатную. Прогресс застопорился, потому что Tree хотело предварительно получить ответы на ряд вопросов:

1. Как представить журнал эффективно и «вкусно» для онлайн-версии?

2. Как изменятся внутренние процессы редактуры и производства, когда журналы станут публиковаться и в печатном виде, и в интернете?

3. Какой наилучший механизм публикации контента в сети следует использовать?

Редакторы, писатели и команды разработчиков программного обеспечения Tree потратили некоторое время, пытаясь найти приемлемое решение. Первоначально все редакторы запрашивали создание «медианейтральных» инструментов публикации, которые генерировали бы потоки данных на XML для дальнейшего преобразования контента в любой требуемый формат. Менеджеры компании Tree принципиально одобрили такой подход, однако решили, что создание и управление таким медианейтральным контентом будут труднее, чем предполагалось вначале. В результате уровень комплексности и неопределенности задачи по переходу на медианейтральный режим работы оказался настолько высоким, что затормозил движение в направлении главной цели – представления журналов Tree в интернете.

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

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

Чтобы устранить неразбериху и продвинуться в достижении цели, был принят ряд решений:

платформа WebPub будет усовершенствована для универсальной публикации, но в первую очередь необходимо реализовать поддержку публикации журналов Tree;

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

веб-разработчики журналов остановят всю внутреннюю разработку, будут учиться использовать платформу WebPub и работать над интеграцией редакционного процесса своего журнала с платформой WebPub посредством XML.

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

Чтобы оправдать довольно дорогостоящее приобретение WebPub, сроки установили очень сжатые, а разработчики WebPub зависели от результатов двух незавершенных и неопределенных активностей. Задачи постоянно менялись по мере уточнения требований журналов к универсальному XML-формату и параллельной доработки основного функционала платформы WebPub. Разработчики стреляли по движущейся цели, остановка которой не предвиделась.

Издательство Tree наняло меня, чтобы запустить скрам в WebPub. Несколько лет назад я уже рассказывал этой компании о фреймворке. Руководители вспомнили презентацию и решили, что скрам может стать подходящим способом улучшить ситуацию. Им особенно понравилась идея инкрементальной поставки функциональности с демонстрацией осязаемого результата. Более 100 человек было задействовано в инициативе по публикации журналов в интернете, и все ощущали срочность этой задачи, однако заметного прогресса не было.

Отдельные усилия по усовершенствованию платформы WebPub, стандартизации XML и публикации журналов в сети оказывались неразрывно переплетенными. К счастью, скрам-команды являются кросс-функциональными. Аналогично ежедневному скраму, который координирует работу нескольких людей в одной команде разработки, встреча скрам скрамов (Scrum of Scrums) координирует работу нескольких команд, работающих над одним проектом. Эта встреча по сути – ежедневный скрам, в котором принимают участие по одному человеку от каждой команды разработки. Перед официальным стартом проекта его планировщики разделяют работу на крупные блоки для минимизации зависимостей между командами, и те работают над условно независимыми частями архитектуры проекта. Такая встреча эффективно координирует команды, когда обсуждения требуют незначительные связи и зависимости. Однако в Tree зависимости были настолько сильными, что скрам скрамов не работал.

Чтобы быстро создать инкремент продукта, была необходима параллельная разработка функциональности XML, WebPub и журналов. Компоненты XML и WebPub были объемны и имели инфраструктурный характер. Зависимости были слишком комплексными, устранение или разрешение их до начала работы заняло бы много времени и остановило бы работу. Я решил, что наилучшим вариантом станет координация зависимостей теми, на кого они влияют: командам разработки придется самоорганизовываться для поиска путей преодоления этих препятствий.

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

На планировании спринта первой команды мы создали бэклог продукта, поместив вверху списка нефункциональные требования к структурам XML и возможностям WebPub, необходимым для публикации журнала. Команда разработки взяла на себя обязательство по реализации готового к поставке инкремента продукта в ходе спринта.

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

Разработчики XML и WebPub, назначенные в четыре журнальные команды разработки, разрешали зависимости, возвращаясь в свои команды XML и WebPub. Они знали о задачах отдельных журнальных команд и добивались, чтобы функциональность для их поддержки была разработана параллельно в командах XML и WebPub.

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

Уровень комплексности в Tree был ошеломляющим, а ситуация была близка к хаосу. Команды XML, WebPub и журналов разрабатывали зависимые функции параллельно. Реализуемые командами разработки требования были крепко переплетены и взаимозависимы. Обычные механизмы инспекции и адаптации скрама были бы перегружены, если бы я организовал команды как обычно: одна команда XML, одна команда WebPub и по одной команде для каждого журнала. Ежедневный скрам не предоставил бы достаточно возможностей для инспекции прогресса, обнаружения зависимостей и, как следствие, поиска, отбора и принятия необходимых мер по адаптации к сложившейся ситуации.

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

Эта кросс-командная координация очень похожа на то, что позже стало называться скрам скрамов (Scrum of Scrums) – встреча и подход, при котором работа нескольких команд разработки координируется участниками от каждой команды. Такой способ амоорганизации работы команд заметно помог издательству Tree, и первые четыре журнала начали появляться в сети в течение трех месяцев, а пятый и следующие не заставили себя долго ждать.

Ситуация в Lapsec

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

В течение нескольких лет компания Lapsec исследовала возможность «слияния данных» (data fusion) для получения ценных знаний из массива разрозненной информации – усовершенствованной формы глубинного анализа данных (data mining). В момент слияния к крупным массивам применялись передовые алгоритмы, которые быстро помещали данные в хранилище и преобразовывали их в формат, который подходит для анализа и поиска цепочек подозрительных фактов. В начале 2002 года Lapsec получила добро на этот проект, и компании был предоставлен доступ ко всем транзакционным базам данных американского правительства различных уровней.

В проекте хватало головоломок и сложностей, решение и преодоление которых требовало разной степени мастерства, интенсивности и упорства. Было необходимо:

постоянно и своевременно получать данные от агентств, которые не знали слова «сотрудничество»;

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

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

приобрести или создать новые технологии для хранения промежуточных данных в динамически изменяющихся структурах;

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

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

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

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

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

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

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

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

Перед вторым днем запуска команды я плохо спал: переживал, что следующий день станет катастрофой, а тренинг в целом может провалиться. Наконец я решил, что у меня достаточно информации для формирования гипотетического проекта. Мне сказали, что видение проекта заключается в поддержании национальной безопасности посредством слияния и анализа данных. Каждый гражданин США был знаком с критикой в адрес правительства относительно сбора и использования разведданных перед 11 сентября. Я знал, что одни участники команды являлись ведущими экспертами страны по данным, другие – отвечающими за разработку алгоритмов математиками, а третьи – специалистами по поиску в интернете. Понимая, однако, что могу ошибаться в деталях, я ощущал уверенность, что смогу создать адекватный гипотетический бэклог продукта, чтобы помочь команде разработки объединиться.

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

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

выявить людей, которые посещали летную школу в течение последних трех месяцев и соответствуют профилю кандидата к совершению террористического акта против Соединенных Штатов;

отображать информацию графически, чтобы облегчить операции объединения и детализации, сворачивания и разветывания данных;

объединить информацию из нескольких источников на основании запроса или введенных критериев;

декомпозировать результаты запроса;

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

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

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

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

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

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

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

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

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

Выводы

Проекты Service1st, Tree и Lapsec были настолько комплексными, что обычные методы планирования и управления не работали – проекты требовали тесной синхронизации многих видов деятельности. Во всех одновременно трудились несколько команд разработки, которые за короткий промежуток времени должны были создать готовый к демонстрации продукт. И все топтались на месте, пытаясь выяснить, с чего следует начать, как изменить свои ситуации и создать работоспособные планы.

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

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

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

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

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

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

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

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

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

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

Сотрудничество заказчика и команды

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

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

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

Разработчики и менеджеры ставят заказчикам условие: «Мы собрали ваши требования и на их основании создали модели. Вместе они составляют полное и точное описание того, что вы хотите, посмотрите его. Имейте в виду, что после ответа “да” вам будет стоить намного дороже передумать!» Такая формулировка подразумевает контракт между заказчиками и разработчиками: «Если вы согласны с тем, что представленное нами является полным описанием ваших требований, мы начнем их реализацию. Если нет, то мы продолжим сбор требований, пока вы не сдадитесь!» Личного сотрудничества практически не остается.

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

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

Давайте рассмотрим некоторые примеры, в которых скрам помог владельцам продуктов и группам разработчиков работать вместе, чтобы максимизировать ценность проекта. В Service1st мы увидим, как высшее руководство приняло непосредственное участие в работе через роли владельцев продуктов. В TechCore мы увидим, как молодой предприниматель смог удачно продать свою компанию, сосредоточив усилия на роли владельца продукта. Наконец, в MegaBank мы увидим, как скрам-мастер аккуратно добился того, чтобы заказчики стали владельцами продуктов, и одновременно он сократил временные затраты на обучение и внедрение скрама.

Руководители Service1st снова в действии

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

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

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

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

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

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

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

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

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

Устранение проблемы XFlow в MegaFund

Страницы: «« « 12345 » »»