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

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Новая страница: «Истории и Задания (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Продукто…»)
 
 
(Не показані 28 проміжних версій 6 користувачів)
Рядок 1: Рядок 1:
−
[[Истории и Задания]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Продуктов Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Історії та Завдання]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Продуктов Работ|Суть Продуктів Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Истории и Задания</strong></p><p>Опись продукта (product scope, solution scope) -- это перечень функций, характеристик и свойств продукта для его разработки. Без этого перечня, разработчики не могут знать, что требуется разработать; разработчики воплощают в жизнь идеи, отображённые в описях. Используя те же перечни, заказчики далее удостоверяются в том, что изготовлено то, что они заказывали.</p><p>Эта опись может быть сделана в разных формах, таких как:</p><ol type="a"><li>Общего описания продукта (product epic). Для оперативно-гибких проектов, эти описания разбиваются на пользовательские истории. Для плановых проектов, описания распределяются по иерархической структуре работ (work breakdown structure или WBS),</li><li>Набора пользовательских историй (product backlog). Для оперативно-гибких проектов, входящие в набор истории расставляются в порядке приоритета,</li><li>Прототипа, макета, чертежа или другого артефакта. Например, начальная система управления пользователями Оплёта была написана волонтёром Игорем без какой-либо описи. Текущий код был создан при воссоздании функций и возможностей той исходной системы. Макеты требуются для тех разработок, которые включают дизайн. Сюда безусловно входит разработка веб-сайтов,</li><li>Делового предложения, обоснования необходимости создания продукта или списка описаний отдельных функций, характеристик и свойств,</li><li>Критериев приемлемости. Как правило, чем меньше проект, тем меньше документов требуется его заказчику. Для некоторых клиентов критерии приемки удовлетворяют все потребности.</li></ol><p>Кто разрабатывает описания? Как минимум частичное описание создаётся на стадии инициирования, ещё до официального открытия проекта.</p><p>Если полная опись нужна и не готова до начала планирования, её создают в ходе планирования. Для этого вначале проводится бизнес-анализ -- то есть, от заинтересованных сторон проекта собираются требования к будущему продукту. На основе требований, системные инженеры или другие разработчики создают концепцию будущего продукта.</p><p>В плановых проектах, опись продукта должна быть утверждена заказчиком до начала разработки. В методике Живой Свалки (Agile Scrum), предварительные описи создаются в результате Нулевого Спринта. В оперативных проектах, опись продукта дорабатывается, часто на основе хода разработки.</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