---

실제 사례로 Scrum 프레임워크를 배우세요! 놀라실 수도 있습니다!

첫 Sprint를 시작하기 전에

Alex는 새로운 소프트웨어 개발 프로젝트의 Scrum Product Owner로 일합니다. 첫 과제 중 하나는 요구사항을 평가하고 파악하여 고객이 원하는 사업 가치를 제공하는 것입니다.

그는 고객이 다음을 얻도록 해야 합니다. 실질적인 사업 결과를 달성할 올바른 소프트웨어. 그는 핵심 사용 사례를 적고 아키텍트, 고객 대표, IT 및 사업 부서의 다른 이해관계자와 논의합니다. (참조: Scrum 예제)

상위 수준의 사용 사례와 요구사항을 모은 뒤 다음에 기록합니다. Scrum 제품 백로그 그리고 Scrum Team과 추정 및 우선순위 설정 회의를 시작합니다. 그 결과 Scrum Product Backlog의 모든 항목에 최초의 대략적인 추정치와 우선순위가 부여됩니다.

이 회의에서 Scrum Master인 Anna는 모두가 같은 언어로 소통하도록 합니다. 따라서 Scrum Product Owner, Scrum Team 구성원, 이해관계자들은 예상 목표와 방향을 맞춥니다. 또한 새로울 수 있는 개념을 적절히 이해합니다 . 사용 사례, Backlog, Sprint 등이 그 예입니다. 가장 중요한 것은 Scrum 소프트웨어 개발 및 제공 프로세스가 직장에서 올바르게 적용된다는 점입니다.

이제 Scrum Product Owner인 Alex는 상위 요구사항을 더 세밀한 사용자 스토리 초안으로 나누기 시작합니다. 이 목록으로 첫 Sprint Planning 회의를 소집합니다.

Sprint 1 - 0일 차

다음 회의에서 Sprint Planning 회의Alex는 Scrum Product Backlog 항목을 우선순위가 높은 순서대로 제시합니다. Scrum Team은 미해결 질문을 하고 명확히 합니다. 각 항목에 대해 개발하고 제공할 충분한 역량과 필요한 노하우가 있는지 논의합니다. Scrum Team은 Sprint 시작 전에 필요한 모든 인력과 기술 자원이 갖추어져 있는지 확인해야 합니다. 특정 소프트웨어 기능의 성공적인 제공에 중요할 수 있는 모든 선행 조건과 의존성이 충족되었는지 확인해야 합니다.

다음 회의 중에 Sprint Planning 회의(WHAT 부분)개발자들은 합의한 Sprint Goal을 지원하기 위해 Sprint 종료까지 사용자 스토리 1,2,3,6,7,8을 완료할 수 있다고 예측합니다. 따라서 이 스토리들은 Scrum Product Backlog에서 다음으로 이동합니다. Sprint Backlog. 사용자 스토리 4와 5는 필요한 기술 기반 시설 일부가 아직 없어 이번 Sprint에서 완료할 수 없습니다.

Sprint Planning 회의의 WHAT 부분이 끝난 뒤 Scrum Master인 Anna는 Scrum Team을 모아 이행을 약속한 사용자 스토리를 어떻게 구현할지 자세히 살펴보도록 합니다(HOW 부분). Sprint Planning 회의의 HOW 부분에서 나온 작업은 카드에 적어 Sprint Backlog에 넣습니다. 이제 모든 Scrum Team 구성원이 시작할 작업을 선택할 준비가 되었습니다.

Sprint 1 - 1일 차

아침에 개발자들이 다음 회의를 위해 모입니다. Daily Scrum 회의. 모두가 짧고 간결하게 설명합니다 . 지금까지 한 일을 말하고 Sprint Backlog 카드의 남은 작업 추정치를 갱신합니다. 각자 오늘 할 일을 말하고 작업 진행을 방해하는 장애물이 있는지 밝힙니다.

오늘 Scrum Team 구성원인 Melinda는 사용 중인 통합 소프트웨어 개발 환경의 라이선스에 문제가 있다고 알립니다. Scrum Master인 Anna는 다른 팀원도 같은 문제를 겪는지 확인하고 회의 후 장애물을 처리하겠다고 합니다. 약 15분 동안의 Daily Scrum 회의가 끝나면 모두 업무로 돌아갑니다.

회의 후 Anna는 다음을 갱신합니다. Sprint 번다운 차트로 이번 Sprint의 작업 진척을 시각화합니다. 그런 다음 소프트웨어 공급업체에 전화하여 필요한 라이선스를 주문하고 Melinda에게 전달합니다.

Scrum 소개: 여러 Scrum 단계와 Sprint에 걸친 실제 예시(사례 연구)

Sprint 1 - 2일 차

아침에 개발자들이 다시 다음 회의를 위해 모입니다. Daily Scrum 회의. 오후에 Scrum Team 구성원 James는 한 사용자 스토리의 기대 결과가 불확실하다고 느낍니다. Scrum Product Owner인 Alex에게 전화하여 스토리를 논의하고 자신이 제대로 이해했는지 확인합니다. 진행 방법을 확신하게 된 James는 구현 작업을 계속합니다.

