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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Термины)
 
(не показано 11 промежуточных версий 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>Например,<blockquote><code>Не имея никаких прав на bskol.com, я хочу видеть кнопку "Войти" на любой странице, чтобы иметь возможность попасть на страницу регистрации после щелчка на эту кнопку.</code></blockquote></p><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, Объём работ, Критерии приемки, Требования, Плановый способ, Оперативно-гибкий способ, Пользовательские истории

Экзамен

Определения

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

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