Відмінності між версіями «Історії та Завдання»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(→‎Текст)
 
(Не показані 8 проміжних версій 5 користувачів)
Рядок 1: Рядок 1:
−
[[Истории и Задания]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Продуктов Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Історії та Завдання]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Продуктов Работ|Суть Продуктів Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
Рядок 10: Рядок 10:
  
 
===Текст (HTML)===
 
===Текст (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>Не маючи жодних прав на idosvid.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]], [[Объём работ]], [[Критерии приемлемости|Критерии приемки]], [[Требования]], [[Плановый способ]], [[Оперативно-гибкий способ]], [[Пользовательские истории]]
  
 
==Экзамен==
 
==Экзамен==

Поточна версія на 11:44, 27 листопада 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

Історії та Завдання

Для зручності розробки, загальний опис виробу (product epic) розбивається на окремі вимоги. Вимоги до виробу можуть бути функціональними та нефункціональними.

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

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

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

Наприклад,

Не маючи жодних прав на idosvid.com, я хочу бачити кнопку "Увійти" на будь-якій сторінці, щоб мати можливість потрапити на сторінку реєстрації.

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

  • Доступність майбутнього виробу, тобто фізичну доступність та доступність сприйняття. Те, що виріб може робити, не означає, що він це зробить. У казці "Чарівник Смарагдового Міста" Еллі мала срібні черевички Гінгеми, але не знала про їхню чарівну силу.
  • Готовність виробу до використання. Ці вимоги можуть включати фізичну готовність, а також документацію, маркування, сумісність з іншими системами, відповідність законам та галузевим інструкціям.
  • Технічні характеристики, як, наприклад, робочий ресурс, запас міцності, безпека та стабільність роботи. Технічні завдання (ТЗ) включають технічні характеристики, але часто мають й інші види вимог.
  • Зручність користування (usability), тобто вимоги до комфорту користувача у застосуванні виробу за призначенням, що часто виражається фразою "не змушуйте мене думати, що мені з цим виробом треба робити".

Нефункціональні вимоги, частіше функціональних, описуються завданнями, оскільки користувальницькі історії не завжди підходять. Наприклад, Брацька Техрада вимагає використання у Брацькій Хмарі останньої стабільної версії готового рішення. Ця вимога не є функціональною. Звичайний користувач, швидше за все, не знає, що таке "остання стабільна версія" і навіщо вона потрібна користувачу.

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

Варианты

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

Термины

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

Экзамен

Определения

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

Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________
Отримано з https://pravka.idosvid.com/w2/index.php?title=Історії_та_Завдання&oldid=32804