Відмінності між версіями «Вимоги у Хмарі»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Материалы)
 
(Не показані 9 проміжних версій 4 користувачів)
Рядок 1: Рядок 1:
[[Требования в Облаке]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Требований]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Вимоги у Хмарі]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Требований|Суть Вимог]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''
  
  
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Требования в Облаке</strong></p><p>"Семь раз отмерь, один раз отрежь". Эта поговорка иллюстрирует важность планирования, но никто не сможет спланировать действия, не зная, что, когда, где и как требуется получить. Изначальные требования -- это отправная точка планирования; окончательные требования -- это то, что подрядчику нужно, чтобы верно "отмерить". Объём требований -- это совокупность заданий, условий, норм и инструкций, которые необходимы подрядчику для удовлетворяющего предоставления того продукта, который заказан и который не противоречит социальным нормам и удовлетворяет требованиям уполномоченных органов.</p><p>Объём требований зависит от многих факторов и может разниться от одного жеста или слова, например, при заказе билета, до выставочных образцов сложнейших систем.</p><p>
+
:<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>
  
1.1.3 ЦЕННОСТЬ БИЗНЕС-АНАЛИЗА
+
===Варіанти===
Организации с высокоразвитой практикой бизнес-анализа считают, что бизнес-анализ оказывает ощутимое влияние
+
:Відповідь у формі есе не потребує варіантів.
на успех своей организации и обеспечивает конкурентное преимущество [3]. Исследования подтвердили, что значительно
 
больший процент высокоразвитых организаций оценивают себя значительно выше среднего по сравнению с аналогичными организациями
 
в отношении к:
 
u Умение реализовывать стратегию,
 
u Организационная гибкость,
 
u Управление проектами, и
 
u Общие финансовые показатели [3].
 
Благодаря сильным исследованиям, подтверждающим, что бизнес-анализ является ключевой компетенцией, организации, которые следят за зрелым бизнесом,
 
методы анализа дадут лучшие результаты и будут делать это более эффективно и результативно, чем аналогичные организации с
 
незрелые практики [3].
 
Подробный отчет PMI's Pulse of the Profession®: Управление требованиями: основная компетенция для проектов и
 
Program Success [1] сообщает, что организации могут сосредоточить больше внимания на следующих трех критических областях, чтобы
 
повысить эффективность своих возможностей бизнес-анализа:
 
u Люди. Располагая необходимыми человеческими ресурсами, которые могут правильно применять бизнес-анализ к
 
рекомендовать решения проблем или возможностей, предлагаемых портфелями, программами и проектами,
 
и в то же время признание и развитие навыков, необходимых для выполнения этой важной роли.
 
u Процессы. Устанавливая и стандартизируя процессы на уровне портфолио, программы и проекта, чтобы
 
последовательное применение хорошего бизнес-анализа может происходить во всех инициативах внутри организации.
 
u Культура. Создавая у руководителей ощущение срочности, чтобы исполнительное руководство и спонсоры полностью ценили
 
Практика бизнес-анализа как критическая компетенция портфелей, программ и проектов, и обеспечивает
 
соответствующая поддержка и приверженность, необходимые для преуспевания во всей организации.
 
  
Те, кто отвечает за бизнес-анализ, могут работать совместно с членами своей организации.
+
:Следующее лектио -- '''[[Что Бизнес-Анализ Есть]]'''
для определения и применения надлежащего уровня общепризнанных передовых практик бизнес-анализа для различных
 
ситуации и потребности. Усилия по определению и применению соответствующих процессов, инструментов, методов бизнес-анализа,
 
и другие предметы, включая используемые жизненные циклы, называются пошивом. Обратитесь к Разделу 1.3.4 для получения дополнительной информации.
 
информация о том, как методы бизнес-анализа могут быть адаптированы к конкретным потребностям организации.
 
Бизнес-анализ может выполняться при создании или улучшении продукта, решении проблемы или стремлении
 
