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

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

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

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

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

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

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

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

Партнер и руководство F-Secure обсудили замедление прогресса в разработке и приостановили все процессы. Деньги были потрачены, но ничего полезного не было создано. Партнер, узнав, что не получит продукт в срок, остановил все приготовления к пресс-конференции, свернул маркетинговую активность и тем самым спас себя от потери репутации на рынке. Ценным опытом, полученным в результате этого проекта, было ограничение потерь.

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

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

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

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

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

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

Компания Kronos из Бостона – девелопер софта для планирования ресурсов организации и учета рабочего времени. Компания предприняла попытку использовать эмпирический метод, чтобы ускорить свои процессы разработки. В 2008 году правление компании было недовольно прогрессом в разработке нового релиза. Команде девелоперов дали это понять и попросили работать усердней. Те, пытаясь соответствовать требованиям руководства, стали создавать функционал быстрее, чем обычно, но с гораздо более низким качеством.

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

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

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

Роль менеджера при таком подходе – только устанавливать цели, содействовать и устранять препятствия. Он наделяет членов команды правом принимать решения.

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

Расположенная в Филадельфии компания Primavera, которой сейчас владеет Oracle, создает программное обеспечение для управления проектами, основанными на предиктивном процессе. Учредители понимали иронию: использовать эмпирический процесс разработки программного обеспечения для создания своих предиктивных (прогнозируемых) инструментов. Тем не менее, чтобы решить свои проблемы, они должны были к нему прибегнуть.

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

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

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

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