Комментарии 14
Если вся система сводится к CRUD, то эта техника работает. Но лучше в этой ситуации работает access ;)
Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:
Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
Таким образом можно получать объективные и достаточно точные оценки объема.
Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:
Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
Таким образом можно получать объективные и достаточно точные оценки объема.
Это называется state machine или «конечный автомат».
«Это» это что?
Если я вас правильно понял, то что вы предлагаете называется подходом «конечного автомата». Кроме входов и выходов еще составляется граф возможных состояний системы. Таким образом еще на этапе проектирования можно избавиться от дублирования и неточностей в требованиях. Имея на руках «автомат», гораздо проще оценивать объем работ, потому что задача формализована.
CRUD аналитика для CRUD задач! Да!
А если задача выглядит так: «на вход поступает набор чисел, на выходе возвращается его разложение на множители или информация о том, что число простое»? С жёсткими требованиями по скорости? Что там наш CRUD-аналитик делать будет? Расписывать табличку «тут нам число вводят, а тут нам числа выводят»?
А если задача выглядит так: «на вход поступает набор чисел, на выходе возвращается его разложение на множители или информация о том, что число простое»? С жёсткими требованиями по скорости? Что там наш CRUD-аналитик делать будет? Расписывать табличку «тут нам число вводят, а тут нам числа выводят»?
1. CRUD-матрицы — это старый инструмент для обеспечения полноты требований
2. Планировать на матрицах ни чем не лучше, чем планировать на реестре способов применения, функциональных точках, пользовательских историях и т.д.
3, Организовывать диалог с клиентом на этих матрицах ничем не лучше, чем на диаграмме способов применения, макетах интерфейса, карте пользовательских историй и т.д.
4. Agile здесь совершенно не при чём.
5. IIBA здесь совершенно не при чём.
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.
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-техника.
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, и я попытался показать, что его применение позволит всем членам команды видеть картину целиком, а не кусочками в виде пользовательских историй.
По крайней мере я попытался решить проблему:
Проблему, которую подняли в этой теме: habrahabr.ru/post/172073/
books.google.ru/books?ei=CGBAUabxFsr34QT4rYDYCw&hl=ru&id=xQNZAAAAYAAJ&dq=inauthor%3A%22Francis+T.+Hartman%22&q=RACI#search_anchor
В статье я ни разу не сказал, что это новый инструмент, просто его не применяли в Agile, и я попытался показать, что его применение позволит всем членам команды видеть картину целиком, а не кусочками в виде пользовательских историй.
По крайней мере я попытался решить проблему:
Проблему, которую подняли в этой теме: habrahabr.ru/post/172073/
Хорошая памятка по одной из менее популярных техник анализа требований, которая может оказать дополнительную помощь в мире разработки систем уровня Enteprise.
На мой взгляд, основная проблема в части применение этого метода в Agile-мире — это то, что пользовательские истории зачастую будут объединять в себе более одной функции акронима CRUD для дружественных классов, что сделает матрицу значительно менее наглядной, а в пределе может привести к ее вырождению в обычные пересечения между функциями и данными без конкретизации методов обработки этих данных. Иметь такую картинку само по себе не плохо, но я предпочитаю прописывать не очевидные зависимости от данных в самих историях.
На мой взгляд, основная проблема в части применение этого метода в Agile-мире — это то, что пользовательские истории зачастую будут объединять в себе более одной функции акронима CRUD для дружественных классов, что сделает матрицу значительно менее наглядной, а в пределе может привести к ее вырождению в обычные пересечения между функциями и данными без конкретизации методов обработки этих данных. Иметь такую картинку само по себе не плохо, но я предпочитаю прописывать не очевидные зависимости от данных в самих историях.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Технология CRUD-матрицы. Практический опыт