|
Название анти-паттерна: Плохое управление проектом
Также известен как: Шалтай-Болтай
Уровень, на котором чаще всего встречается: Предприятие
Название решения, направленного на улучшение: Система предупреждения рисков
Тип решения, направленного на улучшение: Роль и процесс
Основные причины: Ответственность (первопричина)
Неуравновешенные силы: Управление рисками (всеобъемлющая сила)
Пример из жизни:
"Что пошло не так? Всё было отлично, и вдруг... БАБАХ!"
Вводная информация
Этот анти-паттерн касается контроля над проектом по разработке ПО. Этот анти-паттерн можно наблюдать после завершения работ по планированию, во время непосредственного анализа, дизайна, конструирования и тестирования системы ПО. Плохое управление проектом влечёт за собой ошибки, которые совершаются изо дня в день, пока длится проект, при том, что не были сделаны ошибки при планировании (к примеру, Убийственное планирование).
Общая форма
Руководить проектом так же сложно, как и создавать план проекта, разрабатывать ПО, строить небоскрёбы. Для этого требуется организовать те же этапы и процессы, в том числе и разделять полномочия. Очень часто на основные виды деятельности не обращают внимания или уделяют минимальное внимание.
Сюда входит техническое планирование (архитектура) и действия по контролю качества (проверка и тестирование). В частности, вот основные ошибки: неправильное определение архитектуры, недостаточный анализ кода (проверка ПО) и недостаточное тестовое покрытие.
Во время проведения тестирования необходимы несколько этапов, которым часто уделяется минимальное внимание: модульное, интегральное и системное тестирование. Простое интегральное тестирование включает в себя основную проверку совместимости компонентов, прошедших модульное тестирование. Полное интеграционное тестирование необходимо для проверки всех известных состояний ошибки и удачных решений.
Архитектура определяет детальный технический план проекта, включая критерии проверки и тестирования. Когда архитектура определяется неправильно, получается недостаточная основа для проверки дизайна во время этапов проверки и тестирования. Когда производится тестирование, модули ПО могут быть объединены в систему согласно архитектуре, но они не могут быть объединены в систему согласно запросам приложения.
Симптомы и последствия
- Дизайн сложно реализовать из-за недостатков стратегии по архитектуре.
- Анализ кода и проверки происходят в редких случаях и приносят мало пользы.
- Для разработки теста требуются дополнительные усилия и действия наугад, потому что основные принципы работы системы не определены должным образом.
- На этапах интегрального и системного тестирования система постоянно «буксует» из-за большого количества дефектов, которые должны были быть устранены на более ранних этапах архитектуры, дизайна, проверки и модульного тестирования.
- К концу этапов разработки и сдачи-приёмки возрастает количество отчётов о неисправностях.
Типичные причины
- Некорректная архитектура не определяет технические критерии для проверки, тестирования, интеграции и совместимости.
- Анализ кодов и проверки ПО не определяют дефекты дизайна, которые затем будут рассматриваться на более дорогостоящих этапах, таких как приёмочное тестирование.
- Непродуманный тестовый комплекс проверяет основные требования к интеграции, но не рассматривает требования к совместимости этого приложения.
- Все указанные факторы служат признаком неэффективной системы управления рисками, которая может быть следствием профессиональных действий разработчика архитектуры, дизайнера и руководства.
Существующие исключения
Не существует исключений для анти-паттерна «Плохое управление проектом».
Решение, направленное на улучшение
Отлаженная система управления рисками эффективное средство для того, чтобы справиться с прогнозируемыми симптомами и последствиями этого анти-паттерна. Риски можно разбить на несколько категорий: административные, общие риски проекта и качественные риски. Необходимо разобраться, что входит в эти категории, чтобы лучше справиться с этими рисками.
Административные риски
Эти риски возникают из-за руководства и им же решаются:
- Процессы. Комплексное определение разработки продукта.
- Роли. Чёткая ответственность за внедрение процессов.
Общие риски проекта
Эти риски возникают благодаря следующим факторам:
- Перерасход средств.
- Досрочное прекращение проекта.
- Разработка несоответствующего продукта.
- Техническая неисправность.
Качественные риски
- Управление программой и проектом. Эффективность планирования и контроля процесса.
- Идентификация продукта. Точность определения задачи.
- Определение архитектуры. Детализация стратегии дизайна и кодирования.
- Проектное решение. Способность предоставлять постоянный и оптимизированный код, который полностью поддерживает решение.
- Реализация решения (кодирование). Способность создавать точную реализацию кода дизайна, который действует ожидаемым образом.
- Проверка правильности решения (тестирование). Доказательство того, что реализованное решение полностью соответствует требованием задачи.
- Поддержка продукта. Способность длительно поддерживать и улучшать выпущенный продукт.
Одинаковое понимание
Основной проблемой системы управления рисками часто бывает отсутствие одинакового понимания, в результате чего отношение к разработке постоянно меняется. Это может привести к тому, что решение не будет соответствовать всем требованиям задачи. Компания должна понимать, как разрабатывать ПО для любого из сайтов и любого проекта. И для каждого проекта необходимо находить общее понимание его разработки.
В идеале все разработчики проекта (или большая их часть) должны чётко и полностью понимать требования к задаче и делаемому решению. К сожалению, часто дело обстоит не так, и это может привести к одной или нескольким из этих ошибок:
- Потерянный функционал. Какие-то компоненты служб так и не были созданы, потому что не было общего представления о том, как все эти компоненты будут взаимодействовать на базовой инструментальной платформе.
- Неполный функционал. Какой-то компонент не будет демонстрировать весь необходимый функционал, потому что разработчики не расскажут об этом пользователям (другим разработчикам).
- Чрезмерный функционал. Требования так и не были полностью поняты. Это приводит к разработке ПО без учёта каких-либо требований или потребностей.
- Модули кода будут настроены, но не будут полностью взаимодействовать между собой. Нет определения потоков управления в системе и границах модулей.
Решение, направленное на улучшение, подразумевает действия на этапах архитектуры и дизайна разработки. На уровне архитектуры должны быть определены зависимости между модулями. Сюда входит распределение выполняемых функций, которое определяет взаимозависимость между модулями и разделение функционала системы. На уровне дизайна должны быть определены потоки управления (сценарии использования) между модулями. Сюда входят все результативные сценарии использования, также как и выделенные состояния ошибки.
Вариации
Один из подходов к системе управления рисками — формализация планирования и обоснования профилактики рисков. Формализованный подход к системе управления рисками включает в себя определение и документальное оформление рисков проекта, обычно в виде таблицы, в которой есть колонки для степени риска, описания риска и профилактики риска.
Планы управления риском часто составляются с учётом официальной документации проектов, но редко воплощаются в финансируемой деятельности по проекту. Важно уделить внимание управлению рисками и выделить средства на исследования по профилактике риска там, где наиболее вероятна возможность неудачи.
Ещё одна вариация, «опережающая» команда, в чью задачу входит изучить возможности нового продукта и совместимость технологий. Они создают прототипы, которые имеют сходство с целевой архитектурой системы, используя основные технические решения или технические резервные средства.
«Опережающая» команда также выявляет любые технологические недоработки и исследует стратегии решения проблем несовместимости. Затем команда обучает новым технологиям остальных работников, задействованных в проекте, тем самым ускоряя процесс накопления технического опыта. В конце концов, «опережающая» команда должна опережать основные работы по разработке на 1-3 месяца. Иначе могут возникнуть задержки по основному проекту в ожидании результатов исследований «опережающей» команды.
Пример
Работы по разработке ПО не согласованы. Всё от разработки до поставки оставлено на усмотрение команд разработчиков. Это значит, что им необходимо решать вопросы качества и технологий самостоятельно и самим контролировать свою деятельность. Возможная рискованная ситуация воплощается в неприемлемый код из-за недостаточного следования и внимания к:
- Стандартам кодирования (в том числе предъявляемым к проекту)
- Анализу кода
- Планированию тестирования
- Модульному тестированию
- Тестированию API
- Интеграционному тестированию
- Объектному тестированию
- Программной документации
Рискованная ситуация проявляется плохо задокументированным кодом, который большей частью не был протестирован и не интегрирован, и в целом не соответствует требованиям.
Назначение нового руководителя проекта в результате приводит к улучшениям качества и протекания процесса разработки. Улучшения происходят поэтапно. Они интенсивно принимаются командами благодаря «ретроспективным» обзорам, которые проводятся с целью определения проблем, и созданию групп, которые должны изучить эти проблемы с помощью постепенного усовершенствования технологий.
Каждая группа состоит из координатора от технической поддержки и представителя команды разработчиков для этих частей процесса:
- Дизайн
- Кодирование
- Тестирование
- Документальное оформление
Каждый член группы отвечает за:
- Усовершенствование конкретного процесса.
- Обучение своей команды.
- Обеспечение личной оценки реализации конкретного процесса командой и качества отчётной документации.
- Поддерживание связи с остальными группами для обеспечения единых стандартов реализации процесса и решения проблемы.
В течение шести месяцев каждый процесс был несколько раз усовершенствован, и каждая команда реализовала каждый процесс хотя бы один раз. Улучшения были выражены в уменьшении (более 50%):
- Дефектов кода
- Ошибок в документальном оформлении
- Нетестированного кода
Схожие решения
В вариации анти-паттерна «Дым и зеркала» описывается включение в план проекта технических резервных копий. Это важное дополнение к управлению рисками профилактика основных стратегических ошибок, возникающих из-за Плохого управления проектами.
Брэд Эпплтон представляет отличный язык конструктивного шаблона для улучшения в своей работе об усовершенствовании процесса. Внедрение усовершенствования процесса — ключевой элемент решения проблемы плохого управления проектом.
| 
