Путь камикадзе
«Достаточно хорошее» программное обеспечение
Определение приоритетов требований, обсуждавшееся выше, может быть одним из способов, помогающих безнадежному проекту двигаться в «разумном» направлении. Для достижения успеха вовсе не обязательно реализовывать все требования; будет «достаточно хорошо», если мы сможем реализовать требования, которые «необходимо выполнить», и приемлемое количество требований, которые «следует выполнить».
Существует, однако, еще один аспект в разработке ПО, порождающий трудности в безнадежных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количества дефектов (ошибок), но может быть также выражено в терминах переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах достаточно трудно удовлетворить всем этим требованиям, а в безнадежных проектах сделать это просто невозможно. Вместо этого проектная команда должна придти к решению - и по возможности согласовать его с акционерами и заинтересованными лицами - относительно того, какое качество является достаточно хорошим.
Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресурсы проекта - особенно время. Если вы хотите разработать сертифицированную, не содержащую ошибок программу и математически доказать ее корректность, на это потребуется время. Это может также потребовать более высокого уровня таланта и способностей, чем те, которыми располагает проектная команда. Кроме того, одному или более участникам команды придется расходовать дополнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, выполнение таких требований, как надежность, переносимость и сопровождаемость, невозможно без компромиссов, и это необходимо учитывать в процессе определения приоритетов требований.
Командам безнадежных проектов приходится сталкиваться с такой неприятной реальностью лицом к лицу, поскольку альтернатива - «совершенное» ПО, которое не будет готово даже тогда, когда пройдут все мыслимые сроки.
Лучше всего, когда команда с самого начала проекта настроена прагматично на создание достаточно хорошего ПО, однако, мой опыт, к сожалению, говорит о том, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, когда упираются в тупик - например, когда оказываются в кризисном положении за месяц или два до окончания проекта.
Вплоть до этого момента времени они выражают свое недовольство: «Как вам понравится, если мы будем использовать ваш «достаточно хороший» подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадежный проект для создания такого рода высоконадежных приложений, тогда я просто перестану летать на самолетах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадежными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьезны.
В любом случае, совершенная
надежность, сопровождаемость, переносимость и т.д. не являются необходимыми, практичными или даже желательными в большинстве безнадежных проектов. В самом деле, достичь такого совершенства невозможно даже в «нормальных» проектах, хотя в этом случае мы можем позволить себе установить планку своих стандартов гораздо выше, поскольку не связаны такими жесткими ограничениями на время, бюджет и людские ресурсы. Что же касается безнадежных проектов, то пользователям в действительности
нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро - вот в чем заключается их определение «достаточно хорошего» ПО.
Почему же нам не удается создать «достаточно хорошее» ПО? Это обычно объясняется совокупностью следующих причин:
· Мы стремимся определять качество только
в терминах дефектов, не задумываясь о других его аспектах - которые, с точки зрения пользователя, включают, например, готовность к определенной дате.
· Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда
предпочитает такое качество - хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.
· Мы стремимся определить требования к качеству (дефектам) один раз, в самом начале проекта, и зафиксировать их, хотя обстоятельства могут измениться в течение проекта не один раз.
· Мы так долго твердили, что процессы
являются критически важными, что при этом зачастую забываем об их «нейтральности» - дурак, вооруженный процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям методологии структурного анализа или рекомендаций SEI-CMM.
· Мы рассматриваем обеспечение качества как процесс, укладывающийся в жесткую схему, заданную в начале проекта раз и навсегда (или, что еще хуже, для всех проектов во всей компании).
· Мы недооцениваем нелинейный характер зависимостей между такими ключевыми параметрами проекта, как численность персонала, плановые сроки, бюджет и количество дефектов - все эти аспекты в безнадежных проектах являются ключевыми.
· Мы игнорируем динамику процессов: запаздывания, циклы обратной связи и т.д. Например, большое количество сверхурочной работы в течение данной недели может выразиться в повышении продуктивности и прогрессе в работе над проектом в целом; но, с другой стороны, оно может повлечь за собой большее количество ошибок на следующей неделе (о которых конечные пользователи и высшее руководство могут ничего и не узнать), которые снизят продуктивность работы (в терминах конечных результатов) и, может быть, даже отбросят проект назад.
· Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для работы и др.
Каким же образом мы сможем создать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:
· Утилитарная стратегия - искусство количественного анализа и максимизации чистого выигрыша в неопределенных ситуациях - обобщает идеи системного анализа, управления рисками, экономики, теории принятия решений, теории игр, теории управления и нечеткой логики.
· Эволюционная стратегия - рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.
· Героические команды - не Могучие Гениальные Программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.
· Динамическая инфраструктура - противоположность бюрократии и засилью политики. Высшее руководство уделяет необходимое внимание проектам, уделяет внимание положению на рынке, предупреждает и разрешает конфликты между проектами, и становится на сторону проекта в случае конфликта между ним и бюрократами.
· Динамические процессы - процессы, поддерживающие работу в эволюционирующей среде. Динамический процесс, в свою очередь, является часть идентифицируемого мета-процесса и всегда может подвергаться изменениям.
