Відмінності між версіями «Вимоги у Хмарі»
Sonya (обговорення • внесок) |
(→Текст (HTML)) |
||
| Рядок 10: | Рядок 10: | ||
===Текст (HTML)=== | ===Текст (HTML)=== | ||
| − | :<p><strong> | + | :<p><strong>Вимоги в Хмарі</strong></p><p>Спочатку розробники Брацької Хмари створюють загальний опис майбутнього виробу. Цей опис робиться на вікі-сторінці Брацької Правки, назва якої відповідає назві виробу, який належить розробити. Цій сторінці надається категорія "Опис виробу для розробки".</p><p>Загальні описи представляють бачення виробу, але вони рідко бувають ясними або конкретними для реалізації розробниками. Якщо описи нечітко описуватимуть, що майбутній виріб повинен виконувати, і як його функції перевірятимуться, загальні описи також не потрібні для найму підрядників.</p><p>Щоб загальні описи стали зручними для розробників, загальні описи розбивають на власні історії (user story). Кожна історія є однією функцією або характеристикою і написана з точки зору кінцевого користувача. Значна кількість історій міститься в одну пропозицію. Наприклад, "координатору інформаційних проєктів потрібен формат історій користувача, щоб писати завдання для розробників." Для розробників ці історії вказують на те, що потрібно розробити.</p><p>Докладніші технічні завдання (ТЗ) вказують на інше, що необхідно знати розробникам. Ці ТЗ включають існуючі правила і норми, спосіб передачі розробниками своїх робіт і так далі.</p><p>Брацька Техрада встановлює загальні вимоги до розробок для Брацької Хмари.</p><p>Всі вимоги без винятку створюються в Брацькій Правці та відкриті для широкої публіки.</p><p>Політика повної прозорості служить двом цілям. По-перше, таким чином розробники вимог можуть отримати більше пропозицій та доповнень. По-друге, навіть майбутні розробники можуть бачити весь процес розробки 24 години на добу 7 днів на тиждень.</p><p>Наявність багатьох документів та їх версій може створити плутанину. Деякі документи та їх версії можуть бути суперечливими. Концепція єдиного джерела істини (single source of truth або SSOT) спрямовано вирішення цієї проблеми. Вимоги лише розробляються на Брацькій Правці, але їх затверджені версії публікуються на Брацькій Вебці.</p><p><i>А тепер, придумайте, будь ласка, питання для завершення цього лектіо.</i></p> |
===Варианты=== | ===Варианты=== | ||
Версія за 13:42, 9 листопада 2022
Требования в Облаке (здесь и далее по тексту -- Лектио) -- это часть урока Суть Требований. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Зміст
Материалы
Предшественник этого Лектио -- Свойства Требований.
Иллюстрации
Текст (HTML)
Вимоги в Хмарі
Спочатку розробники Брацької Хмари створюють загальний опис майбутнього виробу. Цей опис робиться на вікі-сторінці Брацької Правки, назва якої відповідає назві виробу, який належить розробити. Цій сторінці надається категорія "Опис виробу для розробки".
Загальні описи представляють бачення виробу, але вони рідко бувають ясними або конкретними для реалізації розробниками. Якщо описи нечітко описуватимуть, що майбутній виріб повинен виконувати, і як його функції перевірятимуться, загальні описи також не потрібні для найму підрядників.
Щоб загальні описи стали зручними для розробників, загальні описи розбивають на власні історії (user story). Кожна історія є однією функцією або характеристикою і написана з точки зору кінцевого користувача. Значна кількість історій міститься в одну пропозицію. Наприклад, "координатору інформаційних проєктів потрібен формат історій користувача, щоб писати завдання для розробників." Для розробників ці історії вказують на те, що потрібно розробити.
Докладніші технічні завдання (ТЗ) вказують на інше, що необхідно знати розробникам. Ці ТЗ включають існуючі правила і норми, спосіб передачі розробниками своїх робіт і так далі.
Брацька Техрада встановлює загальні вимоги до розробок для Брацької Хмари.
Всі вимоги без винятку створюються в Брацькій Правці та відкриті для широкої публіки.
Політика повної прозорості служить двом цілям. По-перше, таким чином розробники вимог можуть отримати більше пропозицій та доповнень. По-друге, навіть майбутні розробники можуть бачити весь процес розробки 24 години на добу 7 днів на тиждень.
Наявність багатьох документів та їх версій може створити плутанину. Деякі документи та їх версії можуть бути суперечливими. Концепція єдиного джерела істини (single source of truth або SSOT) спрямовано вирішення цієї проблеми. Вимоги лише розробляються на Брацькій Правці, але їх затверджені версії публікуються на Брацькій Вебці.
А тепер, придумайте, будь ласка, питання для завершення цього лектіо.
Варианты
- Ответ в форме эссе не подразумевает вариантов.
- Следующее лектио -- Что Бизнес-Анализ Есть
