Полезны ли руководители проектов в Scrum?

В Scrum определены три роли: команда, владелец продукта и мастер Scrum. Менеджера проектов нет, вместо этого работа менеджера проекта распределена по трем ролям .

Например:

• Scrum Master: Ответственный за процесс. Устраняет препятствия.
• Владелец продукта: управляет списком работ, которые необходимо выполнить, чтобы максимизировать рентабельность инвестиций. Представляет все заинтересованные стороны (клиенты, заинтересованные стороны).
• Команда: Самостоятельно управляю своей работой, оценивая и распределяя ее между собой. Ответственный за выполнение своих обязательств.

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

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

Согласны ли вы со Scrum, что менеджер проекта не нужен? Как вы думаете, такая роль все еще требуется? Почему?

Может быть, вам следует представить такие вещи:

Менеджер проекта не исчез в Scrum . Он все еще там. Существует три из них сейчас!

• Мастер Скрама : он управляет процессом и устраняет препятствия. Это было обязанностью менеджера проекта раньше.

• Владелец продукта : он управляет отставанием. Это было обязанностью менеджера проекта прежде, когда он предсказал все в Microsoft Project.

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

Для меня это происходит из-за непонимания того, что делает менеджер проекта, и довольно общего характера заголовка PM. Я не эксперт по SCRUM, но я всегда видел, как мастер SCRUM заменяет менеджера по разработке / руководителя группы, а не менеджера проекта.

Менеджеры проектов (как определено в методологиях, таких как PRINCE2 - который в значительной степени совместим с методологиями Agile) на самом деле не имеют ничего общего с процессом разработки, они следят за проектом с более широкой точки зрения, охватывающей не только ИТ строить. В роли менеджера проекта есть много вещей, которые не рассматриваются в других местах в Scrum (управление бизнес-кейсом и его мониторинг, управление заинтересованными сторонами бизнеса, элементы проекта вне ИТ-сборки, такие как доработка бизнес-процессов, поддержка, обучение и тд).

Если ваш премьер-министр - это парень, который заботится о разработчиках и не делает ничего большего (например, в проектах, которые в значительной степени связаны только с ИТ, где сфера довольно четко определена), то вполне может быть, что он не понадобится на проекте SCRUM.

Но прежде чем кто-то скажет, что вам не нужен PM для SCRUM, я хотел бы получить довольно четкое объяснение того, как охватываются не-ИТ-элементы проекта и, в частности, кто управляет бизнес-кейсом (потому что пользователи этого хотят и это то, что должно быть сделано, это разные вещи).

Может случиться так, что премьер-министр в конечном итоге сядет больше на деловую сторону проекта - владелец продукта вполне может взять на себя больше роли премьер-министра, чем Scrum Master, но я думаю, что он вряд ли уйдет полностью.

Менеджер проекта может сделать несколько вещей, которые мастер Scrum Master или владелец продукта могут не иметь.

• Менеджеры проектов обычно имеют большой опыт работы над проектами (сюрприз!).
• Они знают об общих подводных камнях и могут обнаружить их и помочь предотвратить их, прежде чем они произойдут.
• Обычно они являются опытными участниками переговоров и могут поддержать других членов команды в обсуждении сроков, сферы действия и противоречивых требований (очень важно, если ПО является довольно новым в этой роли).
• Они могут управлять деньгами. Они имеют право нанимать и увольнять и могут помочь, если кто-то в команде не способен выполнять свою роль (посредством организации обучения, консультирования и т. Д.).
• Они могут помочь гарантировать, что проект эффективно вписывается в большую программу работы.
• Они могут убрать вещи с пути команды.
• Они могут помочь в обеспечении эффективности политики компании наряду со Scrum (например, если тестеры по-прежнему оцениваются по количеству найденных ошибок).
• Они могут управлять управлением.
• Они могут переместить мебель.
• Их словарный запас принадлежит большему предприятию, и они могут обсудить проект - и подход Scrum - с точки зрения риска, воздействия, рентабельности инвестиций, вариантов и дифференциации.
• Они могут объяснить Правлению, почему внезапная прозрачность и случайные новости о неудачах, появляющиеся через море зеленых отчетов, полезны и полезны для понимания.
• Хороший менеджер поможет вам чувствовать себя в безопасности, звучать круто и отлично выглядеть.

