<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="alternate" type="text/html" hreflang="en" href="http://devprom.ru/news"/>
<link rel="self" type="application/atom+xml" href="http://devprom.ru/rss"/>
<title>Новости проекта: DEVPROM</title>
<subtitle></subtitle>
<updated>2012-02-03T08:08:51Z</updated>
<id>news: devprom</id>
<generator uri="http://projectscloud.ru" version="1.0">Облако проектов</generator>
<author><name>DEVPROM</name></author>
<rights>Copyright (c) 2012 DEVPROM</rights>
<entry>
<title><![CDATA[Персоны - Personas]]></title>
<id>news.post: 729</id>
<updated>2012-02-03T08:08:51Z</updated>
<content type="html"><![CDATA[<p>В практике проектирования продуктов, ориентированной на пользователя, часто используются персоны - как мощный и простой инструмент для разработки программного обеспечения, которым пользователи будут наслаждаться и от которого они будут получать максимальную пользу.</p>

<p><h2>Описание</h2></p>
<p>Персоны являются вымышленными фигурами или архетипами, которые являются примером взаимодействия с разрабатываемым продуктом. Они часто используются в методах <a href="http://devprom.ru">Agile</a>, чтобы понять выгоду с точки зрения конкретного клиента и позволяют команде, которая, возможно, не имеет прямого доступа к представителю заказчика, лучше понять его потребности. Работа команды, при этом, может быть сфокусирована на приносящих наибольшую пользу определенной персоне функциях разрабатываемого продукта. </p>
<p><cut/></p>

<p><h2>Элементы</h2></p>
<p>Персоны должны быть описаны так, как будто они являются реальными людьми. Персоны могут иметь имя, личностные свойства, семью, работу, уровень квалификации, предпочтения, модели поведения и личные отношения. Это также хорошая практика, чтобы написать короткий рассказ вида «день из жизни» и добавить изображения, которые помогут команде визуализировать пользователей.</p>

<p><h2>Особенности использования</h2></p>
<p>Использование персон, дает более глубокое понимание о ключевых заинтересованных сторонах (stakeholders), чем от традиционной роли или описания действующего лица (actor). Персоны помогают продавать целевые и весьма практичные продукты, потому, что они копируют тонкие качества реальных людей, которые будут взаимодействовать с системами и то, как они делают свою работу.</p>

<p>Если доступны демографические (или антропоморфные) данные о предполагаемых пользователях, то это будет хорошим подспорьем для начала создания персон. Однако, в некоторых случаях необходимо проявлять творческий подход и придумывать персоны на основе нескольких сухих фактов о предполагаемых конечных пользователях. В любом случае, должны быть определены конкретные пользователи. В зависимости от размера предполагаемой базы пользователей и их различий, определение персон может значительно варьироваться по количеству.</p>

<p>Затем необходимо ранжировать персоны по нескольким ключевым целям, которые обеспечат наибольшую пользу от создаваемой системы. Когда будут выдвигаться предположения о дизайне, необходимо будет принимать во внимание, какое влияние они окажут на целевых персон.</p>

<p><i>"Частая ошибка заключается в разработке для тех, кто близок к продукту, а не для фактического пользователя ... IT -менеджер, который приобрел продукт, обычно не является его пользователем."</i> (Купер, 1999)</p>

<p><h2>Преимущества</h2></p>
<p><ul><li><p> Персоны помогают членам команды обобщить конкретное, согласованное понимание различных групп аудитории продукта. Данные о группах могут быть внедрены в соответствующую среду и могут быть поняты и служить напоминанием в логически связанных <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">историях</a>.</p></li><li><p> Предлагаемые решения могут определяться тем, насколько хорошо они отвечают потребностям отдельных пользовательских персон. Функции могут быть приоритетными на основе того, насколько хорошо они удовлетворяют потребности одной или нескольких персон.</p></li><li><p> Персона получает человеческое «лицо», для того, чтобы сосредоточиться на сопереживании персоне, представленным демографическими данными.</p></li></ul></p>

<p><h2>Недостатки</h2></p>
<p><ul><li><p> Персоны являются вымышленными, поэтому часто возникает тенденция к созданию персон, которые воплощают черты, являющимися общими для большинства пользователей, но при этом создается некий средний пользователь, который не обладает индивидуальностью или реалистичностью. Это может привести к созданию программного обеспечения, которое предназначено для всего и для всех.</p></li><li><p> Персоны не могут быть хорошей заменой для реальных пользователей, если таковые имеются. Персоны могут дистанцировать команду от сообщества пользователей.</p></li></ul></p>

<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9F%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D1%8B-Personas"/>
</entry>
<entry>
<title><![CDATA[Модель выравнивания по цели]]></title>
<id>news.post: 728</id>
<updated>2012-01-30T10:10:01Z</updated>
<content type="html"><![CDATA[<p>Модель выравнивания по цели используется для оценки идей в контексте клиента и ценности для бизнеса. С точки зрения Agile, эта модель помогает в принятии решений, определении приоритета и фокусировки инвестиций на функциях или возможностях, которые имеют наибольшее значение для организации.</p>

<p><h2>Описание</h2></p>
<p>Модель выравнивания по цели используется для оценки деятельности, процессов, продуктов и возможностей в двух измерениях, а затем для рекомендации действий, которые следует предпринять для их улучшения на основе этих рейтингов. Первое измерение отображает, создает ли активность рыночную дифференциацию, второе измерение отображает степень критичности действия и влияние его на дальнейшее функционирование организации.<cut/></p>

<p>Следующая иллюстрация является примером модели выравнивания по цели.</p>
<p><a class="preview" href="http://projectscloud.ru/file/blogfile/devprom/237&.png" title=""><center><img class="wiki_page_image" alt="" src="http://projectscloud.ru/file/blogfile/devprom/237" width="35%"/></center></a></p>

<p><h2>Элементы</h2></p>
<p><h3>Дифференцирующий квадрант</h3></p>
<p>Функции, продукты или услуги, которые служат для дифференциации организации на рынке и имеют решающее значение для функционирования компании, являются частью дифференцирующего квадранта. Это те вещи, в которые организация должна быть готова инвестировать, чтобы предложить что-то, отличное от предложений конкурентов. Деятельность по дифференциации является тем, что можно использовать для рекламы компании, тем, что создает препятствия для конкурентов, либо иным образом имеет важное стратегическое значение.</p>

<p><h3>Паритетный квадрант</h3></p>
<p>Вещи, которые критически важны, но рыночно не дифференцированы, попадают в паритетный квадрант. Это означает то, что обычно достаточно для работы наравне с другими компаниями в своей отрасли. Многие стандартные функции, такие как финансы, управление персоналом, начисление заработной платы, и другие попадают в этот квадрант для большинства организаций. Виды деятельности в этом квадранте важны, но они не будут предоставлять преимущество фирмы по отношению к конкурентам, так как передовой опыт, как правило, достаточно распространен.</p>

<p><h3>Партнерский квадрант</h3></p>
<p>Виды деятельности, которые могут иметь уникальную ценность для клиентов, но которые не являются критическими для функционирования организации, попадают в партнерский квадрант. Даже если эти мероприятия имеют важное значение для клиентов или других заинтересованных сторон, организация не должна исполнять их, чтобы выжить. Это означает, что организация вряд ли будет иметь ресурсы, чтобы преуспеть в этой деятельности (поскольку более критически важные операции, будут иметь приоритет), а партнер может выполнять их более эффективно.</p>

<p><h3>Квадрант «Кому это вообще надо?»</h3></p>
<p>Наконец, виды деятельности, которые не являются ни критически важными, ни помогают дифференцировать организацию на рынке, попадают в этот квадрант. Поскольку эти виды деятельности не добавляют ценности для потребителя, а организации могут функционировать без них, они являются первыми кандидатами на ликвидацию, а освободившиеся ресурсы направляются для поддержки более полезной работы.</p>

<p><h2>Особенности использования</h2></p>
<p>Модель выравнивания по цели предназначена для использования коммерческими организациями, которые сталкиваются с конкуренцией на рынке. Для государственных организаций и некоммерческих организаций может оказаться, что рыночная дифференциация не является существенным драйвером их решений.</p>

<p>Во-вторых, модель содержит указания о том, что нужно в сфере определения стратегии, но не дает никаких указаний на то, какие стратегии и решения могут быть правильными.</p>

<p><h3>Преимущества</h3></p>
<p><ul><li><p> Одним из ключевых преимуществ этой модели является ее простота. Ей можно обучить спонсоров бизнеса и пользователей за несколько минут, чтобы они могли критически оценить идею сами, без привлечения к анализу бизнес-аналитика, чьи выводы затем могут быть оспорены.</p></li><li><p> Модель проста в использовании и упрощает условия для совместной работы.</p></li><li><p> Ее можно применять на всем пути вверх и вниз процесса принятия инвестиционных решений. От стратегических инвестиций вплоть до отдельных функций в системе.</p></li><li><p> Она быстра и все незавершенные работы могут быть проанализированы менее чем за час.</p></li></ul></p>

<p><h3>Недостатки</h3></p>
<p><ul><li><p> Она предполагает положительные намерения в бизнес-стратегии. Она не включает в себя «помехи» поведения корпораций.</p></li></ul></p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C-%D0%B2%D1%8B%D1%80%D0%B0%D0%B2%D0%BD%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D0%BF%D0%BE-%D1%86%D0%B5%D0%BB%D0%B8"/>
</entry>
<entry>
<title><![CDATA[Обновление 2.9.6.6]]></title>
<id>news.post: 727</id>
<updated>2012-01-30T07:07:43Z</updated>
<content type="html"><![CDATA[<p>Рекомендуем <a href="http://devprom.ru/download">загрузить</a> и установить обновление, решающее следующие проблемы:<cut/></p>
<p><ul><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%9D%D0%B5%D0%BE%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%B0-%D0%BF%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0-%D0%BA%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85-%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2">[<strike>I-14153</strike>]</a> Неоходима поддержка кириллических доменов</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%9F%D0%BE%D0%B4%D1%81%D1%82%D1%80%D0%BE%D1%87%D0%BD%D1%8B%D0%B5-%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D1%8B-%D0%B2-%D0%BD%D0%B8%D0%B6%D0%BD%D0%B5%D0%BC-%D0%B8-%D0%B2%D0%B5%D1%80%D1%85%D0%BD%D0%B5%D0%BC-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%85-%D0%B2%D1%8B%D0%B3%D1%80%D1%83%D0%B6%D0%B0%D1%8E%D1%82%D1%81%D1%8F-%D0%B8%D0%B7-devprom-%D1%81-%D0%BF%D0%BE%D1%82%D0%B5%D1%80%D1%8F%D0%BC%D0%B8">[<strike>I-14158</strike>]</a> Подстрочные символы (в нижнем и верхнем регистрах) выгружаются из devprom с потерями</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%9F%D1%80%D0%B8-%D0%BF%D0%BB%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B8-%D0%BD%D0%B5-%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B0%D0%B5%D1%82%D1%81%D1%8F-%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0-%D0%BF%D0%BE-%D1%83%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA%D0%B0%D0%BC">[<strike>I-14119</strike>]</a> При планировании задачи не отображается загрузка по участникам</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%95%D1%81%D0%BB%D0%B8-%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BE-%D0%B4%D0%B2%D0%B0-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D1%85-%D0%B0%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B0-%D1%81-%D1%82%D0%B8%D0%BF%D0%BE%D0%BC-quot-%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BE%D1%87%D0%BD%D0%B8%D0%BA-quot-%D1%82%D0%BE-%D0%B2-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B5-%D1%84%D0%B8%D0%BB%D1%8C%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8-%D0%B2%D0%BE-%D0%B2%D1%81%D0%B5%D1%85-%D0%B2%D1%8B%D0%BF%D0%B0%D0%B4%D0%B0%D1%8E%D1%89%D0%B8%D1%85-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%B0%D1%85-%D0%B4%D0%BB%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D1%85-%D0%B0%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%BE%D0%B2-%D0%BF%D1%80%D0%B5%D0%B4%D0%BB%D0%B0%D0%B3%D0%B0%D1%8E%D1%82%D1%81%D1%8F-%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F-%D1%82%D0%BE%D0%B3%D0%BE-%D0%B0%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B0-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9-%D0%BE%D1%82%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D0%BB%D1%81%D1%8F-%D1%81%D0%B0%D0%BC%D1%8B%D0%BC-%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D0%BC-">[<strike>I-14151</strike>]</a> Если определено два пользовательских атрибута с типом "Справочник", то в блоке фильтрации во всех...</p></li></ul></p>
]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-2-9-6-6"/>
</entry>
<entry>
<title><![CDATA[Приоритезация MoSCoW]]></title>
<id>news.post: 724</id>
<updated>2012-01-26T07:07:57Z</updated>
<content type="html"><![CDATA[<p>Этот метод приоритезации используется для определения наиболее критического набора функций или историй, которые будут обеспечивать ценность для бизнеса.</p>

<p><h2>Описание</h2></p>
<p>MoSCoW - это метод для задания приоритета историй в инкрементных и итерационных методах. Метод MoSCoW обеспечивает способ достижения общего понимания относительной важности поставляемой <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">истории</a>. Все истории в журнале являются ценными, но зачастую не все из них могут быть поставлены в одно и то же время.</p>

<p>Метод MoSCoW предоставляет механизм для определения приоритета историй в журнале на несколько релизов. Определение приоритета является важным шагом для любого метода разработки программного обеспечения, но методы Agile не могут быть успешными без постоянного и частого переопределения приоритета работы.</p>

<p>Метод MoSCoW получил свое название от акронима, образованного следующими классификациями приоритета: Must have (Должен иметь), Should have (Следовало бы иметь), Could have (Может иметь) и Would like (Хотелось бы иметь). Буква «о» делает акроним произносимым.</p>
<p><cut/></p>
<p>Классификации следующие:</p>
<p><ul><li><p> <b>Must Have</b>. Это истории, которые должны быть поставлены для решения текущих проблем бизнеса. «Must» понимается как минимальное подмножество историй для использования.</p></li><li><p> <b>Should Have</b>. Это истории, которые имеют решающее значение для успеха релиза. Истории «Should» столь же важны, как и истории «Must», но они могут не быть срочным или для их реализации их можно использовать обходной путь (workaround).</p></li><li><p> <b>Could Have</b>. Это менее критичные истории.</p></li><li><p> <b>Would Like</b>. Эти истории, скорее всего, не будут включены, но в конечном итоге могут быть включены.</p></li></ul></p>

<p><h2>Элементы</h2></p>
<p><ul><li><p> Баклог продукта: сборник историй пользователя, описывающих требуемую функциональность продукта.</p></li><li><p> Стратегия: понимание результатов (выходов) для исходной инициативы.</p></li><li><p> Предпочтения клиентов: ясность в том, что является наиболее важным для клиента.</p></li></ul></p>

<p><h2>Особенности использования</h2></p>
<p>Метод MoSCoW полезен при попытке установить приоритеты в баклоге продукта. В отличие от некоторых методов определения приоритета, эта модель помогает выделить множество полезных историй пользователя, тех, которые конкретно направлены на результат.</p>

<p><h3>Преимущества</h3></p>
<p><ul><li><p> Метод MoSCoW легок в описании и обычно является мощным в определении приоритетов незавершенных работ.</p></li></ul></p>

<p><h3>Недостатки</h3></p>
<p><ul><li><p> Метод MoSCoW может быть субъективным. Если нет эффективного сотрудничества с бизнесом, этот метод определения приоритетов может быть неточным. </p></li><li><p> В проекте, в котором используется подход приращения ценности для бизнеса, команда должна только поставлять приращение Must Haves. Поэтому метод MoSCoW неуместен.</p></li></ul></p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9F%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-MoSCoW"/>
</entry>
<entry>
<title><![CDATA[Анализ Кано - Kano Analysis]]></title>
<id>news.post: 723</id>
<updated>2012-01-24T09:09:58Z</updated>
<content type="html"><![CDATA[<p>Анализ Кано помогает команде Agile понять, какие характеристики продукта или возможности будут являться отличительными признаками продукта на рынке и окажутся драйверами при удовлетворении потребностей пользователей.</p>

<p><h2>Описание</h2></p>
<p>Наибольшую пользу анализ Кано принесет проектам Agile по разработке коммерческих продуктов. Он оказывает помощь в выявлении возможностей (features), которые будут иметь наибольшее влияние на удовлетворенность клиентов, либо из-за того, что они являются исключительно важными, либо потому, что их отсутствие вызовет недовольство. Это помогает команде определить, какие функции являются самыми важными для реализации перед выпуском продукта на рынок.</p>

<p>Анализ Кано раскладывает характеристики продукции по двум осям:</p>
<p><ul><li><p> степень, в которой функция реализована в продукте и</p></li><li><p> уровень удовлетворенности клиентов.</p></li></ul></p>

<p>Полученный график строится на матрице размером 2x2. На основании полученного профиля, характеристики продукта должны быть отнесены к одной из трех категорий:</p>
<p><ul><li><p> обязательные (threshold),</p></li><li><p> ожидаемые (performance) и</p></li><li><p> приводящие к восхищению (excitement).</p></li></ul></p>

<p>Этот вид анализа может быть использован, чтобы попытаться определить характеристики, которые придают продукту уникальное положение на рынке.</p>
<p><cut/></p>
<p><h2>Категории характеристик продукта</h2></p>
<p><h3>Обязательные (или пороговые)</h3></p>
<p>Обязательными характеристиками являются те, которые абсолютно необходимы для заинтересованных сторон при рассмотрении вопроса о принятии продукта. Их отсутствие приведет к интенсивному недовольству, но, поскольку они представляют минимальные критерии приемки, их присутствие не будет повышать уровень удовлетворенности клиентов сверх некоторого низкого уровня. Проблемой выявления требований для этих функций является то, что люди подразумевают их наличие по умолчанию и не сообщают о них, если не поступает прямого вопроса.</p>

<p><h3>Ожидаемые</h3></p>
<p>Это такие характеристики, улучшение которых вызывает линейный рост удовлетворенности. Они представляют собой функции, которые клиенты ожидают увидеть в продукте (например, производительность, простоту в использовании, и т.д.). Требования для этих типов функций, скорее всего, наиболее легко приходят на ум для большинства заинтересованных сторон.</p>

<p><h3>Вызывающие восхищение</h3></p>
<p>Это характеристики, значительно превышающие ожидания клиента. Их наличие позволит значительно повысить уровень удовлетворенности клиентов с течением времени. Поскольку эти характеристики в настоящее время не встречаются на рынке, сложно выявить требования, которые описывают их.</p>

<p><h2>Особенности использования</h2></p>
<p>Для того чтобы определить категорию, к которой принадлежит характеристика или функция, можно провести опрос среди клиентов с помощью двух форм вопроса о наличии функции: в функциональной форме и в дисфункциональной форме. </p>

<p>Функциональная форма: <i>Как бы вы себя чувствовали, при наличии данной функции или характеристики в продукте?</i></p>

<p>Дисфункциональная форма: <i>Как бы вы себя чувствовали, при отсутствии данной функции или характеристики в продукте?</i></p>

<p>Возможные ответы на каждую форму вопроса: </p>
<p><ul><li><p> Мне нравится</p></li><li><p> Я этого ожидаю</p></li><li><p> Мне все равно</p></li><li><p> Я могу с этим работать</p></li><li><p> Мне не нравится</p></li></ul></p>

<p>Определение характеристик основывается на сопоставлении ответов на оба вопроса в следующей таблице. Верхняя строка представляет ответы на дисфункциональную форму вопроса. Левая колонка представляет ответы на функциональную форму вопроса. </p>

<p><table class="wiki_table" style=""><tr><td class="wiki_table_header" style=""><p></p></td><td class="wiki_table_header" style=""><p>Нравится</p></td><td class="wiki_table_header" style=""><p>Ожидаемо</p></td><td class="wiki_table_header" style=""><p>Все равно</p></td><td class="wiki_table_header" style=""><p>Приемлемо</p></td><td class="wiki_table_header" style=""><p>Не нравится</p></td></tr><tr><td class="wiki_table_row" style=""><p>Нравится</p></td><td class="wiki_table_row" style=""><p>Q</p></td><td class="wiki_table_row" style=""><p>E</p></td><td class="wiki_table_row" style=""><p>E</p></td><td class="wiki_table_row" style=""><p>E</p></td><td class="wiki_table_row" style=""><p>P</p></td></tr><tr><td class="wiki_table_row" style=""><p>Ожидаемо</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>T</p></td></tr><tr><td class="wiki_table_row" style=""><p>Все равно</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>T</p></td></tr><tr><td class="wiki_table_row" style=""><p>Приемлемо</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>I</p></td><td class="wiki_table_row" style=""><p>T</p></td></tr><tr><td class="wiki_table_row" style=""><p>Не нравится</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>R</p></td><td class="wiki_table_row" style=""><p>Q</p></td></tr></table></p>

<p>E = Восхищение (Exciters)</p>
<p>P = Ожидание (Performance)</p>
<p>T = Обязательность (Threshold)</p>
<p>I = Безразличие (не вписывается ни в одну из 3 категорий)</p>
<p>Q или R = сомнительный или обратный (ответ не имеет смысла) </p>

<p>Этот подход наиболее применим для потребительских товаров или товаров, которые будут перепроданы, поскольку он нацелен на выявление требований, которые будут стимулировать широкое использование или принятие продукта. Оценка некоторых характеристик имеет тенденцию со временем меняться, так как растет ожидание клиентов по отношению к особенностям или характеристиками, которые должны присутствовать в продукте. Функции, вызывающие восхищение, в конечном итоге станут стандартными характеристиками эксплуатации и порога (в качестве примера, подумайте о новизне банкоматов, когда они были впервые представлены, а в настоящее время клиенты ожидают обязательного наличия банкомата у банка).</p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7-%D0%9A%D0%B0%D0%BD%D0%BE-Kano-Analysis"/>
</entry>
<entry>
<title><![CDATA[Обновление 2.9.6.5]]></title>
<id>news.post: 721</id>
<updated>2012-01-23T08:08:37Z</updated>
<content type="html"><![CDATA[<p>Рекомендуем <a href="http://devprom.ru/download">загрузить</a> и установить обновление, решающее следующие проблемы:</p>
<p><ul><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%95%D1%81%D0%BB%D0%B8-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C-%D0%B0%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D1%8B-%D0%B3%D0%B4%D0%B5-%D0%B2-quot-%D0%A1%D1%81%D1%8B%D0%BB%D0%BE%D1%87%D0%BD%D0%BE%D0%BC-%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8-quot-%D0%BA%D0%BE%D0%B4%D0%B5-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D1%82%D1%81%D1%8F-%D0%B7%D0%BD%D0%B0%D0%BA-%D0%B4%D0%B5%D1%84%D0%B8%D1%81%D0%B0-quot-quot-%D1%82%D0%BE-%D0%BF%D0%BE%D1%8F%D0%B2%D0%BB%D1%8F%D0%B5%D1%82%D1%81%D1%8F-MySQL-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-%D0%BD%D0%B0-%D0%BD%D0%B5%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D1%85-%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0%D1%85-%D1%82%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%BE%D0%BD%D0%B0-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-%D0%B8-%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B0%D0%B5%D1%82%D1%81%D1%8F-">[<strike>I-13896</strike>]</a> Если создавать атрибуты где в "Ссылочном имени" (коде) используется знак дефиса ("-"),...</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%9F%D1%8B%D1%82%D0%B0%D1%8E%D1%81%D1%8C-%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83-%D0%BD%D0%B0-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D1%83-%D0%BF%D0%BE%D0%BB%D1%8F-quot-%D0%9F%D0%B0%D1%82%D1%872-quot-%D0%BD%D0%B5%D1%82-%D0%B2-%D1%84%D0%BE%D1%80%D0%BC%D0%B5-%D0%BD%D0%BE-%D0%BF%D1%80%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B8-%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%B8%D1%82-%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BE%D0%B1-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B5">[<strike>I-13963</strike>]</a> Пытаюсь закрыть задачу на разработку - поля "Патч2" нет в форме, но при сохранении выходит...</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/1-%D0%92-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0%D1%85-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D1%8E-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B9-">[<strike>I-13964</strike>]</a> 1. В настройках проекта создаю пользовательский...</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0-quot-%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%B7%D0%B0%D1%8F%D0%B2%D0%BE%D0%BA-quot-%D0%BF%D1%80%D0%B8-%D0%BD%D0%B0%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B8-%D0%BF%D0%BE%D0%B6%D0%B5%D0%BB%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B2%D0%BE%D0%B7%D0%BD%D0%B8%D0%BA%D0%B0%D0%B5%D1%82-%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%B8%D0%B5-%D0%BE%D0%B1-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B5">[<strike>I-13968</strike>]</a> Шаблон проекта "Обработка заявок", при назначении пожелания возникает сообщение об ошибке</p></li></ul></p>
]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-2-9-6-5"/>
</entry>
<entry>
<title><![CDATA[Определение ценности для бизнеса]]></title>
<id>news.post: 720</id>
<updated>2012-01-20T18:06:50Z</updated>
<content type="html"><![CDATA[<p>Для того, чтобы проект приносил пользу, вначале необходимо определить, является ли запрос на самом деле ценным для организации. Без четкого понимания ценности (или пользы) для бизнеса, возможно, проект обеспечит то, что звучит ценными, но на самом деле не является таковым.</p>

<p>Проект создает ценность для бизнеса, если он обеспечивает все то, что способствует достижению организацией заявленных первичных целей, например,</p>
<p><ul><li><p> увеличение или сохранение доходов,</p></li><li><p> сокращение или устранение расходов,</p></li><li><p> улучшение уровня обслуживания,</p></li><li><p> соблюдение нормативных и социальных обязательств,</p></li><li><p> реализация маркетинговой стратегии и</p></li><li><p> повышение квалификации персонала.</p></li></ul></p>

<p>Ценность для бизнеса должна быть выражена в виде модели, а не в абсолютном количестве. Эволюция модели ценности для бизнеса будет развивать понимание того, почему требуется данный проект. Самым важным аспектом разработки модели ценности для бизнеса являются переговоры, которые генерируют общее понимание, а не модель и количество того, что модель производит.</p>
<p><cut/></p>
<p>Примеры плохого заявления ценности для бизнеса:</p>
<p><ul><li><p> Это дает возможность сквозной обработки транзакций.</p></li><li><p> Это составит 1 миллион долларов.</p></li><li><p> Это позволит сэкономить 1 миллион долларов.</p></li><li><p> Мистер Биг нуждается в этом продукте.</p></li></ul></p>

<p>Ни одно из этих выражений не соответствует целям организации. Пример хорошего утверждения относительно ценности для бизнеса: <i>Этот проект обеспечит дополнительные $ 20 млн. прибыли.</i></p>

<p>Модель основана на следующих предположениях:</p>
<p><ul><li><p> Мы поддерживаем 25% от продаж существующего продукта XYZ ($ 150 млн в год).</p></li><li><p> Общая стоимость проектирования, производства и маркетинга продукта $ 7,5 млн.</p></li><li><p> Наш продукт – первый на рынке.</p></li><li><p> Мы можем выпустить продукт весной.</p></li></ul></p>

<p>Это утверждение, в типовой форме, передает понимание того, почему проект необходим, и, скорее всего, способствует ценным переговорам, которые формируют общее понимание проекта.</p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9E%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D1%86%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%B4%D0%BB%D1%8F-%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%D0%B0"/>
</entry>
<entry>
<title><![CDATA[Управление баклогом продукта]]></title>
<id>news.post: 717</id>
<updated>2012-01-18T19:07:00Z</updated>
<content type="html"><![CDATA[<p>Баклог продукта (или незавершенные работы) – это перечень необходимых функций, которые должны быть включены в продукт, и он является основным механизмом для управления требованиями в проектах Agile. </p>

<p><h2>Описание</h2></p>
<p>Баклог продукта, изначально пришедший из Scrum, используется во многих методологиях Agile и вводится в начале проекта. Баклог или журнал незавершенной работы – это постоянно меняющийся документ, который развивается во время выполнения проекта по мере накопления знаний о продукте и клиентах. Владелец продукта (Product Owner) отвечает за упорядочение элементов баклога на основе знаний и пользе бизнесу, важности фич или других соответствующих критериев. При управлении баклогом, элементы должны быть упорядочены так, чтобы наиболее важные элементы находились в верхней части списка и упорядочены по убыванию приоритета. В XP (eXtreme Programming) незавершенная работа по функциональности может управляться как журнал историй пользователя. Бизнес-аналитик может выступать в качестве владельца продукта или помогать ему.</p>

<p>Во время сессий планирования релиза, элементы выбираются из списка незавершенных, на основе таких факторов, как приоритет, риск, ценность для продукта или клиента, а также способность реализовать функцию в рамках данного релиза. В конце каждого релиза обратная связь, полученная по результатам работы, может привести к добавлению новых элементов в журнал, изменению приоритетов, или удалению элементов из журнала.</p>
<p><cut/></p>
<p>Незавершенную работу иногда называют «портфелем вариантов» (portfolio options), в который как раз инвестирует бизнес. Используются также такие термины как «основной <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">список историй</a>» и «список приоритетных функций».</p>

<p><h2>Артефакты</h2></p>
<p><h3>Элементы бэклога</h3></p>
<p>Журнал может содержать <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">истории пользователя</a>, варианты использования, функции, функциональные требования, а также элементы, которые были добавлены командой для поддержки развития таких требований к технической инфраструктуре. Элементы журнала должны быть выражены таким образом, чтобы они явно отражали пользу для бизнеса. Элементы описывающие действия для снижения рисков продукта также могут быть добавлены в журнал, как истории или части работы, которые предстоит выполнить. </p>

<p><h3>Надлежащий уровень детализации</h3></p>
<p>Элементы из верхних строчек журнала должны быть разработаны в ближайших релизах, поэтому они должны быть достаточно подробными, чтобы команда разработчиков тщательно их оценила и имела возможность распределить задачи, необходимые для их реализации. Элементы с более низким приоритетом могут быть описаны лишь высокоуровнево и недостаточно точно, но, когда приоритет повысится, они должны быть проработаны более подробно. Большие элементы журнала, иногда называемые эпосами (epics) или приращением коммерческой ценности (business value increments), также могут быть разбиты на несколько, более подробных элементов, то есть подвергнуться проработке путем декомпозиции на истории пользователей. Некоторые аспекты <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">истории пользователя</a> могут быть важными в ближайшее время, а другие - менее важными. Эта возможность делить истории в журнале помогает сохранить частоту выпуска полезного продукта. Например, добавление новой функции может подразумевать предварительное жесткое программирование (hardcode) и добавление новой истории в журнал, чтобы позже добавить возможность некоторой динамической настройки продукта.</p>

<p><h3>Точность оценки</h3></p>
<p>Элементы с высоким приоритетом должны быть оценены с достаточной точностью, чтобы использовать их для планирования релизов. Элементы с низким приоритетом также должны быть оценены, но с меньшей точностью, так как они часто являются менее детальными. Оценка времени завершения элементов часто поддерживается в рамках самого журнала.</p>

<p><h3>Определение приоритета</h3></p>
<p>Элементы журнала должны быть упорядочены по отношению друг к другу. Порядок может быть установлен с использованием номеров, пунктов (высокое/среднее/низкое), или любого другого метода приоритезации. Порядок элементов в журнале, вероятно, будет меняться во время выполнения проекта, особенно из-за того, что продукт развивается и команда получает обратную связь от заинтересованных сторон и клиентов. Важно отметить, что важным является упорядочение элементов для выполнения в ближайшее время, но планирование на отдаленное будущее может оказаться ненужным, потому что в дальнейшем, элементы журнала могут быть изменены.</p>

<p><h3>Управление изменениями в баклоге</h3></p>
<p>Журнал является основным механизмом для управления изменениями требований в проектах Agile и управления скоупом проекта. Когда новые или измененные требования выявлены, они добавляются в журнал и упорядочиваются по сравнению с другими элементами. Журнал также используется для отслеживания и управления сообщениями о дефектах или ошибках. Порядок ведения журнала может быть организован заранее с помощью обозначений относительной важности (на основе коммерческой ценности), что позволяет определять приоритеты на высоком уровне без лишних препятствий. Поскольку в проектах Agile релизы и итерации ограничены по времени, то нижние элементы журнала часто не попадают в данный релиз. Строгий порядок ведения журнала позволяет команде контролировать скоуп проекта и релизов. </p>

<p>Когда элемент разработан и принят владельцем продукта, он будет перемещен из журнала в другой документ, например, план релиза или баклог спринта. Роль владельца продукта состоит в управлении журналом продукта, добавлении и упорядочивании новых или измененных элементов, удалении выполненных элементов, и пересмотре порядка на постоянной основе. Этот процесс иногда называют отсечением или чисткой журнала.</p>

<p><h2>Особенности использования</h2></p>
<p><h3>Преимущества</h3></p>
<p><ul><li><p> Поскольку требования в журнале упорядочены по важности, команда знает, что то, над чем они работают в данной итерации, имеет высокий приоритет и будет способствовать повышению ценности продукта. Человек в команде, отвечающий за детализацию требований может просмотреть журнал и определить, требуют ли элементы, которые будут разработаны в предстоящем релизе, дальнейшего анализа с целью подготовки их к разработке.</p></li><li><p> Каждый новый релиз обычно дополняется небольшим набором требований, эти требования должны быть своевременно подробно проанализированы. То, что команда и заинтересованные стороны узнают о требованиях, разработанных во время релиза, будет способствовать проведению анализа новых требований в предстоящих итерациях.</p></li></ul></p>
<p><h3>Недостатки</h3></p>
<p><ul><li><p> Большие журналы могут стать громоздкими и трудноуправляемыми. Практика деления общего журнала продукта на более мелкие для релизов (так называемые журналы релизов) может помочь в решении этой проблемы. Кроме того, отсутствие значимых деталей в историях в журнале, может привести к потере информации с течением времени.</p></li></ul></p>

<p>Журнал создается в начале проекта, но он не должен быть полным к этому моменту, поскольку он будет развиваться на протяжении всего проекта.</p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B1%D0%B0%D0%BA%D0%BB%D0%BE%D0%B3%D0%BE%D0%BC-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0"/>
</entry>
<entry>
<title><![CDATA[Роль бизнес-аналитика в проектах Agile]]></title>
<id>news.post: 716</id>
<updated>2012-01-16T10:10:38Z</updated>
<content type="html"><![CDATA[<p>Мыслить как клиент – вот ключевой компонент бизнес-анализа в Agile. Клиент – тот человек, который получает пользу от создаваемого нами продукта. Мы начинаем с определения высокоуровневых целей клиента и постепенно переходим ко всё более глубокому пониманию конкретных потребностей, которым должен отвечать продукт.   </p>

<p>Процессы, основанные на Agile, включают в себя обратную связь для постоянной проверки этого понимания. По мере разработки и передачи продукта, будет развиваться понимание потребностей как клиентом, так и производителем, и очень важно, что эти изменения будут влиять и определять работу команды в будущем.</p>

<p>Анализ в Agile разбивает выпуск продукта на мельчайшие практические шаги, которые приносят пользу в течение всего срока проекта.</p>

<p>Важно, что анализ в Agile начинается с глобального обзора, для того, чтобы помочь команде понять итоговый продукт, который необходимо разработать. Команда сотрудничает с клиентом при проработке ожидаемого восприятия пользователями.</p>

<p>Цель анализа - услышать мнение клиента, особенно конечного пользователя, и воплотить его в продукте.</p>
<p><cut/></p>
<p>Незавершенные элементы (backlog items) подразумевают под собой работу, которую предстоит выполнить с учетом пожеланий клиента, они могут быть представлены через прототипы, истории пользователя, варианты использования, минимальные товарные функции (Minimally Marketable Features), характеристики, эпос и т.д.</p>

<p>Методы, перечисленные ниже, основаны на историях потребителей:</p>
<p><ul><li><p> <a target="_self" href="http://devprom.ru/news/%D0%94%D0%B5%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D1%8F-%D0%BD%D0%B0-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8-Story-Decomposition">Декомпозиция на истории</a></p></li><li><p> <a target="_self" href="http://devprom.ru/news/%D0%A3%D1%82%D0%BE%D1%87%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-Story-Elaboration">Уточнение/проработка историй</a> </p></li><li><p> <a target="_self" href="http://devprom.ru/news/%D0%9F%D0%BE%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%B0%D1%80%D1%82-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B9-Story-Mapping">Story Mapping</a> </p></li><li><p> <a target="_self" href="http://devprom.ru/news/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-User-Story">История пользователя</a> </p></li></ul></p>

<p>Метод для создания прототипов пользовательского интерфейса и его использование для определения подробных требований: </p>
<p><ul><li><p> <a target="_self" href="http://devprom.ru/news/%D0%A0%D0%B0%D1%81%D0%BA%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-Storyboarding">Storyboarding </a></p></li></ul></p>
<p>--</p>
<p>Усилиями членов <a href="http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx">IIBA</a> и экспертами сообщества Agile был разработан черновик <a href="http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02">The Agile Extension of the BABOK</a>, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.</p>

<p>Со своей стороны мы хотим привлечь пользователей системы <a href="http://devprom.ru">управление проектами DEVPROM</a>, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.</p>

<p>Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей <a href="http://devprom.ru">DEVPROM</a> с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.</p>]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%A0%D0%BE%D0%BB%D1%8C-%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-%D0%B2-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D1%85-Agile"/>
</entry>
<entry>
<title><![CDATA[Обновление 2.9.6.4]]></title>
<id>news.post: 715</id>
<updated>2012-01-16T09:09:34Z</updated>
<content type="html"><![CDATA[<p>Рекомендуем <a href="http://devprom.ru/download">загрузить</a> и установить обновление 2.9.6.4, решающее следующие проблемы:<cut/></p>
<p><ul><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%91%D1%80%D0%B0%D1%83%D0%B7%D0%B5%D1%80-IE-8-%D0%9D%D0%B0-%D0%B2%D0%BA%D0%BB%D0%B0%D0%B4%D0%BA%D0%B5-quot-%D0%91%D0%B0%D0%BA%D0%BB%D0%BE%D0%B3-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0-quot-%D0%B2-%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%D0%B5-%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F-quot-%D0%94%D0%BE%D1%81%D0%BA%D0%B0-quot-%D0%BD%D0%B5%D0%BA%D0%BE%D1%80%D1%80%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B0%D0%B5%D1%82%D1%81%D1%8F-%D0%B2%D1%81%D0%BF%D0%BB%D1%8B%D0%B2%D0%B0%D1%8E%D1%89%D0%B5%D0%B5-%D0%BE%D0%BA%D0%BD%D0%BE-%D1%81-%D0%BF%D0%BE%D0%B4%D1%80%D0%BE%D0%B1%D0%BD%D1%8B%D0%BC-%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC-%D0%BF%D0%BE%D0%B6%D0%B5%D0%BB%D0%B0%D0%BD%D0%B8%D1%8F">[<strike>I-13857</strike>]</a> Браузер: IE - 8. На вкладке "Баклог продукта" в режиме отображения "Доска" некорректно отображается...</p></li><li><p> <a class="uid" href="http://projectscloud.ru/requests/devprom/%D0%9F%D1%80%D0%B8-%D1%8D%D0%BA%D1%81%D0%BF%D0%BE%D1%80%D1%82%D0%B5-%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB-%D0%BF%D0%BE%D0%B4%D1%87%D1%91%D1%80%D0%BA%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B7%D0%B0%D0%BC%D0%B5%D0%BD%D1%8F%D0%B5%D1%82%D1%81%D1%8F-%D0%BD%D0%B0-%D0%B4%D0%B5%D1%84%D0%B8%D1%81-">[<strike>I-13859</strike>]</a> При экспорте символ «_»(подчёркивание) заменяется на «-»(дефис).</p></li></ul></p>
]]></content>
<author><name>DEVPROM team</name></author>
<rights>Copyright (c) 2012 projectscloud.ru</rights>
<link rel="alternate" type="text/html" href="http://devprom.ru/news/%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-2-9-6-4"/>
</entry>
</feed>
