Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 41
Текст из файла (страница 41)
Расстановка приоритетов — только часть представляющей масштаб картины. Если бы мы были в состоянии выполнить всю работу, не нужно было бы задавать приоритеты. Если же мы не можем выполнить всю работу, необходимо определить, какую часть мы можем сделать и где. следовательно, иам провести базовый уровень для данного проекта. Второй в»аг заключается в определении приблизительного уровня трудозатрат для каждой из предлагаемых фущсций. Это достаточно сложно сделать, так как еще мало информации для оценки предстоящей работы; у нас нет подробных требований или результатов проектирования, на которых можно основывать этн оценки.
Лу ппее, что можно сделать- определить "примерный порядок величины*' уровня трудозатрат для каждой функции. Оценка трудозатрат на столь раннем этапе является сложной задачей. Команда пр»» граммистов, естественно, неохотно будет проводить оценки до достижения полного п»» нимания осуществимости проекта и требований к нему. Тем не менее, первое сокращение масштаба проекта должно состояться до того, как станет известен этот следующий уровень детализации. Предположим, что менеджер продукта является лидером нашего проекта и у него происходит следующий диалог с разработчикзми проекта».
200 Часть 4. Управление масштабом среднюю степень сложности. Вы согласныз Да, Она является средней. Хорошо. Переходим к следующей функции. Команда разработчиков: Менеджер продукта: Почему мы не рекомендуем использовать процесс определения подробных требова.
ний и информации проектирования для каждой функции, чтобы получить более обоснованные оценки? Разве это не является профессиональным подходом к данной проблеме? Если график позволяет на данпол1 атилле выделить время для более детальной оценки, без всяких сомнений стоит это сделать! Однако мы считаем, что очень важно уметь делать некоторые быстрые предваритель. ные заключения о масштабе предстоящих действий без проведения более детальных оце. нок.
Почему? Потому что в противном случае ресурсы тратятся на то, что впоследствии будет определено как "ненужные продукты", среди которых окажутся спецификации требсг наний для нереализуемых функций, информация по проектированию этих функций, сценарии проверки требований, которые будут позднее удалены в процессе сокращения масвпчба проекта, неправильное определение критического пути проекта и т.д. Мы не мо. жем позволить себе тратить ресурсы иа эти напрасные действия, в противном случае мы не сможем оптимизировать затраты.
Другими словами, в процессе управления масвггабом будет уменыпсно количество разрабатываемых для исходной версии функций, а так как ресурсы чрезвычайно ограничены. мы не люжем тратить дополнительные средства на функции, которые не будут реализованы в текущем базовом уровне. В табл. 20,! представлен список нюнил функций с добавлением информации о трудозатратах. Таблица 20.2, Список функций с добавленными оценками трудоемкости Функция Приоритет Трудоемкость Третий шаг управления масштабом — это оценка риска, связанного с каждой функцией.
В данном случае мы понимаем под риском вероятность того, что разработка функции окажет негативное воздействие на график и бюджет. Риск дает воэможность оценить, какими могут быть последствия включения конкретной функции в базовый уровень проекта. Функция с высоким риском может негативно повлиять иа проект, даже если все остальные функции будут завершены в установленное время.
Функция 1. Поддержка внешней реляционной базы данных Функция 4. Порт лля новой версии ОС Функция б. Импортирование внешних данных по стилям Функция 3. Возможность клонирования проекта Функция 2. Многопользоаателыкая безопасность Функция 5. Новый "мзстер" проекта Функция 7. Реализация средств предупреждения Функция В.
Интеграция с подсистемой управления версиями Добавление элемента риска Критический Критический Критический Важный Важный Важный Полезный Полезный Средняя Высокая Низкая Высокая Низкая Низкая Низкая Высокая Глава 20. Задание масштаба проекта 201 Команда разработчиков задает риск с помощью любой эвристики, используя ту же градацию "низкий. средний-высокий", что и при определении трудоемкости. В табл.
20.3 представлен список функций для нашего примера с указанием рисков. Таблица 20.3. Список функций с добавленными оценками риска Функция Приоритет Трудоемкость Риск Функция Е Поддержка внешней реляционной базы данных Критический Средняя Низкий Критический Критический Функция 4. Порт для новой версии ОС Высокая Низкая Средний Высокий Функция б. Импортирование внешних данных по стилям Средний Высокий Низкий Высокий Низкий В различных проектах стратегии уменьшения риска отличаются, и мы не будем здесь обсуждать эту тему.
Для управления масштабом нам достаточно просто знать о риске, связанном с каждой функцией, чтобы можно было принимать осмысленные решения на ранней стадии осуществления проекта. Например, если функция является к7эишической и имеет высакиб риск, то нужна эффективная стратегия уменьшения риска. Если функция с высоким риском характеризуется как вазсиал и находится в списке близко к черте базового уровня, ее можно удалить или разрабатывать в том случае, "если останется время", Если окончательное решение о включении этого элемента в данную реализацию еще не принято, никакого вреда от подобных действий не будет. Если же функция с высоким риском является всего лишь полезной, следует рассмотреть вариант ее полного удаления.
Сокращение масштаба Мы добились значительного прогресса. Теперь у нас есть набор упорядоченных по приоритету функций, для каждой из которых определены ее относительная трудоемкость и риск. Необходимо отмстить, что зачастую приоритет мало связан с трудоемко стью или риском. Действительно.
многие критические функции требуют невысоких трудозатрат, а некоторые полезные являются очень сложными. Это может помочь команде при определении очередности реализации функций. Например, критическая функция со средней трудоемкостью и низким риском может считаться кандидатом на немедленное финансирование.
Наша задача в том, чтобы применить имеющиеся ограниченные ресурсы с наибольшей выгодой для клиента. В табл. 20.4 предлагается несколько основанных па значениях указанных атрибутов рекомендаций относительно очередности разработки критических функций.
Функция 3. Возможность клонирования проекта Функция 2. Мпогопользоэателыкая безопасиасть Функция 5. Новый "мастер" проекта Функция 7. Реализация средств прелупрежления Функция 8. Интеграция с подсистемой управ- ления версиями Важный Важный Важный Полезный Полезный Высокая Низкая Низкая Низкая Высокая 202 Часть 4. Управление масштабом Таблица 20.4. Методы определения очередности разработки функций Атрибуты и их значения Чтоделать ПРиоримоп:критический Трудпемкппнл:высокая Риис вмсоюот Внимание! Нужно немедленно определять стратегию снижения риска; немедленно финансировать;основное внимание необхо- димоуделить достижимостн посредством архитектуры ПрисРи тепе критический Трудееиипгтл: и кокая Риск; низкий По-видимому, трудоемкий элемент; немедленно финансировать Приприпмт: критический Тр>дпемпвгт л: низкая Риск; низкий Финансировать как безрисковый фактор пли отложить нз потом Обоснованная Первая оненка Команда, которая имеет даже гр>бую (основанную на трудозатратах) оценку, может определить базовый уровень, суммируя оценки трудозатрат, пока сумма пе станет равна произве.
дению наличных ресурсов и выделенного времени. Однако часто команда не плюет в своем распоряжении даже этих данных, но вынуждена произвести первое сокращение обьема про. екта. В этом случае неизвестно, где провести базовый уровень, но если команда чувствует, что объем проекта превышает 100%, список функций, вероятно, придется сократить, Следующий шаг наиболее сложный. Если предположить, что объем работ, необходимый для разработки слшестяузощего набора функций, составляет более 200% от возмояоюго, то базовый уровень должен отсечь половину или болыяе.
Как же ос>тцествнть этот процесс? Первым делом надо выяснить, возможно ли за отведенное время завершить разработку хотя бы только критических элементов списка. Спросите менеджера проекта: "Если все остальное пе делать, можем ли мы быть >сверены в получении хотя бы кулгппгческил элементов к моменту сдачнл". В конечном итоге, если мы правильно составили схелг> определения приоритетов, то только одна треть (или около того) элементов списка будет признана и)>прической для данной версии. За исключением случая, когда одна из крити.
ческих ф>мкций имеет непропорционально большую тр>доемкость, ответ должен быть "да", даже если наши функции представляют объем работ, равный 200%. Если ответом является "да" (а нгна онмт показывает, чпю гграхтическн всегда так и есгяа), то даже после сокращения у нас останется основа для будущего плана.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
