Следует сразу уяснить простую вещь: в списке полно заданий, до которых у вас никогда не дойдут руки, но вам требуется выбрать те, что принесут наибольшую пользу при наименьшем риске. Поскольку Scrum придерживается поступательной модели разработки и поставки – на языке программистов эта модель называется инкрементальной, – надо начать с такого набора возможностей продукта, который немедленно принесет доход; тем самым вы снизите риски, связанные с проектом. Потому сначала советую отбирать основные функциональности. Хотите оказать быструю услугу заказчику? Тогда берите требование с наивысшим приоритетом, выполняйте его – и,
В первой главе я уже говорил о непреложном правиле, не раз подтвержденном на практике: 80 процентов успеха и ценности продукта заложены в 20 процентах его функциональных возможностей. На минутку задумайтесь. Что бы вы ни приобрели, основная ценность товара или услуги, то есть самое необходимое, содержится в пятой части того, что было сделано. Этот универсальный принцип, естественно, касается и любой проектной разработки программного обеспечения. Вернемся к нашей компании, выпускающей системы автоматизации зданий. Разработчики, составив перечень требований, предъявляемых к функциям продукта, принялись внимательно его перечитывать, причем они прекрасно понимали – действительно
Вы никогда не думали о таком беспроигрышном варианте, как выпускать новую продукцию в пять раз быстрее своих конкурентов, при этом впятеро повысив ее рыночную ценность? А вот разработчики из компании по автоматизации – они задумалась. И опять сели за свой бесконечный список, но на сей раз не для того, чтобы его перечитывать, а чтобы решить ряд вопросов. Им предстояло разобраться, за какой участок работы они возьмутся завтра, установить, какие функции системы нужнее всего для потребителя, и понять, как повысить эффективность системы и вывести ее на рынок быстрее всех. По утверждению Скотта Максвелла, сложность не в том, чтобы решить,
Как это сделать? Рассказываю. Для начала вам понадобится человек, который сможет определить концепцию проекта, сформулировать требования заказчика и установить необходимые пользователю основные функциональности продукта. В скрам-команде человека с такими обязанностями мы называем владельцем продукта.
Владелец продукта
В методологии Scrum предусмотрено три роли: группа, или скрам-команда, – каждый исполнитель конкретного проекта является частью этой команды; скрам-мастер – следит за ходом проекта и помогает команде в ее проблемах, и владелец продукта. Все роли и их функции будут подробно рассмотрены в приложении. Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение бэклога; собирает и формулирует пользовательские требования, определяя их приоритетность.