질문의 배경:
고전적인 프로젝트에서 분석가와 아키텍트 간, 또한 시스템 및 비즈니스 분석가 간에 갈등이 종종 발생했습니다. 각자의 책임을 '차지'하려고 하거나 반대로 일부 의무를 떠넘기려 했습니다. 책임 경계를 명확히 하는 것은 성숙한 팀의 주요 특징 중 하나입니다.
문제:
위험은 작업의 중복 및 교차로 인해 발생하며, 이는 오해, 책임 상실, 지연, 경우에 따라 동일 시스템의 동일한 부분을 설명하는 작업이 동시에 상충하여 이루어지는 결과를 초래할 수 있습니다.
해결책:
주요 특징:
시스템 분석가는 전체 시스템의 아키텍처 설계 수준으로 올라가야 합니까?
아니요, 아키텍트가 아키텍처 결정을 담당합니다. 분석가는 아키텍트가 사용할 수 있는 요구 사항을 명확히 하지만, 전체 아키텍처를 설계하지는 않습니다.
비즈니스 분석가가 기술적 제한을 직접 설명할 수 있습니까?
일반적으로는 아닙니다 — 비즈니스 분석가는 비즈니스 요구 사항을 형성합니다. 기술적 제한은 시스템 분석가 또는 아키텍트의 영역입니다.
비즈니스 분석가로부터 작업 설명을 받았다면, 시스템 분석가는 비즈니스와의 미팅을 중복해야 합니까?
아니요, 그러나 시스템 분석가는 자신이 정확하게 이해하고 있는지 확인해야 하며, 불일치가 있을 경우 질문을 제기해야 합니다.
부정적 사례:
두 팀이 동일한 시스템의 한 부분을 동시에 작업하고 있었습니다: 분석가들이 의사 아키텍처를 작성했고 아키텍트들은 비즈니스 프로세스를 설명했습니다. 결과적으로 사양이 불일치하고 구현이 지연되었습니다.
장점:
단점:
긍정적 사례:
시작 시 함께하는 워크숍에서 누가 무엇을 담당하는지 합의하고 경계를 문서화했습니다. 이후 각 단계마다 이러한 합의를 검토했습니다.
장점:
단점: