Истории и Задания — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Sonya (обсуждение | вклад) (→Термины) |
||
| (не показано 7 промежуточных версий 3 участников) | |||
| Строка 9: | Строка 9: | ||
</gallery> | </gallery> | ||
| − | ===Текст=== | + | ===Текст (HTML)=== |
| − | :<p><strong>Истории и Задания</strong></p><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> |
===Варианты=== | ===Варианты=== | ||
| Строка 18: | Строка 18: | ||
===Термины=== | ===Термины=== | ||
| − | :[[WBS]], [[ | + | :[[WBS]], [[Объём работ]], [[Критерии приемлемости|Критерии приемки]], [[Требования]], [[Плановый способ]], [[Оперативно-гибкий способ]], [[Пользовательские истории]] |
==Экзамен== | ==Экзамен== | ||
Текущая версия на 13:12, 4 октября 2022
Истории и Задания (здесь и далее по тексту -- Лектио) -- это часть урока Суть Продуктов Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Описи Продуктов.
Иллюстрации
Текст (HTML)
Истории и Задания
Для удобства разработки, общее описание изделия (product epic) разбивается на отдельные требования. Требования к изделию могут быть функциональными и нефункциональными.
Функциональные требования описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.
В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:
- Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),
- я хочу (описывается желаемый функционал),
- чтобы (описывается выгода, которую функционал создаст для пользователя).
Например,
Не имея никаких прав на bskol.com, я хочу видеть кнопку "Войти" на любой странице, чтобы иметь возможность попасть на страницу регистрации.
Нефункциональные требования к изделию описывают его применимость (warranty), то есть давая гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:
- Доступность будущего изделия, то есть, физическую доступность и доступность восприятия. То, что изделие может делать, не означает, что он это сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.
- Готовность изделия к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.
- Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,
- Удобство пользования (usability), то есть требования к комфорту пользователя в применении изделия по назначению, часто выражаемому фразой "не заставляйте меня думать, что мне с этим изделием надо делать".
Нефункциональные требования, чаще функциональных, описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование в Брацком Облаке последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия" и зачем она пользователю нужна.
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, по каким критериям создаются пользовательские истории:
Варианты
- от лица пользователя, создаётся описание желаемых функциональных преимуществ, для чего и почему; вначале собираются комментарии всех пользователей и выставляются в приоритете самые востребованные; руководитель разработок выполняет описание функционала и передает дальше по процессам; нефункциональные требования выполняются исходя из восприятия функционала.
- Следующее лектио -- Продукты Творчества
Термины
- WBS, Объём работ, Критерии приемки, Требования, Плановый способ, Оперативно-гибкий способ, Пользовательские истории
Экзамен
Определения
Вопросы экзамена
- Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________
