Книга: Экстремальное программирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги