В комментариях произошел следующий обмен ответами на другой вопрос Как мне управлять разработкой с тестированием и получать надлежащую отчетность в JIRA? , которые, кажется, подчеркивают другую точку зрения между принципами Agile, которая заключается в предоставлении ценности, и желанием менеджера ресурсов, чтобы люди работали / вносили свой вклад в любое время. Ключевые элементы я выделил жирным шрифтом . Между этими позициями есть принципиальная разница, так какова же или какой должна быть роль менеджера ресурсов в среде Agile (Scrum)?
Пожалуйста, не отвечайте на это ссылкой на реструктуризацию в многопрофильные команды — это не мой вопрос. Это связано исключительно с организационными ролями менеджеров ресурсов в Agile-среде и с тем, насколько они должны быть вовлечены / заинтересованы в том, что люди делают ежедневно.
Редактировать: я не являюсь ни менеджером по ресурсам, ни практиком Agile, поэтому я не задаю этот вопрос с каким-либо заранее сформированным мнением. Мне просто интересно мнение сообщества по этому поводу.
«Например… почему разработка завершается в 17:00 в пятницу, а не в 17:00 в четверг, поэтому работу можно протестировать в пятницу?» - допустим, они закончат в четверг, так что они будут делать в пятницу?? — пользователь 48230 вчера
@ user48230 Это ошибка 100% использования. Цель не в том, чтобы занять людей; цель состоит в том, чтобы обеспечить приращение ценности в надежном темпе. Вы реализовали неправильную цель. – Тодд А. Джейкобс ♦ 16 часов назад
@ToddA.Jacobs - вы правы, 100%. тем не менее, как менеджер по ресурсам, я также должен следить за тем, чтобы люди приносили пользу в пятницу с 9 до 17, пока QA заканчивает тестирование. – user48230 15 часов назад 1
@user48230 user48230 Нет. В среде Scrum «ценность», доставляемая в пятницу, — это демонстрация/обзор с заинтересованными сторонами, а не «дополнительная работа». Если никто другой не примет это во внимание, я напишу более подробный ответ, когда смогу. Ценность Scrum не в занятости; речь идет о последовательности, быстрой обратной связи и сотрудничестве. – Тодд А. Джейкобс ♦ 13 часов назад
Менеджеру ресурсов как организатору повседневной продуктивности не место в agile-команде. Мы знаем, почему они не принадлежат, это в вашем вопросе. Они пытаются оптимизировать то, что не следует оптимизировать. Это контрпродуктивно.
Возможно, этот «менеджер ресурсов» играет более стратегическую роль, чем кажется. Например, в агентстве по увеличению штата есть люди, которые следят за тем, чтобы у разработчиков были новые задания, к которым они могли бы перейти после завершения текущих. Это полезная работа, но она не предполагает ежедневного вмешательства в команду. И если это происходит, команда должна возразить против этого и обострить свои опасения.
Но если «менеджер ресурсов» — это роль, которая существует в команде изо дня в день, то у нас есть проблема. Этому человеку придется не обращать внимания на свою роль и на то, какой вклад он вносит в результат команды. Что-то должно быть организовано командой и их менеджером по отчетности, чтобы наилучшим образом продуктивно использовать свои навыки. В идеале что-то, что не подрывает их карьерный рост и оставляет за ними роль, которая им нравится и может преуспеть. Это сложная проблема, и она зависит от человека. Их работа не так уж далека от Agile-коуча или Scrum-мастера (в конце концов, они задают вопросы о процессе), но их отношение и способности могут быть несовместимы, это невозможно сказать на расстоянии.
Вопрос, который вы цитируете, имеет теги «scrum» и «scrum-master». Как управлять разработкой с помощью тестирования и получать надлежащие отчеты в JIRA? Итак, я отвечаю на этот вопрос в контексте Scrum.
В Scrum всего три роли:
Кроме того, как очень хорошо объяснил @todd-a-jacobs, ваша цель не должна заключаться в том, чтобы все были полностью загружены работой и были заняты полные 40 часов в неделю.
Это ошибка 100% использования. Цель не в том, чтобы занять людей; цель состоит в том, чтобы обеспечить приращение ценности в надежном темпе.
Таким образом, в Scrum нет роли «Менеджер ресурсов».
Если роль менеджера ресурсов в вашей организации рассматривается как максимизация измеримой деятельности, а не производимой ценности, у вас серьезная проблема. Вы создадите больше отходов, заставив людей заниматься тем, что в данный момент не может принести пользы.
Если вы посмотрите на ситуацию с QA, то время в спринте, когда выполняется окончательный QA (и, следовательно, никакая дальнейшая разработка не может быть включена в результаты спринта, поскольку нет времени на ее тестирование), может быть использовано разработчиками для просмотра. изгородь, узнавать что-то новое, читать технические блоги, читать и публиковать сообщения в StackExchange, пробовать инструменты или садиться и размышлять о том, как можно было бы лучше справляться с распространенными ситуациями. Но это должны быть действия, вытекающие из стремления разработчиков к улучшению и качеству, а не навязанные им для того, чтобы заполнить свое время.
То же самое в основном верно для QA-специалистов в начале спринта, когда код, относящийся к спринту, еще не готов для тестирования. Это может быть время, чтобы подумать о своей работе и узнать что-то новое.
Обратите внимание, что это размышление на индивидуальном уровне отличается от ретроспективы спринта, которая охватывает общий процесс на уровне команды, а не в первую очередь индивидуальное улучшение.
Я решил подойти к этому вопросу не с точки зрения предыдущего вопроса, который породил этот, а с более творческого, основанного на мозговом штурме подхода, с сочувствием к точке зрения человека, чья сегодняшняя работа — менеджер ресурсов, перед лицом организационного перехода к Agile. и задаваясь вопросом: «Какова же должна быть моя работа?»
Я также явно не использую Agile как синоним scrum. Есть другие рамки! ;)
Итак, что может делать менеджер ресурсов в гибкой организации?
Прежде всего, я не думаю, что они являются частью гибкой команды. Я думаю, что это организационная роль, которая находится вне команд.
Возможно, они станут традиционным менеджером по персоналу, поддерживая карьерный рост своих непосредственных подчиненных, включая обучение.
Но я думаю, что лучше было бы, чтобы менеджер ресурсов имел широкое представление о нескольких agile-командах. В agile «ресурсом» в большей степени является команда , чем отдельный человек.
Они будут ответственными за решение таких проблем, как «у нас нет всех необходимых навыков в команде», будь то добавление членов команды или организация обучения, и «есть 5 команд, но только 3 администратора баз данных, что нам делать?» делать".
Они могут нести ответственность за выяснение того, какие проекты должны быть переданы каким командам, сопоставляя сильные стороны с потребностями проекта. Они могут нести ответственность за принятие решений о том, следует ли, когда и как смешивать команды.
Это также может быть человек, которому SM создает препятствия, которые команда не может решить или контролировать. Они могут нести ответственность за препятствия, затрагивающие несколько команд.
Если вы оставите описание работы «убедитесь, что все сотрудники заняты на 100%» на столе, кажется, что есть несколько возможностей, которые могут принести пользу организации и командам.
Блуривер
Иэн9688