Меня спрашивали, что должна делать команда, когда характер проекта исключает вертикальные срезы в их готовых историях.
Определение «Постепенной разработки» представлено здесь: https://www.agilealliance.org/glossary/incremental-development/
В верхней части этого документа находится следующее:
в контексте Agile это означает, что каждую последующую версию продукта можно использовать, и каждая из них основывается на предыдущей версии, добавляя видимые пользователю функции.
Недавно у меня был запрос вида:
Что происходит в agile-проекте, когда природа создаваемого программного обеспечения просто не имеет предыдущей версии, на которую можно было бы опираться, и, следовательно, не может предоставить последующую, пригодную для использования версию? Например, уровни программного обеспечения в мобильном телефоне, частью которого еще не является «телефон» и которые, скорее всего, не требуют ввода данных пользователем и просто предоставляют услуги другим функциональным единицам.
Короче говоря, как вы можете реализовать INVEST, когда кажется, что в истории недостаточно глубины для этого.
(Ранее я был свидетелем того, как скрам-мастер в веб-проекте принудительно выполнял полную работу DB-to-UI над каждой историей — буквально — и, да, это вызывало много трений.)
После первых двух спринтов продукт Scrum всегда должен находиться в потенциально готовом к выпуску состоянии. По сути , это означает, что всегда есть что продемонстрировать на демо-версии Sprint, но вам, возможно, придется проявить творческий подход и «нестандартно мыслить», чтобы найти это. Относитесь к демонстрациям как к первоклассным рабочим продуктам во время планирования спринта, чтобы упростить разработку демонстраций и сделать их более интуитивно понятными.
Что происходит в agile-проекте, когда природа создаваемого программного обеспечения просто не имеет предыдущей версии, на которую можно было бы опираться, и, следовательно, не может предоставить последующую, пригодную для использования версию? Например, уровни программного обеспечения в мобильном телефоне, частью которого еще не является «телефон» и которые, скорее всего, не требуют ввода данных пользователем и просто предоставляют услуги другим функциональным единицам.
Это распространенное непонимание того, что означает «итеративный» или «инкрементный» в контексте гибкой разработки. Это никоим образом не означает, что у вас должна быть предыдущая версия программного обеспечения; это означает, что будущие версии могут (и, как правило, должны) опираться на проделанную ранее работу. Agile-проекты значительно выигрывают от эмерджентного дизайна, и agile-фреймворки оптимизируются для этого.
API-интерфейсы и промежуточное ПО могут расти и развиваться небольшими проверяемыми шагами точно так же, как и любое другое программное обеспечение, поэтому нет ничего ортогонального, чтобы инвестировать в такие системы. Версии API и промежуточного программного обеспечения можно изменять, изменять и расширять почти так же, как и более традиционное программное обеспечение.
В API-интерфейсах или промежуточном программном обеспечении нет ничего, что мешало бы им сохраняться в потенциально готовом к выпуску состоянии или демонстрироваться. Такие системы все равно должны что-то делать , и если вы можете это протестировать, то вы можете это продемонстрировать.
Сказав все это, что, кажется, сбивает многих людей с толку, так это сложность демонстрации новых функций в продукте, который не поддается легкому визуальному представлению. Для этого часто требуется немного больше творчества и опыта гибкого тестирования, чем у многих магазинов, когда они начинают свое гибкое путешествие. Некоторые распространенные решения включают в себя:
Использование исполняемых тестов для демонстрации.
Огурец — отличный тому пример. Наблюдение за тем, как хорошо написанные тесты (и, следовательно, документация, описывающая поведение) становятся зелеными, является вполне реальной демонстрацией для многих типов программного обеспечения.
Использование вашей системы разработки или тестирования QA для демонстраций.
Почти любой бренд TDD/BDD или непрерывной интеграции потребует определенного уровня абстракции тестов. Макеты, заглушки, фикстуры и фабрики часто заменяют другие части «настоящей» архитектуры даже в интеграционных тестах. Ничто не мешает вам использовать такие методы, чтобы заглушить функциональность клиентов API или промежуточного программного обеспечения в ваших демонстрациях Sprint.
Создайте «демонстрационный клиент».
Смысл в том, чтобы показать, что ваш продукт что-то делает. Если вы не можете показать это на месте, вы можете, по крайней мере, создать макет или симулятор, показывающий, как клиент API или промежуточного программного обеспечения будет взаимодействовать с вашим кодом. Продемонстрируйте это взаимодействие!
Документация, круговые диаграммы и другие наглядные пособия.
Демонстрация спринта предназначена для демонстрации прогресса и получения отзывов заинтересованных сторон для использования в будущих спринтах. Хотя все абстракции негерметичны, если вы действительно не можете представить себе какой-либо другой способ продемонстрировать приращение работы, вы всегда можете использовать вторичные артефакты. Познакомьте людей с кодом, историей коммитов, живой документацией API, такой как Swagger, или другими вещами, которые обеспечивают правильное представление о текущем состоянии продукта.
Scrum предписывает демонстрировать приращения работы, но не предписывает , как должны выполняться демонстрации. Нет требования, чтобы для демонстрации требовалась клавиатура или графический интерфейс. Если это имеет отношение к продукту, скайрайтинг или интерпретирующий танец могут быть столь же уместны для демонстрации.
Цель фреймворка — избежать традиционной отчетности о состоянии и дать заинтересованным сторонам возможность «больше показывать, меньше говорить». Если команда не сможет найти способ продемонстрировать приращение работы, осмелюсь предположить, что им тоже будет очень трудно его протестировать.
Среды TDD/BDD лучше всего работают, когда вы сначала разрабатываете тесты, а не пишете их постфактум; это упрощает тестирование и гарантирует, что продукт создан для тестирования ab initio . Демонстрации спринта ничем не отличаются. Во время планирования спринта команда должна учитывать то, как они планируют демонстрацию работы, в своих пользовательских историях и оценках на внешнем, а не на заднем плане.
Иногда планирование демонстраций может изменить то, как вы разделяете истории, или как вы планируете или оцениваете работу. Если так, отлично! Это означает, что вы используете фреймворк.
Относитесь к демонстрациям как к первоклассному рабочему продукту, а не как к второстепенным. Когда вы переформулируете работу таким образом, лучший способ продемонстрировать приращения работы обычно становится очевидным.
тл;др; Постарайся. Старайтесь всегда создавать проверенные знания или полезную функциональность. Всегда ищите отзывы пользователей. Не переживайте, если не видите хорошего варианта.
Целью этой практики было производство приращений продукта. В Agile мы хотим избавиться от идеи, что мы знаем «правильное» решение и нам просто нужно его закодировать. Это почти никогда не бывает.
В этом видео объясняются различные типы управления процессами, а скрам использует эмпирические данные. ( https://www.youtube.com/watch?v=S-VaiB3uPdk ) В нем цель всегда состоит в том, чтобы сделать следующий маленький шаг и посмотреть, насколько он приблизит нас к нашему ответу. Проектирование базы данных — это здорово, если мы контролируем определенный процесс, потому что мы уже точно знаем, каковы все шаги, и вопрос лишь в том, как их проработать. Это ужасно для эмпирического управления процессом, потому что вы мало что из него узнаете или вообще ничего не узнаете. Вы знаете, что работали, но нет никакого способа сказать, правильная ли это работа.
Итак, если вы спрашиваете себя, каков будет следующий шаг и как вы будете использовать следующую прибавку к продукту, чтобы узнать что-то о том, как ваш клиент будет использовать продукт и что на самом деле означает для вас «готово», вы, вероятно, находитесь на верном пути. правильный путь, даже если вы не закончите кодирование функциональности пользовательского интерфейса.
Даниэль