понимать потребности заинтересованных сторон. Ценность бизнес-анализа распространяется на многие отрасли и типы проектов. Например:
 
u В финансовой отрасли бизнес-анализ может использоваться для создания или изменения финансовых продуктов, отвечающих требованиям
 
потребности клиентов;
 
u В сфере здравоохранения можно использовать бизнес-анализ, чтобы минимизировать время ожидания от входа до первого
 
диагностика;
 
u В строительных проектах бизнес-анализ может использоваться для определения требований к новому зданию для использования.
 
как основа объема работ;
 
u Правительства используют бизнес-анализ для анализа ситуаций и определения лучших решений для устранения проблем.
 
такие как бедность, экономический кризис и экологические проблемы;
 
u В производстве бизнес-анализ может применяться для оптимизации процессов сборки; а также
 
u В ИТ-проектах проводится бизнес-анализ, чтобы довести бизнес-требования до заинтересованных сторон и
 
Системные требования, чтобы дать дизайнерам и разработчикам четкое руководство о том, что создавать.
 
Есть много неопределенностей, которые влияют на бизнес-результаты, например, купят ли потребители товар.
 
когда он будет построен, будет ли существующая инфраструктура поддерживать будущие темпы роста, неуверенность в наличии достаточного
 
персонал для поддержки требований клиентов или множество неизвестных, которые могут привести к поломке продукта при использовании в
 
нетрадиционные способы, которые не были учтены при разработке продукта. Эффективный бизнес-анализ позволяет людям,
 
групп, а также государственных и частных организаций для достижения лучших результатов в бизнесе. Эффективный бизнес-анализ помогает:
 
u Удовлетворять потребности бизнеса;
 
u Управлять рисками и сокращать переделки;
 
u Сведение к минимуму дефектов продукции, отзывов, судебных исков и снижения доверия потребителей; а также
 
u Обеспечение удовлетворенности заинтересованных сторон.
 
Эти пункты более подробно рассматриваются в разделах с 1.1.3.1 по 1.1.3.4.
 
1.1.3.1 УСТРАНЕНИЕ БИЗНЕС-ПОТРЕБНОСТЕЙ
 
Организации часто склонны предлагать решения, прежде чем полностью разобраться в ситуации. Бизнес-анализ
 
позволяет организации выявлять и устранять первопричины проблем вместо того, чтобы постоянно устранять симптомы
 
как они происходят. Хороший бизнес-анализ зависит от проведения оценки потребностей и рекомендации решения.
 
исходя из специфики проблемного пространства, включая, но не ограничиваясь, понимание бизнеса и предприятия
 
архитектуры. Бизнес-анализ помогает в обнаружении
 
 
 
новых возможностей, необходимых для роста и, возможно,
 
даже выживание организации. Использование возможностей крайне важно для обеспечения конкурентного преимущества в
 
рынок. Бизнес-анализ помогает организациям получить ценность для бизнеса при удовлетворении потребностей бизнеса.
 
 
 
1.1.3.2 УПРАВЛЕНИЕ РИСКАМИ И СНИЖЕНИЕ Доработок
 
Что составляет достаточный бизнес-анализ, зависит от аппетита организации к риску и уровня
 
уверенности, необходимой для того, чтобы организация смогла приступить к реализации своих инициатив. Решение продолжить
 
без проведения достаточного бизнес-анализа и принятия более высокого уровня неопределенности часто является результатом
 
недооценка деятельности по бизнес-анализу. Хотя бизнес-анализ требует значительных затрат времени и ресурсов, если
 
упускается из виду, это может привести к недостаточно понятным требованиям, неверным ожиданиям заинтересованных сторон и разочарованию.
 
со стороны команды проекта и других ключевых заинтересованных сторон. Эти проблемы могут привести к большому количеству доработок и множеству запросов.
 
для изменения. Это может показаться нелогичным, но время, потраченное на бизнес-анализ, на самом деле экономит время.
 
снижает затраты и сводит к минимуму подверженность рискам в долгосрочной перспективе.
 
