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

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Текст)
 
(Не показані 26 проміжних версій 6 користувачів)
Рядок 1: Рядок 1:
[[Описи Продуктов]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Описи Продуктів]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Продуктов Работ|Суть Продуктів Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Работы по Проектам]].
+
Предшественник этого ''Лектио'' -- [[Объекты Приёмки]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Описи Продуктов</strong></p><p>Опись продукта (product scope, solution scope) -- это перечень функций, характеристик и свойств продукта для его разработки. Без этого перечня, разработчики не могут знать что требуется разработать. Эта опись может быть сделана в разных формах, таких как:</p><ol type="a"><li>Словарного описания продукта,</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>Некоторые клиенты, такие как Брацка Команда, предоставляют подрядчикам подробные описания продуктов. В противном случае менеджеры проектов или бизнес-аналитики собирают требования от заинтересованных сторон проекта, начиная с клиента или его представителей. Если целевой результат является сложным, системные инженеры разрабатывают решения.</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, Объём работ, Критерии приемки, Фактор предприятия, Опись продукта, Плановый способ, Оперативно-гибкий способ

Экзамен

Определения

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

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