Скрам - стр. 12

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

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

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

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

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