12.0 Сравнение водопада и циклического управления проектами (часть 5) – Условия управления циклическими проектами

Пользователи / клиенты активно участвуют #

Каждый цикл циклического управления проектом включает в себя разработку требований, проектирование, выполнение и тестирование. Это означает, что в течение цикла нужно делать множество выборов. Если программа должна точно отражать желания клиента, он должен быть активным членом команды проекта.

Заказчики должны сообщать свои требования программистам и дизайнерам настолько ясно, насколько это возможно. Это часто влечет за собой еженедельное (или, по крайней мере, раз в две недели) участие в команде проекта.

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

Команда наделена полномочиями делать выбор. #

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

Результат проекта (программное обеспечение) можно разделить на более мелкие компоненты. #

Циклическое управление проектами – это метод управления проектами, при котором части проекта выполняются в серии циклов. Это возможно только в том случае, если разрабатываемое программное обеспечение может быть разложено на ряд более или менее отдельных компонентов.

Требования руководства к программному обеспечению для управления проектами в первую очередь глобальны; руководство не предъявляет прямых, конкретных или конкретных требований. Одним из преимуществ циклического управления проектами является тесное сотрудничество между заказчиком, дизайнерами, программистами и любыми тестировщиками в течение циклов. Если в начале проекта устанавливаются конкретные и конкретные требования, это ограничивает способность проектной группы принимать правильные решения при выборе дизайна. Выявлено, что многочисленные требования к проекту нуждаются в адаптации в ходе процесса и, следовательно, не должны (слишком) твердо устанавливаться с самого начала.

Заказчик понимает действия. #

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

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

Должна быть возможность вернуться назад. #

Даже при циклическом управлении проектами команды иногда выбирают неверные пути. В таком случае должна быть возможность сделать шаг назад. Если новый модуль, созданный во время цикла, окажется недостаточным, должна быть возможность возобновить работу с предыдущим модулем. Это предъявляет требования, в первую очередь, к архивированию и документации проектных материалов. CVS и Subversion – два полезных инструмента для этих задач (полный список инструментов см. В Приложении 3).

Наряду с навыками программирования программисты должны уметь эффективно взаимодействовать с клиентами и наоборот. Члены команды должны быть интеллектуальными мыслителями. Для продолжения работы требуется дисциплина.

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

Приоритезация #

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

Директору фирмы по разработке программного обеспечения, который был больше дальновидным, чем менеджером, почти каждый месяц приходила отличная идея, и он постоянно инициировал новые инициативы в своей компании. В результате старые проекты так и не были завершены, и рабочие одновременно работали над пятью проектами. Харизматический директор только что закончил читать книгу по быстрой разработке приложений (RAD) и был очень взволнован этим – особенно «быстрым» элементом. Он записал основные идеи RAD на копировальный аппарат и затем ожидал, что все начнут работать с этими идеями. В конце концов, это была отличная техника.

Риски циклического управления проектами #

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

Хотя это законное беспокойство, оно также присуще водопадному подходу . Определяющий этап водопадного подхода влечет за собой углубленное изучение требований. Этот анализ, вероятно, приведет к улучшению управления временем. На самом деле это часто не так по причинам, указанным выше.

Кроме того, в этом подходе отсутствуют функциональные возможности из-за отсутствия средств на их разработку.

Требования обрабатываются прагматично в циклических подходах. Например, потребности в циклах можно классифицировать с использованием критериев MoSCoW (Stapleton, 2003) следующим образом:

  • Должен иметь: системные требования
  • Должны иметь: критические потребности, которых действительно желают пользователи
  • Могли бы иметь: желаемые потребности, которые можно легко игнорировать
  • Хочу иметь: требования, которые не будут выполнены на этот раз: требования, которые могут подождать позже

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

Понимание потенциальных недостатков #

Один из часто упоминаемых недостатков XP заключается в том, что значительная власть передается программистам. Если они злоупотребляют этими полномочиями, они могут использовать недостаток технических знаний у клиента в своих интересах. Чтобы избежать этого сценария, нужен руководитель проекта, который будет учитывать интересы как программистов, так и клиентов. Эти руководители проектов помогают своим клиентам в выборе и планировании циклов, в том, чтобы сделать техническую основу своего выбора понятной, а также в обеспечении администрирования и отчетности.

Наконец, еще одним недостатком XP является то, что реализация метода требует длительного обучения программистов, менеджеров и потребителей.