Agile-моделирование: принципы и практика гибкой разработки программного обеспечения

Введение

Agile modeling (AM) — это методология моделирования и документирования программных систем, основанная на передовых практиках. Это совокупность ценностей и принципов, которые могут быть применены в проекте разработки программного обеспечения (agile). Данная методология более гибкая, чем традиционные методы моделирования, что делает её более подходящей для быстро меняющейся среды. Она является частью набора инструментов для гибкой разработки программного обеспечения. Agile modeling дополняет другие методологии гибкой разработки, такие как Scrum, экстремальное программирование (XP) и Rational Unified Process (RUP). Она явно включена в состав фреймворка Disciplined Agile Delivery (DAD). По данным статистики за 2011 год, на agile modeling приходилось 1% от всей гибкой разработки программного обеспечения. Agile modeling является одной из форм Agile model driven engineering (Agile MDE), которая была внедрена в различных областях применения, таких как разработка веб-приложений, финансы и автомобильные системы.

Документация

Документируйте непрерывно. Документация ведется на протяжении всего жизненного цикла, параллельно с разработкой остальной части решения. Документируйте как можно позже. Документация создается как можно ближе к моменту необходимости, избегая преждевременных предположений и фокусируясь на стабильной информации. Исполняемые спецификации. Требования задаются в виде исполняемых "приемочных тестов", а не в виде неисполняемой "статической" документации. Единственный источник информации. Информация (модели, документация, программное обеспечение) хранится в одном месте, чтобы исключить вопросы о том, какая версия / информация является "актуальной".

Моделирование

Активное участие заинтересованных сторон. Заинтересованные стороны моделируемого решения/программного обеспечения должны быть активно вовлечены в процесс моделирования. Это развитие практики непосредственной работы с заказчиком, используемой в Extreme Programming. Архитектурное видение. Команда выполняет быстрое, высокоуровневое моделирование, достаточно хорошее для текущих целей (JBGE) в начале проекта, чтобы исследовать архитектурную стратегию, которая, по мнению команды, будет наиболее эффективной. Доступные инструменты. Следует отдавать предпочтение инструментам моделирования, таким как доски и бумага, с которыми легко работать (они способствуют вовлечению). Итерационное моделирование. Если требование/задача не было достаточно подробно изучено с помощью предварительного моделирования, команда может провести такое исследование в рамках планирования итерации/спринта. Необходимость этого обычно указывает на то, что команда недостаточно занимается предварительным моделированием. Достаточно хорошее для текущих целей (JBGE). Все артефакты, включая модели и документы, должны быть достаточными для решения текущей задачи. JBGE носит контекстуальный характер: в случае модели его определяет сочетание сложности моделируемого объекта и уровня подготовки аудитории. Предварительное моделирование. Agile-команда просматривает бэклог на одну или несколько итераций/спринтов вперед, чтобы убедиться в готовности требования/задачи к работе. Также известно как "уточнение бэклога" или "подготовка бэклога" в Scrum. Мозговой штурм моделей. Короткая, часто спонтанная сессия Agile-моделирования. Сессии мозгового штурма моделей проводятся для изучения деталей требования или аспекта дизайна. Разнообразие моделей. Agile-моделировщики должны уметь создавать различные типы моделей (например, пользовательские истории, карты историй, модели данных, диаграммы Unified Modeling Language (UML) и другие), чтобы выбрать наиболее подходящую модель для конкретной ситуации. Приоритезированные требования. Требования должны выполняться в порядке приоритета. Анализ требований. Команда выполняет быстрое, высокоуровневое моделирование, достаточно хорошее для текущих целей (JBGE) в начале проекта, чтобы изучить требования заинтересованных сторон.

Active stakeholder participation. Stakeholders of the solution/software being modeled should be actively involved with doing so. This is an extension of the on site customer practice from Extreme Programming. Architecture envisioning. The team performs light weight, high level modeling that is just barely good enough (JBGE) at the beginning of a software project so as to explore the architecture strategy that the team believes will work. Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive). Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look ahead modeling the team may choose to do that exploration during their iteration/sprint planning session. The need to do this is generally seen as a symptom that the team is not doing sufficient look ahead modeling. Just barely good enough (JBGE). All artifacts, including models and documents, should be just sufficient for the task at hand. JBGE is contextual in nature, in the case of the model it is determined by a combination of the complexity of whatever the model describes and the skills of the audience for that model. Look ahead modeling. An agile team will look down their backlog one or more iterations/sprints ahead to ensure that a requirement/work item is ready to be worked on. Also called "backlog grooming" or "backlog refinement" in Scrum. Model storming. A short, often impromptu, agile modeling session. Model storming sessions are held to explore the details of a requirement or aspect of your design. Multiple models. Agile modelers should know how to create a range of model types (such as user stories, story maps, data models, Unified Modeling Language (UML) diagrams, and more) so as to apply the best model for the situation at hand. Prioritized requirements. Requirements should be worked on in priority order. Requirements envisioning. The team performs light weight, high level modeling that is JBGE at the beginning of a software project to explore the stakeholder requirements.