Блог российского сообщества менеджеров программных продуктов
Archive for the ‘Методологии разработки’ Category.
Понравилась картинка, демонстрирующая применение Agile подхода в управлении продуктами:
Взято отсюда: http://blogs.forrester.com/tom_grant/10-04-22-agile_poses_boss_level_pm_challenge
А придумано товарищами из Quantum Whisper – небольшой компании, которая делает тул для Product Manager’ов, работающих по Agile.
Перевод статьи из блога http://onproductmanagement.net (Saeed Khan).
Ссылка на статью:
http://onproductmanagement.net/2008/10/28/agilescrum-and-product-roadmaps/
——перевод——↓
При обсуждении Agile / Scrum часто возникает вопрос о создании и поддержке Roadmap в Agile среде. Замешательство возникает из-за того, что Scrum основан на коротких циклах разработки и постоянной приоритизации и реприоритизации функциональности в Product Backlog.
Итак, есть ли здесь противоречие, которое помешает созданию и поддержке Product Roadmap в Agile среде?
Ответ – абсолютно нет. Вкратце: Scrum – это методология разработки, а Roadmap – это инструмент бизнес-планирования и общения. Эти две вещи не зависимы друг от друга, и внедрение Scrum должно оказывать слабое влияние на поддержку Roadmap.
Не удовлетворены? Тогда предоставлю вам более развернутый ответ.
Прежде всего, определимся чем НЕ является Roadmap.
Это НЕ на 100% гарантированное и непоколебимое описание того, что мы безусловно будем делать в ближайших релизах нашего продукта.
Нет, Roadmap этим не является. Даже несмотря на то, что многие продавцы хотят, чтобы так было.
Кстати (небольшое отступление), есть небольшой трюк, позволяющий справиться с продавцами, которые хотят абсолютно фиксированную, определенную Roadmap на будущее.
Скажите им, что менеджмент продукта сделает такую Roadmap, когда команда продавцов подготовит абсолютно фиксированный и определенный объем продаж на 4 квартала. Посмотрите на их реакцию. Я сомневаюсь, что будут желающие.
Итак, что такое Product Roadmap?
Roadmap – это планируемое будущее, изложенное в общих чертах, то есть в виде планируемых релизов или перечислений высокоуровневых функций, примерно связанных с определенными временными промежутками (обычно по плановому календарю или финансовым кварталам) обычно с глубиной в 2-3 значительных релиза.
Для стартапов или компаний, работающих на быстро меняющихся или растущих рынках, эти 2-3 релиза могут покрывать только ближайшие 12 месяцев. Для более зрелых компаний, работающих на менее динамичных рынках, эти релизы могут покрывать несколько лет.
Я выделил слово «планируемый» выше. Планы – это просто планы. Это только наши представления о будущем, основанные на том, что мы знаем и во что верим сегодня. Это не обязательства. Большинство презентаций Roadmap, которые я видел, и практически все презентации, которые делали публичные компании, начинались с оговорки о том, что компания снимает с себя всякие обязательства относительно того, что указано в Roadmap.
И люди, слушающие эту презентацию Roadmap, принимали это как должное. Они понимают, что будущее неопределенно. Что они хотят услышать, так это заявление о намерениях, которые достижимы и заслуживают доверия, и которые могут помочь спланировать их собственное будущее.
Заметьте, что ничего из этого никак не связано с методологией разработки, которая используется для потенциальной реализации этой функциональности. И если кто-то спросит вас об этом, хороший ответ может выглядеть следующим образом:
Наши команды разработки используют гибридный подход к разработке, который позволят использовать лучшее из существующих Agile методологий, соединенное с наиболее предсказуемыми и устойчивыми элементами водопадной методологии. Это дает нам гибкость, которая позволяет нам адаптироваться к изменяющимся условиям рынка и потребностям пользователей, а также устойчивый фундамент в части циклов разработки, что позволяет нам создавать высококачественные релизы год от года.
Если нет никаких других обстоятельств, люди будут кивать головами и никогда больше не спросят о вашей методологии разработки.
Наконец, большинство Product Roadmap настолько лишены полезной информации, что они представляют собой просто перечень пунктов или список кодовых имен релизов на одном слайде. Это дает большое пространство для маневра презентатору (топ-менеджеру, менеджеру продукта, маркетологу продукта или кому-либо другому) для того, чтобы нарисовать светлое будущее, но ни к чему не быть обязанным.
Вот несколько РЕАЛЬНЫХ Roadmap, которые я нашел в Интернете. Какая из этих компаний использует Agile в разработке? Вы можете сказать? Это имеет значение?
Перевод статьи из блога tynerblain.com (Scott Sehlhorst).
Ссылка на статью:
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
——перевод——↓
User Stories – один из ключевых Agile артефактов, который позволяет командам разработчиков создавать наиболее важные возможности системы в первую очередь. Они отличаются от Use Cases по ряду значительных причин, но у них есть гораздо больше общего, чем вы можете подумать.
Майк Кон написал книгу User Stories Applied: For Agile Software Development. Это книга о том, как писать, оценивать и использовать User Stories. Если вы думаете о том, чтобы попробовать Agile в первый раз и не читали эту книгу, то вам необходимо это сделать. Автор очень подробно и с забавными историями рассказывает о том, как писать, управлять и использовать User Stories.
User Story – это пользовательско-ориентированное описание целей, которые люди смогут достичь, используя ваш продукт. User Stories применимы всегда, когда есть человек, взаимодействующий с интерфейсом продукта для достижения цели. Они применимы не только к программному обеспечению, хотя характер данной статьи предполагает это (в силу того, что я живу в мире программного обеспечения большую часть времени).
User Story пишется в формате
Вот и все. Ничего больше. Совершенно атомизированно, очень кратко и недвусмысленно. Откуда эта элегантная идея появилась?
User-Centered Design (UCD, пользовательско-ориентированный дизайн) – это подход к дизайну продуктов, который также может рассматриваться как философия. В колледже у меня была привычка говорить, что индустриальные дизайнеры проектируют вещи «снаружи внутрь» (from the outside in), а инженеры проектируют вещи «изнутри наружу» (from the inside out). Идеальные продукты – это такие продукты, в которых соединены форма (то, что снаружи) и функции (то, что внутри) в виде элегантного решения, в котором размывается разделяющая форму и функцию граница. Первые дизайнеры инженерных продуктов были инженерами, а первыми дизайнерами программного обеспечения были программисты – только они знали, что может быть сделано. Любой, кто использовал приложение с интерфейсом, созданным специалистам по базам данных, помнит, что оно из себя представляло. В итоге, кто-то успешно адаптировал образ мыслей проектирования продукта, основанный на том, что кто-то может использовать его, чтобы что-то сделать вместо того, чтобы смотреть на то, что оно умеет делать и пытаться понять, как его использовать. Это подчеркивает важность UCD, ну вы поняли идею.
Из подхода UCD следует много выводов, которые реально определяют то, как мы создаем продукты сегодня. Kessler и Sweitzer сфокусировались на понимании этих целей пользователей в книге Outside-In Software Development. Цели стейкхолдеров задают требования (возможно, это и есть требования). Но тяжело создавать практические планы из целей. Вам необходимо что-то, чтобы преодолеть этот разрыв.
User Story в Agile процессе преодолевает этот разрыв. В мире структурированных требований Вигерса, этот разрыв покрывается с помощью Use Cases.
Концептуально User Story преодолевает ту же пропасть, что и Use Case. User Story определяет, что люди должны сделать (например, более быстрое осуществление звонков) для того, чтобы достигнуть целей компании (например, снизить затраты на кол-центр), с определенным подходом к решению (написать программное обеспечение вместо того, чтобы использовать дешевых сотрудников в кол-центре).
Сейчас мы находимся в запутанной ситуации: у нас есть User Srories, Use Case Scenarios и по крайней мере три различных типа Use Cases – формальные и неформальные Use Cases и Use Case Briefs. В чем они отличаются друг от друга и в чем они схожи?
Use Cases, Use Case Scenarios и User Stories представляют собой документированное описание того, как продукт будет использован. Они могут быть отображены на одной прямой в зависимости от затрат, необходимых для их создания.
Use Case Scenarios несколько из другого рода. Как и User Story, Use Case Scenario описывает один путь в Use Case с несколькими путями. Но вы не можете (по крайней мере, я никогда не видел, чтобы кто-то делал это) создавать Use Case Scenario без предварительного создания формальных Use Cases. Этот артефакт сочетает слабость формальных Use Cases (высокая документированность) со слабостью User Stories (ограниченный контекст). Они могут быть очень удобны для разработки Test Cases, если ваша команда тестирования не очень хороша в написании Test Cases. Мы не будем рассматривать Use Case Scenarios в дальнейшей дискуссии.
Высокая документированность с соответствующими издержками несет определенное преимущество – возросшую детализированность.
Т.к. User Story описывает один путь в Use Case, при меньшей затратности она включает также и меньше деталей. Это нормально, т.к. Agile ставит коммуникацию выше исчерпывающей документации. Вы попадете в ситуацию неэффективности, когда объем обсуждений (особенно повторяющихся) станет обременительным. Необходимый объем обсуждений задается как функция от количества знаний о предметной области или контекстов, которые уже были выявлены командой разработчиков.
Это зависит от вашей аудитории. Формальные и неформальные Use Cases помимо того, что более затратны в реализации, также предоставляют больше контекста и позволяют вам описать более сложные варианты использования вашего продукта. Некоторые пользователи настолько сложны, что вам необходимо использовать Use Cases для их описания. Некоторые настолько просты, что что-либо сложнее User Story является бесполезной тратой усилий. Интерпретация того, что является сложным, а что простым, тем не менее, не является просто оценкой того, что пользователи хотят делать, она также зависит от уровня владения предметной областью вашей командой разработчиков.
Некоторые команды просто не готовы к восприятию User Stories и Use Case Briefs. Вы должны писать ваши требования для читателей, поэтому вы должны знать, когда у людей возникают проблемы с реализацией решений, основанных на User Stories или Use Case Briefs и предоставить им больше структуры и формализованности. Вы должны адаптироваться к реалиям вашей текущей ситуации и опыта вашей команды.
Вы можете заменить слова «компетентность читателя в предметной области» (Reader Domain Expertise) на слова «уровень доверия к команде», если хотите, и диаграмма будет выглядеть примерно так же. Это другая концепция, которая критична для того, чтобы команда работала эффективно: уровень доверия приравнивается к уровню делегирования.
Если вы доверяете своей команде создать решение, которое будет соответствовать User Story, делегируйте этот «следующий уровень детализации» им. Если вы не доверяете им, тогда не стоит этого делать. Но вы должны. Одно из преимуществ Agile состоит в том, что ваша команда быстро предоставит вам решение и вы сможете дать им обратную связь. Если они не предоставят вам решение, которое было бы отражением потребностей пользователей, предоставьте им обратную связь и они изменят его. Agile процесс фактически основан на этой возможности сохранять эффектинвость «немногословных» артефактов. Кто-то из команды в общих чертах опишет, как будет выглядеть решение и получит обратную связь до начала реализации. Чем больше будет такого взаимодействия, тем более эффективной будет легковесная документация.
Не надейтесь на банальное описание User Stories и Use Cases. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.
Перевод статьи из блога requirements.seilevel.com/blog.
Ссылка на статью:
http://requirements.seilevel.com/blog/2009/06/what-does-requirements-sign-off-mean-in.html
——перевод——↓
Я недавно работал с клиентом над проектом, в котором использовался Agile. Организация находилась в процессе перевода всех проектов на Agile, поэтому, естественно, у них оставалось множество не-Agile частей в их методологии. Мы находились в процессе определения требований и должен был начаться первый спринт разработки, когда руководитель проекта сказала мне, что у нас есть конечная дата для определения требований.
Подождите минутку! Придержите своих лошадей! Требования определены? В Agile?
Я напомнил ей о используемой нами методологии в данном проекте… и то, что она просит определиться с требованиями в методологии, в которой это не имеет значения… и пользователи имеют право приоритизировать любые функции в бэклоге в любое время. Поэтому, если они забудут о каких-либо функциях в процессе выявления функций, им необходимо будет лишь определиться, куда их поместить в приоритизированный бэклог и понимать, что другая функция при этом теряет приоритет. Она рассмеялась и сказала, что она прекрасно это понимает, но корпоративный процесс этого требует! Поэтому мы начали дискутировать на тему, что для нас означает «требования определены».
В итоге, мы пришли, на мой взгляд, к достаточно интересному решению. У нас было множество требований в формате user stories и других моделей, таких как «диаграммы процессов», «диаграммы состояний» и т.д. Также мы тесно работали с пользователями для выявления требований. Итак, мы попросили подтвердить, что к данному моменту времени не пропущено никаких серьезных требований, о которых они знают, и нет никаких значительных вопросов, которые не были сформулированы, о которых они знают. Суть в том, что они видели требования, участвуют в процессе и разработка прототипа не отклониться слишком далеко от необходимого. Но по-прежнему они имеют право добавить что-то новое после того, как увидят систему, подумают об этом или что-то в этом роде.
Что мне действительно нравится в этом подходе, так это то, что никто не загнан в угол тем, что их попросили подписать массивный документ с требованиями, который они едва понимают, или они, подписывая документ, подтверждают, что все прекрасно получилось с первого раза. Поэтому я думаю, что дух гибких методологий более или менее сохранился в нашей версии утверждения требований.
Что такое OpenUP
OpenUP – облегченная версия RUP, основанная на идеологии гибких методологий разработки ПО. OpenUP разрабатывается в рамках интересного проекта Eclipse Process Framework. См. сайт проекта и wiki, в которой представлены все проекты.
Для знакомства с OpenUP почитайте статью Пера Кролла на русском языке, там все хорошо описано.
Полное описание OpenUP см. в wiki здесь.
Существует и русскоязычная версия, но переводится вариант OpenUP для маленьких команд - OpenUP/Basic (совсем облегченный процесс). Перевод осуществляется на принципах wiki, так что каждый может внести свою лепту. Я участвую.
Шаблоны Vision в RUP и OpenUP
С точки зрения управления продуктами нас в этих методологиях интересует, прежде всего, такой документ как Vision. См.:
Сравните 14 страниц первого шаблона и одну страницу второго. Действительно облегченная версия 
Перевод заметки по созданию Agile roadmap от консалтинговой компании Enthiosys.
Оригинал здесь:
http://www.enthiosys.com/problems-we-solve/agile-roadmaps/
Текст в значительной степени рекламный, но это не мешает ему быть интересным.
——перевод——↓
Roadmap продукта – критический элемент любой продуктовой стратегии и основной инструмент каждого менеджера продуктов. Roadmap ликвидирует разрыв между долгосрочными стратегическими планами и планированием релизов и итераций. Содержательные, согласованные, актуальные roadmap удерживают продуктовые команды от блужданий и позволяют достичь целей компании гораздо быстрее.
Agile roadmap - фундамент гибкости бизнеса. Они предоставляют основу для принятия решения о том, когда планы должны быть изменены, как повлияют изменения на связанные продукты / релизы / цели и служат инструментом взаимодействия при написании планов.
Осмысление roadmap
Менеджеры продуктов не делают успешных продуктов, реагируя на каждый выпад конкурентов, жалобу пользователей или предложение маркетологов / разработчиков. После выявления фундаментальных потребностей потребителей, менеджеры продуктов должны определить коммерческую сторону (рынок, продажи, маркетинговые исследования и т.д.) и техническую сторону (разработка, поддержка и т.д.) мероприятия и отразить в одном документе. Под этим мы понимаем совместное и глубокое понимание сегментов рынка, функций и преимуществ продукта, своевременность вывода на рынок функций в различные сегменты рынка, маркетинговые мероприятия и архитектуру, которая позволят развивать продукт в соответствии с планом. Лучшие roadmap создаются кросс-функциональными командами, которые провели хотя бы один день в непрерывном взаимодействии.
Мы называем этот документ agile roadmap продукта. В нем рассматриваются четыре ключевые условия успешности программного продукта в его коммерческой жизни:
Хорошие roadmap предоставляют также основу для сценарного планирования и создания «roadmap of roadmaps».
Модель взаимодействия и результаты
Создание roadmap – процесс, требующей серьезного взаимодействия. В типовой процесс вовлечены основные заинтересованные лица (менеджеры продуктов, разработчики и архитекторы, маркетологи, консультанты) для создания начальное версии roadmap продукта, а в дальнейшем происходят ежеквартальные собрания для пересмотра и обновления roadmap. Многие клиенты Enthiosys расширили этот процесс до создания «roadmap of roadmaps» для управления портфелем продуктов.
Мы определили пятишаговый процесс для каждого совещания по roadmap:
<…> пользуйтесь нашими услугами <…>
В продолжение темы фреймворка управления продуктами в Agile.
Начало см. http://swpm.ru/2009/06/agile-product-management-framework/
Derek Morrison сделал презентацию его фрейморка для управления продуктами в Agile и представил ее для всеобщего обозрения в своем блоге All About Product Management.
http://allaboutproductmanagement.blogspot.com/2009/07/presentation-on-agile-pm-framework.html
Я, в свою очередь, сделал перевод.
Внимание! В перевод могут быть есть косяки, я не везде на 100% понял, что имелось в виду. Присылайте ваши замечания на bredyuk@gmail.com.
Перевод статьи из блога All About Product Management.
Ссылка на статью:
http://allaboutproductmanagement.blogspot.com/2008/02/how-product-managers-can-estimate.html
——перевод——↓
Недавно мы закончили scrum спринт. В рамках обзора (review) этого спринта команда разработчиков провела демонстрацию владельцам бизнеса новой функциональности и исправленных багов. На ретроспективе спринта и последующей дискуссии было замечено, что на демонстрации было отведено равное время для каждой из user story. Однако в некоторых user story были подправлены небольшие баги, в то время как реализация других user story привела к значительному улучшению главной страницы сайта. Вопрос заключается в том, как команда разработчиков может узнать, как много времени тратить на демонстрацию той или иной user story?
Один из способов – демонстрировать user story в порядке приоритетов. Однако это даст лишь порядок демонстрации и не даст никакого указания на то, сколько времени необходимо тратить на демонстрацию. Я думаю, что один из способов – представить оценку business value для каждой user story (см. Measuring business value with metrics). Команда разработчиков достаточно давно использует числа Фибоначчи (1, 2, 3, 5, 8, 13, 21, …) для оценки сложности user story и владелец продукта (product owner) и стейкхолдеры привыкли наблюдать, как разработчики используют poker cards для голосования по поводу сложности реализации пунктов из бэклога, а потом участники, которые дали самую маленькую и самую большую оценку, объясняют, почему они проголосовали именно так. Потом участники команды голосуют еще раз, основываясь на новой информации.
Шагом вперед будет использование такой же процедуры для стейкхолдеров. Business value будет зависеть от типа продукта, который вы разрабатываете. Для сайта сообщества это может быть: SEO; улучшение юзабилити; спонсорство, приносящее реальных доход; улучшение админской части, которое повышает эффективность работы; автоматизация процессов администрирования…
Когда бизнес-Фибоначи будут применяться, тем, кто проводит демонстрацию новой функциональности и исправленных багов, будет легко определить, сколько потратить времени на демонстрацию той или иной user story, таким образом обеспечивается релевантность обзора (review) и заинтересованность стейкхолдеров.
Однако существует и гораздо более значительная причина для использования busineess value для каждого из элементов бэклога: это не только помогает с определением приоритетов, но также может помочь с определением ROI каждого спринта и определять business velocity** тем же образом, как Scrum Master определяет technical velocity для команды или для отдельного человека. Оценка business velocity (см. Understanding your Velocity) будет также давать менеджеру продукта или владельцу продукта высокоуровневый индикатор того, какое количество business value команда может сделать в каждом roadmap.
* business value – ценность для бизнеса
** business velocity – скорость, с которой решаются задачи бизнеса
Так как тема Agile в России сейчас достаточно популярна, перевожу статью из блога All About Product Managment, опубликованную 01 марта 2009 года.
Ссылка на статью: http://allaboutproductmanagement.blogspot.com/2009/03/agile-product-management-framework.html
——перевод——↓
Сейчас существует много хороших фреймворков управления продуктом, однако, я подумал, что сделаю фреймворк для управления продуктом в Agile, который будет достаточно обширным, чтобы применяться для всех команд управления продуктом, которые используют Scrum. С каждым процессом связан документ, который необходим для коммуникации различных заинтересованных лиц. Первым процессом во фреймворке является:
Недавно я делал презентацию по roadmaps на нашем ежемесячном форуме по управлению продуктами и отметил следующие моменты относительно продуктовых roadmaps:
Road map, согласно Marty Cagan из SVPG*** (Статья – Продуктовая стратегия в мире Agile):
«Road map продукта – это то, что описывает ваш план относительного того, как вы доберетесь из того состояния, в котором находитесь сегодня, до того видения, которое описано в вашей продуктовой стратегии.» Marty продолжает в данной статье и говорит, что «Продуктовая стратегия анализирует выозможности на рынке и существующие технологии и описывает, чем продукт может быть». И далее: «Road map продукта описывает последовательность релизов продукта, которые делают продуктовую стратегию реальной». Продуктовая стратегия способствует достижению бизнес-стратегии компании.
В соответствии с вышесказанным, менеджер продукта должен иметь четкое понимание стратегии бизнеса, в котором он работает. Вовлеченность в бизнес-стратегию будет менятся от компании к компании, но всегда менеджер продукта должен иметь ясное представление бизнеса, в котором он работает.
Абсолютно необходимо, чтобы менеджеры продуктов постоянно общались между собой, а roadmap могут быть использованы как хороший инструмент коммуникации с:
- разработчиками, тестировщиками и другими техническими специалистами
- линейными менеджерами и руководителями департаментов
- директорами и топ-менеджментом
Совместная работа над roadmap говорит нам о том, что существует четкое видение развития продукта и, таким образом, имеет большое значение для укрепления доверия на всех уровнях.
UPD. См. презентацию фреймворка здесь http://swpm.ru/2009/07/agile-product-managemen-framework-presentation/
* Слово Framework переводить не стал
** Аналогично. Roadmap дословно – дорожная карта. По смыслу – план развития продукта. см. http://swpm.ru/2009/07/roadmap-templates/
*** Silicon Valley Product Group (http://svpg.com)
 |
 |
 |
