Интеграция критической цепи в методы Scrum/Agile

Управление проектами критической цепи требует от вашей команды большей гибкости:

Из Википедии «Управление проектами критической цепи»:

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

Но также (из Википедии «Управление проектами критической цепи»):

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

А также (из Википедии «Управление проектами критической цепи»):

Поскольку продолжительность задач была запланирована с вероятностью 50%, существует потребность в ресурсах для выполнения задач критической цепи как можно быстрее, преодолевая синдром студента и закон Паркинсона.

Что меня больше всего беспокоит, так это вероятность того, что команда в конечном итоге плохо справляется с многозадачностью. См. статью Джоэла Спольски « Переключатели задач человека считаются вредными »:

Из упомянутой выше статьи Джоэла:

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

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

Также из статьи Джоэла:

Фактически, реальный урок из всего этого заключается в том, что вы никогда не должны позволять людям работать более чем над одним делом одновременно . Убедитесь, что они знают, что это такое. Хорошие менеджеры видят свою ответственность в устранении препятствий , чтобы люди могли сосредоточиться на одном деле и по-настоящему его выполнить. Когда возникает чрезвычайная ситуация, подумайте, сможете ли вы справиться с ней самостоятельно, прежде чем делегировать ее программисту, который глубоко погружен в проект.

Чтобы устранить конфликты между Scrum/Agile и Critical Chain:

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

Этот конфликт можно разрешить, если принять тот факт, что задача на 4 дня на самом деле является задачей на 2 дня. Реальная работа выполняется за меньшее время, чем предусмотрено.

Из закона Паркинсона :

Следствие Сток-Сэнфорда из закона Паркинсона гласит: «Если вы будете ждать до последней минуты, это займет всего минуту».

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

Критическая цепь использует буфер в конце проекта. (Если график вашего проекта составляет восемь недель, вам дается четыре недели на выполнение работы и четырехнедельный буфер в конце проекта.) В Agile у вас есть спринты (итерации) только тогда, когда у вас есть работа.

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

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

Очень важно установить приоритеты задач, например must do(необходимо обоснование, если оно не выполнено) и should doи could do(обоснование не требуется, если не выполнено).

По сути, вы будете использовать прагматичную методологию Scrum под присмотром Critical Chain.

На самом деле, концепция буфера хорошо работает с таким гибким методом разработки, как scrum. Хотя я не уверен в сокращении оценок вдвое, но мы также применяем нечто подобное, используя оценки «наиболее вероятные» — «наихудшие» . Вот как мы это делаем:

Сначала мы осуществляем надлежащее управление проектом, начиная с хорошо разработанной структуры распределения работ ( WBS ) до уровня пакета работ. Список рабочих пакетов — это наш бэклог продукта. Затем эти рабочие пакеты оцениваются в диапазоне от «наиболее вероятного» до «наихудшего случая».

Наш «бюджет» представляет собой сумму «наиболее вероятных» оценок. «Буфер» рассчитывается как сумма средних — сумма наиболее вероятных. Некоторые используют двукратные стандартные отклонения, как объясняется в книге Кона, рекомендованной Марси (см. главу 17 «Планы буферизации для неопределенности»).

Теперь к исполнению: допустим, что в соответствии с возможностями нашей команды мы можем закончить проект за 6 спринтов (согласно наиболее вероятным оценкам), а нашего « буферного» бюджета хватит еще на 2 спринта. Делает в общей сложности 8 спринтов, чтобы закончить работу.

Обычно мы разбиваем наши проекты на несколько технических этапов (или более формальных релизов); каждая такая фаза получает свой собственный буфер.

Я считаю, что существует потенциал для хорошей синергии между CCPM и Scrum.

Если мы сосредоточимся на том, как улучшить Agile/Scrum, используя мышление CCPM:

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

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

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

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

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

