Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин.
Немного теории: описание методики
IIBA в компетенцию бизнес-аналитика в области Agile (далее Agile-аналитик) относит следующие технологии:
— Определение критериев оценки и приёмки;
— Мозговой штурм;
— Различные методы оценки (метод Delphi, параметрический метод, метод аналогий, трёхточечный метод и т.п.);
— Прототипирование;
— Разработка сценариев и описание прецедентов;
— Моделирование областей для анализа или поставки решений;
— Пользовательские истории.
IIBA не относит технологию моделирования данных к компетенции Agile-аналитика, а относит её к компетенции роли бизнес-архитектора. В то же время, в компетенцию бизнес-архитектора, также как и Agile-аналитика отнесена технология моделирования областей для анализа или поставки решений.
В результате того, что моделированием данных в основном занимается бизнес-архитектор, то Agile-аналитик не видит актуальной взаимосвязи между процессами и данными в системе, что может порождать создание противоречивых сущностей или дублирование функционала в системе.
Для решения этой проблемы Agile-аналитиком разрабатывается матрица, которая называется CRUD.
Практическая часть: разработка CRUD-матрицы
Разработка CRUD-матрицы помогает Agile-команде сконцентрироваться на существенных прецедентах, описывающих бизнес-процесс. CRUD-матрица формируется в виде таблицы, в которой в верхней части перечисляются все классы из диаграммы классов, а в левой части отражается список прецедентов. Задача Agile-аналитика заполнить пересечения между прецедентами и классами следующими комбинациями доступа к экземплярам классов: создание (Create), чтение (Read), обновление (Update) или удаление (Delete).
Таким образом описываются все прецеденты, которые выполняют создание, чтение, обновление или удаление одного или нескольких экземпляров класса.
В качестве примера приведу опыт построение CRUD-матрицы в 2007-2008гг. при планировании разработки автоматизированной библиотечной информационной системы для научно-технической библиотеки (далее АБИС НТБ).
Анализ CRUD-матрицы производится в семь шагов:
1.Проверка полноты построения модели
2.Определение зависимостей
3.Определение пакета типовых работ для разработки
4.Оценка времени, необходимого для разработки
5.Проверка модели на непротиворечивость
6.Определение последующей работы и дополнений функционала
7.Определение приоритетов для разработки и поставки
Шаг 1. Проверка полноты построения модели
На основе CRUD-матрицы проверяется полнота построения модели на предмет целесообразности использования классов или прецедентов в разрабатываемой системе.
К примеру, в рамках перечисленных прецедентов не описано создание или удаление класса “Книжный формуляр”. Данный факт может конечно говорить о том, что “Книжный формуляр” создается и удаляется вне разрабатываемой системы или же о том, что Agile-аналитик не описал прецедент “регистрация книги” или “списание книги”, а для этого нужно ввести еще один класс “инвентарная книга”.
Шаг 2. Определение зависимостей
При планировании процесса разработки системы CRUD-матрица помогает определить перечень классов, которые разрабатываются в первую очередь, чтобы покрыть максимальное количество прецедентов. Например, для разработки АБИС НТБ прецедент “регистрация читателя” будет реализован первым, потому что класс читатель согласно CRUD-матрицы используется в 8 прецедентах, в отличие от класса “бронь”. Таким образом определяются нужные и актуальные данные.
Шаг 3. Определение пакета типовых работ для разработки
CRUD-матрица помогает определить типовую реализацию и выявить дублирование функционала в системе. К примеру, класс “книжный формуляр” реализуется по типу класса “библиотекарь” и соответственно времени на реализацию класса “книжный формуляр” потребуется меньше. Таким образом, сокращается время разработки системы.
Шаг 4. Оценка времени, необходимого для разработки
CRUD-матрица предоставляет Agile-команде простой механизм для оценки времени, необходимого для разработки и тестирования определенной части функциональности.
В первом приближении производится оценка каждой комбинации доступа, а затем производится оценка каждого прецедента. К примеру, создание нового экземпляра класса требуется в 4 прецедентах, чтение информации об экземпляре класса в 7 случаях, в 16 случаях требуется обновлять информацию экземпляра класса, а в 6 случаях необходимо удалять экземпляр класса. Используя плановое время на разработку каждой комбинации доступа формируется таблица сложности реализации каждого класса, а также системы в целом:
В случае необходимости, аналитик может ранжировать не только сложность реализации каждого класса, но и каждого прецедента.
Что касается 53 дней, то этот срок уменьшается за счет типовых работ, а именно реализации классов “библиотекарь” и “книжный формуляр”. Для обеспечения более реалистичной оценки на будущее можно использовать фактические значения собранные на основе статистического анализа процессов реализации подобного функционала в предыдущих проектах. В любом случае, последнее слово должно быть за Agile-командой, ведь никакая статистика не поможет в разработке системы, а иногда даже мешает Agile-команде корректно оценить свои возможности.
Шаг 5. Проверка модели на непротиворечивость
В процессе итеративного развития CRUD-матрицы обеспечивается согласованность между прецедентами и теми моделями, которые являются основой разработки и поставки решений. Например, в рамках модели могут быть классы, которые не используются ни в одном прецеденте, что может являться снижением производительности системы, а следовательно это может напрямую повлиять на удовлетворённость клиента. Таким образом, решение, при разработке которого использовалась технология CRUD-матрицы, будет максимально непротиворечивым, что является хорошей основой для разработки.
Шаг 6. Определение последующей работы и дополнений функционала
В CRUD-матрице описываются все ответные действия системы по каждому прецеденту, что позволяет разработчику увидеть работу всей системы в целом. На базе CRUD-матрицы Agile-аналитик, в случае необходимости, может проводить уточнение модели и строить диаграммы последовательности, диаграммы коммуникации, диаграммы обзора взаимодействия или диаграммы синхронизации. Также CRUD-матрица может использоваться дизайнером при проектировании интерфейсов или архитектором решений для разработки продуктовой спецификации. Таким образом CRUD-матрица служит хорошим инструментом для каждого члена Agile-команды на протяжении всего жизненного цикла продукта.
Шаг 7. Определение приоритетов для разработки и поставки
CRUD-матрица позволяет клиентам адекватно оценить приоритеты в реализации какой-либо функциональности, и не позволит переместить её реализацию на следующую итерацию. Например, прецеденты “выдача читательского билета” и “перерегистрация читателя” не могут быть поставлены полностью до тех пор пока не будут разработаны классы: читатель, читательский билет и библиотекарь.
Итог
Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом (заказчиком) и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин. Что касается комбинаций доступа к экземплярам класса, то тут не обязательно использовать именно CRUD-комбинацию, возможны и другие комбинации, например такие: REST, RESTful, GET-PUT-POST-DELETE и др.