Но разве мы не можем заранее избежать узких мест при планировании работы?

Командно-административное управление проектом начинается с предположения, что задачи по развитию проекта должны быть выполнены определенным членом команды. Причина, как правило, в наличии специальных знаний (например, администратор баз данных с навыками оптимизации БД). Это выглядит как аргумент в пользу предварительного планирования: создает узкое место в потоке работ, и команда, имеющая фиксированный крайний срок выполнения работы, должна учитывать это при планировании.

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

Невозможно все просчитать заранее. Существует несколько решений, принимаемых в начале проекта (Java или C#? Windows или Linux? Mac или PC?).

И есть еще ряд задач, которые необходимо сделать конкретному человеку. Но вообще scrum-команды не распределяют задачи в начале проекта или спринта.

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

Поэтому вместо декомпозиции работ на задачи в начале спринта, упорядочивания задач, распределения их между членами команды перед началом любой работы и отслеживания плана agile-команды следуют простому правилу планирования. Они принимают все решения в

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

Еще по теме Но разве мы не можем заранее избежать узких мест при планировании работы?:

  1. 7.1. Маржинальный анализ «узких мест
  2. «ЗНАЛ БЫ, ГДЕ УПАДЕШЬ, СОЛОМКИ БЫ ПОДСТЕЛИЛ» — ГЛАСИТ ПОГОВОРКА. НИКТО ИЗ НАС НЕ МОЖЕТ ЗНАТЬ ЗАРАНЕЕ, ГДЕ ОСТУПИТСЯ. НО ПОДГОТОВИТЬСЯ К НЕПРИЯТНОСТЯМ МЫ МОЖЕМ. 41. Упражнение«Просчитайте свои опасения»
  3. Разве у кого-нибудь есть время на планирование?
  4. Учет, аттестация, рационализация и планирование рабочих мест
  5. Как избежать раздельного учета при одновременной торговле оптом и в розницу
  6. Как избежать единого налога на вмененный доход при оптовой торговле с оплатой товара наличными деньгами
  7. Особенности учета продукции, работ, усауг при использовании счета 46 «выполненные этапы по незавершенным работам»
  8. Планирование работы
  9. ШИРОКАЯ ИЗВЕСТНОСТЬ В УЗКИХ КРУГАХ
  10. Планирование работы с кадрами
  11. Граница во времени при планировании
  12. Анализ работ и планирование персонала.
  13. Планирование работы с персоналом
  14. Планирование работы PR-отдела в компании
  15. Планирование кадровой работы
  16. Планирование и организация работы с резервом кадров
  17. 7.4. Применение теории игр при планировании роизводства
  18. 4.3 . Исследования при планировании Интернет-стратегии компании
  19. Порядок определения налоговой базы при совершении операций по передаче товаров (выполнению работ, оказанию услуг) для собственных нужд и выполнению строительно-монтажных работ для собственного потребления