Отчасти трудность с точки зрения написания клиентом документа спецификаций заключается в том, что клиент часто не знает, как перевести то, что хочет клиент, на язык, который фактически описывает то, что ему нужно. В то время как клиент может сказать, что он хочет, чтобы в системе существовало определенное поведение, он, как правило, не столь озабочен мелочами, пока не увидел и не использовал и не испытал программное обеспечение, работающее таким образом, что, по его мнению, клиент не совсем соответствует необходимо.
Когда клиенты описывают бизнес-процесс, они часто пропускают много важной информации. Часто эта информация относится к вещам о процессе, которые обычно понимаются в конкретном домене клиента и поэтому воспринимаются как должное и часто не передаются программисту. В других случаях заказчик на самом деле не знает, как справляться со всеми граничными условиями в системе, и обращается за помощью к программисту. Иногда это простой случай юзабилити, когда клиент думает, что он хочет, чтобы что-то работало одним способом, но потом передумал, когда стало яснее, что все должно работать по-другому.
Итак, достаточно «отношений с клиентами для программистов». Вопрос заключается в том, имеет ли еще смысл, чтобы клиент использовал читаемый бизнес DSL, чтобы определить, как определить спецификацию. Я полагаю, что с руководством ответ является предварительным «да», и я говорю предварительный, потому что следующий вопрос, который приходит на ум, - зачем вам заказчик создавать DSL, если у вас может быть программист, который легче определит тот, который будет предоставить клиенту простой, но богатый язык, чтобы определить, как система должна работать?
Когда вы предоставите клиенту язык для описания того, как он хотел бы, чтобы система работала, вы получите в итоге утверждения, которые говорят что-то вроде:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Этот тип заявления в конечном итоге описывает требование в очень четкой форме, предоставляя общую форму, которую клиент в основном желает принять в системе, или другой способ взглянуть на это, что клиент описывает, что представляет собой система. Если вы хотите, чтобы ваш клиент думал о вещах немного дальше, вы можете попросить их описать правила, которым должна следовать функция, используя ряд утверждений, подобных, возможно, следующим:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Опять очень четкие описания, на этот раз о том, каксистема должна вести себя Дело в том, что это не заменит необходимость для разработчика программного обеспечения заполнить все пробелы и выявить дополнительные детали, о которых клиент может знать только на периферии. В то время как клиент может быть «обучен» программистом описывать функции и поведение в удобном для программиста формате, у клиента не будет ни навыков, ни знаний для создания значимых тестовых случаев, ни для обеспечения реализации. код. Это было, я думаю, смысл статьи Мартина Фаулера, на которую ссылался ФП. Так что да, само программное обеспечение не доступно для записи клиенту, но описание программного обеспечения, безусловно, может - и ИМХО должно - быть написано клиентом. Что бы это ни стоило, я не читал статью Фаулера о том, что клиент не должен
Я чувствую, что мы, программисты, иногда можем забыть, что наши клиенты, как правило, очень умны с точки зрения понимания своего бизнеса и бизнес-процессов, и, конечно, намного лучше, чем мы. Когда у них нет программиста, который мог бы рассказать им, как создать программную систему, клиенты обычно прибегают к другим - возможно, менее эффективным - способам решения своих конкретных проблем управления бизнесом. Под этим я подразумеваю простые базы данных (например, Access), электронные таблицы или даже рукописные книги, а также четко определенные правила и процедуры для управления этими процессами. Чего не хватает многим клиентам, это не средство определения того, как должна работать система, а то, как она должна быть построена , и, что более важно, насколько эффективно описывают поведенческие правила системы для людей, которыеу меня есть навыки, чтобы реально построить систему.
Если действительно существует консенсус по поводу отсутствия возможности записи, то увидите ли вы проблему с инструментом, который вместо того, чтобы начинать со сценариев и инструментировать их, генерировал бы читаемые бизнес-сценарии из реальных тестов?
Я думаю, что это смотрит на проблему неправильно. Я видел бы большую проблему с инструментом, который генерирует документацию из тестов, если эта документация была предназначена для представления спецификации каким-либо образом. Чтобы протестировать сценарий, вы должны его понять, поэтому сценарий должен уже существовать, чтобы вы оба определили для него тест. Если вы описываете сценарий в BDD-синтаксисе, то вы уже указали его, и, таким образом, вы можете использовать сценарии только после факта. Если, с другой стороны, у вас был инструмент, который позволил бы клиенту описать систему в удобном DSL, дружественном к программированию, и если этот инструмент можно было бы использовать для генерации шаблонов кода, которые будут использоваться в качестве набора тестов, то я ' Я бы сказал, что такой инструмент будет иметь большую ценность. Это не приведет к тому, что клиент выведет программистов из этого уравнения, и поможет уменьшить усилия, необходимые для удовлетворения пожеланий клиента и генерировать тестовые кодированные требования в стиле BDD, и, возможно, сделает пожелания клиента более понятными. Однако это не заменит опытного разработчика программного обеспечения, который поможет клиенту отделить потребности клиента от его потребностей.