Как избежать" плохих " требований [закрыто]

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

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

всякий раз, когда я вижу эту статистику, мне напоминают о дорогих, тяжелых, водопадных проектах, где был завершен первый релиз и представлен клиенту, который быстро сказал проекту: "это не то, что я хотел."

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

в этом контексте, "требования" более расплывчато, и они развиваются несколько по мере продвижения проекта.

в agile мы используем аббревиатуру INVEST. Истории (которые стоят в для требований) должны быть:

• Я - Независимая
• N - Договорная
• V-Valuable
• E-Estimable
• S - Маленький
• T-Тестируемый

требования не являются артефактом, который будет передан вам с вершины горы. Они являются живым побочным продуктом процесса открытия и разговора между вами и вашими клиентами (или их доверенные лица.)

во-первых, для того, чтобы требование было действительным, оно должно быть проверкой. Если нет, то нет возможности отслеживать его, измерять его, сообщать о нем... это коренная причина зла.

Как можно избежать этой ситуации? Убедитесь, что требование:

• ограничено как во времени ,так и в ресурсах (например,$)

• проверкой

или же, вы работаете над "открытым циклом" , и я конечно, вы можете оценить последствия.

Примечание это иногда требование приходит скорее с "качественным" характером: это зависит от менеджера продукта/команды, чтобы определить "количественное" определение для него.

Я думаю, вы обнаружите, что если вы интерпретируете это следующим образом, это будет иметь больше смысла:

"X% программных проектов терпят неудачу из-за плохого определения требований"

есть много вещей, которые вы можете сделать

• убедитесь, что вы действительно можете проверить требование
• убедитесь, что аналитик действительно понимает, что пользователь действительно средства. Часто пользователь просит не то, что он на самом деле хочет.
• сделать конечно, разработчик понимает требование. Если разработчик получает плохую спецификацию и должен сделать предположение, которое оказывается неправильным, то время будет потрачено впустую, когда программист должен исправить это предположение поверх обычных ошибок.
• убедитесь, что пользователь фактически проверяет, что их требования были выполнены. Лучше поздно, чем никогда.

в дополнение к невозможным / непрактичным или непроверяемым требованиям, "плохой", вероятно, относится к неправильно собранным - они требования, которые у вас есть, не соответствуют тому, что на самом деле необходимо для приложения. Одним из источников этого является то, что пользователи часто не знают, что им нужно или чего они хотят.

вероятно, они означают "неправильно переданные" требования.

Если вы думаете об этом, есть много способов, которыми вы можете неправильно сформулировать требования, намеренно или иначе. Некоторые способы решения проблемы:

• осознайте, что требования системы могут меняться непрерывно. В противном случае клиент скажет: "Да, это изменилось, вам никто не сказал?"

• задать требования нескольких ключевых людей - это не достаточно, чтобы спросить CEO, а также, недостаточно спросить нижние чины, которые на самом деле будут использовать вашу систему.

• убедитесь, что есть несколько человек, ответственных за передачу требований к вам - эти люди (не более 5 в проекте среднего размера) должны иметь большой стимул, чтобы дать вам всю информацию для успешной реализации. Если у вас нет этих людей, вы, скорее всего, потерпите неудачу, поскольку все будут слишком заняты, чтобы объяснить вам вещи, и они у вас будет стимул не разговаривать с вами, так как вы сможете утверждать, что X человек сказал вам реализовать систему так, как вы это сделали. Вам нужна поддержка руководства в создании этой группы людей.

• вам нужно проверить предположения с другими людьми. Иногда нужно задать один и тот же вопрос пятью разными способами.

• бойтесь абсолютов... "Цена продажи не может быть изменена" иногда означает "Я хотел бы, чтобы переопределение супервизора было реализовано в случае необходимости изменения цены для текущего клиента."

• понять бизнес-процесс как можно больше. Если вы пишете банковское приложение, попросите провести день в банке, чтобы увидеть, как люди будут использовать систему. Если вы доставляете фазу проекта, сделайте то же самое: следите за используемой системой и будьте активны в поиске дыр.

• распознать, когда что-то не указано достаточно подробно и настаивайте на том, чтобы все было правильно. Сделайте макеты, ручные рисунки, блок-схемы, все, что нужно, чтобы убедиться, что источник требований и вы находитесь на одной странице.

