ScrumTrek - scrumtrek.ru

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

C точки зрения логики — для начала проверьте условия применимости Scrum, описанные в этой статье (там же вы найдете выгоды, ожидаемые от внедрения Scrum, и типичные причины, почему Scrum бывает неэффективен).

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

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

• Статистику о целях и выгодах внедрения гибких подходов (и многие другие данные) можно найти в исследованиях Agile в России (пример).
• Кейсы в видеоформате можно посмотреть выше. Другие кейсы в текстовом формате описаны здесь.

С точки зрения Scrum, Product Owner (PO) — это роль, а точнее, «зона ответственности» в Scrum-команде. PO отвечает за то, чтобы создать классный продукт, ценный для клиентов и в конечном итоге приносящий деньги бизнесу. «Product Owner — это один человек, а не комитет».

Если смотреть на эту роль с точки зрения современного рынка труда, то владелец продукта — это некая разновидность менеджеров продукта, которая так или иначе связана с Agile. В чистом Скраме (в т.ч. в LeSS) Product Owner имеет больше полномочий, чем Product Manager, а в SAFe — меньше (см. подробное сравнение двух ролей). Но на практике полномочия PO очень сильно варьируются, зависят от конкретного человека, продукта и организации.

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

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

Разница в том, что Agile — это лишь общая система ценностей, а не способ организации работы. Поэтому выражение «работать по Аджайлу» не имеет смысла (в отличие от «работать по Скраму»).

Scrum — это все же руководство к конкретным действиям (базирующимся на ценностях Agile): проведение 4-х конкретных встреч, работа с 3-мя конкретными артефактами, более-менее конкретное разделение ответственности между людьми.

Впрочем, Скрам — это фреймворк («каркас»), а отнюдь не набор директив, и Руководство по Scrum гласит: «Scrum не предоставляет людям подробных инструкций, вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей».