Это означает, что менеджер безнадёжного проекта должен безоговорочно настаивать на процессах, которые он считает принципиально важными — например: «Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменениями, будет немедленно уволен!» Или проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит сократить затраты. Такое может скорее произойти в том случае, если участники команды ранее уже работали вместе и приобрели общий опыт использования различных процессов создания ПО; и наоборот, это маловероятно, если только один из участников команды встанет и скажет: «Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта», в то время как другие и понятия не имеют, о чем это он говорит. Ещё одно утверждение, следующее из этого правила: попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.
Это означает, что такие формальные подходы, как SEI-CMM, ISO-9000 или внедрение новых методологий анализа/проектирования должны иметь место где-нибудь за пределами безнадёжного проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть безнадёжным проектом), сопровождаясь организацией необходимого обучения.
Если все это уже сделано, и если все другие разработки ПО в организации уже выполняются на третьем уровне SEI-CMM, то интересно выяснить, следует ли также использовать такие процессы в безнадёжном проекте. Как однажды заметил Watts Humprey на конференции в докладе по поводу SEI-CMM: «Если процесс нельзя использовать в критических условиях, его вообще не следует использовать».
Я не уверен, что многие согласятся с этим утверждением, особенно если безнадёжный проект рассматривать как единственное в жизни исключение из правил. Если это в самом деле так, то, возможно, имеет смысл отказаться от формальных процессов и предоставить проектной команде возможность использовать любые методы, которые она сочтёт приемлемыми. Однако не забывайте при этом моё утверждение, высказанное в главе 1: безнадёжные проекты становятся нормой, а не исключением. Если это так, то официально принятые в организации процессы следует, при необходимости, усовершенствовать, чтобы сделать их пригодными для использования в безнадёжном проекте. Тогда и только тогда утверждение Humprey будет иметь смысл.
Между прочим, если вы в самом деле столкнулись с потребностью усовершенствовать сложившуюся практику работы команды безнадёжного проекта, я рекомендую обратиться к методологии PSP (Personal Software Process), автором которой является Watts Humprey. Её основные положения изложены в моей книге «Rise and Resurrection of the American Programmer. Можно также прочесть книгу [2], хотя я честно предупреждаю: в ней 789 страниц.
5.4 «Достаточно хорошее» программное обеспечение
Определение приоритетов требований, обсуждавшееся выше, может быть одним из способов, помогающих безнадёжному проекту двигаться в «разумном» направлении. Для достижения успеха вовсе не обязательно реализовывать все требования; будет «достаточно хорошо», если мы сможем реализовать требования, которые «необходимо выполнить», и приемлемое количество требований, которые «следует выполнить».
Существует, однако, ещё один аспект в разработке ПО, порождающий трудности в безнадёжных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количества дефектов (ошибок), но может быть также выражено в терминах переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах достаточно трудно удовлетворить всем этим требованиям, а в безнадёжных проектах сделать это просто невозможно. Вместо этого проектная команда должна придти к решению — и по возможности согласовать его с акционерами и заинтересованными лицами — относительно того, какое качество является достаточно хорошим .
Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресурсы проекта — особенно время. Если вы хотите разработать сертифицированную, не содержащую ошибок программу и математически доказать её корректность, на это потребуется время. Это может также потребовать более высокого уровня таланта и способностей, чем те, которыми располагает проектная команда. Кроме того, одному или более участникам команды придётся расходовать дополнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, выполнение таких требований, как надёжность, переносимость и сопровождаемость, невозможно без компромиссов, и это необходимо учитывать в процессе определения приоритетов требований.
Командам безнадёжных проектов приходится сталкиваться с такой неприятной реальностью лицом к лицу, поскольку альтернатива — «совершённое» ПО, которое не будет готово даже тогда, когда пройдут все мыслимые сроки. Лучше всего, когда команда с самого начала проекта настроена прагматично на создание достаточно хорошего ПО, однако, мой опыт, к сожалению, говорит о том, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, когда упираются в тупик — например, когда оказываются в кризисном положении за месяц или два до окончания проекта.
Вплоть до этого момента времени они выражают своё недовольство: «Как вам понравится, если мы будем использовать ваш „достаточно хороший“ подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадёжный проект для создания такого рода высоконадёжных приложений, тогда я просто перестану летать на самолётах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадёжными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьёзны.
В любом случае, совершённая надёжность, сопровождаемость, переносимость и т.д. не являются необходимыми, практичными или даже желательными в большинстве безнадёжных проектов. В самом деле, достичь такого совершенства невозможно даже в «нормальных» проектах, хотя в этом случае мы можем позволить себе установить планку своих стандартов гораздо выше, поскольку не связаны такими жёсткими ограничениями на время, бюджет и людские ресурсы.
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 58 59