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

17

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

Например:

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

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

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

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

Мартин Викман
источник
Я узнаю это. Однако, возможно, ScrumMasters считают, что они новый премьер-министр.
Амир Резаи
Кто делает бюджет и синхронизируется с другими проектами?
Амир Резаи
3
@Amir Rezae Ну, конечно, это PM. Но они не должны принимать участие в схватке. Это именно то, что у нас есть, наблюдатель, который следит за тем, чтобы различные части проекта (dev и non-dev) были на ходу, и никто не ждет отзывов от других. Оно работает.
biziclop
Что вы подразумеваете под менеджером проекта здесь? Я привык видеть, что руководители проектов оргструктуры становятся Владельцами Продуктов в Scrum, поэтому они там очень много, хотя и не обязательно обладают такой же мощью, как раньше.
JB Кинг
Я согласен с @biziclop. Так мы тоже работаем. Наш превосходный менеджер проектов постоянно бегает между командами разработчиков (и всеми другими вовлеченными людьми), следя за тем, чтобы не было серьезных проблем, и помогает нам их решать, когда они возникают. Но она вообще не участвует в «схватках», и так и должно быть.
Бойсе

Ответы:

15

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

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

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

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

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


источник
Спасибо, я добавил акцент на мой вопрос, чтобы подчеркнуть это.
Мартин Уикман
Я видел, как ты изменился, это не лишает законной силы мой ответ. Думаю, проблема в том, как они все видят правильно? Они хотят, чтобы один человек управлял процессом. Объяснение, где ответственность и как это работает, может помочь. Поэтому я предлагаю больше рассказать о ролях и, следовательно, сделать Scrum более понятным для них.
Кто покрывает элементы вне IT-сборки?
Джон Хопкинс
1
@Jon: владелец продукта и Scrum Master (намного меньше, чем владелец продукта). То есть владелец продукта выглядит как менеджер проекта, о котором мы говорим. Он просто делегировал вещи, которые он не может контролировать команде.
@Pierre - Интересно. Понимаете, я никогда не видел, чтобы премьер-министр был тесно связан с командой разработчиков, он всегда позволял им заниматься этим, пока он руководил бизнесом. Может, мне просто повезло.
Джон Хопкинс
9

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

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

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

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

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

Джон Хопкинс
источник
1
Я бы сказал, что, возможно, ближайшая роль к классическому PM - Scrum Master. Scrum Master гарантирует, что команда сможет работать в соответствии с планом, активно выслушивая их проблемы и устраняя препятствия. Премьер-министр, как Scrum Master, может потерять свои прежние задачи (например, планирование), когда он перейдет на более консультативную роль -> они могут не планировать и не оценивать спринт, но они помогают команде сделать это и должны быть готовы присоединиться, если любые проблемы возникают.
Anne Schuessler
@ Анна - это хороший момент. Вы можете обнаружить, что у вас есть один менеджер по проектам в нескольких проектах, помогающий Владельцу продукта в экономическом обосновании, Scrum Master в планировании (в частности, зависимости вне группы) и координации с элементами вне ИТ-проекта.
Джон Хопкинс
4

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

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

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

Lunivore
источник
1
Здесь много точек, большинство из них попадают в руки ПО и / или ScrumMaster по определению. Портфель проектов управляющей компании - это отличный момент, но я не уверен, что это обязанность премьер-министра. ROI - это проблема PO.
Мартин Уикман,
1
ROI - единственная проблема, с которой сталкивается менеджер проекта. Много раз продукт на самом деле не предназначен для того, чтобы зарабатывать деньги - он просто останавливает конкурента, который крадет долю рынка, поэтому не будет никакой окупаемости инвестиций (спасибо Крис Мэттс). Зачастую им приходится работать с архитектурой, инфраструктурой и т. Д., Чтобы варианты оставались открытыми на будущее. Окупаемость инвестиций редко является проблемой большинства проектов. Это действительно хороший пример того, что может знать руководитель или хороший аналитик, а недавно обученный ПО - нет.
Лунивор
2
Что здесь пытаются сказать, что премьеры супер люди? Это не имеет никакого смысла. Здесь речь идет о ролях , а не отдельных лицах. Конечно, «хороший аналитик» знает больше вещей, чем «недавно обученный ПО», это очевидно. Относительно вашего ответа: Все точки, кроме точки портфолио проекта, обрабатываются SM или PO в Scrum. А что с лекцией о рентабельности инвестиций? Никто не сказал, что ROI является наиболее важным, только то, что ROI является проблемой PO (по определению).
Мартин Уикман,
Благодарю. Это отличная обратная связь, которая поможет мне лучше донести свою точку зрения в будущем. Я прошу прощения за чтение лекций.
Лунивор
1

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

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

Петер Тёрёк
источник
1
Интересный. Обратите внимание, что именно ПО отвечает за рентабельность инвестиций, всегда следя за тем, чтобы строились самые важные вещи. Так что эта часть покрыта довольно хорошо.
Мартин Уикман
1

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

Шехан
источник
Я не думаю, что я согласен с этим, я думаю, что открытость для PM / SM одновременно относится к компании, которая верит в разборки, роль PM просто переименована и не понимает, что она была полностью изменена. Это и набор навыков премьер-министра в некоторой степени поддаются роли Scrum Master (хотя и более заинтересованным сторонам, если вы спросите меня)
Джимми Хоффа
1

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

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

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

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

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

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

Калеб
источник
1

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

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

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

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

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

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

комар
источник
2
Что с комментариями, я не понимаю.
Мартин Уикман,
2
@MartinWickman Я прочитал это, чтобы означать «не совсем преданный делу схватки», как в: Мы занимаемся скрамом, но у нас все еще есть менеджер, устанавливающий расписание.
Калеб
0

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

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

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

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

guillaume31
источник
0

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

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

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

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

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

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

Бойсе
источник