Каждому проекту своя методология
Шрифт:
Потеря жизни означает, что в результате ошибки в программе могут погибнуть люди. К этой категории относятся предприятия, работающие на атомной энергии, проекты, связанные с космосом, системы управления полетами самолетов и т.д. Согласно этому принципу, дополнительные затраты на более тщательную защиту от ошибок вполне могут себя оправдать - в зависимости от того, в какой из четырех вышеперечисленных категорий находится проект.
Поломка на атомной станции гораздо серьезнее, чем, например, поломка в моей программке, которая отслеживает течение матча по боулингу. Следовательно, при создании программных продуктов для атомной станции можно позволить себе использовать более
Допустим, в обоих проектах используются варианты использования (use cases). Ребята из Лиги по боулингу вполне могут написать их в виде нескольких предложений на салфетке или на доске и считать это достаточным документом. Команда, которая строит атомную станцию, наверняка будет настаивать на том, чтобы все варианты использования были написаны с помощью специального инструментария, чтобы были заполнены все необходимые поля и т.д. После они обязательно потребуют пересмотра, внесения правок и многократного подписания документов в течение жизненного цикла проекта. При этом стоимость вторично написанных вариантов использования возрастает. Однако преимущество этого метода состоит в том, что чем большее количество "писателей" и "читателей" будут взаимодействовать между собой, тем меньше вероятность возникновения ошибок и недопонимания. Возрастающая стоимость разработок вполне оправдывается большей безопасностью и надежностью конечного продукта.
Принцип 2 указывает на то, что есть ситуации, когда дополнительные расходы на разработку оправдывают себя. И это хорошо, поскольку следующий Принцип, за номером 3, гласит, что более "тяжелая" методология ложится тяжким бременем на бюджет проекта.
Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.
Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.
Этот принцип справедлив для любого проекта. Как вы уже заметили, мы не обсуждаем, выгодны или не выгодны компании дополнительные затраты - здесь затрагивается исключительно вопрос стоимости, не более. Проблема определения сообразности дополнительных расходов относится к Принципу 2.
Итак, мы подошли к точке, когда уже можно обсуждать отношения между размером методологии, проекта и задачи. Делать это довольно непросто, потому что существует тенденция считать, что чем больше задача, тем больше нужно людей для ее выполнения.
Размеры проекта и методологии связаны между собой положительной обратной связью. Если над проектом работает сравнительно немного людей, то им нужна сравнительно небольшая методология. Чем меньше "весит" методология, тем продуктивнее работает команда. А чем продуктивнее работают люди, тем больше задач они могут решать - иначе говоря, маленькая команда разработчиков, использующая "легкую" методологию, вполне способна решать крупномасштабные задачи.
С другой стороны, когда в проекте участвует большее количество людей, их работу сложнее координировать, т.е. нужна более "тяжелая" методология. Такая методология будет снижать их продуктивность, поэтому для выполнения задачи понадобится большее
Именно поэтому (см. Рисунок 3) для решения конкретной задачи вам понадобится меньше людей, если вы будете использовать легкую методологию, и больше - если тяжелую. Впрочем, существует ограничение по размеру задачи, которую может решить данное число людей. У большой команды, использующей тяжелую методологию, этот "порог" выше, чем у маленькой команды, которая использует легкую методологию. Таким образом, если ваша задача выходит за рамки такого ограничения, то вам придется, с одной стороны, увеличивать количество разработчиков и, с другой, использовать более тяжелую методологию.
Рисунок 3 . Объем задачи и методологии непосредственным образом влияет на количество персонала в компании.
Главная трудность состоит в том, что практически невозможно точно определить объемы задачи в самом начале проекта, а следовательно, и минимальное число людей, которые могут эту задачу решить. К тому же, количество разработчиков напрямую зависит от того, какие конкретно люди будут работать над проектом.
И наконец, если размеры проекта возрастают, может оказаться, что оптимальным решением будет применить другую методологию.
Завершившийся не так давно проект С3 (Chrysler Comprehensive Compensation [C3a, C3b]), может служить убедительным примером всего, о чем я сейчас говорил. После того, как 26 человек не смогли выполнить задачу по созданию системы, которая считалась "большим проектом", за дело взялась малая часть этой команды - всего восемь человек. Используя новую, максимально легкую, но при этом строгую методологию [XP], они начали проект с нуля и уже через год смогли завершить то, что не смогла сделать большая команда, применявшая тяжелую методологию. Можно с уверенностью сказать, что частично такой успех методологии ХР был обеспечен последним, четвертым Принципом.
Принцип 4. Наиболее эффективная форма коммуникации (для передачи идей) - непосредственное взаимодействие, лицом к лицу, как при рисовании у доски .
Принцип 4 гласит, что разработчикам, которые сидят друг возле друга и могут свободно общаться, легче создавать программный продукт, то есть, затраты на разработку этого программного продукта будут меньше. Это также означает, что если проект растет таким образом, что обеспечить непосредственную коммуникацию между разработчиками уже не удается, ее эффективность будет падать, а значит, возрастут связанные с ней затраты.
На рисунке 4 изображена кривая, которая показывает, как падает эффективность коммуникации при переходе от непосредственного общения у доски к разговору по телефону, интерактивной переписке (чату и т.п.), видеозаписям, и, наконец, к документации на бумаге. Чем ниже находится кривая, тем меньше у разработчиков возможности общаться между собой, исчезает мультимодальность коммуникации, возможность передавать информацию с помощью интонации, задавать вопросы по мере их возникновения.