1.1.3.3 ВЛИЯНИЕ ДЕФЕКТОВ ИЗДЕЛИЯ
 
Когда на бизнес-анализ уделяется недостаточно времени, могут возникнуть пробелы в требованиях. Отсутствует и
 
неправильно понятые требования могут привести к дефектам продукта. Дефекты продукта, обнаруженные в рамках проекта
 
приводят к доработке, но если эти дефекты продукта обнаруживаются после того, как продукт передается потребителю, результаты
 
экспоненциально хуже. Производственные дефекты продукта могут привести к отзыву продукта, судебным искам, сокращению числа потребителей.
 
доверие или вред конечным пользователям.
 
1.1.3.4 УДОВЛЕТВОРЕНИЕ ЗАИНТЕРЕСОВАННЫХ СТОРОН
 
Создание продуктов для удовлетворения потребностей бизнеса и доставка этих продуктов вовремя и в рамках бюджета.
 
в то время как минимизация потенциальных угроз для организации приводит к повышению удовлетворенности заинтересованных сторон. Глядя на то, как
 
принимающие заинтересованные стороны относятся к конечному продукту или насколько заинтересованные стороны готовы платить за решение после его создания
 
может дать общее представление об истинном удовлетворении заинтересованных сторон. Применение передовых практик бизнес-анализа
 
может привести к тому, что продукт или решение будут приняты на раннем этапе и будут полностью приняты после внедрения или выпуска, и
 
достижение высокого уровня удовлетворенности заинтересованных сторон. </p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, требования нужны, чтобы:</p>
 
 
 
===Варианты===
 
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
 
 
 
:Следующее лектио -- '''[[Требования и Желания]]'''
 
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[SSOT]], [[Технические задания]], [[Пользовательские истории]], [[Брацка Правка]], [[Брацка Вебка]]
  
 
==Экзамен==
 
==Экзамен==

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

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


Материалы

Предшественник этого Лектио -- Свойства Требований.

Иллюстрации

Текст (HTML)

Вимоги в Хмарі

Спочатку розробники Брацької Хмари створюють загальний опис майбутнього виробу. Цей опис робиться на вікі-сторінці Брацької Правки, назва якої відповідає назві виробу, який належить розробити. Цій сторінці надається категорія "Опис виробу для розробки".

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

Щоб загальні описи стали зручними для розробників, загальні описи розбивають на власні історії (user story). Кожна історія є однією функцією або характеристикою і написана з точки зору кінцевого користувача. Значна кількість історій міститься в одну пропозицію. Наприклад, "координатору інформаційних проєктів потрібен формат історій користувача, щоб писати завдання для розробників." Для розробників ці історії вказують на те, що потрібно розробити.

Докладніші технічні завдання (ТЗ) вказують на інше, що необхідно знати розробникам. Ці ТЗ включають існуючі правила і норми, спосіб передачі розробниками своїх робіт і так далі.

Брацька Техрада встановлює загальні вимоги до розробок для Брацької Хмари.

Всі вимоги без винятку створюються в Брацькій Правці та відкриті для широкої публіки.

Політика повної прозорості служить двом цілям. По-перше, таким чином розробники вимог можуть отримати більше пропозицій та доповнень. По-друге, навіть майбутні розробники можуть бачити весь процес розробки 24 години на добу 7 днів на тиждень.

Наявність багатьох документів та їх версій може створити плутанину. Деякі документи та їх версії можуть бути суперечливими. Концепція єдиного джерела істини (single source of truth або SSOT) спрямовано вирішення цієї проблеми. Вимоги лише розробляються на Брацькій Правці, але їх затверджені версії публікуються на Брацькій Вебці.

А тепер, придумайте, будь ласка, питання для завершення цього лектіо.

Варіанти

Відповідь у формі есе не потребує варіантів.
Следующее лектио -- Что Бизнес-Анализ Есть

Термины

Требования, SSOT, Технические задания, Пользовательские истории, Брацка Правка, Брацка Вебка

Экзамен

Определения

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