Scrum не требует наличия PM. Но вы можете захотеть иметь его в любом случае.

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

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

Я буду честен и скажу, что, на мой взгляд, для меня работает мастер Scrum, который также является менеджером проекта. Быть мастером Скрама - это не работа на полную ставку - как только команда созреет, мастеру Скрама даже не нужно посещать ежедневные занятия.
Я вижу все больше и больше вакансий для менеджера проектов / Scrum Master, где компании не хотят разграничивать эти роли - вместо этого один и тот же человек отвечает за обе роли - то есть: менеджер проекта Agile.

Руководитель проекта: роль в традиционной организации или предприятии.

Scrum master: роль в команде разработчиков программного обеспечения с использованием методологии Scrum.

Говоря о менеджере проекта и мастере Scrum, на самом деле речь идет о яблоках и апельсинах, потому что роли имеют разные контексты. Я никогда не слышал об организации, в которой «Scrum master» является официальным названием или оценкой. И руководители проектов любого проекта, Scrum или иного, часто несколько отстранены от повседневной деятельности по разработке программного обеспечения.

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

Менеджер проекта должен быть интерфейсом Scrum-мастера к организации. Scrum master должен быть интерфейсом менеджера проекта для команды.

Итак, полезны ли руководители проектов в Scrum? Нет, менеджеры проектов полезны за пределами Scrum. Они не являются частью методологии разработки программного обеспечения Scrum, но они предоставляют ресурсы, которые позволяют Scrum работать.

Этот вопрос пахнет Scrumbut .

Scrum - это подмножество того, что содержится в методе управления проектом (Prince2 / PMP и т. Д.). На самом деле, если вы посмотрите на MP процесса Prince2 (управление доставкой продукта), все элементы Scrum могут содержаться там.

Scrum Master не хочет зацикливаться на встречах с поставщиками, персоналом, юристами, финансами, поставщиками, руководителями или представителями BAU . Они должны сосредоточиться на устранении препятствий в команде по текущему спринту, а не на переговорах о том, насколько агентство по трудоустройству может рассчитать ставки подрядчика в 2011 финансовом году / 12, или на утверждении соглашения об условном депонировании с поставщиком x.

Если ваш Scrum Master выполняет вышеописанное, вы не используете Scrum, а Scrumbut.

Исходя из опыта, лучшая комбинация состоит в том, чтобы иметь Scrum Master для каждого руководителя команды и менеджера проекта для координации мастеров Scrum Scrum of scrum. Наличие руководителя проекта на этой должности более эффективно в силу приведенных выше причин и их глубокого опыта. В свою очередь, эти менеджеры проектов подотчетны Менеджеру Портфеля / Программы и т. Д., И все в цепочке команд являются по крайней мере сертифицированными Мастерами Скрама.

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

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

Agile каким-то образом объединяет эти понятия - власть над организацией работы принадлежит команде в целом (посредством релизов, итераций и ежедневных собраний), так что каждый чувствует, что он может сказать свое слово, взамен которого каждый из Члены команды должны взять на себя ответственность за создание качественного программного обеспечения, которое работает, и твердо привержены достижению этой цели. Таким образом, вы можете теоретически избавиться от менеджера проекта.

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

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

Роли Scrum довольно хорошо определены (если они кажутся расплывчатыми, это потому, что они предназначены для применения в различных типах организаций), и так как команды Scrum всегда (ну, как правило,) примерно одного размера - т.е. не очень большие - относительно легко договориться о том, что они охватывают, даже если это варьируется в зависимости от базовой организации.

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

Так или иначе, поскольку это работает на моей работе, менеджеры проектов очень редко связаны с фактическим "Scrumming". Им не разрешается быть мастерами Scrum (локальное правило конфликта интересов, которым мы все очень довольны), и они являются только владельцами продукта в исключительных случаях.

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

Я уверен, что это совсем другое дело в других местах, но для нас это прекрасно работает.

Изменить : Может быть, я должен уточнить, что для нас команда Scrum не заменяет команду проекта. Одна или несколько команд Scrum начинают выполнять фактическую работу по разработке для (и обычно в) проекта. Команды Scrum могут (и, вероятно, всегда) состоят из старых членов команды, за исключением лидера проекта :-)