Требования в Облаке — различия между версиями

Текущая версия на 14:34, 27 сентября 2022

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

Содержание

1 Материалы
2 Экзамен
- 2.1 Определения
- 2.2 Вопросы экзамена

Материалы

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

Иллюстрации

Текст (HTML)

Требования в Облаке

Первоначально разработчики Брацка Облака создают общее описание будущего изделия. Это описание делается на вики-странице Брацкой Правки, название которой соответствует названию изделия, которое предстоит разработать. Этой странице присваивается категория "Описание изделия для разработки".

Общие описания представляют видение изделия, но они редко бывают ясными или конкретными для реализации разработчиками. Если описания нечётко будут описывать, что будущее изделие должно делать, и как его функции будут проверяться, общие описания также бесполезны для найма подрядчиков.

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

Более подробные технические задания (ТЗ) указывают остальное, что необходимо знать разработчикам. Эти ТЗ включают в себя существующие правила и нормы, способ передачи разработчиками своих работ и так далее.

Брацки Техсовет устанавливает общие требования к разработкам для Брацка Облака.

Все требования без исключения создаются в Брацкой Правке и открыты для широкой публики.

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

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

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

Варианты

Ответ в форме эссе не подразумевает вариантов.

Следующее лектио -- Что Бизнес-Анализ Есть

Термины

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

Экзамен

Определения

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

@@ Строка 1: / Строка 1: @@
-[[Объёмы Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Требований]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+[[Требования в Облаке]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Требований]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
 ==Материалы==
-Предшественник этого ''Лектио'' -- [[Типы Требований]].
+Предшественник этого ''Лектио'' -- [[Свойства Требований]].
 ===Иллюстрации===
@@ Строка 9: / Строка 9: @@
 </gallery>
-===Текст===
+===Текст (HTML)===
-:<p><strong>Объёмы Требований</strong></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.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.3.1 УСТРАНЕНИЕ БИЗНЕС-ПОТРЕБНОСТЕЙ
-Организации часто склонны предлагать решения, прежде чем полностью разобраться в ситуации. Бизнес-анализ
-позволяет организации выявлять и устранять первопричины проблем вместо того, чтобы постоянно устранять симптомы
-как они происходят. Хороший бизнес-анализ зависит от проведения оценки потребностей и рекомендации решения.
-исходя из специфики проблемного пространства, включая, но не ограничиваясь, понимание бизнеса и предприятия
-архитектуры. Бизнес-анализ помогает в обнаружении
-новых возможностей, необходимых для роста и, возможно,
-даже выживание организации. Использование возможностей крайне важно для обеспечения конкурентного преимущества в
-рынок. Бизнес-анализ помогает организациям получить ценность для бизнеса при удовлетворении потребностей бизнеса.
-.1.3.2 УПРАВЛЕНИЕ РИСКАМИ И СНИЖЕНИЕ Доработок
-Что составляет достаточный бизнес-анализ, зависит от аппетита организации к риску и уровня
-уверенности, необходимой для того, чтобы организация смогла приступить к реализации своих инициатив. Решение продолжить
-без проведения достаточного бизнес-анализа и принятия более высокого уровня неопределенности часто является результатом
-недооценка деятельности по бизнес-анализу. Хотя бизнес-анализ требует значительных затрат времени и ресурсов, если
-упускается из виду, это может привести к недостаточно понятным требованиям, неверным ожиданиям заинтересованных сторон и разочарованию.
-со стороны команды проекта и других ключевых заинтересованных сторон. Эти проблемы могут привести к большому количеству доработок и множеству запросов.
-для изменения. Это может показаться нелогичным, но время, потраченное на бизнес-анализ, на самом деле экономит время.
-снижает затраты и сводит к минимуму подверженность рискам в долгосрочной перспективе.
-.1.3.3 ВЛИЯНИЕ ДЕФЕКТОВ ИЗДЕЛИЯ
-Когда на бизнес-анализ уделяется недостаточно времени, могут возникнуть пробелы в требованиях. Отсутствует и
-неправильно понятые требования могут привести к дефектам продукта. Дефекты продукта, обнаруженные в рамках проекта
-приводят к доработке, но если эти дефекты продукта обнаруживаются после того, как продукт передается потребителю, результаты
-экспоненциально хуже. Производственные дефекты продукта могут привести к отзыву продукта, судебным искам, сокращению числа потребителей.
-доверие или вред конечным пользователям.
-.1.3.4 УДОВЛЕТВОРЕНИЕ ЗАИНТЕРЕСОВАННЫХ СТОРОН
-Создание продуктов для удовлетворения потребностей бизнеса и доставка этих продуктов вовремя и в рамках бюджета.
-в то время как минимизация потенциальных угроз для организации приводит к повышению удовлетворенности заинтересованных сторон. Глядя на то, как
-принимающие заинтересованные стороны относятся к конечному продукту или насколько заинтересованные стороны готовы платить за решение после его создания
-может дать общее представление об истинном удовлетворении заинтересованных сторон. Применение передовых практик бизнес-анализа
-может привести к тому, что продукт или решение будут приняты на раннем этапе и будут полностью приняты после внедрения или выпуска, и
-достижение высокого уровня удовлетворенности заинтересованных сторон. </p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, требования нужны, чтобы:</p>
 ===Варианты===
-:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+:Ответ в форме эссе не подразумевает вариантов.
-:Следующее лектио -- '''[[Требования и Желания]]'''
+:Следующее лектио -- '''[[Что Бизнес-Анализ Есть]]'''
 ===Термины===
-:[[Требования]], [[Эпические продукты]], [[SSOT]]
+:[[Требования]], [[SSOT]], [[Технические задания]], [[Пользовательские истории]], [[Брацка Правка]], [[Брацка Вебка]]
 ==Экзамен==

Требования в Облаке — различия между версиями

Текущая версия на 14:34, 27 сентября 2022

Содержание

Материалы

Иллюстрации

Текст (HTML)

Варианты

Термины

Экзамен

Определения

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

Навигация

Персональные инструменты

Пространства имён

Варианты

Просмотры

Ещё

Поиск

Навигация

Инструменты