Это все просто из опыта... Я думаю, что " плохие требования "действительно означает" плохие коммуникации между клиентом и исполнителем."

мой опыт показывает следующие возможные источники плохо требования:

• пользователи / клиенты часто не знают, чего они хотят. Возможный способ справиться с этим-либо иметь хороший бизнес-аналитиков, которые могли бы выполните необходимый анализ или имейте хороший готовый продукт который смог одеть этот потребитель (или не).
• аналитики не могут обеспечить надлежащее качество требований. Да, такое случается. Нанимайте лучших аналитиков / экспертов по технологиям, но до неудача, а не после. Требования к тестированию, анализ вариантов использования, построение диаграмм последовательности состояний как можно раньше, чтобы понять охват случаев пользователей и так далее. Другими словами, это связано с общим моделированием.
• Ну, есть возможность плохого перевода из маркетинговых требований / модели в технические параметры.
• проблема качества дизайна (реализация не может соответствовать требованиям).

Что нужно сделать, чтобы преодолеть эти проблемы? Давайте позволим инженерам обеспечить обратную связь, давайте не будем закрывать требования и делать их максимально гибкими. Часто даже с в целом хорошими последовательными требованиями мы сталкиваемся с некоторыми ограничениями аппаратного обеспечения низкого уровня на этапе реализации и должны отслеживать изменения. С другой стороны, давайте разбираться в клиентах, а не только в технологиях. Я видел, как многие проекты с большой частью работы выбрасывались просто потому, что они хорошо выглядят для разработчиков, но не для клиентов. Бест общение с клиентом у вас тем ниже, чем меньше вероятность таких случаев.

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

одна из самых ценных вещей, которые может сделать организация-разработчик (но редко делается), - это проверить требования. Макет дизайна, как можно быстрее и недорого, и просмотрите его с клиентами. Если это вообще возможно, сделайте это таким образом, чтобы обзор мог быть структурирован как пошаговое руководство по задаче, чтобы разработчики и пользователи вместе могли пройти через варианты использования и решить, решает ли предложенный дизайн проблему. Затем, если необходимо, сделайте это снова.

там отличная книга по сбору и пониманию требований называется анализ пользователя и задачи для дизайна интерфейса Джоанн Хакос и Дженис Редиш. Это большая книга, но она очень удобочитаема и наполнена практическими советами и инструментами.

что делает плохое требование? Тот, которого там нет

Я вижу много хороших ответов здесь о плохом требовании, которое является неправильным или наполовину испеченным. И они, вероятно, правы.

но для меня один из худших типов "плохого требования" - это тот, который просто отсутствует. Я вижу это снова и снова в систем. Через день после выхода в эфир пользователи говорят: "о, как насчет XYZ? Нам это действительно нужно."На что отвечает команда проекта, - КСИ что? Мы работали над этим проектом в течение года и теперь Вы нам расскажете?"

почему это плохо?

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

опять же, это не плохое требование, но тот, который был никогда не требование, чтобы начать с. Это не означает, что он недействителен; он, безусловно, может быть критическим. Но из-за спешки и агрессивного темпа проекта, и того факта, что мы все люди и совершаем ошибки, это было упущено.

Как вы избегаете этого?

вы могли бы провести больше времени впереди и надеяться, что острый предмет эксперт поднимает недостающую щель. Более эффективным и дорогостоящим методом является использование того, что некоторые называют фазой "типового офиса". Это похоже на системный тест, но предназначено для имитации реальных условий жизни. Тестировщики не просто проверяют правильность вывода системы для 1 + 1, но и то, что все ее части работают в контексте бизнес-процесса.

Это, конечно, трудно продать. Многие проекты дадут бизнес-анализ и тестирование short shrift для того, чтобы поддерживайте всемогущие показатели "вовремя и по бюджету". Но если вы хотите избавиться от этих отсутствующих требований, вы должны позволить пользователю работать с ним. Именно тогда они узнают вещи, которые они принимали как должное в словесном сеансе определения требований. Специалисты Agilists добавят, что этот тест необходимо проводить как можно раньше и как можно чаще, чтобы выявить эти риски и дать проектной группе Время для определения своих приоритетов и внесения коррективов, когда это необходимо.