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

Рассмотрим, например, выпуск новой версии программного продукта версии, которая предоставляет некоторые новые возможности и в которой устранено множество раздражающих дефектов. Можно работать над этой версией бесконечно. Чем дольше, тем больше удастся добавить новых возможностей и исправить недостатков. Но можно взглянуть на это иначе: чем дольше вы станете задерживать отгрузку новой версии, тем дольше ваши клиенты будут вынуждены уживаться с проблемами той версии, которой сейчас пользуются. Таким образом, вопрос ставится так: что лучше избавить пользователей от 50 дефектов сегодня или от 55 дефектов, но через две недели? Если тысячи пользователей ежедневно страдают от дефекта №29 в вашем списке, то, я думаю, есть достаточно оснований утверждать, что отгружать продукт нужно было еще вчера.

Как только вы начинаете понимать, что отгрузка продукта - это не просто часть вашей работы, а весьма критичный момент в проекте - «пересечение финишной ленты», как сказал бы Роберт Бонд,

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

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

Если Вы его построите, они придут

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

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

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

Вначале была песочница.

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

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

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

Почему же сборка продукта так трудна?.

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

Работу по подготовке продукта для «посторонних» иногда называют «шлифовкой». Если вы сразу же не устраните «заусенцы» (по крайней мере, самые «острые» из них), ваши первые пользователи могут о них сильно «порезаться».

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

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

Препятствие первое: организационная политика.

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

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

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

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

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

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

Вот несколько более конкретных советов:.

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

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

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

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

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

Препятствие второе: процесс.

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

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

Основной конфликт возникает между сторонниками строгого, жесткого процесса (иногда характеризуемого как «множество правил и никакой милости»)

и теми, кто предпочитает относительно свободные порядки.

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

Это не означает, что надо изобретать процесс заново. Я неспроста употребил слово «настроен» в предыдущем абзаце: я твердо убежден, что лучший способ решения данной проблемы - это отталкиваться от известного базового процесса, работоспособность которого уже была продемонстрирована в прошлом. Например, разработанный в Rational Software процесс «унифицированного управления изменениями» (Unified Change Management, или UCM) имеет богатую историю успешного применения на практике. Мы знаем, что он годится для широкого спектра программных продуктов, предметных областей и организаций. Зачем начинать все сначала? Уверены ли вы, что сможете сделать лучше?.

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

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

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

Наконец, не затягивайте установление процесса. Лучшее - враг хорошего.

Процедуру надо разрабатывать итеративно - точно так же, как программное обеспечение. Приступайте к итерации номер 1 как можно скорее. Учитесь. Изменяйте. Улучшайте. Повторяйте, пока не закончите.

Препятствие третье: инструментарий.

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

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

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

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

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

Как насчет итеративной разработки?.

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

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

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

Резюме.

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

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

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

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

На этом завершается часть II, посвященная основам. В части III я взгляну на разработку ПО с точки зрения управления проектами.