Sprint 1 - 6일 차

오늘도 팀의 Daily Scrum 회의로 하루를 시작합니다. Scrum Master인 Anna는 오늘 아침 회의가 15분을 넘기려 한다는 것을 알아차립니다. Scrum Team 구성원들이 데이터베이스 쿼리 최적화를 논의하고 있습니다. Anna는 팀에 다음을 상기시킵니다. Daily Scrum 회의는 긴 기술 논의를 위한 것이 아니라 Sprint Goal을 향한 진척을 점검하고 개발자들의 계획을 조정하기 위한 것입니다.

Daily Scrum 회의 후 Alex(Product Owner)는 고객이 진행 중인 Sprint와 이후 Sprint에 영향을 줄 수 있는 여러 새 요구사항을 제기했다고 Anna(Scrum Master)에게 알립니다. Anna는 Alex에게 정중하게 다음을 상기시킵니다. 변경은 Sprint Goal을 위태롭게 해서는 안 됩니다. 개발자와 Product Owner는 선택한 모든 스토리를 바꿀 수 없는 약속으로 보기보다 배운 내용에 따라 범위를 명확히 하거나 재협의할 수 있습니다. 따라서 Anna는 다음 회의를 마련합니다. Backlog 정제 회의 오후에 Alex가 팀에 새로운 요구사항을 알릴 수 있도록 합니다.

이 회의에서 참석자들은 Alex가 이 사용자 스토리가 전체 소프트웨어 개발 계획에서 차지하는 위치, 최초 작업 분할, 추정치, 우선순위를 파악하도록 돕습니다.

Sprint 1 - 10일 차

마침내 첫 Sprint의 마지막 날입니다. Scrum Master인 Anna는 Scrum Team을 다음 회의에 초대합니다. Sprint Review 회의. 팀은 만든 출시 가능한 소프트웨어 Increment의 최신 버전을 갖춘 비운영 서버를 준비했습니다.

Scrum Product Owner인 Alex와 고객 이해관계자 중 한 명인 Rich 씨가 이 소프트웨어의 그래픽 사용자 인터페이스 앞에 앉습니다. 이들은 구현이 기대에 맞는지 확인합니다 . 또한 팀이 현재 애플리케이션 수준의 세부사항을 적절히 문서화했는지도 검증합니다.

Sprint Review 회의가 끝날 때 Alex는 다음과 같이 결론 내립니다.

• 팀은 약속과 기대대로 사용자 스토리 1,2,6,7을 제공했습니다.
• 팀은 사용자 스토리 3을 제때 완료하지 못했고 이를 전혀 시연하지 않았습니다. 미완료 스토리는 Product Backlog로 돌아가 순서를 다시 정합니다. 남은 작업은 다음 Sprint Planning에서 선택할 수 있습니다.
• 사용자 스토리 8은 공통 Definition of Done(DoD)을 충족하지 못했습니다. Product Backlog로 돌아가며 팀은 다시 선택할 시점을 결정하기 전에 인수 기준과 남은 작업을 명확히 할 수 있습니다.

Scrum Product Owner인 Alex와 고객 이해관계자 Rich 씨는 Scrum Team에 간단히 설명합니다 . 앞으로의 소프트웨어 요구사항 변경과 어려움, 그리고 이 소프트웨어의 전체 전략이 나아가야 할 방향에 관해서입니다. Rich 씨는 Scrum Team의 노력과 헌신에 감사하며 자리를 떠납니다.

Sprint Review 회의가 끝난 뒤 Scrum Team은 다음 회의를 위해 함께 앉습니다. Sprint 회고 회의. 회의에서 Sprint 중 잘된 점과 개선할 점을 논의하여 향후 예측을 개선하고 다음 Sprint에서 사용자 스토리 3과 8의 문제를 반복하지 않도록 합니다. Sprint Retrospective에서 확인한 장애물 중 하나는 팀이 전체 시스템 아키텍처를 충분히 모른다는 것입니다. Scrum Master인 Anna는 다음 Sprint 초기에 시스템 아키텍트를 참여시켜 팀을 코칭하고 안내하도록 하는 일을 맡습니다.

Sprint 2 - 1일 차

Scrum Product Owner인 Alex는 최근 고객 회의를 바탕으로 Scrum Product Backlog에 새 요구사항을 계속 추가합니다. 또한 공통 Definition of Done을 유지하면서 사용자 스토리 8의 인수 기준과 남은 작업을 명확히 하여 Scrum Team이 기대 결과를 더 잘 그릴 수 있게 합니다.

그런 다음 Alex는 Sprint 2의 Sprint Planning 회의에 팀을 초대합니다. Scrum Team은 Sprint Goal에 합의하고 개발자들은 이를 지원하는 사용자 스토리를 선택하여 계획합니다. Scrum Master인 Anna가 이벤트의 효과를 높이도록 돕고 두 번째 Sprint가 시작됩니다.