DEVPROM

В практике проектирования продуктов, ориентированной на пользователя, часто используются персоны - как мощный и простой инструмент для разработки программного обеспечения, которым пользователи будут наслаждаться и от которого они будут получать максимальную пользу.

Описание

Персоны являются вымышленными фигурами или архетипами, которые являются примером взаимодействия с разрабатываемым продуктом. Они часто используются в методах Agile, чтобы понять выгоду с точки зрения конкретного клиента и позволяют команде, которая, возможно, не имеет прямого доступа к представителю заказчика, лучше понять его потребности. Работа команды, при этом, может быть сфокусирована на приносящих наибольшую пользу определенной персоне функциях разрабатываемого продукта.

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

Описание

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

Рекомендуем загрузить и установить обновление, решающее следующие проблемы:

Этот метод приоритезации используется для определения наиболее критического набора функций или историй, которые будут обеспечивать ценность для бизнеса.

Описание

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

Метод MoSCoW предоставляет механизм для определения приоритета историй в журнале на несколько релизов. Определение приоритета является важным шагом для любого метода разработки программного обеспечения, но методы Agile не могут быть успешными без постоянного и частого переопределения приоритета работы.

Метод MoSCoW получил свое название от акронима, образованного следующими классификациями приоритета: Must have (Должен иметь), Should have (Следовало бы иметь), Could have (Может иметь) и Would like (Хотелось бы иметь). Буква «о» делает акроним произносимым.

Анализ Кано помогает команде Agile понять, какие характеристики продукта или возможности будут являться отличительными признаками продукта на рынке и окажутся драйверами при удовлетворении потребностей пользователей.

Описание

Наибольшую пользу анализ Кано принесет проектам Agile по разработке коммерческих продуктов. Он оказывает помощь в выявлении возможностей (features), которые будут иметь наибольшее влияние на удовлетворенность клиентов, либо из-за того, что они являются исключительно важными, либо потому, что их отсутствие вызовет недовольство. Это помогает команде определить, какие функции являются самыми важными для реализации перед выпуском продукта на рынок.

Анализ Кано раскладывает характеристики продукции по двум осям:

• степень, в которой функция реализована в продукте и

• уровень удовлетворенности клиентов.

Полученный график строится на матрице размером 2x2. На основании полученного профиля, характеристики продукта должны быть отнесены к одной из трех категорий:

• обязательные (threshold),

• ожидаемые (performance) и

• приводящие к восхищению (excitement).

Этот вид анализа может быть использован, чтобы попытаться определить характеристики, которые придают продукту уникальное положение на рынке.

Рекомендуем загрузить и установить обновление, решающее следующие проблемы:

• [I-13896] Если создавать атрибуты где в "Ссылочном имени" (коде) используется знак дефиса ("-"),...

• [I-13963] Пытаюсь закрыть задачу на разработку - поля "Патч2" нет в форме, но при сохранении выходит...

• [I-13964] 1. В настройках проекта создаю пользовательский...

• [I-13968] Шаблон проекта "Обработка заявок", при назначении пожелания возникает сообщение об ошибке

Для того, чтобы проект приносил пользу, вначале необходимо определить, является ли запрос на самом деле ценным для организации. Без четкого понимания ценности (или пользы) для бизнеса, возможно, проект обеспечит то, что звучит ценными, но на самом деле не является таковым.

Проект создает ценность для бизнеса, если он обеспечивает все то, что способствует достижению организацией заявленных первичных целей, например,

• увеличение или сохранение доходов,

• сокращение или устранение расходов,

• улучшение уровня обслуживания,

• соблюдение нормативных и социальных обязательств,

• реализация маркетинговой стратегии и

• повышение квалификации персонала.

Ценность для бизнеса должна быть выражена в виде модели, а не в абсолютном количестве. Эволюция модели ценности для бизнеса будет развивать понимание того, почему требуется данный проект. Самым важным аспектом разработки модели ценности для бизнеса являются переговоры, которые генерируют общее понимание, а не модель и количество того, что модель производит.

Баклог продукта (или незавершенные работы) – это перечень необходимых функций, которые должны быть включены в продукт, и он является основным механизмом для управления требованиями в проектах Agile.

Описание

Баклог продукта, изначально пришедший из Scrum, используется во многих методологиях Agile и вводится в начале проекта. Баклог или журнал незавершенной работы – это постоянно меняющийся документ, который развивается во время выполнения проекта по мере накопления знаний о продукте и клиентах. Владелец продукта (Product Owner) отвечает за упорядочение элементов баклога на основе знаний и пользе бизнесу, важности фич или других соответствующих критериев. При управлении баклогом, элементы должны быть упорядочены так, чтобы наиболее важные элементы находились в верхней части списка и упорядочены по убыванию приоритета. В XP (eXtreme Programming) незавершенная работа по функциональности может управляться как журнал историй пользователя. Бизнес-аналитик может выступать в качестве владельца продукта или помогать ему.

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

Мыслить как клиент – вот ключевой компонент бизнес-анализа в Agile. Клиент – тот человек, который получает пользу от создаваемого нами продукта. Мы начинаем с определения высокоуровневых целей клиента и постепенно переходим ко всё более глубокому пониманию конкретных потребностей, которым должен отвечать продукт.

Процессы, основанные на Agile, включают в себя обратную связь для постоянной проверки этого понимания. По мере разработки и передачи продукта, будет развиваться понимание потребностей как клиентом, так и производителем, и очень важно, что эти изменения будут влиять и определять работу команды в будущем.

Анализ в Agile разбивает выпуск продукта на мельчайшие практические шаги, которые приносят пользу в течение всего срока проекта.

Важно, что анализ в Agile начинается с глобального обзора, для того, чтобы помочь команде понять итоговый продукт, который необходимо разработать. Команда сотрудничает с клиентом при проработке ожидаемого восприятия пользователями.

Цель анализа - услышать мнение клиента, особенно конечного пользователя, и воплотить его в продукте.

Рекомендуем загрузить и установить обновление 2.9.6.4, решающее следующие проблемы: