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

Чрезмерное усердие в Contoso.com

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

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

Недостаточно просто быть правым

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

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

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

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

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

Извлеченные уроки

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

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

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

Волк в MegaFund

MegaFund – одна из крупнейших в мире компаний по управлению фондами: ее инновационные фонды привлекали инвесторов сильнее, чем фонды других организаций. Однако к 1997 году eTrade, Charles Schwab и другие финансовые компании произвели революцию в торговле акциями: у клиентов появилась возможность управлять своими счетами, покупать и продавать акции без участия и помощи профессиональных биржевых брокеров.

Интернет и мобильные технологии сделали возможным использование карманных персональных компьютеров, сотовых телефонов и интерактивных голосовых меню. К сожалению, MegaFund осталась в стороне. Ее технологическое подразделение было громоздким и неповоротливым. Вдобавок в течение предыдущего года внедрялся стандарт CMM[10]10
  Capability Maturity Model – модель зрелости возможностей (или модель полноты потенциала) создания программного обеспечения.


[Закрыть] уровня 3, который при некорректном применении мог усугубить бюрократию в организации. Это и произошло в MegaFund: добиться чего-либо стало неимоверно тяжело.

Специалисты компании изучили новые технологии и начали проект, который позволил бы получить доступ к старым базам данных, где хранилась вся информация о счете клиента и торговых операциях. После нескольких провальных запусков руководство MegaFund решило сделать все правильно. Обычно, когда менеджеры говорят, что собираются «сделать проект правильно», этот проект постепенно умирает от микрокоординации и избыточного администрирования. С этим проектом случилось то же: через девять месяцев он застопорился на неугасающих спорах о том, какие технологии использовать. Операционной системой должна быть Microsoft Windows NT 4.0, Solaris или AIX? Должна ли MegaFund стандартизировать технологию Intel? Какие серверы более масштабируемы: Sun или IBM? Использовать технологию COM или CORBA? Споры внутри организации продолжались, а конкуренты шли вперед.

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

Атака волка

Команда разработки начала месячный спринт и в течение первых двух недель добилась впечатляющего прогресса: выбрала необходимые ей технологии, настроила инструменты и стала осуществлять первые транзакции. Целью спринта была выработка подхода к решению технологических проблем MegaFund и созданию пакета конкурентоспособных решений.

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

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

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

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

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

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

Извлеченные уроки

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

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

Выводы

В Trey Research и Litware мы увидели, как нелегко бывает понять роль скрам-мастера, в Contoso.com – как скрам-мастер может нарваться на увольнение, а в MegaFund – как скрам-мастер одновременно и выполняет обязанности новой роли, и внедряет правила и практики скрама в организации. В каждой компании произошло что-то уникальное. Зная о практиках и правилах скрама, скрам-мастера по-разному реагировали на ситуации: в одних случаях реакция была подходящей для организации, в других – нет. В каждом случае скрам-мастер интерпретировал свои обязанности и цели по-своему, поэтому и результаты значительно отличались.

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

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

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

Обязанности скрам-мастера можно резюмировать следующим образом:

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

■ научить владельца продукта максимизировать рентабельность инвестиций (ROI) и достигать своих целей с помощью скрама;

■ улучшать жизнь команды разработки: поощрять креативность и расширять полномочия участников по выбору способов реализации требований из бэклога продукта;

■ повышать производительность команды разработки любыми способами;

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

■ поддерживать информацию о прогрессе команды актуальной и доступной для всех.

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

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

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

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

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


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

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

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

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

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

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

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

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

Ситуация в Service1st

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

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

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

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

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

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

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

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

Следующий релиз был запланирован на 7 апреля, в марте должна была бы состояться демонстрация пользователям. Шел конец октября: сотрудники уже сосредоточились на предстоящих праздниках[12]12
  В США к Хеллоуину – кануну Дня Всех Святых, который проходит 31 октября, – готовятся по времени и усердию примерно так же, как к встрече Нового года. И постепенно начинают планировать День благодарения – четвертый четверг ноября.


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

Применение скрама

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

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

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

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

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

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

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

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

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

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

После составления списка я объяснил команде разработки концепцию трассирующей пули, представленную Эндрю Хантом и Дэвидом Томасом в книге «Программист-прагматик. Путь от подмастерья к мастеру»[13]13
  Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мастеру. – М.: Лори, 2009. – Прим. ред.


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

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

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

Извлеченные уроки

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

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

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