Чи корисні менеджери проектів у Scrum?

У Scrum визначено три ролі: команда, власник продукту та Scrum Master. Немає менеджера проектів, натомість робота менеджера проектів розподілена на три ролі .

Наприклад:

• Майстер Scrum: Відповідає за процес. Усуває перешкоди.
• Власник продукту: Керує та визначає пріоритетність списку робіт, які необхідно виконати для досягнення максимальної рентабельності інвестицій. Представляє всіх зацікавлених сторін (замовників, зацікавлених осіб).
• Команда: Самостійно керуйте своєю роботою, оцінюючи та розподіляючи її між собою. Відповідальний за виконання власних зобов'язань.

Тож у Scrum вже немає жодної людини, відповідальної за успіх проекту. Не існує структури команд та управління. Це, здається, бентежить багато людей, зокрема тих, хто не звик до спритних методів, і, звичайно, ПМ.

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

Чи згодні ви з Scrum, що менеджер проектів не потрібен? Як ви вважаєте, така роль все ж потрібна? Чому?

Можливо, ви повинні представити такі речі:

Керівник проекту не зник у Scrum . Він досі там. Зараз їх три !

• Майстер Scrum : він керує процесом і вирішує перешкоди. За це відповідав керівник проекту раніше.

• Власник продукту : він керує відставанням. За це відповідав керівник проекту раніше, коли він передбачив все в Microsoft Project.

• Команда : самостійно керуючи своїм виробництвом. Хто і як дана історія користувача перетворюється на потенційно збільшуваний продукт. Це було обов'язком керівника проекту, коли він призначав завдання.

Для мене це випливає з нерозуміння того, що робить менеджер проектів, і досить загального характеру назви ПМ. Я не фахівець з SCRUM, але я завжди бачив, як Майстер SCRUM замінює менеджера розвитку / керівника команди, а не менеджера проекту.

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

Якщо ваш прем'єр-міністр - це той, хто доглядає за розробниками і не робить багато іншого (наприклад, для проектів, які значною мірою є ІТ лише там, де сфера досить чітко визначена), то, можливо, він не буде потрібен. на проект SCRUM.

Але перш ніж хтось скаже, що вам не потрібен прем'єр-міністр для SCRUM, я хотів би досить чітке пояснення того, як висвітлюються елементи, які не стосуються ІТ, і, зокрема, хто керує бізнес-справою (адже користувачі цього хочуть) і це те, що слід зробити, це різні речі).

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

Є кілька речей, які може зробити менеджер проектів, що майстер Scrum або власник продукту можуть не зробити.

• Керівники проектів зазвичай мають великий досвід роботи з проектами (сюрприз!).
• Вони знають про загальні підводні камені, і можуть помітити їх і допомогти усунути їх, перш ніж вони трапляться.
• Зазвичай вони є досвідченими учасниками переговорів і можуть підтримувати інших членів команди в обговоренні строків, обсягу та суперечливих вимог (дуже важливо, якщо організація професійних відносин є досить новою у ролі).
• Вони можуть управляти грошима. Вони мають право наймати та звільняти, і можуть допомогти, якщо хтось із колективу нездатний виконувати свою роль (організовуючи навчання, консультування тощо).
• Вони можуть допомогти гарантувати, що проект ефективно вписується в більшу програму роботи.
• Вони можуть витягти речі з команди.
• Вони можуть допомогти орієнтувати політику компанії на ефективність поряд із Scrum (наприклад, якщо тестери все ще вимірюються кількістю знайдених помилок).
• Вони можуть керувати управлінням.
• Вони можуть пересувати меблі.
• Їх словниковий запас складається з більших підприємств, і вони можуть обговорювати проект - і підхід Scrum - щодо ризику, впливу, рентабельності інвестицій, варіантів та диференціації.
• Вони можуть пояснити дошці, чому раптова прозорість та випадкові новини про невдачу, що потрапляють через море зелених звітів, добре і корисно знати.
• Гарний прем'єр-міністр може допомогти вам почуватися в безпеці, здорово звучати та чудово виглядати.

Scrum не має обов'язків мати прем'єр-міністра. Але ви все одно можете захотіти його мати.

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

Передумовою цього було те, що компанія опинилася у важкій фінансовій ситуації, хоча ми (команда) про це дізналися лише через деякий час. Тож була причина тримати все під жорстким контролем, щоб забезпечити, що будується лише абсолютно необхідний матеріал, і перша версія продукту буде доставлена ​​вчасно.

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

Керівник проекту: роль у традиційній організації чи підприємстві.

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

