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

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

Версія за 00:18, 6 листопада 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

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

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

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

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

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

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

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

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

Варіанти

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

Термины

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

Экзамен

Определения

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

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