Истории и Задания — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Термины)
 
(не показана 21 промежуточная версия 4 участников)
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Истории и Задания</strong></p><p>Для удобства разработки, общее описание продукта (product epic) разбивается на отдельные требования. Требования к продукту могут быть функциональными и нефункциональными.</p><p>Функциональные требования к продукту описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.</p><p>В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:</p><ol type="a"><li><code>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li><code>я хочу (описывается желаемый функционал),</code></li><li><code>чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol><p>Нефункциональные требования к изделию описывают его применимость (warranty), то есть гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:</p><ol type="a"><li>Доступность будущего продукта, то есть, физическую доступность и доступность восприятия. То, что продукт может делать, не означает, что сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.</li><li>Готовность продукта к использованию. Эти требования могут включать документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.</li><li>Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,</li><li>Удобство пользования.</li></ol><p>Нефункциональные требования описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия".</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, опись продукта:</p>
+
:<p><strong>Истории и Задания</strong></p><p>Для удобства разработки, общее описание изделия (product epic) разбивается на отдельные требования. Требования к изделию могут быть функциональными и нефункциональными.</p><p><strong>Функциональные требования</strong> описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.</p><p>В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:</p><ol type="a"><li>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</li><li>я хочу (описывается желаемый функционал),</li><li>чтобы (описывается выгода, которую функционал создаст для пользователя).</li></ol><p>Например,<blockquote>Не имея никаких прав на bskol.com, я хочу видеть кнопку "Войти" на любой странице, чтобы иметь возможность попасть на страницу регистрации.</blockquote></p><p><strong>Нефункциональные требования</strong> к изделию описывают его применимость (warranty), то есть давая гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:</p><ul><li>Доступность будущего изделия, то есть, физическую доступность и доступность восприятия. То, что изделие может делать, не означает, что он это сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.</li><li>Готовность изделия к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.</li><li>Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,</li><li>Удобство пользования (usability), то есть требования к комфорту пользователя в применении изделия по назначению, часто выражаемому фразой "не заставляйте меня думать, что мне с этим изделием надо делать".</li></ul><p>Нефункциональные требования, чаще функциональных, описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование в Брацком Облаке последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия" и зачем она пользователю нужна.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, по каким критериям создаются пользовательские истории:</p>
  
 
===Варианты===
 
===Варианты===
:неотъемлемая часть в разработках; главная задача на этапе планирования; делается после утверждения заказчиком; может быть бесполезной в проекте.
+
:от лица пользователя, создаётся описание желаемых функциональных преимуществ, для чего и почему; вначале собираются комментарии всех пользователей и выставляются в приоритете самые востребованные; руководитель разработок выполняет описание функционала и передает дальше по процессам; нефункциональные требования выполняются исходя из восприятия функционала.
  
 
:Следующее лектио -- '''[[Продукты Творчества]]'''
 
:Следующее лектио -- '''[[Продукты Творчества]]'''
  
 
===Термины===
 
===Термины===
:[[WBS]], [[Объем Проекта]], [[Области Решения]], [[Критерии Приемки]], [[Бэклог Продукта]]
+
:[[WBS]], [[Объём работ]], [[Критерии приемлемости|Критерии приемки]], [[Требования]], [[Плановый способ]], [[Оперативно-гибкий способ]], [[Пользовательские истории]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 13:12, 4 октября 2022

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


Материалы

Предшественник этого Лектио -- Описи Продуктов.

Иллюстрации

Текст (HTML)

Истории и Задания

Для удобства разработки, общее описание изделия (product epic) разбивается на отдельные требования. Требования к изделию могут быть функциональными и нефункциональными.

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

В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:

  1. Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),
  2. я хочу (описывается желаемый функционал),
  3. чтобы (описывается выгода, которую функционал создаст для пользователя).

Например,

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

Нефункциональные требования к изделию описывают его применимость (warranty), то есть давая гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:

  • Доступность будущего изделия, то есть, физическую доступность и доступность восприятия. То, что изделие может делать, не означает, что он это сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.
  • Готовность изделия к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.
  • Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,
  • Удобство пользования (usability), то есть требования к комфорту пользователя в применении изделия по назначению, часто выражаемому фразой "не заставляйте меня думать, что мне с этим изделием надо делать".

Нефункциональные требования, чаще функциональных, описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование в Брацком Облаке последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия" и зачем она пользователю нужна.

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

Варианты

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

Термины

WBS, Объём работ, Критерии приемки, Требования, Плановый способ, Оперативно-гибкий способ, Пользовательские истории

Экзамен

Определения

Вопросы экзамена

Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________