Что именно оценивается.

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

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

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

Размер проекта.

Размер проекта — еще один фактор, который необходимо учитывать при выборе методики.

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

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

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

Большие проекты. К большим проектам относятся проекты, выполняемые группами около 25 участников, занимающие от 6 до 12 месяцев и более.

Оптимальный выбор методики оценки для большого проекта существенно изменяется в зависимости от состояния проекта. На ранних стадиях лучший результат обычно дают «нисходящие» методы, основанные на алгоритмах и статистике. Они состоятельны на той стадии проекта, когда конкретный состав участников еще не известен — когда планы основываются на группах, состоящих, допустим, из «11 ведущих инженеров, 25 рядовых разработчиков и 8 тестеров», нежели на конкретных личностях.

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

Средние проекты. К этой категории относятся проекты, выполняемые 5-25 участниками, занимающие от 3 до 12 месяцев. К преимуществам средних проектов можно отнести возможность применения практически всех методов оценки, применимых в крупных проектах, а также ряда методик малых проектов.

Стиль разработки.

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

Далее представлены некоторые подходы к разработке, выделенные по указанным критериям.

Эволюционное макетирование используется в тех случаях, когда требования неизвестны, а одна из главных причин для применения этой методики — содействие в определении требований (McConnell 1996). В контексте оценки эволюционное макетирование относится к итеративному стилю разработки.

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

Эволюционная выдача. В проектах с эволюционной выдачей доля изначально определяемых требований изменяется от «почти отсутствует» до «большинства» (Gilb 1988, McConnell 1996). В зависимости от того, к какому концу шкалы относится конкретный проект, проекты с эволюционной выдачей могут быть как последовательными, так и итеративными. Как правило, проекты с эволюционной выдачей оставляют достаточно большое количество требований неопределенными на момент начала разработки, чтобы разработку можно было отнести к итеративной.

Поэтапная выдача. В проектах с поэтапной выдачей основные требования определяются до начала основной работы над проектом (McConnell 1996). Поэтапная выдача использует итеративный подход к проектированию, конструированию и тестированию и поэтому в некотором смысле является итеративной. Тем не менее в контексте оценки ее следует отнести к последовательному стилю разработки.

Унифицированный процесс Rational. Стадии процесса RUP (Rational Unified Process) называются «итерациями». Тем не менее в типичном проекте RUP около 80 % требований должны определяться до начала разработки (Jacobson, Booch, and Rumbaugh 1999). В контексте оценки RUP относится к последовательному стилю разработки.

Scrum — стиль разработки, при котором рабочая группа проекта выбирает набор возможностей, которые она может реализовать в течение 30-дневного «броска» (Schwaber and Beedle 2002). После того как «бросок» начался, клиенту не разрешается изменять требования. Если рассматривать отдельные броски, в контексте оценки Scrum относится к последовательному стилю. Но поскольку функциональность не распределяется более чем по одному броску, с учетом множественных итераций Scrum относится к итеративному стилю.

Влияние стиля разработки на выбор методов оценки.

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

Стадия разработки.

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

В книге стадии разработки определяются следующим образом.

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

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

Поздняя стадия. Термином «поздняя стадия» обычно обозначается время от середины разработки до выпуска.

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

Возможная точность.

Точность методики отчасти зависит как от самой оценки, так и от того, насколько правильно выбрана методика для конкретной проблемы, и от специфики проекта.

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

6.2. Таблицы применимости методов.

Большинство остальных глав книги начинается с таблиц, описывающих область применения метода, представленного в данной главе. Пример:.

Область применения методов этой главы — ПРИМЕР

Приведенные в таблице данные основаны на сведениях, приведенных в предыдущем разделе. Смысл содержимого таких таблиц объясняется в табл. 6.1.

Таблица 6.1. Содержимое таблиц «Область применения методов этой главы»

СОВЕТ № 29 -.

При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, стадию разработки, стиль разработки и требуемую точность.