Множество людей хорошо знает, что такое затраты, качество и время, и как с их помощью контролируется процесс производства программного обеспечения, однако при этом многие из них не признают четвертую переменную – объем работ. Объем работ, связанный с производством программного продукта, – это наиболее важная переменная, с которой приходится иметь дело в производстве программного продукта. В большинстве случаев как программисты, так и бизнесмены обладают весьма туманными представлениями о том, что является наиболее ценным в разрабатываемом программном продукте. Однако если вы активно управляете показателем объема работ, вы можете предоставить менеджерам и заказчикам контроль над затратами, качеством и временем.
Отличительной чертой этого показателя является то, что объем работ – сильно изменяющаяся переменная. В течение десятилетий программисты привыкли жаловаться: Заказчики не могут сказать нам, чего они хотят. Когда мы даем им то, о чем они нас просили, они говорят, что им это не нравится. И это абсолютная горькая правда всей индустрии производства программного обеспечения. В самом начале работы над проектом требования заказчика никогда не бывают четкими и ясными. Заказчики никогда не могут сказать вам, что именно они хотят.
После разработки некоторого фрагмента программного продукта требования к нему изменяются. Как только заказчики видят первую версию продукта, они понимают, что они хотят увидеть во второй версии... или что они на самом деле хотели увидеть в первой версии. И это достаточно важный процесс познания, так как во многих случаях заказчики просто не могут сформулировать требования к продукту, которого в реальности пока что не существует. Зачастую не возможно четко и полностью сформулировать техническое задание на основе только лишь беспочвенных абстрактных размышлений и предположений. Многие важные умозаключения и выводы делаются заказчиками на основе опыта. Однако заказчики не имеют возможности получить свой опыт в одиночку. Они нуждаются в людах, которые умеют программировать. И эти люди должны быть не просто советчиками, они должны быть компаньонами.
Что, если посмотреть на нечеткость требований не как на проблему, а как на удобную возможность? В этом случае мы можем обнаружить, что показатель объема работ является наиболее удобной в управлении переменной из тех четырех переменных, о которых я говорил ранее. Так как этот показатель наименее четко очерчен, мы можем формировать его в соответствии с нашими собственными предпочтениями и предпочтениями заказчика – немного в эту сторону, немного в ту сторону. Если время поджимает и надо выпускать очередную версию продукта, у нас всегда будет что‑то, что мы можем отложить до следующей версии. Однако если мы будем стараться не втискивать в рамки одной версии слишком много работы, то сохраним возможность выпустить продукт требуемого качества в указанные сроки.
Если мы создадим дисциплину разработки программного обеспечения на основе описанной модели, то получим возможность контролировать дату выпуска, качество и стоимость любого фрагмента программного продукта. Вначале мы можем рассматривать объем работ как функцию от первых трех переменных, однако в дальнейшем мы получаем возможность постоянно корректировать объем работ с учетом складывающихся условий.
Разрабатываемая нами дисциплина должна подразумевать низкую стоимость внесения изменений в проект, так как предполагается, что направление развития проекта будет меняться достаточно часто. Не стоит тратить деньги на разработку программного продукта, который в дальнейшем не будет использоваться. Не стоит тратить деньги на асфальтирование дороги, по которой вы все равно не будете ездить, так как вам придется свернуть на ближайшем повороте. Чтобы в подобной ситуации добиться желаемых результатов, вы должны использовать методику, в рамках которой стоимость внесения в проект изменений будет приемлемой в течение всего времени жизни системы.
Если вы будете отказываться от реализации важной функциональности в конце каждого очередного периода работы над очередной версией продукта, заказчик в скором времени разочаруется в вашей работе. Чтобы избежать этого, ХР использует две стратегии.
1. В процессе работы, приступая к реализации очередной части проекта, вы постоянно делаете предположение относительно того, сколько времени и усилий вам потребуется для того, чтобы реализовать эту часть проекта. В дальнейшем вы сравниваете реально затраченное время с вашими предварительными оценками. Таким образом вы тренируете свою способность правильно оценивать свои силы и снижаете вероятность отказа от реализации ранее запланированной функциональности.
2. В первую очередь вы реализуете те требования заказчика, которые являются наиболее важными для него. Таким образом, если на завершающем этапе работы над очередной версией системы приходится отказываться от реализации какой‑либо функциональности, эта функциональность оказывается менее важной, чем та функциональность, которая уже присутствует в системе.