Роль владельцев продуктов при разработке программного обеспечения

Agile-разработка программного обеспечения - это отдельный мир, со своим языком, философией и методами. С точки зрения стороннего наблюдателя бывает непросто ориентироваться в таких "жужжащих" словах и понятиях, как scrum, stories или технический долг. Но это необходимо сделать, поскольку agile-методологии являются неотъемлемой частью современной разработки. <\/p>\r\n\r\n

Поэтому необходимо усвоить все ее понятия, начиная с важнейшего понятия "владелец продукта". Возможно, вы слышали, что владельцы продукта "отвечают за максимизацию ценности продукта, в первую очередь путем постепенного управления и выражения бизнес и функциональных ожиданий по продукту команде разработчиков". (это, кстати, прямая цитата из официального глоссария терминов Scrum). Это хорошее определение, но оно требует некоторой распаковки.<\/p>\r\n\r\n

С тех пор как люди стали собираться в племена, у нас так или иначе появились визионеры - люди, которым приходят в голову большие идеи и которые знают, как донести их до других. Кен Швабер и Джефф Сазерленд, разработав концепцию Scrum, поняли, что человек с идеями не обязательно должен быть менеджером.<\/p>\r\n\r\n

В каскадной методологии, как правило, есть менеджер, которому поручено решать общую задачу и одновременно управлять командой разработчиков. Это логично - человек, который понимает, как все части соединяются вместе, должен быть тем, кто делает выстрелы, верно?<\/p>\r\n\r\n

Не обязательно. Это большая ответственность для одного человека, особенно если предположить, что видение проекта будет меняться и развиваться по мере запуска в производство. Когда клиент начнет использовать продукт, цели будут перетасовываться по мере появления новых идей и необходимости. Поэтому вместо того, чтобы поручать обе задачи одному человеку, мы разделяем их, а общую картину поручаем владельцу продукта.<\/p>\r\n\r\n

Владельцы продуктов определяют видение<\/h2>\r\n\r\n

Считайте, что владелец продукта - это связующее звено между клиентом и командой разработчиков. Более того, некоторые разработчики программного обеспечения даже отводят роль владельцев продуктов своим клиентам. Их задача - понять потребности клиента и использовать их для определения целей и создания единой концепции для всех участников проекта.<\/p>\r\n\r\n

Пользуясь еще одним термином из методологии agile, можно сказать, что когда клиент сообщает о своих потребностях, он создает эпопею, большой рассказ, переданный в общих терминах, который невозможно реализовать за один спринт. Затем владелец продукта придает этому эпосу структуру и делит его на легко достижимые фрагменты, называемые историями.<\/p>\r\n\r\n

В каком порядке следует работать над историями? Какие из них уже проработаны? Какие остались? Это называется бэклог продукта, и обычно его ведет владелец продукта. Наличие человека с более высокой перспективой обеспечивает единство взглядов, несмотря на гибкость agile-систем. В некотором смысле владельцы продуктов объединяют всех вокруг общей цели.   <\/p>\r\n\r\n

<\/p>\r\n\r\n

Работа рука об руку с клиентом<\/h2>\r\n\r\n

Как мы уже говорили, одна из ключевых обязанностей владельца продукта - быть главным связующим звеном между клиентом и командой. Владельцы продуктов должны быть отличными коммуникаторами и еще лучшими слушателями. <\/p>\r\n\r\n

Чтобы помочь клиенту и лучше понять его эпопею, хороший владелец проекта должен хорошо знать рынок клиента. Для этого владельцу проекта часто приходится выполнять небольшую домашнюю работу и проводить исследования, но, как правило, эти усилия стоят того.<\/p>\r\n\r\n

Благодаря активному слушанию и знанию рынка владелец продукта может предвидеть потенциальные проблемы и изучить области, которые клиент может поначалу не заметить. Это, в свою очередь, приведет к более четкому представлению о конечной цели.<\/p>\r\n\r\n

Управление бэклогом<\/h2>\r\n\r\n

Одна из ключевых ценностей agile-методологии - "реагировать на изменения, а не следовать плану". В основе этого принципа лежит предположение о том, что проекты не являются стабильными, и какие бы предположения мы ни делали, не гарантировано, что они останутся неизменными.<\/p>\r\n\r\n

Таким образом, бэклог продукта - это живой организм, который растет и адаптируется по мере развития процесса разработки. Таким образом, его необходимо постоянно поддерживать и обновлять с учетом обратной связи с клиентом. Например, функциональность, имевшая низкий приоритет, может внезапно стать необходимой, когда клиент поймет, что ее отсутствие создает еще одну проблему в дальнейшем.<\/p>\r\n\r\n

Под обновлением я понимаю:<\/p>\r\n\r\n

\r\n\t
1. Создание новых пользовательских историй для добавления в бэклог<\/li>\r\n\t
2. Удаление историй пользователей, необходимость в которых отпала<\/li>\r\n\t
3. Реорганизация бэклога по мере изменения приоритетов<\/li>\r\n\t
4. Переписывание или изменение формулировок пользовательских историй по мере появления новой информации<\/li>\r\n<\/ol>\r\n\r\n

   Разумеется, владелец продукта должен убедиться, что все участники проекта имеют доступ к бэклогу, от клиентов до команды разработчиков, а также собрать обратную связь, чтобы убедиться, что приоритеты соответствуют видению бизнеса и ресурсам проекта.<\/p>\r\n\r\n

   Оценка результатов каждой итерации<\/h2>\r\n\r\n

   Итерации лежат в основе agile-методологий, это то, что лежит в основе девиза "откажись быстро, откажись сильно". При каждой итерации создается новый продукт, который нужно оценить: его сильные и слабые стороны - это данные, которые позволяют понять, что делать дальше.<\/p>\r\n\r\n

   Некоторые считают владельца продукта "внутренним клиентом компании" - группой глаз, которая смотрит и оценивает прогресс продукта глазами конечного пользователя. И если владелец продукта очень четко представляет себе эпопею своего клиента, то это действительно очень точная оценка.    <\/p>\r\n\r\n

   Владелец продукта может оценить текущую функциональность, производительность и даже эстетику проекта и решить, соответствует ли конечный результат общему видению. Исходя из его мнения, команда разработчиков может продолжить проект или вернуться к чертежной доске.<\/p>\r\n\r\n

   Именно по этой причине многие agile-команды считают своих клиентов владельцами продуктов: нет лучшего человека для оценки соответствия продукта видению, чем тот, кто первым его задумал.<\/p>\r\n\r\n

   Работа с владельцем продукта<\/h2>\r\n\r\n

   Понимание процесса, лежащего в основе роли владельца проекта, может значительно ускорить ранние этапы и ускорить выход на рынок. Когда вы нанимаете команду разработчиков ПО, использующих agile-фреймворк, постарайтесь сформулировать свой проект в терминах целей, которые могут быть достигнуты в краткосрочной перспективе. <\/p>\r\n\r\n

   Помните, что ваше видение - это как путешествие Одиссея на Итаку: <\/strong>оно должно быть быстрым и безопасным, но в итоге превратится в удивительную эпопею с поворотами сюжета и новыми проблемами на пути. В конце концов, благодаря этому авантюрному путешествию вы получите более качественный продукт.<\/p>\r\n