Якщо говорити про менеджера проектів проти майстра scrum, то справді йдеться про яблука та апельсини, оскільки ролі мають різний контекст. Я жодного разу не чув про організацію, яка має "Scrum master" як офіційну назву чи платні. А керівники проектів будь-якого проекту, Scrum чи іншого, часто дещо віддаляються від щоденної діяльності з розробки програмного забезпечення.

Саме те, що робить менеджер проектів і наскільки його роль / роль перетинається з майстром Scrum або власником проекту, сильно залежить від розміру та характеру проекту, але звичайно є завдання, які зазвичай відносяться до менеджера проектів, які не є конкретно частина ролей майстра Scrum або власника проекту. У невеликому проекті можливо розширити обов'язки майстра Scrum або власника проекту, щоб включити ці завдання (найм, звільнення, закупівлі, управління контрактами, взаємодія з керівниками вищого рівня тощо). Що стосується більш масштабного проекту, розробка програмного забезпечення - це лише одна частина управління проектом, і обов'язки керівника проекту та обов'язків майстра Scrum навряд чи взагалі сильно перегукуються.

Менеджером проектів повинен бути інтерфейс майстра Scrum до організації. Майстер Scrum повинен бути інтерфейсом менеджера проекту до команди.

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

Це питання пахне Скрумбутом .

Scrum - це підмножина того, що міститься в методі управління проектами (Prince2 / PMP тощо). Насправді, якщо ви подивитеся на процес MP MP-процес Prince2 (керування доставкою товару), там можуть міститися всі елементи Scrum.

Майстер Scrum не хоче занурюватися на зустрічі з постачальниками, персоналом, юридичними справами, фінансами, постачальниками, керівниками чи активами БАУ . Їм потрібно зосередитись на усуненні перешкод у команди на поточному спринті, не домовляючись про те, наскільки агентство з працевлаштування може зняти ставки підрядника у FY2011 / 12 або затвердити угоду про депонірування з постачальником x.

Якщо ваш майстер Scrum робить вищезазначене, ви не запускаєте Scrum, ви працюєте з Scrumbut.

З досвіду найкраща комбінація - мати майстра Scrum для кожного керівника команди та керівника проекту, який координує майстрів Scrum в режимі Scrum of scrums. Наявність керівника проектів на цій ролі більш ефективно через причини, наведені вище, та глибину досвіду. У свою чергу, ці керівники проектів звітуються перед менеджером по портфоліо / програмі тощо і всі в ланцюзі команд принаймні сертифіковані майстри Scrum.

Пам’ятайте, що Scrum - це інструмент для управління доставкою продукції, на шарі абстракції він може використовуватися для запуску проектів, але для цього вже є набагато кращі процеси.

Однією з головних проблем традиційної ролі менеджера проектів є те, що він відокремлює владу від відповідальності. Прем'єр-міністр має повноваження щодо організації проекту - він вирішує, які завдання потрібно виконувати, ким, в якому порядку тощо. Але він (і) не несе відповідальності за виконання цих завдань або якість програмного забезпечення що виробляється. Члени команди є єдиними відповідальними. Це створює величезні накладні комунікації, оскільки, щоб повернути повноваження та рішення синхронізовано з оперативною роботою, члени команди постійно повинні повідомляти про все, що робиться, крім решти команди. Це також створює відчуття розчарування, безсилля та втрати мети у членів команди, що є великим джерелом розчарування та розчарування.

Agile якимось чином поєднує ці поняття разом - повноваження щодо організації роботи утримується командою в цілому (через звільнення, ітерацію та щоденні зустрічі), щоб кожен відчував, що може сказати свою справу в питанні, натомість чого кожен із члени команди повинні взяти на себе відповідальність за створення якісного програмного забезпечення, яке працює, і твердо зобов’язатися досягти цієї мети. Таким чином, ви теоретично можете позбутися керівника проекту.

Після того, як ви це сказали, все ще існують обов'язки, які традиційно покладаються на прем'єр-міністра, про які все ще потрібно потурбуватися - лунатик їх досить точно описав.

Як свідчить ця стаття , у справді багатокваліфікованих командах одне, що можна зробити, - це відмовитись від функції керівника проекту, перерозподілити свої обов'язки серед членів команди та перетворити колишніх прем'єр-міністрів на постійних членів команди.

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

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

У будь-якому випадку, як це працює на моїй роботі, керівники проектів дуже рідко пов'язані з власне «Скрамбінг». Їм не дозволено бути майстрами Scrum (місцеве правило конфлікту інтересів, якого ми всі дуже раді), і вони є виключно власниками продукції лише у виняткових випадках.

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

Я впевнений, що це зовсім інакше в інших місцях, але для нас це чудово працює.

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