главе 6.

ХР-команды признают, что такая проблема, как сложность, может повлиять на планирование проектов. В этой книге мы уже упоминали, как scrum-команды сталкивались со схожими трудностями.

Например, несложно убедить сотрудников, что для команды, стремящейся быть продуктивной и выполнить проект, не имеет смысла держать людей, сидящих сложа руки. Однако некоторые менеджеры, исповедующие командно-административный стиль руководства, доводят эту идею до крайности: они приносят план проекта, где все 100 % ресурсов уже распределены[58], и требуют от разработчиков отчета за каждую минуту работы. Постоянный контроль за 100 %-ной загрузкой персонала запланированной работой перегружает управление проектом. Люди должны следить за использованием своего времени и вносить данные в систему контроля (что несложно сделать в теории, но на практике отнимает уйму времени и сил). Менеджерам необходимо составлять, обновлять и пересматривать планы, и невозможно избежать множества совещаний по «решению» проблем, потому что только кажется, что разработчик занимается делом 95 % своего времени.

Получается сложная система управления проектом, но дополнительное усложнение не добавляет ценности в проект.Теперь команда тратит около 20 % своего времени на отслеживание и разговоры о том, на что уходят остальные 80 %, а это увеличивает длительность проекта. Похоже, команда тратит все больше времени на планерки, обсуждая такие вопросы, как «На сколько процентов завершено дело?» и «Можете ли вы оценить, сколько минут потратите на эту задачу?».

XP-команды, так же как scrum-команды, используют итерации для принятия решений по планированию проекта в последний ответственный момент. Такой способ планирования проектов гораздо проще. XP-команды, как правило, не следят постоянно за временем каждого сотрудника, как показано в нашем примере, потому что мониторинг не помогает выполнять проект. Несмотря на благие намерения, собранная информация редко используется для прогнозирования проекта и почти никогда не пересматривается после его завершения. Как уже было сказано, ситуацию ухудшает то, что проекты со временем меняются. Планирование 100 %-ного распределения ресурсов потребует от команды принятия всех решений в начале проекта. Если какое-то из них оказывается неверным (а это обязательно случится, таков нормальный ход проекта), то вся команда должна будет пересмотреть планы, задачи и варианты распределения.

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме главе 6.:

  1. Введение к главе
  2. Введение к главе
  3. Введение к главе
  4. Введение к главе
  5. Введение к главе
  6. Введение к главе
  7. Введение к главе
  8. Введение к главе
  9. Введение к главе
  10. Введение к главе
  11. Главе 18
  12. Выводы по главе 1
  13. Выводы по главе 2
  14. Выводы по главе 3
  15. Выводы по главе 4
  16. Выводы по главе 5