Scrum/Agile дает вам отличный старт на типичном CCPM — из-за работы с использованием сквозных историй в бэклоге, гибкости ресурсов благодаря стремлению к коллективному владению и уменьшенной необходимости синхронизации благодаря командам Feature/Scrum, вы получаете гораздо более простая критическая цепочка с меньшей потребностью в питающих буферах, буферах ресурсов и т. д.

Если у вас есть зависимости между командами и другими внешними объектами, у вас может быть высокоуровневая перт-диаграмма вашего проекта, также известная как «упреждающее планирование» в мире Agile. Но если вы видите СЛИШКОМ МНОГО зависимостей, это может указывать на то, что ваши команды сформированы не идеально для выполнения работы.

В этой дискуссии есть еще много чего, но в итоге - не враги, а двоюродные братья... теперь консультант CCPM скажет вам, что CCPM намного сильнее, а Agile - локальное решение, но будьте сильными ;-) CCPM со своей стороны имеет многому можно научиться в мире Agile — гибкость в отношении функций/требований, ранняя обратная связь, расширение прав и возможностей команды, все замечательные вещи, которые могут улучшить среду CCPM и помочь справиться с изменчивостью, повысить предсказуемость и производительность даже для отличной реализации CCPM. Я рассматриваю Agile/Scrum как способ применения процесса постоянного улучшения (POOGI) в мире CCPM.

Надеюсь это поможет.

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

1. Сокращение спринта на x дней, например, 3 дня
2. Использование всех или части этих 3 дней в качестве буфера
3. НЕ допускайте отмены или переноса историй. Они должны быть выполнены в рамках спринта плюс буфер.
4. Расширяйте определенные результаты на несколько спринтов (расширяя истории) и создавайте/управляйте буфером, состоящим из всех буферных дней из всех спринтов, например, 9 дней, если вы используете 3-дневный буфер и распределяете историю по 3 спринтам.

Было бы здорово услышать какие-либо отзывы об этом подходе на практике.

Это, вероятно, не будет популярным ответом, но если вы используете Scrum, выбросьте большую часть того, чему вы научились во время PMP. Это совершенно разные мыслительные процессы.

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

Теперь, если вам нравится концепция «буферов», вы все еще можете использовать их в Scrum. Я рекомендую книгу Майка Кона Agile Estimating and Planning. У него есть несколько отличных методов для гибкой работы с оценками и «буферами».

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

Scrum и Critical Chain предназначены для решения разных задач. При использовании Scrum вы имеете дело с плохо определенным продуктом. Методы Agile предназначены для максимально эффективной разработки продукта, который плохо изучен на старте проекта.

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

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

О да, деление на два просто происходит из обычной практики: взять наилучшую оценку длительности задачи и удвоить ее.

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

Цель Critical Chain состояла в том, чтобы гарантировать, что ни одной задаче не придется ждать, потому что кто-то закончил раньше. Это работает только тогда, когда у вас много ресурсов, которые могут постоянно переключаться с задачи на задачу. Мы получаем то же самое в Scrum, НЕ назначая составные задачи элементов невыполненной работы членам команды, вместо этого члены команды берут задачу с наивысшим приоритетом, которая еще не была начата и которую они могут выполнить, когда закончат свою текущую задачу. Это позволяет нам использовать систему вытягивания, как в Lean/TPS, и гарантирует, что «готовые» задачи будут запущены, как только будет доступен соответствующий ресурс.

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

Если ваш проект:

1. может справиться одна команда
2. можно разделить таким образом, чтобы каждая часть могла быть обработана одной командой

Тогда вам подойдет Scrum (конечно, если вам нужен Agile).

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

Это сказало:

Agile-оценка задачи является грубой — вы можете сопоставить это с оценкой буфера. Например, популярный модифицированный ряд Фибоначчи даст вам прибл. 30% размер буфера. Сопоставьте это с количеством спринтов, необходимых для выполнения «задачи». Например: Команде А потребуется 3 спринта для реализации функции X: добавьте буфер одного спринта для расчета крайнего срока.

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