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

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Текст)
 
(Не показано 24 проміжні версії 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><li>Списка описаний отдельных функций, характеристик и свойств.</li><li>Критериев приемлемости. Как правило, чем меньше проект, тем меньше документов требуется его заказчику. Для некоторых клиентов критерии приемки удовлетворяют все потребности.</li></ol><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>
  
<p>Некоторые клиенты, такие как Брацка Команда, предоставляют подрядчикам подробные описания продуктов. В противном случае менеджеры проектов или бизнес-аналитики собирают требования от заинтересованных сторон проекта, начиная с клиента или его представителей. Если целевой результат является сложным, системные инженеры разрабатывают решения.</p>
+
===Варіанти===
 
+
: невід'ємна частина у розробках; головне завдання на етапі планування; робиться після затвердження замовником; може бути марною в проєкті.
<p>В Заданных Методологиях объем проекта вообще редко документируется. Выполнение проекта начинается после утверждения Бэклога Продукта. Это отставание выполняет роль объема продукта, и разработчики принимают решения о том, какую работу им следует выполнять, исходя из этого объема. По мере того как проект по Заданному Подходу развивается, объем продукта уточняется.</p> <p>Рассмотрим подробнее значение определения Бэклог Продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале Бэклога Продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь.</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, Объём работ, Критерии приемки, Фактор предприятия, Опись продукта, Плановый способ, Оперативно-гибкий способ

Экзамен

Определения

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

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