Відмінності між версіями «Описи Продуктів»

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

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

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


Материалы

Предшественник этого Лектио -- Объекты Приёмки.

Иллюстрации

Текст (HTML)

Описи Продуктів

Опис продукту (product scope, solution scope) -- це перелік функцій, характеристик та властивостей продукту для його розробки. Без цього переліку, розробники неспроможні знати, що потрібно розробити; розробники втілюють у життя ідеї, які у описах. Використовуючи ті ж переліки, замовники далі пересвідчуються в тому, що виготовлено те, що вони замовляли.

Цей опис може бути зроблений у різних формах, таких як:

  1. Загальний опис продукту (product epic). Для оперативно-гнучких проєктів, ці описи розбиваються на власні історії та завдань на розробку. Для планових проектів описи розподіляються за ієрархічною структурою робіт (work breakdown structure або WBS),
  2. Набору історій (product backlog). Для оперативно-гнучких проєктів, що входять у набір історії, розставляються в порядку пріоритету,
  3. Прототипу, макета, креслення або іншого артефакту. Наприклад, початкова система управління користувачами Оплета була написана волонтером Ігорем без жодного опису. Поточний код був створений при відтворенні функцій та можливостей вихідної системи. Макети та прототипи потрібні для розробок, які включають дизайн. Сюди безумовно входить розробка веб-сайтів,
  4. Ділової пропозиції, обґрунтування необхідності створення продукту або списку описів окремих функцій, характеристик та властивостей,
  5. Критеріїв прийнятності. Як правило, чим менший проєкт, то менше документів потрібно його замовнику. Для деяких клієнтів критерії приймання відповідають усім потребам.

Хто розробляє описи? Як мінімум частковий опис створюється на стадії ініціювання, ще до офіційного відкриття проєкту.

Якщо повний опис потрібний і не готовий до початку планування, його створюють у ході планування. Для цього спочатку проводиться бізнес-аналіз -- тобто від зацікавлених сторін проєкту збираються вимоги до майбутнього продукту. На основі вимог, системні інженери або інші розробники створюють концепцію майбутнього продукту.

У планових проєктах опис продукту має бути затверджений замовником до початку розробки. У методиці Живого Звалища (Agile Scrum), попередні описи створюються в результаті Нульового Спринту. В оперативних проєктах опис продукту допрацьовується часто на основі ходу розробки.

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

Варіанти

невід'ємна частина у розробках; головне завдання на етапі планування; робиться після затвердження замовником; може бути марною в проєкті.
Следующее лектио -- Истории и Задания

Термины

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

Экзамен

Определения

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

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