Pull to refresh

Comments 14

Если вся система сводится к CRUD, то эта техника работает. Но лучше в этой ситуации работает access ;)

Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:

Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
Таким образом можно получать объективные и достаточно точные оценки объема.

Это называется state machine или «конечный автомат».
Если я вас правильно понял, то что вы предлагаете называется подходом «конечного автомата». Кроме входов и выходов еще составляется граф возможных состояний системы. Таким образом еще на этапе проектирования можно избавиться от дублирования и неточностей в требованиях. Имея на руках «автомат», гораздо проще оценивать объем работ, потому что задача формализована.
В том то и дело, что не составляется граф. Потому что внутренняя реализация может меняться довольно сильно, а потоки данных относительно стабильны. Кроме того не каждая задача хорошо описывается автоматом.
CRUD аналитика для CRUD задач! Да!

А если задача выглядит так: «на вход поступает набор чисел, на выходе возвращается его разложение на множители или информация о том, что число простое»? С жёсткими требованиями по скорости? Что там наш CRUD-аналитик делать будет? Расписывать табличку «тут нам число вводят, а тут нам числа выводят»?
В вашем случае можно добавить новую комбинацию доступа: «вычисление», прецедент будет называться: «вычисление простого числа», а классом будет Int.
1. CRUD-матрицы — это старый инструмент для обеспечения полноты требований

2. Планировать на матрицах ни чем не лучше, чем планировать на реестре способов применения, функциональных точках, пользовательских историях и т.д.

3, Организовывать диалог с клиентом на этих матрицах ничем не лучше, чем на диаграмме способов применения, макетах интерфейса, карте пользовательских историй и т.д.

4. Agile здесь совершенно не при чём.

5. IIBA здесь совершенно не при чём.
1. CRUD-матрицы в сущности похожи на матрицу RAСI, поэтому может и в правду казаться, что это где-то уже было.
2. Если обратить внимание на таблицу, то я перечислил как раз способы применения или прецеденты или варианты использования или как вы говорите функциональные точки.
3. Вы рассуждаете как настоящий аналитик, но макет интерфейса должен соотносится с моделью системы, а также с прецедентами, которые отражают функциональность продукта. Все это можно держать в голове, как и делает большинство аналитиков, но этой информацией будете владеть только вы. Если разрабатывается большая система, то в голове все не удержишь.
4. Не хочу вас расстраивать, но в Business Analysis Competency Model (Version 3.0) описана компетенция Agile BA (стр.53-54).
5. IIBA есть The Agile Extension to the BABOK® Guide.
1. CRUD-матрицы упоминаются по крайней мере в книге Карла Вигерса 2003-го года:
books.google.ru/books?id=WcO3Ca9NuvQC&pg=PT202&lpg=PT202&dq=Wiegers+CRUD&source=bl&ots=d97cAhI5xe&sig=lAERvRdcTBrLIN-aARJkoeZyv-Q&hl=ru&sa=X&ei=1VFAUe3mO4aL4ASPuIHwAQ&ved=0CIQBEOgBMAk
Это 10 лет назад, если что.

4-5. ну понятно, что эти старпёры, чтобы продолжать продавать свои МЛМ-услуги впихивают новомодные техники в свои своды, так же как и PMBOK. Только их упоминание ничем вашей статье про МЕТОД не помогает.

И это при том, что CRUD-матрица — это не новая, не модная и не agile-техника.
RACI-матрица упоминается Francis T. Hartman «Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value with SMART Management», 2000г.
books.google.ru/books?ei=CGBAUabxFsr34QT4rYDYCw&hl=ru&id=xQNZAAAAYAAJ&dq=inauthor%3A%22Francis+T.+Hartman%22&q=RACI#search_anchor
В статье я ни разу не сказал, что это новый инструмент, просто его не применяли в Agile, и я попытался показать, что его применение позволит всем членам команды видеть картину целиком, а не кусочками в виде пользовательских историй.
По крайней мере я попытался решить проблему:
image
Проблему, которую подняли в этой теме: habrahabr.ru/post/172073/
При чём тут вообще RACI? Им точно уже лет 30.
При том, что подход идентичный, только в RACI вместо классов, процедур и функций выступают люди, а вместо прецедентов их задачи.
Хорошая памятка по одной из менее популярных техник анализа требований, которая может оказать дополнительную помощь в мире разработки систем уровня Enteprise.

На мой взгляд, основная проблема в части применение этого метода в Agile-мире — это то, что пользовательские истории зачастую будут объединять в себе более одной функции акронима CRUD для дружественных классов, что сделает матрицу значительно менее наглядной, а в пределе может привести к ее вырождению в обычные пересечения между функциями и данными без конкретизации методов обработки этих данных. Иметь такую картинку само по себе не плохо, но я предпочитаю прописывать не очевидные зависимости от данных в самих историях.
Only those users with full accounts are able to leave comments. Log in, please.