Спецификация на примерах, ключевые идеи
| October 22, 2012 | Posted by admin under Практики, Статьи |
http://specificationbyexample.com/key_ideas.html
Автор: Gojko Adzic
Спецификация на примерах (specification by example) – это набор процессных шаблонов, которые способствуют созданию правильных, эффективно поставляющихся продуктов. Когда я говорю «правильный продукт», я имею в виду программное обеспечение, которое дает требуемый бизнес эффект или выполняет бизнес цель, поставленную заказчиками или бизнес пользователями, и которое достаточно гибко для будущих изменений, а цена изменения достаточно определенная.
Эти процессы являются шаблонами, потому что они происходят в разных контекстах и дают похожие результаты. Большинство команд реализовали идеи этих процессов путем проб и ошибок, когда стремились внести улучшения и реализовать программное обеспечение более эффективно.
Определение содержания (scope) исходя из целей
Многие команды рассчитывают, что заказчик, product owner или бизнес пользователь придет к ним с содержанием работ до начала реализации. Подразумевается, что все, что предшествует этому, не относится к области программной разработки. Команды рассчитывают, что бизнес пользователи точно определят, чего они хотят, и тогда команды пойдут и реализуют это. Таким вот предположительно образом заказчики будут счастливы. Фактически отсюда начинаются проблемы с построением правильного продукта. Содержание проекта – это на самом деле решение бизнес проблемы или способ достижения бизнес цели. Полагаясь на то, что заказчики дадут нам список пользовательских историй, use case-ов или еще чего-то в этом роде, мы , в действительности, просим их спроектировать решение. Бизнес пользователи – не дизайнеры программного обеспечения. Если они определяют содержание, значит проект не получает пользу от знаний людей из команды разработки. Это часто приводит к созданию программного обеспечения, которое делает то, что просит заказчик, но это не то, что ему действительно нужно, или есть функциональная незавершенность.
Вместо требований, которые являются решением неизвестной проблемы, действительно успешные команды определяют содержание проекта исходя из целей. Они начинают с рассмотрения бизнес цели, которую хочет достичь заказчик. Они совместно определяют содержание, которое позволяет достичь эту бизнес цель, начиная с желаемого бизнес эффекта. Команда приходит к хорошему решению вместе с бизнес пользователями. Бизнес пользователи сосредотачиваются на том, чтобы рассказать о назначении желаемой фичи, на той ценности, которую они ожидают получить от нее. Это помогает всем понять, что же в действительности нужно. Команда может предложить решение, которое дешевле, быстрее, легче поставить или поддерживать, чем то, к чему могли бы прийти сами бизнес пользователи. Для получения дополнительной информации прочитайте про Отображение воздействия (Impact Mapping).
Совместное определение
Если разработчики и тестировщики не участвуют в разработке спецификаций, то эти спецификации нужно отдельно объяснять команде, что оставляет множество возможностей для неправильного понимания и потери важных деталей. Как следствие, бизнес пользователи должны валидировать программное обеспечение после поставки, а команды должны вносить изменения, если валидация провалилась. Это все ненужные переделки.
Вместо того, чтобы полагаться на одного человека, который создаст правильную спецификацию в изоляции, успешные команды вместе с бизнес пользователями вместе определяют решение. Люди с разным опытом используют разные эвристики для решения проблем, и идеи у них разные. Технические эксперты знают, как лучше использовать базовую инфраструктуру и как применить новые технологии. Тестировщики знают, где может сломаться система, и где искать потенциальные проблемы, и эти проблемы должны быть предотвращены в первую очередь. При определении содержания проекта нужно собрать всю эту информацию.
Совместное определение позволяет нам использовать знания и опыт всей команды. Кроме того, создается ощущения коллективного владения спецификацией, что делает людей более вовлеченными в процесс создания системы.
Иллюстрирование на примерах
Обычный язык неоднозначен и зависим от контекста, поэтому любые требования, описанные обычным языком редко бывают полными. Они просто не обеспечивают полный и недвусмысленный контекст для разработки или тестирования. Разработчики и тестировщики должны интерпретировать такие требования для создания программного обеспечения и тестовых скриптов, а разные люди могут интерпретировать сложные концепции по-разному. Это особенно проблематично, когда что-то кажется очевидным, но нам нужна экспертиза в этом домене или знание определенного жаргона для того, чтобы полностью это понять. Небольшие различия в понимании могут дать серьезный накопительный эффект, что часто становится причиной переделок сразу после поставки. Это вызывает ненужные задержки. Вместо того, чтобы ждать, когда спецификации станут писать сразу на языке программирования, успешные команды делают их конкретными, иллюстрируя с помощью примеров. Они определяют и записывают ключевые примеры, типичные примеры для всех важных классов функций, нужных для полноты спецификации. Разработчики и тестировщики часто предлагают дополнительные примеры, которые иллюстрируют краевые случаи или определенные проблематичные области системы. Это проясняет функциональные пробелы и несоответствия и дает уверенность в том, что у всех, кто вовлечен, одинаковое представление о том, что же нужно поставить, а также позволяет избежать переделок, вызванных неверной интерпретацией.
Если система работает правильно для всех ключевых примеров, мы знаем, что она соответствует спецификации, которую мы совместно выработали. Фактически ключевые примеры эффективно определяют, что должна делать система. Они одновременно являются целью для разработчика и критерием оценки того, что система готова. Если ключевые примеры легко понять и обсудить, мы можем заменить требования ключевыми примерами.
Совершенствование спецификации
Открытый диалог во время совместной работы над спецификацией дает общее понимание домена, но полученные примеры часто содержат больше деталей, чем это действительно нужно для иллюстрации определенной фичи. Бизнес пользователи думают о системе с точки зрения пользовательского интерфейса, поэтому они предлагают примеры работы фичи на уровне кликов, ссылок и заполнения полей. Использование таких многословных описаний слишком ограничивает систему и определяет, как что-то должно быть сделано, а не что должно быть сделано. Избыток деталей делает примеры сложнее для обсуждения и понимания. Ключевые примеры должны быть «вычищены», чтобы быть полезными. Совершенствуя спецификацию, удаляя из ключевых примеров лишние детали, успешные команды получают очень конкретный и точный контекст для разработки и тестирования. Цель определяется с детальностью, достаточной для реализации и проверки, но без всякой дополнительной информации. Команды определяют, что должна делать система, а не как.
Очищенные примеры можно использовать в качестве приемочных критериев для поставки. Разработка не завершена, пока система не станет работать корректно для всех этих примеров. Добавив к ключевым примерам некоторую дополнительную информацию, которая делает их проще для понимания, команды получают спецификацию с примерами, которая в то же время является спецификацией работ, приемочным тестом и функциональным регрессионным тестом в будущем.
Автоматизация валидации без изменения спецификаций
Как только мы пришли к соглашениям по спецификациям с примерами и очистили их, мы может использовать их как цель разработки и для валидации продукта. Система много раз будет проверяться на этих тестах в течение разработки, чтобы убедиться, что она соответствует цели. Выполнение этих проверок вручную будет вносить ненужные задержки и замедлять обратную реакцию.
Быстрая обратная реакция – это важная часть разработки программного обеспечения на коротких итерациях или в потоковом режиме, поэтому нам нужно сделать процесс валидации системы дешевым и эффективным. Очевидное решение – это автоматизация. Однако эта автоматизация концептуально другая по сравнению с обычной автоматизацией, которую проводят разработчики и тестировщики. Если мы автоматизируем валидацию ключевых примеров, используя традиционные инструменты unit-тестирования или традиционные инструменты автоматизации функциональных тестов, есть риск возникновения проблем , если что-то потеряется при переходе от бизнес спецификаций к технической автоматизации. Технически автоматизированные спецификации становятся недоступными для бизнес пользователей. Когда требования меняются (именно «когда», а не «если») или когда разработчикам или тестировщикам нужны дальнейшие уточнения, мы не сможем просто использовать спецификацию, которую уже автоматизировали. Мы могли бы хранить ключевые примеры в более читабельной форме, например в виде документов Word или web страниц, но как только появится несколько версий, у нас возникнут проблемы с синхронизацией. Вот почему объемная бумажная документация никогда не бывает до конца корректной.
Чтобы получить максимум из ключевых примеров, успешные команды автоматизируют валидацию без изменения информации. Они оставляют спецификацию без изменений, когда проводят автоматизацию, без каких-либо рисков связанных с переводом. Поскольку они автоматизируют валидацию, не меняя спецификации, ключевые примеры остаются почти в той же форме, как они выглядели на доске – читабельными и доступными всем членам команды.
Автоматизированная спецификация с примерами, в читабельной форме, доступная всем членам команды, становится выполняемой спецификацией. Мы можем использовать ее как цель разработки и легко проверять, делает ли система то, о чем мы договорились. Мы можем использовать тот же документ, чтобы получить уточнения у бизнес пользователей. Если нужно изменить спецификацию, нужно делать это только в одном месте.
Частая валидация
Чтобы эффективно поддерживать программную систему, нам нужно знать, что она делает и почему. Во многих случаях единственный способ сделать это – залезть в программный код или найти кого-то, кто может это сделать, если вы не эксперт по иероглифам. Часто код – это единственная вещь, которой мы действительно доверяем. Большинство написанной документации устарело еще до того, как проект поставлен. Программисты становятся оракулами знаний и узким местом для получения информации. С выполняемой спецификацией можно легко провалидировать систему, чтобы проверить делает ли она то, что должна. Если валидация происходит часто, то мы будем уверены в выполняемой спецификации, так же как и в коде.
Часто проверяя все выполняемые спецификации, команды быстро находят разницу между системой и спецификациями. Поскольку их выполняемые спецификации легко понять, команды могут обсудить изменения со своими бизнес пользователями и решить, как справиться с проблемами. Они постоянно поддерживают синхронизацию между системой и выполняемой спецификацией.
Развитие системы документации
Большинству успешных команд не достаточно множества часто валидирующихся выполняемых спецификаций. Они хотят быть уверены, что спецификации хорошо организованны, легко доступны и согласованны. По мере развития проекта, у команды появляется понимание изменений домена. Рыночные возможности становятся причиной изменений в модели бизнес домена. Команды, которые получают максимум из Спецификаций на примерах, вносят изменения в спецификации, чтобы отразить эти изменения, развивая живую систему документации. Живая документация заменяет все артефакты, которые нужны команде для поставки правильного продукта, и это хорошо подходит для коротких итеративных или потоковых процессов.
Живая документация – это надежный и авторитетный источник информации по системной документации, который доступен всем. Она так же надежна как код, но ее намного легче читать и понимать. Группа поддержки может использовать ее, чтобы понять, что система делает и почему. Разработчики могут использовать ее как цель разработки. Тестировщики могут использовать ее для тестирования. Бизнес аналитики могут использовать ее как начальную точку, анализируя запросы на изменение функциональности. И, кроме того, мы бесплатно получаем регрессионные тесты.
Живая документация – это конечный продукт Спецификации на примерах. Для создания системы живой документации многие команды приходят к определению специфичного для домена языка, с помощью которого создаются спецификации и тесты. Они структурируют свои спецификации на этом языке, чтобы поддерживать их согласованность, легкость в понимании и минимизировать цену поддержки. При создании выполняемых спецификаций для уже существующих продуктов, командам часто нужно сделать систему и архитектуру более тестируемой, тогда требуется спланировать и реализовать серьезные изменения, касающиеся дизайна.
Pingback: HoT NeWs » Построение эффективных команд()