Просмотр исходного текста страницы Ценность Разработок

[[Ценность Разработок]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Продуктов Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.


==Материалы==
Предшественник этого ''Лектио'' -- [[Объекты Приёмки]].

===Иллюстрации===
<gallery mode="packed">
</gallery>

===Текст===
:<p><strong>Ценность Разработок</strong></p><p>Ценность разработки -- это воспринимаемые важность, полезность и стоимость, которые получает та сторона, которая в этой разработке заинтересована. Эта ценность отображает преимущества, потери и риски, которые разработка или её продукт несёт. Так как восприятие индивидуально, ценность также всегда субъективна.</p><ol type="a"><li>Для заказчиков, примерами ценностей будут достигнутые выгоды, а также прогнозируемость затрат и рисков,</li><li>Для подрядчиков, ценностями могут быть финансирование от заказчиков, развитие бизнеса и улучшение имиджа,</li><li>Примеры ценностей для разработчиков -- это материальные и нематериальные стимулы, карьера и профессиональный рост, а также чувство сопричастности к созданию чего-то нового,</li><li>Общество может быть заинтересовано в налогах, местных расходах и социальной значимости,</li></ol> 

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

Функциональность изделия (utility) -- это способность изделия выполнить ту работу, ради которой оно создано. Простыми словами, функциональность -- это то, что система может сделать.

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

Применимость изделия (warranty) -- это гарантия того, что изделие может быть применено по назначению. Функциональность системы не означает её применимости. Запасная лампочка может светить, но даст свет только будучи установленной.

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



Приобретаемые с продуктом преимущества, полезность и важность. </p><p>Для разработчика, ценностями могут быть получение опыта, участия в создании чего-то нового и, возможно, материального вознаграждения. Для потребителя, ценность продукта разработки -- это решение проблем, удовлетворение потребностей, расширение возможностей, снятие барьеров и познание чего-то нового, которое этот продукт несёт.</p></li><li>Затраты или то, что потребитель вместе с продуктом теряет.</li><li>Риски.</li></ol>



<p>Выполнение проекта начинается после утверждения Бэклога Продукта. Это отставание выполняет роль объема продукта, и разработчики принимают решения о том, какую работу им следует выполнять, исходя из этого объема. По мере того как проект по Заданному Подходу развивается, объем продукта уточняется.</p> <p>Рассмотрим подробнее значение определения Бэклог Продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале Бэклога Продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь.</p> 

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


В поисковых проектах этапы проекта всегда перекрываются. Предварительное планирование работы, которое называется Нулевой Спринт, устанавливает правила и приоритеты для проекта. Каждый день планирование открывается заново, чтобы учесть разработки предыдущего дня.

Владелец проекта несет ответственность за управление проектом. Чтобы направлять, контролировать и/или поддерживать персонал проекта, владелец может создать офис управления проектом, часто сокращенно ОУП.</p>
<p>В управлении проектами Гибкой Методологии ключевую роль играет руководитель проекта. Эти менеджеры концентрируются на разработке утвержденных продуктов в соответствии с утвержденными бюджетами и утвержденными графиками.</p>
<p>Менеджер проекта ведет Планирование проекта до утверждения базовых показателей, выполнение проекта до подтверждения результатов и закрытие проекта. На этапе планирования менеджер может нанять бизнес-аналитиков для сбора требований и системных инженеров для разработки системы, как Решения. Те разработчики, которые непосредственно создают результаты, нанимаются только на стадии Выполнения.</p>
<p>Если персонал проекта составляет менее 5-9 человек и график не сжат, менеджер редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве менеджера проекта в дополнение к другим обязанностям.</p>
<p>В Жестком Подходе функции управления распределены между несколькими ролями. Например, разработчики определяют работу на основе требований решения, таких как пользовательские истории.
На этапе Планирования некий координатор, например, менеджер по работе с клиентами, работающий в ОУП, нанимает членов группы планирования в дополнение к владельцу продукта. Эта команда проводит Нулевой Спринт или аналогичные действия, предпринимаемые для создания Бэклога Продукта.</p>
<p>На исполнительный этап нанимается команда разработчиков. Помимо product owner-а(Владелец Продукта), в эту команду входят разработчики и, возможно, такие официальные лица, как Scrum Master. Разработчики обычно работают в итерациях и, как только разрабатываются новые инкременты и обнаруживаются новые данные, обсуждают будущий продукт и его доставку с Владельцем Продукта. Скрам-Мастера не занимаются рабочими продуктами и поставками; Вместо этого Скрам-Мастера следят за тем, чтобы разработка шла в соответствии с согласованными правилами.
В отличие от Управления проектами, администрирование разработки часто распределяется между двумя организациями, если две организации участвуют в одном проекте.</p>
<p>Заказчик Проекта определяет бизнес-потребность, которая является проблемой, которую необходимо решить, инициирует проект по созданию решения и предоставляет бюджет проекта.
Владелец Проекта, следовательно, нанимает кого-то, кто действует от имени клиента при утверждении Требований к решению, базовых планах проекта и / или оценке того, соответствует ли рабочий продукт критериям приемки.</p>
<p>В проектах Гибкой Методологии -- эта административная роль называется Спонсором Проекта. Базовые показатели не являются особенностью проектов с Жесткким Подходом, поэтому администрация концентрируется только на требованиях к продукту.</p>
<p>Владелец продукта - ключевая административная роль в Жестких Методологиях проекта. Этот человек концентрируется на представлении правильного продукта, описании этого продукта обычно с использованием пользовательских историй и расстановке приоритетов в отставании по продукту. Владельцы Продуктов не занимаются бюджетами, графиками, а также другими функциями управления, такими как найм и закупки. Область ответственности product owner-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.

</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>

===Варианты===
:

:Следующее лектио -- '''[[Заказать или Сделать]]'''

===Термины===
:[[Бюджет Проекта]], [[Активы Проекта]], [[Внешние Среды]], [[Внутренние Среды]], Проектная Среда, [[Затраты На Проект]], [[График Проекта]], [[Фактор Предприятия]], [[Рабочий Продукт]], [[Временные Шкалы Проекта]]

==Экзамен==

===Определения===
:

===Вопросы экзамена===
:Использование подвижного Подхода для разработки в Брацкой Школы лучше всего можно классифицировать как:
Актив проекта .
Фактор предприятия .
Проектная среда .
Все остальные ответы по существу верны.

[[Category: Лектио]]