К 2021 году 40% IT-специалистов будут мультидисциплинарными (versatilists), у них будут разнообразные роли, из которых большинство — не столько технологические, сколько бизнес-роли. По мнению Gartner, более 50% крупных компаний формализует мультидисциплинарные описания вакансий и профили специалистов. 20% IT-организаций будет нанимать мультидисциплинарных специалистов для масштабирования бизнеса — Gartner Symposium/ITxpo 2017.

Даже простейшие проекты могут затрагивать много отделов и функциональных групп в организации. Так что Аджайл приходится отстаивать перед самым разным людьми, не только перед одной конкретной командой и топ-менеджментом. И неспособность его отстоять могут привести к серьезным проблемам на проекте. Авторы этой статьи методом проб и ошибок вывели несколько подходов к внедрению Аджайла в организации на разных уровнях.

О работе Владельца Продукта много книг и статей, но на практике их оказывается мало — необходим еще опыт с реальными проектами. Как учиться так, чтобы понимать работу по Скраму практически, и где найти первую работу? В этот раз в нашем блоге — адаптация нескольких статей о том, как стать Владельцем Продукта. Кто такой Владелец Продукта Как сказано в Руководстве по Скраму, Владелец Продукта отвечает за максимизацию ценности продукта, который производит Команда разработки. То, как именно он/а это выполняет, во многом зависит от организации, команды и конкретной личности.   Владелец Продукта в Скраме — единственный человек, который отвечает за управление Бэклогом […]

Немногие говорят о работе Владельца Продукта системно, в формате чек-листа или схемы. Одна из любопытных попыток создать систему — фреймворк для оценки работы PO от Роберта Гэлена. Он построен по аналогии с Индексом освоения Аджайла Билла Кребса (Bill Krebs), который, в свою очередь, связан с такими системами, как инструмент самопроверки команд IBM (IBM Rational Self-check for Software Teams TM). Предлагаем перевод главных тезисов о продуктивном PO.

Ни для кого не секрет, что Скрам Мастер и Владелец Продукта — две отдельные роли, которые дополняют друг друга, и никто не может их совмещать. К сожалению, в реальной жизни случается, что Скрам Мастер не поддерживает Владельца Продукта, частично выполняет его обязанности, или Скрам Мастера нет вовсе.

Большинство участников тренингов BrainRain для Владельцев Продукта хочет пройти сертификацию. Отсюда — вопросы о том, как получить желанный балл по тесту, как вовремя дать все ответы и многие другие.     Мы решили ответить на них — и на этот раз не только по материалам от иностранных экспертов. О тесте рассказали наши выпускники, которые успешно прошли его, а также один из наших тренеров. Сертификация и тренинги Сертификат Владельца Продукта — документальное подтверждение ваших знаний. Часто он важен для трудоустройства. Помимо этого, сертификация и Scrum Master, и Product Owner — возможность проверить, насколько хорошо вы поняли Скрам.   В мире есть […]

Представьте себе, что вы саунд-продюсер. К вам в студию приехало новое оборудование под названием Скрам. Технические специалисты, конечно, просят его не сломать, а чтобы этого не случилось, использовать правильные настройки. Но параметров так много, а в инструкции об этом сказано совсем не все! Кнопки, эквалайзеры, слайдеры… Присмотримся, какие переменные есть с Скраме, вместе с Ильей Павличенко.

Сколько разработчиков у вас в одной команде (то есть сколько людей, кроме Скрам Мастера и Владельца Продукта)? В Руководстве по Скраму рекомендации немногочисленны: от 3 до 9 человек, и нет никакой аргументации именно такого количества.Конечно, из одного такого общего ответа нельзя вывести оптимальную цифру для каждого отдельного случая. Так что стоит разобраться, какие факторы влияют на размер команды и какие тут есть варианты.

Аджайл активно используется не только в IT, но и, например, в маркетинге, образовании и даже автопромышленности. В нетехнических командах сопротивление новому способы работы может быть сравнительно больше. В новом материале нашего блога — о том, как справляться с таким сопротивлением. Эти принципы могут оказаться ценными и для технических команд.

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