Большинство людей с удивлением узнают, что документальный подход ведет к неоптимальным результатам. «Пользовательские истории в Agile» и «спецификация на примере» заменяет традиционные документы с требованиями от заказчика на общение и семинары по спецификациях, в которых команда определяет примеры их работы, которые потом будут тестироваться. Но где же разница между традиционным документированием требований и, тем, как команда Agile прорабатывает требования в этом коллаборационном процессе?
Виды коммуникации при реализации проекта разработки программ. Существует пять условий, при которых происходит коммуникация:
Наипростейший способ передачи сообщения – его прямая передача от отправителя к получателю, которая ведет прямо к передаче знаний.
Условие № 1 не требует внесения изменений сообщение или его расширения; каждая сторона понимает другую без каких-либо дальнейших переговоров.
Условие № 2 требует немного больше работы; сообщение должно быть преобразовано, чтобы быть понятым. Например, при использовании мобильного устройства для чтения романа, вы не поддаете пониманию непосредственно электрические сигналы. Дисплей представляет собой преобразованную версию цифровой книги, чтобы можно было понять, содержащуюся в нем информацию. Это прямое преобразование сообщения не продливает и не сокращает его.
Когда связь не может быть достигнута в условиях 1 и 2, сообщение должно быть обогащено, условием № 3. Например, показывая кому-то схему разработки через тестирование (TDD), доставка сообщения может упустить детали о том, как это работает, в то время как книга по теме передает эти знания эффективно.
Традиционный документ спецификаций дает еще один пример. Во время семинара сбора требований, бизнес-пользователи обсуждают свои пожелания к продукту с членами команды разработчиков, которые затем создают расширенную версию данной коммуникации в документе спецификаций для всей команды разработчиков.
Иногда все вышеупомянутые действия по-прежнему не передают нужную информацию. Условие № 4 состоит в передачи сообщения, а также физические изменения на принимающей стороне, например, внесения в них изменений. Вспомните, когда вы узнали, как ездить на велосипеде.
Последнее условие для передачи информации, условие № 5, состоит из сообщения плюс гибких и физических изменений на принимающей стороне.
Например, в социальном контексте, молодые люди должны в конечном итоге вырваться из прави, которые они ранее поллучили от взрослых, и применить знания полученные на практике при поведении в социальных кругах.
Что такое семинар по спецификации?
Давайте внимательнее посмотрим на то, что же такое семинар по спецификациям, для того, чтобы понять, какие типы коммуникации происходят во время их проведения, и почему они фактически замещают традиционный сбор требований. Семинар обычно включает троих разных специалистов:
- Клиент или владелец продукта
- Программист
- Эксперт по тестированию
Вы можете начать такой семинар, имея только этих трех людей, или вы можете провести официальную встречу. В любом случае, эти три роли вносят основную экспертизу проекта разработки ПО под заказ:
Клиенты имеют неявные знания о бизнесе, как он работает в настоящее время, и то как будущее программное обеспечение может помочь им более эффективно выполнять свою работу.
Конечные пользователи знают, как они хотят применять программное обеспечение, из каких шагов в настоящее время состоят процедуры, и конкретные базовые правила их работы.
Программисты имеют неявные знания о том, как построен программный код в настоящее время, то, какие альтернативные варианты архитектуры возможны для новых функций, и какие виды реализуемых в настоящее время правил могут противоречить новому функционалу в будущем.
Тестеры знают о некоторых ограничениях системы из прошлого, а также некоторые подробности о реализуемых в настоящее время бизнес-правилах. Они также приносят критическое мышление – способность видеть, где одно правило может противоречить другому, или, где часть системы должна меняться вместе с функционалом, который обсуждается в настоящее время командой.
На таком семинаре спецификации, команда обсуждает любые предстоящие реализации в течение следующих итераций продукта. Программисты и тестеры поднимают все открытые вопросы о том, как они должны понимать, бизнес-правила. Они выявляют пробелы и выводят критерии приемлемости, чтобы знать, поменяеься та или иная функциональность. Клиенты объясняют, как они работают, а также правила и принципы, которыми они руководствуются, чем они также помогают команде.
Семинары по спецификациям проясняют ситуацию
Организация таких семинаров может показаться простой. Позовите нужных людей к столу, обсудите будущие функции, определите критерии приемки, и реализуйте их. Многие команды начинают с таким подходом, и они четко определяют проблемы заранее.
Кроме того, семинар по спецификациям приносит общее понимание бизнес-логики и системы. В общем, это помогает команде разработать качественный продукт, который будет приносить успех бизнесу заказчика.
Подготовлено компанией PNN Soft