Я часто слышу, что "X% проекта программного обеспечения выходит из строя из-за плохих требований". X в этом заявлении варьируется от 70 до 95. Однако я редко слышу, как требования ухудшаются. Фактически, само утверждение предполагает, что на самом деле были требования.
Что делает "плохое" требование? Как можно избежать?
Для успешного получения требований вам нужно
Обычно проблема заключается в отсутствии связи и понимания между клиентом и разработчиком. Кроме того, имейте в виду, что иногда даже сам клиент точно не имеет хорошей картины того, что он хочет. Поэтому обсуждение, прототипы бумаги и т.д. Действительно важны.
Эта фотография моя любимая:)
Большая часть гибких методологий разработки заключается в том, чтобы принять тот факт, что требования будут изменены.
Следовательно, вы не должны пытаться бороться с этим и вместо этого создавать процесс, который охватывает это.
Всякий раз, когда я вижу эти статистические данные, мне вспоминаются дорогие, тяжелые проекты с водопадом, где первый выпуск был завершен и представлен клиенту, который быстро сказал проекту: "Это не то, что я хотел".
Вот почему большинство успешных проектов в настоящее время выполняется с использованием "итеративной" модели, где клиент постоянно участвует в процессе проектирования.
В этом контексте "требования" более четко определены, и они несколько развиваются по мере продвижения проекта.
В гибком режиме мы используем акроним INVEST. Истории (которые соответствуют требованиям) должны быть:
Требования не являются артефактом, который будет передан вам с вершины горы. Они являются жизненным побочным продуктом процесса обнаружения и разговора между вами и вашими клиентами (или их доверенными лицами).
Во-первых, для требования быть действительным он должен быть testable. Если нет, нет возможности отслеживать его, измерять, сообщать об этом... это первопричина зла.
Как можно избежать этой ситуации? Убедитесь, что требование:
ограничено как временем, так и ресурсами (например, $)
проверяемым
Или иначе вы работаете над "открытым циклом", и я уверен, что вы можете оценить последствия.
Примечание, которое иногда требует скорее "качественного" характера: менеджеру/команде продукта следует определить "количественное" определение.
Я думаю, вы обнаружите, что если вы интерпретируете его следующим образом, это будет иметь больше смысла:
"X% программных проектов выходит из строя из-за плохого определения требований"
Есть много вещей, которые вы можете сделать
В дополнение к невозможным/нецелесообразным или непроверенным требованиям, "плохое", вероятно, относится к неправильно собранным требованиям - они не соответствуют тому, что действительно необходимо для приложения. Одним из источников этого является то, что пользователи часто не знают, что им нужно или хотят.
Возможно, они означают "неверно отрешенные" требования.
Если вы думаете об этом, есть много способов, которыми вы можете неправильно устанавливать требования, преднамеренно или иначе. Некоторые способы решения проблемы:
Поймите, что требования системы могут непрерывно меняться. В противном случае клиент скажет: "Да, что изменилось, никто не сказал вам?"
Спросите требования нескольких ключевых людей - недостаточно спросить генерального директора, а также недостаточно спросить нижние ряды, которые фактически будут использовать вашу систему.
Удостоверьтесь, что для передачи вам требований требуется несколько человек. Эти люди (не более 5 в проекте среднего размера) должны обладать БОЛЬШИМ стимулом, чтобы предоставить вам всю информацию для успешного реализация. Если у вас нет этих людей, вы, скорее всего, потерпите неудачу, потому что все будут слишком заняты, чтобы объяснить вам вещи, и у них будет стимул, чтобы не разговаривать с вами, так как вы сможете требовать, чтобы X человек сказал вам реализовать как они это сделали. Вам нужна поддержка управления при создании этой группы людей.
Вам нужно проверить допущения с другими людьми. Иногда вам нужно задать один и тот же вопрос пятью разными способами.
Бойтесь абсолютов... "Цена продажи не может быть изменена" иногда означает "Я бы хотел, чтобы надбавка супервизора была реализована в случае, если цена должна быть изменена для текущего клиента".
Понимать бизнес-процесс как можно больше. Если вы пишете банковское приложение, попросите провести день в банке, чтобы узнать, как люди будут использовать систему. Если вы выполняете этап проекта, сделайте то же самое: следите за тем, чтобы система использовалась, и проявляйте инициативу в поиске дыр.
Признайте, когда что-то не указано достаточно подробно, и настаивайте на том, чтобы все было правильно. Сделайте макеты, чертежи вручную, блок-схемы, все, что требуется, чтобы убедиться, что источник требований и вы находитесь на одной странице.
Все это только из опыта... Я думаю, что "плохие требования" действительно означают "плохие связи между клиентом и разработчиком".
Мой опыт показывает следующие возможные источники плохого:
Что нужно сделать для преодоления этих проблем? Позвольте инженерам предоставить отзывы, не закрывать требования и сделать их максимально гибкими. Часто даже при хороших согласованных требованиях мы сталкиваемся с ограниченным аппаратным ограничением на этапе реализации и должны отслеживать изменения. С другой стороны, пусть понимают клиентов, а не только технологии. Я видел количество проектов с большой частью работы, выброшенных просто потому, что они выглядят хорошо для разработчиков, но не для клиентов. Лучшая связь с клиентом у вас ниже - возможность таких случаев.
Мое понимание заключается в том, что процесс должен позволять гибкие требования меняться на всех этапах, но с другой стороны должно сделать всю эту работу отслеживаемой и ограничить область до минимума, которая требуется. Проблема состоит в том, чтобы сбалансировать все это. По крайней мере, мое предложение состоит в том, что мы должны перейти к кратчайшим циклам разработки, чтобы снизить все риски.
Одна из самых ценных вещей, которые организация развития может делать (но редко делается), - это проверка требований. Выполните макет дизайна, как можно быстрее и дешевле, и просмотрите его с клиентами. Если это вообще возможно, сделайте это так, чтобы обзор мог быть структурирован как прохождение пошагового задания, поэтому разработчики и пользователи вместе могут пройти через варианты использования и решить, разрешает ли предлагаемый проект проблему. Затем, при необходимости, сделайте это снова.
Там отличная книга по сбору и пониманию требований, называемых User and Task Analysis для дизайна интерфейса JoAnn Hackos и Janice Redish. Это большая книга, но она очень читаема и наполнена практическими советами и инструментами.
Что делает плохое требование? Тот, который не существует
Я вижу здесь много хороших ответов о том, что плохое требование - это то, что неправильно или полупечено. И они, вероятно, верны.
Но для меня один из худших типов "плохого требования" - это тот, который просто отсутствует. Я вижу это снова и снова в системах. На следующий день после концерта пользователи говорят: "О, как насчет XYZ? Нам это действительно нужно". На что отвечает команда проекта: "XY, что? Мы работаем над этим проектом в течение года, а ТЕПЕРЬ вы нам рассказываете?"
Почему это плохо?
Это убийца, потому что теперь каждый должен скремблировать и вытеснять решение, а не то, что средний разработчик нуждается в какой-либо помощи, способствующей полуподобным вещам для производства, но вы просто знаете, что это будет означать много поддержки производства для всех бедные люди, это "решение" передано на обслуживание... вы знаете, те, которые не получали бонусы за проект.
Опять же, это не плохое требование, но это никогда не требовалось начинать. Это не означает, что он недействителен; это, безусловно, может быть критическим. Но между спешкой, чтобы добиться успеха и агрессивным темпом проекта, и тем фактом, что мы все люди, и мы совершаем ошибки, это было упущено.
Как вы его избегаете?
Вы могли бы потратить больше времени на фронт и надеяться, что эксперт по предметным темам соберет недостающий пробел. Более эффективный и более дорогостоящий метод занимает время, чтобы задействовать то, что некоторые называют фазой "модельного офиса". Это похоже на системный тест, но предназначенный для имитации реальных условий жизни. Тестеры не просто проверяют, что система обеспечивает правильный вывод для 1 + 1, но все его части работают в контексте бизнес-процесса.
Конечно, это трудная продажа. Многие проекты дадут бизнес-анализ и проверку короткого стресса, чтобы отстоять всемогущие показатели "вовремя и по бюджету". Но если вы хотите избавиться от этих недостающих требований, вы должны позволить пользователю работать с ним. Тогда они узнают то, что они считают само собой разумеющимся на сессии определения словесных требований. Агилисты добавили бы, что этот тест нужно сделать как можно раньше и как можно чаще, чтобы выявить эти риски и дать время проектной группе определить свои приоритеты и внести коррективы там, где это оправдано.