Чем занимается бизнес аналитик в Agile проекте?
| May 2, 2012 | Posted by admin under Практики, Статьи |
Автор: Kent J. McDonald
http://www.b2ttraining.com/?download-id=36
Популярность Agile растет, и бизнес аналитики хотят понять, как их роль отображается в новом подходе и насколько она изменилась по сравнению со знакомым процессом разработки. Часто можно услышать “нигде, где я читал об agile не упоминается бизнес аналитик!”
Хотя роль бизнес аналитика редко упоминается в описаниях agile, это не означает, что бизнес анализ не происходит. Agile фокусируется на поставке ценности заказчику, для этого вся команда должна совместно выполнять бизнес анализ на регулярной основе. Эта и другие характеристики agile меняют характер работы бизнес аналитика в проекте.
Одно из таких изменений, которые вносит agile, это процесс, не предусматривающий никакой документации, в том числе артефакты требований. Это не означает, что документы не делаются. Скорее это означает, что бизнес аналитик взаимодействует с остальными членами команды, чтобы решить, что нужно для наиболее эффективной поставки решения, включая то, сколько документации нужно. Сравните это с детальными методологиями и стандартами для управляемых планом (plandriven) проектов, которые используются крупными организациями, и требуют от бизнес аналитика создания обширных документов требований. Это приводит к тому, что бизнес аналитики, особенно менее опытные, документируют одни и те же требования, используя разные модели и текстовую форму, хотя достаточна более краткая запись требований.
Другое изменение, связанное с agile подходами , это короткие циклы поставки, которые называются итерациями или спринтами. Итерация включает всю работу, от требований и до готовой, протестированной фичи, которую можно поставить в рабочее окружение. Использование итераций позволяет команде анализировать прошлые действия и улучшать процесс разработки. Короткий период итерации (от недели до месяца) означает ,что объем задач по итерации (scope) намного меньше, чем в традиционных проектах, поэтому бизнес аналитику нужно сфокусироваться только на той части всей системы, которая поставляется в текущей итерации. Бизнес аналитики взаимодействуют с остальными членами команды в начале проекта – чтобы определить какой анализ нужен для создания большой картины; а также в каждой итерации – чтобы достичь общего понимания, не создавая обширный набор документов. Третье изменение agile – это роль product owner-а. Product owner принимает решения и представляет в проекте потребности бизнеса. Чтобы быть действительно эффективным, product owner должен разбираться в ключевых методах бизнес анализа, хотя на деле это редко так. Это дает бизнес аналитику прекрасную возможность содействовать product owner-у (см. ниже). Наконец, все члены команды имеют возможность проводить анализ, поэтому бизнес аналитик помогает остальным членам команды по методам анализа и в том, с какими заинтересованными лицами контактировать. За счет участия всех членов команды в сборе требований предотвращается состояние отчуждения, которое бывает в других подходах, и предотвращается ситуация, когда аналитики становятся узким местом общего прогресса команды.
Ниже обсуждаются активности бизнес аналитика по сопровождению product owner-а и команды, а также другие вопросы, связанные с работой аналитика в проекте.
Что же в действительности представляет собой agile?
Определений agile столько, сколько людей, которые дают эти определения. В этой статье, agile определяется как сотрудничество заинтересованных лиц (stakeholders) для поставки ценности заказчику с частыми инкрементами, при постоянном размышлении (reflection) и адаптации. Это определение фокусируется на характеристиках, присущих любому agile окружению, а именно:
- Сотрудничество – как люди работают вместе, включая команду, занимающуюся разработкой, и заинтересованных лиц (stakeholders)
- Поставка ценности – цель прилагаемых усилий – это поставка ценности заказчикам, что бы это ни было: программное обеспечение, более эффективные процессы или новые продукты.
- Частые инкременты – команда поставляет ценность каждые несколько дней, недель или месяцев, а не единожды, в конце проекта.
- Постоянное размышление и адаптация – проектная команда размышляет над подходами и проектом на регулярной основе, и настраивает свою работу в соответствии со сделанными выводами.
Agile подходы позволяют командам сфокусироваться на поставке нужной бизнесу ценности в кратчайшие сроки. Команды, использующие agile подходы, самоорганизуются , чтобы быстро и постоянно проверять действительно работающее ПО в течение итераций, длящихся от одной недели до одного месяца.
В конце каждой итерации все видят работающее ПО и решают, выпускать его в реальное окружение или продолжить улучшение в следующей итерации.
Наибольшее изменение, касающееся итераций для аналитика – это отсутствие фазы анализа. Вместо того, чтобы выполнить весь сбор требований в начале проекта, бизнес анализ происходит в течение всего проекта. Сначала появляется высокоуровневая картинка, определяющая рамки проекта. Затем по мере того, как требуется поставка новых фич, происходит детализация требований по ним.
Суть в том, чтобы провести бизнес анализ, достаточный для понимания проблемы и аспектов поставляемого решения, и все же поддерживать продвижение проекта вперед. Другой аспект agile подходов, влияющий на работу бизнес аналитиков, это небольшое количество документов.
Agile подходы базируются на предпосылке, что простые правила создают сложное поведение, поэтому команде обеспечивается минималистичный фреймворк для организации работы, а остальное зависит от самодисциплины команды. Поэтому, хотя agile подходы не требуют документации,они и не запрещают ее. Скорее, речь идет о создании подходящего множества документов. Когда команда решает вопрос о документах в agile проекте, бизнес аналитики могут посоветовать ответить на такие вопросы для решения этой задачи:
- Это что-то, что требует заинтересованное лицо (stakeholder) ?
- Это что-то нужное команде для эффективного выполнения работы?
Поскольку аналитикам не надо фокусироваться на написании множества документов требований для команды разработчиков, они могут больше обратить внимание на реальный анализ – рассмотрели ли мы все сценарии, которые могут произойти? Поддерживаем ли мы наше решение в целостном состоянии? Знаем ли мы о тех непредвиденных обстоятельствах, которые вызовут наши изменения?
И последний аспект agile, представляющий отход от традиционных подходов – это акцент на командной работе, а не на жесткой специализации. Наиболее заметно для бизнес аналитиков это выражается в том, что всех членов команды поощряют напрямую общаться с заинтересованными лицами, чтобы понять их потребности. Поначалу бизнес аналитики могут рассматривать это как угрозу, но потом они понимают, что у них появляется возможность проводить коучинг среди членов своей команды, помогать им быть более эффективными в этом. Они тоже могут расширить свои навыки, помогая другим членам команды с их задачами. Agile команды не всегда стартуют полностью сплоченными. По началу команды часто попадают в ловушку, когда разработчики только разрабатывают, тестировщики только тестируют и , конечно, аналитики только проводят анализ. Бизнес аналитики помогают команде двигаться в сторону сплочения и взаимодействия, исполняя сразу две роли, что делает их по-настоящему ценными членами команды:
- Бизнес советник (Business Advisor) (для поддержки Product Owner-а)
- Бизнес коуч (Business Coach) (бизнес аналитик действует как эксперт по анализу в команде)
Характер изменений в работе бизнес аналитиков касается исключительно взаимодействия с другими членами команды, product owner-ом и заинтересованными лицами. Теперь они уже не отвечают в одиночку за требования. Они гораздо больше взаимодействуют – помогают членам своей команды улучшать навыки анализа и фокусируются на более важных стратегических активностях, общаясь с product owner-ом.
Роли в Agile
В agile подходах фокус делается на командную работу и взаимодействие, поэтому роли там более общие по своей природе, чем те, что выделяют в традиционных подходах. В agile окружении не описаны задачи, специфичные для бизнес аналитика, и поэтому практикующему бизнес аналитику нужно знать, какие методики бизнес анализа нужно применять в таких проектах. Вот четыре основные роли, присутствующие в agile проектах.
Product Owner основной специалист, принимающий решения по проекту. Эта роль отвечает за видение продукта ( product vision), приоритезацию фич, в соответствии с бизнес ценностью, и за ответы на вопросы команды.
Scrum Master отвечает за процесс. Эта роль отвечает за окружение, подходящее для достижения успеха, за устранение препятствий и за получение тесного сотрудничества между всеми ролями.
Team – это группа из 5-9 человек, выделенных для проекта на полное время, они отвечают за самоорганизацию и поставку ценности заказчику в каждой итерации. Команда определяет, как разрабатывать продукт и как распределить работы в условиях выделенного на проект времени.
Stakeholder (заинтересованное лицо) – это любой, кто может повлиять на проект и внести вклад в определение бизнес целей продукта. Заинтересованные лица, активно вовлеченные в проект, это часть команды. Заинтересованные лица, которые не вовлечены активно в проект, могут взаимодействовать с product owner-ом, участвуя таким образом в пополнении баклога (backlog) продукта.
Бизнес аналитик как бизнес советник
В большинстве agile подходов выделяется специфическая роль, представляющая лицо, принимающее окончательные бизнес решения, такая как product owner. Product owner определяет видение продукта, отвечает за понимание и представление нужд бизнеса и пользователей. Product owner определяет, какие требования более важны перед началом каждой итерации, и как инкрементально поставлять ценность, чтобы удовлетворить нужды заинтересованных лиц. У бизнес аналитика не всегда есть власть для принятия решений, необходимая эффективному product owner-у. Но бизнес аналитики могут стать незаменимыми, дополняя product owner-а при нехватке времени или навыков бизнес анализа. Бизнес аналитик поддерживает product owner-а, помогая ему анализировать бизнес область (business domain), пополняя и приводя в порядок баклог.
Анализ бизнес области
Бизнес аналитик помогает команде и product owner-у понять и описать бизнес область и проблемы, которые нужно решить путем дискуссий по таким вопросам:
- Какие бизнес процессы нужно пересмотреть, создать или исключить?
- Какую информацию мы хотим знать и отслеживать по разным сущностям?
- Какие заинтересованные лица (такие как заказчики, поставщики. вендоры) и системы вовлечены?
- Какие правила и политики определяют бизнес поведение и решения?
Важно добиться того, чтобы все понимали бизнес область. Но с другой стороны это может занять много времени, особенно учитывая то, что по мере прогресса проекта меняются модели и команда получает все новые знания. Чтобы не упускать ничего из виду и поддерживать анализ в актуальном состоянии, бизнес аналитики определяют время для анализа, приоритезируют анализируемые темы и не оставляют без внимания все дискуссии в команде.
Бизнес аналитик помогает команде определить, насколько полезны модели требований вне жизни проекта. Для принятия таких решений нужно учитывать усилия, требуемые для поддержки модели в актуальном состоянии и ценность модели после проекта. Если модель нужна только для краткого обсуждения. чтобы понять что-то, достаточно сохранить картинку с доски в виде цифрового изображения. Если диаграмма используется в течение всего проекта или предполагается, что она будет нужна после окончания проекта, команда может решить создать модель с помощью средства моделирования. Это решение касается вопроса создания подходящего количества документов.
Наполнение баклога продукта
Наполнение баклога продукта – это определение списка пользовательских историй, которые представляют весь объем проекта. Пользовательская история (user story) кратко описывает функциональность или фичу, ценную для пользователя или заказчика системы или программного решения. До конца этой статьи пользовательские истории и их более крупные вариант, эпики (epic) [прим. перев. – см. на devprom.ru, Требования в Agile: что такое Epic и в чем отличие от User Story?] называются историями, если не указано другое. Бизнес аналитик помогает product owner-у выделять истории из моделей, созданных во время анализа бизнес области. Это аналогично определению бизнес требований и границ проекта (scope).
Дополнительные истории возникают с развитием проекта и выделяются из моделей, созданных или обновленных во время общения с заинтересованными лицами в течение проекта. Бизнес аналитики помогают product owner-у и заинтересованным лицам, и команда создает истории как напоминание о том, что нужно поставить функциональность из моделей или обсуждений. Истории могут возникать из таких моделей требований, как модели данных, диаграммы потоков, use case-ы, бизнес правила и диаграммы пользовательских интерфейсов.
Истории возникают также из разговоров с заинтересованными лицами. Эти обсуждения варьируются от неформальных бесед до запланированных и подготовленных совещаний, специально с целью определения списка историй. Неформальные обсуждения приводят к появлению в проекте новых историй, это большое преимущество проектов в agile окружении. Использование баклога продукта – список того, что нужно поставить за проект – позволяет команде отмечать возникающие по ходу новые требования, не отвлекаясь от текущей работы в ходе итерации.
Требования помещаются в баклог для будущего анализа и изучения product owner-ом. С новыми историями также сталкиваются во время работы над итерацией и в конце демонстраций по итерации. Новая функциональность вдохновляет заинтересованных лиц на рассмотрение дополнительных фич или на размышление над другими сценариями, где система должна вести себя по-другому.
Чистка баклога продукта
Чистка баклога продукта – это поддержка баклога, так чтобы он оставался живым инструментом для команды и product owner-а, и не был бы тяжким бременем. Бизнес аналитики помогают product owner-у чистить баклог продукта, принимая во внимание цели, приоритезируя и организуя истории, разбивая эпики на пользовательские истории и заботясь о полноте описания решения.
Зная, как история поддерживает цель проекта, и зная организационную стратегию, бизнес аналитик может помочь product owner-у решить, включать ли историю в баклог, и какой подход использовать при поставке каждой конкретной истории. Модель Purpose Based Alignment помогает команде понять организационную стратегию, понять, какие активности выделяются, и в соответствии с этим принимать решения проектного уровня. Размещение историй в подходящем блоке помогает команде определить, как:
- Поставлять истории, которые поддерживают отличающиеся активности уникально.
- Поставлять истории, которые поддерживают похожие активности, наиболее простым способом.
- Работать с другой организацией для поставки историй, которые поддерживают партнерские активности.
- Решать, поставлять ли истории, которые поддерживают “непонятно кому нужные” активности.
Бизнес аналитики могут помочь product owner-у упорядочить баклог , обеспечивая информацию по оценке разных пунктов баклога со стороны заинтересованных лиц. В моделях не указываются приоритеты, но есть много других методов для сбора информации о приоритетах у заинтересованных лиц. Две из них – это value point-ы и покупка фич (buying features). В подходе с value point-ами заинтересованных лиц просят собраться вместе и определить относительные оценки историй, по сравнению с другими историями, подобно тому как это делается в planning poker-е. В методе покупки фич заинтересованные лица определяют, как много фичи из баклога значат для них, когда тратят некоторое количество “фича-долларов” (“feature dollars”) на некоторые или на все пункты из баклога. Количество фича-долларов, назначенных каждому пункту, определяет важность этого требования. Приоритезация вносит некоторый порядок в баклог, но часто командам нужен другой порядок упорядочивания требований. Бизнес аналитики помогают product owner-у и команде поддерживать баклог так, чтобы с ним было легко работать, они используют множество методов, таких как группировка историй по темам и организация историй в релизы и итерации.
Для команды, работающей с большим баклогом над сложным проектом, группировка историй по темам – это прекрасный способ добавления некоторой иерархии в баклог. Истории, покрывающие разные аспекты одной потребности, и истории, которые нужно сгруппировать, чтобы поставить завершенную ценность для заказчика, – это хорошие кандидаты для темы.
Кроме того, команды организуют баклог по релизам и итерациям, чтобы определить, когда нужно поставить истории. От текущего момента в жизненном цикле проекта зависит, когда точно истории будут назначены на релиз или итерацию.
Во время планирования проекта (roadmap planning) бизнес аналитики помогают product owner-ам и заинтересованным лицам упорядочивать истории в баклоге по релизам, учитывая приоритетность поставки наиболее ценных для стейкхолдеров историй. Заинтересованные лица получают первоначальное представление о том, когда ожидать поставку той или иной функциональности.
Во время планирования конкретного релиза бизнес аналитики работают с product owner-ом и командой над декомпозицией эпиков в данном релизе на пользовательские истории и определяют итерацию, в которой каждая история должна быть поставлена. По мере работы над итерациями план релиза подвергается изменениям. План релиза помогает команде определить, нужна ли им внешняя помощь, а для сложных историй возможно потребуется анализ на итерации, предшествующей поставке.
При планировании итерации команда берет на себя обязательства поставить набор историй в данной итерации, и product owner вносит необходимые изменения в план релиза.
Бизнес аналитики часто работают с командой, чтобы определить правильный размер историй для поставки в итерации. Размер историй отличается, в зависимости от того, насколько они близки к поставке. Эпики слишком велики для поставки в одной итерации, они существуют как напоминание о функциональности, которую еще нужно будет в дальнейшем определить, когда приблизится время реализации. Из этого дальнейшего определения создаются пользовательские истории, они достаточно небольшие, и их можно сделать за одну итерацию. Пользовательские истории определяют для поставки в ближайшем будущем. Есть много разные способов разбить историю на части. Два наиболее часто встречающихся подхода – это разбивка по границам операций (создание, чтение, модификация и удаление) или по границам данных (различные части информации, ассоциированные с сущностью). И наконец, бизнес аналитики помогают product owner-ам удостовериться, что часть решения, поставляемого в текущей итерации и релизе полностью выяснена. Вот некоторые вопросы, которые помогут удостовериться в полноте описания решения:
- Знаем ли мы, у каких пользователей одна цель?
- Есть ли пользователи, которые не должны использовать разработанную функциональность?
- Есть ли сценарии, которые мы должны взять во внимание, чтобы обеспечить ожидаемый результат?
- Достаточно ли у нас информации, чтобы достичь цель, поставленную в пользовательских историях?
- Достаточно ли у нас информации для обеспечения определенных правил?
- Какие непредвиденные последствия могут произойти, если мы поставим эти пользовательские истории?
- Есть ли у нас полное понимание процесса, который будет использовать эту функциональность?
Жизненный цикл проекта в Agile
Итеративный характер проектов в agile окружении меняет форму жизненного цикла, а не выполняемые активности.
Организации, работающие в agile окружении делают планы на множестве уровней, с разной степенью детальизации.Чем ближе срок выполнения плана, тем более детальным он является.
В Видении продукта product owner описывает, как должна выглядеть организация или продукт в будущем, чтобы реализовать стратегию организации. Бизнес аналитики поддерживают процесс планирования продукта, работая с product owner-ом по определению видения продукта и цели проекта. Во время планирования проекта бизнес аналитик вместе с остальной командой и заинтересованными лицами помогает product owner-у определить на высоком уровне, что нужно поставить, наполняя баклог эпиками и пользовательскими историями (историями). Во время планирования релиза бизнес аналитик вместе с остальной командой и заинтересованными лицами помогает product owner-у приоритезировать истории текущего релиза и определять, в каких итерациях их поставить. Во время планирования итерации команда берет обязательство поставить множество историй и определяет соответствующий набор задач, необходимых для поставки этих историй. Этот набор задач определяет баклог спринта.Бизнес аналитик полностью участвует в этой активности как член команды, и может продвигать эту активность.
Навыки бизнес аналитика жизненно важны для определения полноты баклога продукта. В результате бизнес аналитики либо сами проводят этот анализ или помогают другим членам команды проводить его. Вовлечение всей команды увеличивает шансы на достижение полного понимания проблемы и описание решения.
Бизнес аналитик как бизнес коуч
Во время работы над итерацией бизнес аналитик взаимодействует с командой , выступая как специалист по анализу. Вот некоторые из активностей, которые бизнес аналитик делает сам или в которых он помогает команде во время итерации: обеспечение взаимодействия, создание примеров, передача знаний.
Обеспечение взаимодействия
Взаимодействие внутри команды и между командой и заинтересованными лицами жизненно важно для успеха проекта. Бизнес аналитики поддерживают взаимодействие, помогая работать с заинтересованными лицами и выступая в качестве языкового коуча. У бизнес аналитиков есть самое ясное представление о заинтересованных лицах, вовлеченных в проект, поэтому они могут подсказать членам команды, с какими заинтересованными лицами поговорить для получения той или иной информации.
Когда нужные заинтересованные лица определены, бизнес аналитики обращаются в сторону перевода “бизнес речи” в “техническую речь” и наоборот, помогая общаться членом команды с разным опытом работы, а также помогая общению заинтересованных лиц с командой. Переводя сообщения людей, говорящих с разных позиций, они помогают общению между ними.
Создание примеров
В agile окружении команды используют примеры, чтобы точно выражать бизнес намерения, добавлять больше деталей в истории и подтверждать, что эти истории поставлены правильно. Примеры – это хороший метод запоминания информации, которую обсудили во время разговора, а также прекрасный способ передачи этой информации тем членам команды, которые будут поставлять пользовательскую историю, а также, чтобы подтвердить то, что пользовательская история поставлена правильно.
Одни и те же примеры используются , чтобы обсудить требования с командой разработчиков, и для описания тестов, чтобы проверить правильное понимание ожидаемого поведения. Все примеры реальные – в том смысле, что все они возможны, даже если некоторые из них маловероятны.
Примеры может создавать любой член команды. Если команда посчитает, что необходим анализ на итерации, предшествующей реализации пользовательских историй, то бизнес аналитики могут делать основную часть этой работы.
Примеры могут иметь разную форму. При описании применения бизнес правил подходящая форма примеров – таблица. Обсуждение примеров в табличной форме помогает понять содержание, найти пробелы и несоответствия. При описании процесса более подходящей является форма “Учитывая – Когда – Тогда” (Given, When, Then).
Учитывая <Предусловие>
Когда <Действие>
Тогда <Ожидается>
Примеры также создаются, чтобы рассмотреть нормальное использование, анормальное, но приемлемое использование и анормальное и неприемлемое использование, для чтобы идентифицировать разные сценарии. Вот несколько хороших вопросов, которые стоит задать команде, создавая примеры:
- Как нам проверить, что эта пользовательская история реализована полностью и правильно?
- Представим, что мы уже поставили это – как нам оттестировать это?
- Есть ли еще сценарии, связанные с этой пользовательской историей, для которых мы не определили поведение системы?
Передача знаний
Бизнес аналитик и product owner лучше всего представляют себе большую картинку проекта, и место, которое он занимает в организационной стратегии. Во время работы по итерации бизнес аналитики проводят значительное количество времени , передавая другим членам команды информацию, полученную когда они действовали как бизнес советники. Лучший способ передачи знаний – это вовлечение членов команды в анализ бизнес области и в наполнение и чистку баклога. Вся команда не может быть вовлечена в каждую из этих активностей, поэтому требуется некоторая ретрансляция этой информации. Эту информацию можно передавать, вывешивая ее на информационных источниках или в общей области, доступной всей команде.
Хороший член команды
У бизнес аналитиков есть возможность помочь членам своей команды убрать узкие места. Это укрепляет отношения с другими членами команды и дает бизнес аналитику возможность расширить свои знания и изучить новые навыки, выполняя задания, которые обычно делают другие роли, например тестирование, дизайн пользовательского интерфейса, подготовка тестовых данных, обучение и поставка.
Заключение
Agile подходы не дают описание многих ролей, потому что акцент на взаимодействие делает многие роли ненужными. Недостаток описанных ролей дает бизнес аналитику прекрасную возможность расширить свои горизонты, с бизнес и с технической стороны. Бизнес аналитики тесно сотрудничают с product owner-ом , чтобы доставить наибольшую ценность заинтересованным лицам. В этом процессе они расширяют свои знания по бизнес области и получают новый опыт решения проблем бизнеса. Кроме того, бизнес аналитики тесно сотрудничают с членами своей команды, улучшая их аналитические навыки и получая новые навыки, например тестирования или даже кодирования. Эти возможности заставляют аналитиков смотреть вне рамок роли, вместе с членами своей команды поставлять ценность заказчикам, и улучшать их ценность в организации.
Ключевые бизнес аналитические навыки в Agile проектах
Высокопродуктивный бизнес аналитический персонал команды повышает вероятность того, что результирующий продукт действительно будет отвечать потребностям бизнеса и хорошо подойдет текущему бизнес окружению.Если нет опытного бизнес аналитика, хотя бы один член команды должен пройти обучение по бизнес анализу и иметь опыт анализа.Ключевые бизнес аналитические навыки, которые нужны в agile проектах:
- Понимание бизнес области проекта
- Экспертиза в концептуальном моделировании; способность увидеть большую картинку и представить возможные решения
- Выдающиеся вербальные и невербальные коммуникативные навыки
- Многозадачность
- Способность приводить команду к консенсусу по рамкам проекта, решениям связанным с дизайном и реализацией
- Способность задавать вопросы, которые помогают команде находить проблемные области
- Способность документировать требования формально или неформально, в зависимости от нужд проекта
- Понимание agile процесса разработки
- Знание методик , таких как пользовательские истории, use case-ы и неформальное моделирование. Это основные методики работы с требованиями в agile командах.
Библиография
Cohn, Mike, (2004), User Stories Applied: For Agile Software Development, Addison Wesley.
Cohn, Mike. (2005), Agile Estimating and Planning, Addison-Wesley Professional.
Cohn, Mike (2009), Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional.
Cohen, Greg (2010), Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams, Super Star Press.
Pichler, Roman (2010), Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional.
Pixton, Pollyanna, Niel Nickolaisen, Todd Little and Kent McDonald (2009), Stand Back and Deliver: Accelerating Business Agility, Addison Wesley.
-
Victor Gleim
-
Евгения Погребняк
