Понятие «архитектура» обычно определяют как “структурная декомпозиция системы, включающая ее разделение на части, их связность, механизмы взаимодействия и руководящие принципы, которые формируют проект системы.” [1]

Хотя, с технической точки зрения это не такое уж ошибочное определение, оно все же достаточно вольно интерпретируется.

В новой версии Devprom мы реализовали несколько важных доработок, которые позволят вам использовать современные практики работы с документацией при разработке требований и тестовой документации, а также более детально планировать работы в Kanban-проектах или проектах другого типа, в которых не используется планирование по релизам или итерациям:

- версионирование требований и тестовой документации

- создание подзадач в Kanban-проекте

- редактирование структуры документа путем перетаскивания разделов в дереве

- использование локального времени пользователя

Совместная работа членов проектной команды является ключевой ценностью процесса гибкой разработки и наравне с выявлением уровня зрелости требований и практикой визуализации требований, позволяет выстроить процесс приоритезации требований в Agile проекте. Совместная работа способствует развитию общего и неявного знания; она стимулирует ход общения, переговоров и соглашения во многих аспектах.

Следующим элементом модели приоритезации требований в Agile проектах, после оценки уровня зрелости требований, является практика визуализации требований. Разработчики сообщества Agile согласны с тем, что степень прозрачности является ключевой ценностью гибкости [12]. Одним из наиболее успешных подходов к улучшению прозрачности считается визуализация требований.

Одним из элементов в методике приоритезации требований в Agile проектах является оценка уровня зрелости требований, согласованного с заинтересованными лицами. Требования разрабатываются со временем. Начиная от смутного представления о заинтересованном лице, требование постепенно превращается в набор более конкретных фичей, пользовательских историй и задач, что в итоге становится частью протестированного программного продукта (на основе критериев приемки).