Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 [ 9 ] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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

Политические риски

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

Когда исследование заканчивается?

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

Разработчики могут с уверенностью оценить, что следует делать в ближайшие дни и сколько времени при этом потребуется на реализацию каждого варианта использования.

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

Планирование фазы построения

Существует множество способов планирования итеративного проекта. Важно понимать, что план разрабатывается с целью обеспечить осведомленность всей команды о ходе выполнения проекта. Используемый мною подход к планированию основан на методах Экстремального программирования. Бек (Веек), 2000 [2].

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

В ходе планирования я предпочитаю рассматривать две группы лиц: клиенты и разработчики.

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

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

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

Первый шаг состоит в классификации вариантов использования. Это можно сделать двумя способами.

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

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

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

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

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

жет продолжаться от двух до трех недель, а языка С++ - от шести до восьми недель.

Теперь мы можем рассмотреть трудоемкость каждой итерации.

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

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

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

Следующий шаг заключается в распределении вариантов использования по итерациям.

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

Для оценки внедрения выделите 10-35% от времени построения на тонкую настройку и конфигурирование конечного продукта. (Если у вас нет опыта выполнения этих операций в конкретной обстановке, то выделите еще больше времени.)

Затем добавьте коэффициент учета непредвиденных обстоятельств: от 10 до 20% времени построения в зависимости от степени оцениваемого вами риска. Прибавьте этот коэффициент ко времени окончания фазы внедрения. Для своей команды следует планировать поставку конечного продукта без учета этих непредвиденных обстоятельств, однако приступать к поставке конечного продукта следует после окончания непредвиденного времени.

1 2 3 4 5 6 7 8 [ 9 ] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.