На самом деле, вся суть матрицы в том, что она очень гибридна, ее можно подстраивать как угодно, но главное (как вы подметили) - это выставить связи. Без правильных взаимодействий компонентов не будет логической проверки. Допустим я использую связь: ФТ-UC-ТК, также важны связи м к м или м к одному. Допустим 1 фт - много uc; один uc - один ТК
А если у проекта уже имеется большое кол-во юз кейсов и не хочется от них отказываться, но их уже никак не расширить, можно ли их переформировать по формат юз кейсов 3.0?
Ну не совсем этот случай, пример с ТЗ это еще ок, но когда тебя на позиции БА просят писать гипотезы, или выявлять BI метрики, это не тоже самое) а в случае с написание ТЗ это достаточно распространенное требование к вакансии БА
Да, я не имел ввиду опыт, хотя в зависимости от того, что для вас значит опыт, отсиживаться над одними и теме же задачами несколько лет в узко направленной области или разносторонне развиваться, выполнять различные задачи и не сидеть на одном месте 🤔возможно не совсем точно выражаюсь, достаточно сложная тема для рассуждения, но интересная !
Вот именно! Существуют профстандарты на которые работодатели даже не смотрят или не знают и пишут требования к кандидату как видят они ) в этом большая трудность. А разница БА и СА колоссальная, в одном ответе трудно описать, лучше делать это с примерами. Но работодатели не видят этих различий
Перечень вопросов стейкхолдеру, каким образом формируется? Ориентир только на предметную область проекта или еще до встречи есть какие-то "точки опоры"? Имею ввиду, что на чем в целом основан список вопросов.
На самом деле, частый случай, что заказчик не хочет писать ТЗ. Он может рассказать об этом, а затем исполнитель уже пишет функциональные и нефункциональные требования, из которых собирается ТЗ (по умолчанию — вместе с use case и user story). Обсуждение и утверждение сторонами документов — это отдельная процедура, чаще всего называемая валидацией требований. Параллельно происходит верификация внутри команды. Короче говоря, процесс составления ТЗ и сбора требований сильно декомпозируется и часто сопровождается различной терминологией))
На самом деле, вся суть матрицы в том, что она очень гибридна, ее можно подстраивать как угодно, но главное (как вы подметили) - это выставить связи. Без правильных взаимодействий компонентов не будет логической проверки. Допустим я использую связь: ФТ-UC-ТК, также важны связи м к м или м к одному. Допустим 1 фт - много uc; один uc - один ТК
А если у проекта уже имеется большое кол-во юз кейсов и не хочется от них отказываться, но их уже никак не расширить, можно ли их переформировать по формат юз кейсов 3.0?
Ну не совсем этот случай, пример с ТЗ это еще ок, но когда тебя на позиции БА просят писать гипотезы, или выявлять BI метрики, это не тоже самое) а в случае с написание ТЗ это достаточно распространенное требование к вакансии БА
Да, я не имел ввиду опыт, хотя в зависимости от того, что для вас значит опыт, отсиживаться над одними и теме же задачами несколько лет в узко направленной области или разносторонне развиваться, выполнять различные задачи и не сидеть на одном месте 🤔возможно не совсем точно выражаюсь, достаточно сложная тема для рассуждения, но интересная !
Вот именно! Существуют профстандарты на которые работодатели даже не смотрят или не знают и пишут требования к кандидату как видят они ) в этом большая трудность. А разница БА и СА колоссальная, в одном ответе трудно описать, лучше делать это с примерами. Но работодатели не видят этих различий
Перечень вопросов стейкхолдеру, каким образом формируется? Ориентир только на предметную область проекта или еще до встречи есть какие-то "точки опоры"? Имею ввиду, что на чем в целом основан список вопросов.
На самом деле, частый случай, что заказчик не хочет писать ТЗ. Он может рассказать об этом, а затем исполнитель уже пишет функциональные и нефункциональные требования, из которых собирается ТЗ (по умолчанию — вместе с use case и user story). Обсуждение и утверждение сторонами документов — это отдельная процедура, чаще всего называемая валидацией требований. Параллельно происходит верификация внутри команды. Короче говоря, процесс составления ТЗ и сбора требований сильно декомпозируется и часто сопровождается различной терминологией))