역할
Scrum 팀의 멤버는 세 가지 역할 중 하나 이상을 수행합니다. 대부분의 사용자는 소프트웨어를 만들 책임이 있는 팀 역할을 수행합니다. 또한 제품 소유자는 고객이 팀에서 대변되는지 확인하고, Scrum 마스터는 팀과 제품 소유자가 Scrum 프로세스를 효율적으로 따를 수 있도록 도와 줍니다.
항목 내용
팀
팀은 소프트웨어 작성을 담당하는 개개인으로 구성됩니다. 팀에서는 스프린트가 시작될 때 사용자 스토리를 선택하고, 스프린트 동안 공동 작업을 통해 사용자 스토리를 구현 및 테스트하고, 스프린트 검토 시 완성된 소프트웨어를 제시합니다. 팀은 팀과 팀 작업을 자체적으로 관리하기 때문에 자기 조직화된 단위입니다. 또한 팀은 사용자 스토리를 전달하는 데 필요한 기술을 제품 백로그에 포함하기 때문에 교차 기능적입니다. MSF for Agile Software Development v5.0에서는 엔지니어링 분야나 전문 영역 등의 기준으로 팀에서의 역할을 구별하지 않습니다.
최적의 팀을 구성하기 위한 요소
최적의 소프트웨어 팀을 구성하는 것은 어렵고 시간도 오래 걸립니다. 훌륭한 팀의 예는 수술 팀, 야구 팀, 개와 조련사 등, 우리 주변에서 얼마든지 볼 수 있습니다. 팀 멤버마다 고유한 전문 분야가 있을 수 있지만 팀에서는 공동으로 작업을 수행하며 성공이나 실패도 함께 하게 됩니다.
또한 최적의 소프트웨어 팀은 공통의 목표를 향해 협력해 나가는 개인들로 구성됩니다. 소프트웨어 팀은 각 멤버가 번갈아 가며 자신의 전문 분야에 속하는 작업을 수행하는 전문가 집단에 머물러서는 안 됩니다. 대신 팀 멤버가 보유한 개별 기술보다는 모든 멤버의 총체적인 기술 및 전문성이 우선하는 그룹이어야 합니다. 팀은 공동 작업, 의사 교환, 신뢰 및 개방성을 통해 작업을 성공으로 이끌고 멤버 개개인의 능력을 뛰어 넘어 높은 성과를 이루는 팀으로 성장할 수 있습니다.
최적의 팀에는 작동하는 소프트웨어를 전달하는 데 필요한 사람과 기술이 포함됩니다. 팀의 정규 멤버는 프로젝트를 완수하는 데 필요한 대부분의 기술이나 모든 기술을 갖추고 있어야 합니다. 디자이너, 운영자, 설계자 또는 특정 기술의 전문가와 같이 전문 기술을 보유한 개인은 정규 멤버로 확보하지 못할 수도 있습니다. 팀은 이러한 단기 작업을 외부 전문가에게 의뢰할 수 있습니다. 그러나 팀의 정규 멤버는 작업을 완료하는 데 필요한 대부분의 기술을 처리할 수 있는 사람들로 구성해야 합니다.
팀의 주요 역할
팀의 주요 역할은 고객의 기대 수준과 완성된 소프트웨어에 대한 팀의 기준을 모두 충족하는 소프트웨어를 만드는 것입니다. 팀의 책임은 스프린트 계획 회의에서 시작되어 스프린트 검토 회의에서 끝납니다. 팀은 스프린트 계획 회의에서 사용자 스토리를 여러 작업으로 나누고, 스프린트 검토 회의에서 작동하는 소프트웨어를 제품 소유자에게 제시하고 가능하면 고객에게도 제시합니다.
또한 팀은 팀 자체의 결과에도 책임을 집니다. 팀은 팀에서 선택한 작업을 정의 및 완료하고 팀 멤버 간의 공동 작업을 통해 팀의 효율성을 최적화하는 과정을 통해 자체적으로 관리됩니다. 팀에서는 다음과 같은 작업을 통해 결과를 향상시킬 수 있도록 항상 노력해야 합니다.
완료된 단계를 판별하기 위한 기준을 정의하고 다음 단계를 시작하기 전에 각 작업을 완료합니다.
효과적인 엔지니어링 방법을 채택합니다.
자세한 내용은 엔지니어링 방법을 참조하십시오.
제품 소유자가 효과적인 사용자 스토리를 만들고 우선 순위를 지정하도록 도와 줍니다.
사용자 스토리를 예측합니다.
Scrum 마스터
Scrum 마스터는 Scrum 프로세스를 따르는 효율적인 팀을 구성하고 유지 관리하는 역할을 담당합니다. 또한 팀이 장애 요소를 극복할 수 있도록 도와 주는 변경 에이전트의 역할을 담당합니다.
훌륭한 Scrum 마스터가 갖춰야 할 능력
훌륭한 Scrum 마스터가 되려면 탁월한 의사 소통 기술, 협상 기술 및 충돌 해결 기술을 갖추거나 키워야 합니다. 팀의 발전을 위해 이러한 기술을 매일 사용해야 합니다. 사람들이 말하고 쓰는 단어뿐만 아니라 메시지를 전달하는 방식(신체 언어, 표정, 말하는 속도 및 다른 비언어 의사 소통 방식)에도 적극적으로 귀를 기울여야 합니다. 숨겨진 문제를 드러내는 질문을 하고 사람들의 이야기를 올바르게 이해했는지 확인해야 합니다. 이러한 기술을 사용하여 팀의 잠재적인 문제를 식별하고 실제 문제가 되는 것을 방지해야 합니다. 버그가 발견되는 즉시 수정하는 것이 더 쉬우며 팀 문제가 크고 제어할 수 없을 경우보다 팀 문제가 작고 관리가 가능할 때 수정하는 것이 더 쉽고 파급 효과가 덜합니다. 생산성을 크게 높일 수 있도록 팀을 이끌어 나가면서 팀, 제품 소유자 및 다른 비즈니스 관련자가 편안함을 느낄 수 있도록 해야 합니다. 또한 데이터를 모으고, 분석하고, 비즈니스 관련자에게 제시하는 과정에서 팀이 발전 및 성장하고 있음을 보여줘야 합니다. 예를 들어 팀이 창출한 가치가 현저하게 증가했고 버그의 수가 줄어든 경우 이러한 발전 상황을 비즈니스 관련자에게 알려야 합니다.
Scrum 마스터의 주요 역할
주요 역할은 팀과 제품 소유자가 Scrum 프로세스를 따르는지 확인하는 것입니다. 예를 들어 매일 진행되는 Scrum 회의가 45분 동안 진행되는 공개 토론이 되지 않도록 해야 합니다. 또한 제품 소유자가 이미 시작된 스프린트에 작업을 추가하도록 팀에 요청하지 않게 해야 합니다. 사용자 스토리가 완전히 완료되지 않은 경우에는 스프린트 검토 회의에서 팀이 사용자 스토리를 제시하지 않도록 해야 합니다.
팀에서 직면할 수 있는 장애 문제를 해결하는 데 도움을 주어야 합니다. 이러한 문제는 새 빌드 컴퓨터의 구매 주문 승인과 같은 비교적 간단한 업무나 팀 멤버 간의 충돌 해결처럼 비교적 중요하고 어려운 업무와 관련이 있습니다. 팀 내에서 곤란한 상황이 발생할 경우 팀이 이를 해결하고 이후에 보다 효과적으로 작업할 수 있도록 도와야 합니다.
제품 소유자
제품 소유자의 주 역할은 고객과 팀을 연결해 주는 것입니다. 제품 소유자는 다양한 고객과 관련자로부터 여러 가지 요구를 받게 됩니다.
훌륭한 제품 소유자가 갖춰야 할 능력
고객 요구 사항을 분석하고 사용자 스토리로 표현해야 합니다. 요청한 기능의 부작용과 이에 따른 일정상의 영향을 고객이 이해하게 도울 수 있도록 좋은 협상 기술을 가지고 있어야 합니다. 팀에서 최대한 가치 있는 제품 또는 시스템을 만들 수 있도록 고객과 협력하여 한 번에 한 증분씩 제품 백로그의 우선 순위를 지정해야 합니다. 시스템을 구축 중인 비즈니스 영역이나 업계에 대한 실질적인 전문 지식을 갖춰야 합니다. 예를 들어 팀이 병원에 의료 시스템을 구축 중인 경우에는 의료 및 건강 보험에 대한 배경 지식이 필요합니다. 이 지식이 없으면 사실상 제품 백로그의 우선 순위를 지정하거나 제품 백로그 항목을 팀에 설명할 수 없습니다. 시스템의 투자 회수 기간, 예산 상각, 자본 및 경비 예산을 파악할 수 있는 능력 등의 기본적인 재무 기술도 도움이 됩니다. Scrum 프로세스에 대한 이해와 이에 적극적으로 참여하는 노력도 팀의 성공에 중요한 기여를 합니다.
제품 소유자의 주요 역할
제품 소유자의 주요 역할은 팀에 고객과 관련자의 요구 사항을 대변하고, 팀의 질문에 응답하는 것입니다. 제품 백로그를 최신 상태 및 우선 순위대로 유지해야 합니다. 제품 백로그를 유지하려면 고객, 관련자 및 팀과 정기적으로 커뮤니케이션해야 합니다. 적어도 2주에 한 번은 관련자를 만나야 합니다. 사용자 스토리가 구현되는 순서는 투자 회수 기간과 팀이 수행하는 작업의 양에 영향을 줍니다. 팀은 사용자 스토리의 순서가 작업에 어떠한 영향을 미치는지를 이해할 수 있도록 도와 줍니다. 제품 소유자는 관련자가 순위 결정의 영향을 이해할 수 있도록 도움을 주어야 합니다. 또한 팀 멤버가 기능을 구현하는 방법에 대해 궁금한 점이 있을 때 바로 연락할 수 있도록 함으로써 자세한 사양의 필요성도 줄여야 합니다. 팀이 멈추지 않고 작업할 수 있도록 곧바로 응답하거나 매우 빠른 시간 안에(몇 시간 안에) 답변을 찾아낼 수 있어야 합니다. 이것이 가능하지 않으면 팀의 결과에 부정적인 영향을 주게 됩니다.
참고
사양이 얼마나 자세해야 하는지는 여러 가지 요소에 달려 있습니다. 그 중에는 팀이 개발 중인 응용 프로그램의 유형도 포함됩니다. 대부분의 응용 프로그램에서는 올바른 수준의 자세한 사용자 스토리와 개방적인 통신 라인이 가장 효율적인 사양입니다. 하지만 랩 테스트를 처리하는 응용 프로그램은 팀이 시간 경과에 따라 수행하는 변경에 따른 영향을 보다 자세히 분석할 수 있도록 자세한 사양을 필요로 할 수 있습니다.
팀 및 관련자 모두와 함께 작업하여 승인 테스트를 작성할 수도 있습니다. 승인 테스트는 특정 사용자 스토리가 완료되어 스프린트 검토를 진행할 준비가 되었는지를 확인하는 데 도움이 됩니다. 팀 및 관련자 모두에 대한 위험을 이해하고, 식별하고, 표현해야 합니다.