Глава 4. Четыре переменные

Глава 4.

Четыре переменные

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

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

• затраты (cost);

• время (time);

• качество (quality);

• объем работ (scope).

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

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

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

Взаимосвязь между переменными

Затраты (cost) – чем больше денег, тем легче работать, однако слишком большое количество денег в самые кратчайшие сроки создаст больше проблем, чем требуется решить. С другой стороны, если вы выделяете на проект слишком мало денег, вы не сможете решить поставленные перед вами заказчиком проблемы.

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

Качество (quality) – эта переменная контролируется хуже всего. Если вам необходимо достигнуть каких-либо краткосрочных целей (для достижения которых требуется несколько дней или недель), вы можете намеренно пожертвовать качеством, однако связанные с этим затраты – человеческие, деловые и технические – могут оказаться чрезмерными.

Объем работ (scope) – сократив объем работ, вы можете повысить качество (при условии, конечно, что поставленная заказчиком задача решена). Сокращение объема работ позволяет также сократить время проекта и связанные с проектом затраты.

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

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

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

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

Он настаивал: Вы не понимаете. Мы обязаны задействовать в проекте 40 программистов.

Я ответил: Вы не сможете сделать этого.

Однако он не унимался: Но мы обязаны.

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

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

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

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

Затратив дополнительные деньги, вы также снижаете трение – вы получаете более быстрые компьютеры, большее количество технических специалистов, более просторные и удобные офисы.

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

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

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

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

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

Фокус на объеме работ

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.