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

Большая часть методологий гибкой разработки состоит в том, чтобы принять тот факт, что требования БУДУТ изменяться.

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

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

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

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

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

• I - независимые
• N - обсуждаемые
• V - ценные
• E - оценочные
• S - маленькие
• T - проверяемые

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

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

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

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

• testable

Или вы работаете над «разомкнутым циклом», и я уверен, что вы понимаете последствия.

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

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

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

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

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

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

Вероятно, они имеют в виду «неправильно переданные» требования.

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

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

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

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

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

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

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

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

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

Класс XProperties Криса Мэра может стать хорошей отправной точкой.

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

CONST_1 = shoes and ships
CONST_2 = sealing wax
SomeValue = {CONST_1} and {CONST_2} 

В этом примере свойство SomeValue оценивается как «обувь и корабли и сургуч. "

См. также: http://webcache.googleusercontent.com/search?q=cache:gCgFCpEgmsgJ:www2.sys-con. Возможный способ справиться с этим либо означает наличие хороших бизнес-аналитиков, которые могут выполнить требуемый анализ или иметь хороший готовый продукт, который мог бы удовлетворить этого пользователя (или нет).

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

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

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

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

Но для меня один из худших типов «плохих требований» - это то, чего просто не хватает. Я вижу это снова и снова в системах. Через день после запуска пользователи говорят: «А как насчет XYZ? Нам это действительно нужно». На что команда проекта отвечает: «XY что? Мы работали над этим проектом год, и СЕЙЧАС вы нам рассказываете?»

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

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

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

Как этого избежать?

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

Конечно, это нелегкая сделка. Многие проекты будут содержать бизнес-анализ и тестирование в кратчайшие сроки, чтобы поддерживать всемогущие показатели «вовремя и в рамках бюджета». Но если вы хотите избавиться от этих недостающих требований, вы должны позволить пользователю работать с ними. Именно тогда они узнают то, что они считали само собой разумеющимся на сеансе устного определения требований. Agilists добавят, что этот тест необходимо проводить как можно раньше и как можно чаще, чтобы выявить эти риски и дать команде проекта время определить свои приоритеты и внести коррективы, если это необходимо.