М. Фаулер, К. Скотт - UML Основы, страница 9

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

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

В среде специалистов по образцам такая групповая работа над книгами считается особенно полезной. Уже появилось несколько групп по обсуждению образцов. Дополнительную информацию о таких группах можно получить в Интернете по адресу: ятгр://шшш.ЫДаЫе.пег/розге глв. Планирование фазы построения На стадии исследования следует обращать внимание на любые аспекты, по которым у вас отсутствуют знания или опыт. Планируйте приобрести нужный опыт к тому моменту, когда вам он станет необходим. Политические риски Я не могу предложить по этому поводу никаких серьезных советов, поскольку не слишком искушен в корпоративной политике. Могу лишь настоятельно порекомендовать вам найти компетентного в этой области эксперта.

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

Используемый мною подход к планированию основан на методах Экстремального программирования. Бек (Веса), 2000 ~21. Сущность формирования плана заключается в установлении последовательности итераций построения и в определении функциональности, которую следует реализовать на каждой итерации. Некоторые разработчики предпочитают работать с небольшими вариантами использования и на каждой итерации завершать работу с одним из них. Другие предпочитают работать с большими по масштабу вариантами использования и на отдельной итерации рассматривать только один из сценариев, а другие — на последующих итерациях.

Базовый процесс при этом является тем же самым. Итак, опишем этот процесс применительно к небольшим вариантам использования. В ходе планирования я предпочитаю рассматривать две группы лиц: клиенты н разработчики. Клиентами являются лица, которые предполагают использовать систему, не выходя за пределы внутрифирменной разработки. Для гото- 42 Глава 2. Основы процесса разработки вой системы представителями клиента являются менеджеры. Главная особенность здесь заключается в том, что клиентами являются лица, которые могут оказывать влияние на бизнес-процессы в том или ином варианте использования, который подлежит реализации. Разработчиками являются лица, которые участвуют в построении системы. Они должны адекватно оценивать затраты и объемы работ, необходимые для реализации отдельного варианта использования.

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

После этого разработчики упорядочивают варианты использования в соответствии с риском разработки. Например, «высокую степень риска» следует использовать для чего-либо, что представляется очень трудным для выполнения, может привести к неудаче проекта или до сих пор не является хорошо понятным. После того как это сделано, разработчики должны оценить продолжительность времени в человеко-неделях, которое потребуется для реализации каждого варианта использования. При выполнении такой оценки учитывайте время, необходимое для анализа, проектирования, кодирования„тестирования модулей, их интеграции и подготовки документации. При этом следует придерживаться принципа, что все разработчики полностью согласны с решениями друг друга без влияния деструктивных аспектов.

(Мы рассмотрим дополнительный фактор принятия спорных решений позже.) Подготовив такие оценки в тот или иной момент времени, можно сделать вывод о том, в состоянии ли вы выполнить намеченный план или нет. Проанализируйте варианты использования с высокой степенью риска. Коли большая часть времени работы над проектом тратится на эти варианты использования, то вам необходимо выполнить дополнительное исследование. Следующий шаг состоит в определении периода времени для вашей итерации. Вы можете установить фиксированную продолжительность итерации, чтобы иметь возможность получать результаты с заданной регулярностью. Для вариантов использования, которые доставляют много хлопот, следует увеличить продолжительность соответствующей итерации. Например, при использовании языка Яша11та1)с она мо- Планирование фазы построения 43 жет продолжаться от двух до трех недель, а языка С++ — от шести до восьми недель.

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

Этот коэффициент может быть получен путем сравнительных оценок выполнения реальных проектов. Теперь следует оценить скорость вашей работы над проектом. Другими словами, оценить объем работ, который вы можете выполнить в течение некоторой итерации. Его можно рассчитать, зная количество разработчиков в команде, умножив его на продолжительность итерации и разделив результат на поправочный коэффициент. Например, пусть имеется 8 разработчиков, длительность итерации составляет 3 недели, а поправочный коэффициент равен 2. В этом случае трудоемкость отдельной итерации в идеале составит 12 человеко-недель (8 х 3 х 1/2). Просуммируйте время, необходимое для реализации всех вариантов использования, разделите на трудоемкость одной итерации и добавьте на всякий случай единицу.

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

Реально может потребоваться меньше усилий, чем трудоемкость итерации, но никогда не следует планировать больше, чем позволяют ваши способности. Для оценки внедрения выделите 10 — Зб'/о от времени построения на тонкую настройку и конфигурирование конечного продукта. (Если у вас нет опыта выполнения этих операций в конкретной обстановке, то выделите еще больше времени.) Затем добавьте коэффициент учета непредвиденных обстоятельств: от 10 до 20'/о времени построения в зависимости от степени оцениваемого вами риска. Прибавьте этот коэффициент ко времени окончания фазы внедрения.

Для своей команды следует планировать поставку конечного продукта без учета этих непредвиденных обстоятельств, однако приступать к поставке конечного продукта следует после окончания непредвиденного времени. 44 Глава 2. Основы процесса разработки После применения всех перечисленных рекомендаций у вас будет некоторый план проекта, в котором для каждой итерации указаны варианты использования, подлежащие реализации в ходе ее выполнения. Этот план символизирует согласие между разработчиками и пользователями.

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