Проблема анти-паттерна
«Пожарные Учения» регулярно повторяющийся сценарий многих организаций, занимающихся разработкой ПО. Проект уже начат, но команда задерживает дизайн и разработку на несколько месяцев, пока на уровне менеджмента решаются управленческие проблемы. Один разработчик ПО так сказал о поставке программы, разработка которой ещё не закончена: «Подожди, пока руководство придёт в отчаяние, и они примут что угодно, что вы им дадите».
Руководство не даёт разработчикам идти вперёд, требуя подождать или раздавая неясные и противоречивые указания. Наверное, самые вредные изменения это изменения в развитии проекта, навязанные извне, которые ведут к переделыванию и тормозят прогресс.
После того, как к графику проекта добавилось ещё несколько месяцев, руководство начинает понимать, что разработка должна немедленно показать результат. Побуждающим к этому мотивом обычно служит угроза закрытия проекта.
На ноги поднимается весь «личный состав». Пожарные Учения служат причиной собрания разработчиков, во время которого руководство предъявляет завышенные (или нереальные) запросы к поставкам программного обеспечения. Типичный пример: проект, при выполнении которого на анализ требований и планирование ушло шесть месяцев, а разработку, внедрение и демонстрацию ПО предполагается завершить меньше чем за четыре недели.
Поскольку времени, отведённого на проект, катастрофически не хватает, то компромисс достигается за счёт качества ПО и тестирования. С другой стороны, критическая ситуация упрощает работу разработчикам ПО, так как руководство примет любой продукт (или документацию), не задавая вопросов, если идёт отставание от графика. Однако, руководство часто вынуждает добросовестных разработчиков, которые предоставляют продукт раньше критических сроков, переработать решения.
Решение, направленное на улучшение
Эффективное решение, которое может применить руководство проекта, называется «прикрытие». Руководители проекта отвечают за результаты независимо от нерешённых на уровне руководства вопросов. Рабочая среда, которая необходима для качественной разработки программного обеспечения, значительно отличается от обстановки Пожарных Учений.
В частности, разработка на основе архитектуры требует длительного времени и капиталовложений. Как уверяют авторитетные специалисты, разработка на основе архитектуры самый эффективный способ достичь успеха при создании программного обеспечения. В противоположность этому, обстановка Пожарных Учений способствует текучке кадров, а сегодня это серьёзная проблема для руководства проектов по разработке ПО.
В случае «прикрытия» руководство создаёт и поддерживает две альтернативные среды проекта: внешнюю и внутреннюю. Большая часть персонала, занятого в разработке ПО, работает во внутренней среде, где все нацелены на долгосрочность и поощряется непрерывный прогресс в разработке программного обеспечения.
Около 80% программного обеспечения в системах не зависит от области применения — это так называемая внутренняя модель. Внутренняя среда проекта может способствовать созданию внутренней модели, независимой от внешних технополитических факторов. Создание внутренних вариантов будет также наиболее эффективным использованием ресурсов разработки программного обеспечения в итеративно-инкрементальных проектах.
Второе название внешней среды «общественный имидж». Её цель поддержание отношений с внешними величинами: высшим начальством, потребителями и другими проектами (по отношению к которым существует конкуренция и возможность взаимного использования).
Персоналу, который занимается поддержанием внешней среды, может понадобиться периодически демонстрировать кризис проекта, чтобы получить ресурсы на разработку. В среде Пожарных Учений сценарии критического положения можно рассматривать как эквивалент настойчивости, когда проект борется за внимание руководства и ресурсы. Мало кто из руководства и разработчиков может поддерживать внешнюю среду.
Эта работа заключается в реагировании на изменения во внешней среде, так, чтобы прикрыть большую часть персонала, работающего над проектом. Вот некоторые примеры действий по работе с внешней средой: отчёты о ходе работы, документация о готовности, поставках необходимых материалов, набор персонала, презентации для потребителей и демонстрации для участников рынка. Прикрытие эффективно избавляет большую часть персонала от совершения этих действий.
Но иногда бывает так, что чрезвычайные ситуации реальны, и действительно необходимо пожертвовать временем, выделенным на разработку. Но как бы там ни было, очень важно ограничивать частоту Пожарных Учений, чтобы разработчики в случае необходимости могли справиться с возникшими проблемами.
Схожие решения
Анти-паттерн Пожарные Учения связан с некоторыми другими распространёнными анти-паттернами, такими как Аналитический Паралич, Проектирование Слайдов и Управление Грибами. При Аналитическом Параличе стремление к совершенству в аналитическом моделировании затягивает этап анализа, сокращая этап разработки, что и приводит к Пожарным Учениям.
При Проектировании Слайдов дело никак не дойдёт до разработки ПО вместо анализа на бумаге. Рабочая среда очень похожа на ту ситуацию, которая предшествует собраниям Пожарных Учений. При Управлении Грибами разработчики безо всяких на то оснований изолируются от реальных конечных потребителей (но не от взаимодействия с руководством высшего звена).
Разработчики не могут уточнить набор требований пользователей и узнать их мнение об интерфейсе.
Решение проблемы Управления Грибами благоприятствует конструктивному взаимодействию между конечными пользователями и разработчиками, в то время как решение проблемы Пожарных Учений благоприятно сказывается на взаимодействии разработчиков и руководства, когда изменения курса и неуверенность могут нарушить процесс разработки ПО.
| 
