Блог Brain Rain - Статьи о SCRUM (Скрам) и Agile от Богдана Мисюры
Немногие говорят о работе Владельца Продукта системно, в формате чек-листа или схемы. Одна из любопытных попыток создать систему — фреймворк для оценки работы PO от Роберта Гэлена. Он построен по аналогии с Индексом освоения Аджайла Билла Кребса (Bill Krebs), который, в свою очередь, связан с такими системами, как инструмент самопроверки команд IBM (IBM Rational Self-check for Software Teams TM). Предлагаем перевод главных тезисов о продуктивном PO.
Ни для кого не секрет, что Скрам Мастер и Владелец Продукта — две отдельные роли, которые дополняют друг друга, и никто не может их совмещать. К сожалению, в реальной жизни случается, что Скрам Мастер не поддерживает Владельца Продукта, частично выполняет его обязанности, или Скрам Мастера нет вовсе.
Большинство участников тренингов BrainRain для Владельцев Продукта хочет пройти сертификацию. Отсюда — вопросы о том, как получить желанный балл по тесту, как вовремя дать все ответы и многие другие.     Мы решили ответить на них — и на этот раз не только по материалам от иностранных экспертов. О тесте рассказали наши выпускники, которые успешно прошли его, а также один из наших тренеров. Сертификация и тренинги Сертификат Владельца Продукта — документальное подтверждение ваших знаний. Часто он важен для трудоустройства. Помимо этого, сертификация и Scrum Master, и Product Owner — возможность проверить, насколько хорошо вы поняли Скрам.   В мире есть […]
Представьте себе, что вы саунд-продюсер. К вам в студию приехало новое оборудование под названием Скрам. Технические специалисты, конечно, просят его не сломать, а чтобы этого не случилось, использовать правильные настройки. Но параметров так много, а в инструкции об этом сказано совсем не все! Кнопки, эквалайзеры, слайдеры… Присмотримся, какие переменные есть с Скраме, вместе с Ильей Павличенко.
Сколько разработчиков у вас в одной команде (то есть сколько людей, кроме Скрам Мастера и Владельца Продукта)? В Руководстве по Скраму рекомендации немногочисленны: от 3 до 9 человек, и нет никакой аргументации именно такого количества.Конечно, из одного такого общего ответа нельзя вывести оптимальную цифру для каждого отдельного случая. Так что стоит разобраться, какие факторы влияют на размер команды и какие тут есть варианты.
Аджайл активно используется не только в IT, но и, например, в маркетинге, образовании и даже автопромышленности. В нетехнических командах сопротивление новому способы работы может быть сравнительно больше. В новом материале нашего блога — о том, как справляться с таким сопротивлением. Эти принципы могут оказаться ценными и для технических команд.
Многие (бывшие) продакт-менеджеры видят отпуск и другое время отсутствия сотрудника (болезнь, обучение) как блок, фактор отрицательной ценности или, по крайней мере, отдельный от бизнес-системы случай. Например, для некоторых это HR-вопрос вне проблематики планирования в разработке. Такой взгляд на вещи нереалистичен: плановые отсутствия все равно влияют на работу команды. Вопрос только в том, как учитывать это влияние.
Уже само название указывает на то, что Владелец Продукта должен распоряжаться продуктом от имени компании. Этот человек отвечает (в англоязычной литературе используется термин responsible) за то, чтобы продукт создавал ценность для клиентов и пользователей, как и для компании, которая предоставляет доступ к нему.Можно представить Владельца Продукта как куратора и защитника продукта, фасилитатора продуктовых решений и человека, принимающего о продукте окончательные решения. Роман Пихлер видит во Владельце Продукта гибкого продакт-менеджера, который следит за созданием продукта в течение долгого периода и отвечает за успешность продукта.
Если рынок конкурентный, технологии быстро развиваются, а крупные игроки инвестируют много, стартапу не остается других путей, кроме как осваивать Аджайл.
Сколько усилий нужно потратить на задачу? В условиях неопределенности и сложности ответ лучше дать не в часах. Куда удобнее относительные единицы, из которых самые известные — стори поинты. Мы перевели статью Майка Кона о том, какие факторы нужно учитывать, оценивая работу в стори поинтах, и как согласовывать эти факторы между собой. Бонус — список типичных ошибок в применении стори поинтов.

Будь в курсе! Подпишись на scrum-новости