role business analysts scrum
c 프로그래밍 인터뷰 질문 및 답변 설명 pdf
SCRUM에서 비즈니스 분석가의 탁월한 역할 :
곧 BA라고 불리는 비즈니스 분석가는 다음 분야에서 매우 과감하고 중요한 역할을합니다. 스크럼 .
이 사람은 제품 소유자 / 고객과 기술 IT 팀 간의 연결 고리입니다. BA에 대한 우리 웹 사이트에서 여러 튜토리얼을 보았지만,이 튜토리얼은 어떻게 든 독특한 것이며 SCRUM에서 BA의 중요성을 설명 할 것입니다.
탐험하자 !!
=> 여기에서 모든 비즈니스 분석가 자습서를 확인하십시오.
학습 내용 :
- BA의 책임
- 제품 소유자로서의 비즈니스 분석가
- 팀원으로서의 비즈니스 분석가
- SCRUM 팀에서 비즈니스 분석가의 중요성과 역할
- QA가이 작업에 가장 적합한 이유는 무엇입니까?
- 추천 도서
BA의 책임
스크럼에는 비즈니스 분석가의 여러 역할이 있으며 BA가 준수해야하는 특정 책임이 있습니다.
그중 일부는 아래에 언급되어 있습니다.
- 제품 소유자가 제공 한 우선 순위에 따라 제품 백 로그를 정리합니다.
- 고객의 요구 사항을 분석하고이를 해결하기위한 솔루션을 찾습니다.
- 적절한 허용 기준을 사용하여 사용자 스토리 형식으로 요구 사항을 만듭니다.
- 제품 소유자가 이미 사용자 스토리를 생성 한 경우 (승인 기준 포함), 모든 비즈니스 규칙이 적용되고 승인 기준이 사용자 스토리 기능을 충족하는지 확인하기 위해 검토합니다.
- 제품 소유자 및 이해 관계자와 협력하여 범위를 이해하고 요구 사항에 대한 개선 사항을 제안합니다.
- 필요에 따라 와이어 프레임, 디자인 흐름, UI 등과 같은 문서를 준비합니다.
이 외에도 비즈니스 분석가 팀이 다가오는 스프린트의 백 로그를 논의하기 위해 만날 때 브레인 스토밍 세션에서 중요한 참가자입니다. BA는 팀을 안내하고 요구 사항을 이해하도록 돕고 때로는 구현을 승인해야합니다.
그는 또한 테스트 범위 분석, 실제 사용 사례를 테스트 사례로 변환, 복잡한 기능 테스트에 대한 통찰력 제공 등과 같은 QA와 긴밀히 협력합니다. 흐름, 복잡성 및 종속성을 이해합니다.
BA는 항상 시장에서 진행되고있는 새로운 트렌드에 대해 지속적으로 학습하고, 제품이 만들어진 비즈니스 영역에 대해 지속적으로 혁신하고 최신 정보를 유지해야합니다.
제품 소유자로서의 비즈니스 분석가
고객과 회사에 따라 일부 회사는 비즈니스 분석가를 제품 소유자로 두는 경우가 있습니다. 이러한 경우 BA는 모든 쿼리에 대한 연락처입니다. 그런 다음 BA는 팀과 이해 관계자의 중재자가됩니다.
BA는 이해 관계자의 요구 사항, 비즈니스를 앞당기는 것에 대한 생각, 비즈니스가 어떻게 성장해야하는지 (그리고 어떻게) 이해해야합니다. 그런 다음 이해 관계자의 요구 사항에 따라 BA는 문서, 사용자 스토리를 만들고 스토리의 우선 순위를 지정하고 팀이 스토리를 이해하도록 돕고 동일한 내용에 대한 질문에 답해야합니다.
여기서 주목해야 할 가장 중요한 점은 BA를 물리적으로 사용할 수 있고 '통신 간극'을 피하기 위해 다른 시간대에 지리적 위치가 지정되지 않았을 때 권장된다는 것입니다.
제품 소유자의 BA가 다른 시간대에 위치하는 경우 매번 그에게 접근 할 수 없으며 커뮤니케이션하는 유일한 방법은 이메일, 채팅 또는 전화를 통하는 것이므로 부족, 격차 및 심지어 때때로 잘못된 의사 소통.
제 경험에 따르면 BA가 팀 옆에 사무실에 앉아있을 때 작업이 방해받지 않고 쉽게 접근 할 수 있도록이 작업을 수행해야합니다. BA의 관점에서 그들은 이해 관계자 / 고객을 대신하여 제품을 소유하고 적절한 결정을 내리고 개발의 일부 기술을 배우는 것을 포함 할 수있는 새로운 기술을 배워야합니다.
비즈니스 분석가를 제품 소유자로 두는 것은 비즈니스 분석가가 제품을 매우 잘 이해하고 작업의 우선 순위와 범위를 협상 할 수 있기 때문에 추가적인 이점입니다.
팀원으로서의 비즈니스 분석가
다른 옵션은 제품 소유자를 매번 사용할 수 없기 때문에 비즈니스 분석가를 팀 구성원으로 두는 것입니다. 비즈니스 분석가가 팀 구성원이면 백 로그 그루밍에서 동료를 돕습니다.
비즈니스 분석가를 팀원으로 두는 것이 더 유리합니다. 기술 팀은 설명이나 토론을 위해 BA와 쉽고 편안하게 의사 소통 할 수 있기 때문입니다. BA는 또한 QA 팀과 긴밀히 협력하여 테스트, 즉 적용 범위, 사용 사례, 숨겨진 요구 사항 또는 신뢰성 또는 효과를 분석합니다.
때로는 제품 소유자가 작성한 승인 기준이 모호하고 명확하지 않을 수 있으며, 팀원으로서 정교하고 잘 설명 된 승인 기준을 작성하는 것은 BA의 책임이됩니다. 팀에 더 많은 정보가 필요한 경우 BA는 팀이 요구 사항을 이해하는 데 도움이되는 와이어 프레임 문서, 흐름 문서 등을 만듭니다.
모듈이 팀간에 분산되는 대규모 프로젝트에서 둘 이상의 팀에 대한 BA를 보유하는 것도 추가 이점입니다. BA는 팀간에 동일하므로 모듈의 상호 운용성, 새로운 기능 또는 업데이트가 다른 모듈에 미치는 영향 등에 대해 생각할 수 있습니다.
따라서 이것은 기술 팀이 항상 사용자 스토리 또는 수용 기준에서 언급하는 것은 아닌 측면을 고려하는 데 큰 도움이 될 것입니다.
SCRUM 팀에서 비즈니스 분석가의 중요성과 역할
SCRUM에서 비즈니스 분석가의 역할은 프로젝트의 성공에 매우 중요합니다. 그들의 참여는 고객의 요구를 이해하는 것에서부터 Sprint 데모에 이르기까지 시작됩니다. 설명을 위해 기술 팀의 첫 번째 연락 지점입니다. 그들은 새로운 프로젝트와 대규모 프로젝트의 초기 단계에서 훨씬 더 중요합니다.
제품 소유자는 항상 좋은 작가가 될 수 없으며 때로는 기술적 배경에서 왔기 때문에 스토리, 수용, 와이어 프레임 등을 작성하는 것은 비즈니스 분석가의 책임이됩니다.
내 프로젝트에서 우리의 PO는 문서화가 그다지 좋지 않았고, 심지어 작성된 사용자 이야기조차도 2-3 라이너를 넘지 않았고 승인 기준은 1 라이너에 불과했습니다. 이를 수정하고 더 설명적이고 정교하게 만드는 것은 비즈니스 분석가였습니다.
때때로 PO가 21 개 이상의 스토리 포인트가있는 사용자 스토리를 작성했기 때문에 비즈니스 분석가는이를 분류하고 제품 소유자와 함께 우선 순위를 지정하는 데 추가 시간과 노력을 투자해야했습니다.
비즈니스 분석가가없고 제품 소유자가 다음과 같은 승인 기준을 사용하여 '고객으로서 모든 은행 업무를 수행하고 싶습니다'와 같은 사용자 스토리를 만들면 어떤 일이 일어날 지 상상할 수 있습니다.
- 고객이 로그인 할 수 있어야합니다.
- 고객이 내 계정에서 거래를 할 수 있어야합니다.
- 고객은 내 과거 명세서 등을 다운로드 할 수 있어야합니다.
제 생각에는이 사용자 스토리는 34 개 이상의 스토리 포인트를 포함 할 것이므로 더 세분화 할 필요가 있습니다. 적절한 흐름도와 UI 화면 (생성 예정)이 제공되지 않으면 기술 팀의 상황이 악화 될 수 있습니다.
이것은 실패한 스프린트로 이어질 것이고 결국 실패한 프로젝트로 이어질 것입니다. 제품 소유자가 훈련 된 / 실무적인 비즈니스 분석가가 아니라면 팀에 하나를 둘 필요가 있습니다.
QA가이 작업에 가장 적합한 이유는 무엇입니까?
QA는 문제 / 요구 사항에 대해 제안 된 솔루션을 테스트하여 확인하는 사람입니다. 따라서 비즈니스 분석가 / 이해 관계자 / 제품 소유자는 QA의 피드백에 대해 매우 알고 싶어합니다. 테스트에 BA의 참여는 개발중인 것보다 조금 더 많습니다.
비즈니스 분석가는 숨겨진 흐름 또는 요구 사항 / 효과에 대한 통찰력을 제공하는 테스트 사례 범위를 검토 할 때 QA와 긴밀하게 협력합니다. 따라서 이러한 종류의 지식 공유 (BA에 의한)는 제품 기능, 비즈니스 규칙, 고객 기대치, 흐름, 종속성 및 모든 것을 완전히 이해하게합니다.
QA는 항상 제품을 사용하는 최종 고객의 관점에서 테스트하므로 고객이 제품 개선 및 개선을 위해 도움을 줄 가능성이 더 높습니다 (개발자에 비해). 개발자는 주어진 사용자 스토리와 일련의 승인 기준에 따라 제품을 개발하지만 고객이 제품을 어떻게 사용할지 항상 생각하지는 않습니다. .
개발 과정에서 제품의 구현, 흐름 및 규칙은 잘 정의되어 있지만 테스트는 완전히 논리적 사고와 최종 사용자의 관점에서 생각할 수있는 능력을 기반으로합니다.
QA는 일상 업무에서 제공되는 많은 기회로 인해 SCRUM에서 비즈니스 분석가의 역할을 시작할 수 있습니다.
추천 읽기 => 테스터에서 BA로 경력 이동
QA가 다음과 같은 역할을 수행하는 것은 매우 쉽습니다.
- 요구 사항을 매우 깊이 연구하고 검토 회의 / 브레인 스토밍 세션 등의 차이를 지적하십시오. 더 나은 솔루션에 대해 생각하고 팀 및 BA와 동일한 내용을 논의하십시오.
- 제품 소유자와의 통화에주의를 기울이고 질문하고 결과를 공유하십시오. 이것은 제품에 대한 귀하의 관심을 보여주는 제품 소유자의 신뢰를 높일 것입니다.
- BA와 개발 팀 사이에 자신을 맞추십시오. 명확하거나 의문이있는 경우 개발자의 연락처가되어야합니다.
- 테스트 프로세스를 설정하고 계속해서 혁신하여 성공적인 스프린트를 제공하는 데 도움이되도록 변경하십시오.
- 멋진 UI가있는 제품의 경우 새로운 트렌드를 찾아 개선을 제안하세요.
- 제품 안팎을 완전히 이해하십시오.
- 이해 관계자와 그들의 기대에 대한 강력한 지식을 구축하고 경험을 공유하십시오.
이것은 또한 BA 역할을 수행하기 위해 기술을 향상시켜야 함을 의미합니다. 기본 수준과 고급 수준을 모두 포함하는 여러 과정이 시장에 나와 있습니다.
당신은 BA / QA입니까? 당신의 역할에 대해 모두 지적 했습니까? 아니면 우리가 놓친 것 같아요 당신이 독특하게 수행하는 무언가? 우리는 당신의 의견을 기뻐할 것입니다. 아래 댓글 섹션에서 자유롭게 공유하십시오!
=> 모두를위한 비즈니스 분석가 시리즈를 보려면 여기를 방문하십시오.