애자일 소프트웨어 개발 (Agile Software Development) 방법론(2) - PM, 스크럼(Scrum)

애자일 방법론 (Agile Methods)

 

애자일 방법론의 특징

1. 코드에 중점: 애자일 방법론은 설계(Design)보다는 실제 코드에 중점을 둡니다. 이는 실질적으로 작동하는 소프트웨어를 빠르게 개발하는 데 초점을 맞추기 위함입니다.
2. 반복적 접근 (Iterative Approach): 소프트웨어 개발을 여러 번의 반복 주기로 나누어 진행합니다. 각 반복 주기마다 소프트웨어의 일부 기능을 개발하고, 이를 점진적으로 완성해 나갑니다.
3. 신속한 작동 소프트웨어 전달 및 진화: 작동하는 소프트웨어를 빠르게 제공하고, 이를 바탕으로 변화하는 요구사항에 맞춰 지속적으로 발전시킵니다.

애자일 방법론의 두 가지 유형

1. 애자일 개발 기법 (Agile Development Techniques): 실제 소프트웨어 개발 과정에서 사용하는 구체적인 기술과 방법론을 말합니다. 예를 들어, 스크럼(Scrum), 익스트림 프로그래밍(XP) 등이 이에 해당합니다.
2. 애자일 프로젝트 관리 (Agile Project Management): 프로젝트 관리 측면에서 애자일 원칙을 적용하는 방법론입니다. 프로젝트의 계획, 실행, 모니터링, 통제를 유연하게 관리하여 변화에 효과적으로 대응합니다.

저번 포스트에서는 애자일 개발 기법 (Agile Development Techniques)에 대해서 알아봤으니 이번 포스트에서는 애자일 프로젝트 관리 (Agile Project Management)와 스크럼 기법에 대해서 알아보겠습니다!

---

 2. 애자일 프로젝트 관리 (Agile Project Management)

 

소프트웨어 프로젝트 관리자의 주요 책임

소프트웨어 프로젝트 관리자의 주요 책임은 소프트웨어를 정해진 시간 내에, 계획된 예산 내에서 성공적으로 전달하는 것입니다. 이를 위해 프로젝트의 범위, 일정, 자원 등을 효과적으로 관리해야 합니다.

전통적인 계획 중심 프로젝트 관리 (Plan-Driven Project Management)

전통적인 프로젝트 관리 접근 방식은 계획 중심(plan-driven)으로, 프로젝트 시작 시 상세한 계획을 수립하고 이를 기반으로 프로젝트를 진행합니다. 주요 특징은 다음과 같습니다:

• 무엇을 전달해야 하는지 정의: 프로젝트의 목표와 산출물을 명확히 설정합니다.
• 언제 전달해야 하는지 정의: 프로젝트 일정과 마일스톤을 설정합니다.
• 누가 개발에 참여할 것인지 정의: 팀 구성원과 역할을 명확히 합니다.

애자일 프로젝트 관리의 차별점

애자일 프로젝트 관리는 전통적인 계획 중심 접근 방식과는 다른 유연하고 적응적인 방식을 채택합니다. 주요 차별점은 다음과 같습니다:

• Increment 개발에 적응: 소프트웨어를 작은 단위로 나누어 점진적으로 개발하고, 각 단위가 완성될 때마다 고객에게 전달합니다.
• 애자일 개발 방법론의 실천 방안 적용: 애자일 방법론(예: 스크럼, 칸반 등)의 실천 방안을 프로젝트 관리에 통합하여 유연하게 대응합니다.

---

스크럼 (Scrum)

애자일 프로젝트 관리 방법론 중 하나인 스크럼(Scrum)은 반복적(iterative) 개발을 효과적으로 관리하기 위한 프레임워크입니다. 스크럼은 특정 애자일 실천 방안보다는 반복적 개발 관리에 초점을 맞추고 있습니다.

---

Scrum Terminology

---

스크럼의 개요

스크럼(Scrum)은 애자일 방법론 중 하나로, 반복적(iterative) 개발을 관리하는 데 중점을 둡니다. 스크럼의 주요 특징은 다음과 같습니다:

• 짧은 일일 미팅: 스크럼의 이름은 매일 진행되는 짧은 미팅에서 유래되었습니다.
• 팀원 간의 정보 공유: 모든 팀원은 지난 회의 이후의 진행 상황, 발생한 문제, 다음 날의 계획을 공유합니다.
• 투명성 유지: 팀 내 모든 구성원이 프로젝트의 현재 상황을 파악하고, 문제가 발생할 경우 단기 작업을 재계획할 수 있습니다

---

스크럼의 3 Phase

스크럼은 크게 세 가지 단계로 나눌 수 있습니다:

1. 초기 단계 (Initial Phase)
   • 개요 계획 수립: 프로젝트의 일반적인 목표를 설정하고, 소프트웨어 아키텍처를 설계합니다.
2. 스프린트 사이클 (Sprint Cycles)
   • 스프린트 개발: 각 스프린트는 소프트웨어의 인크리먼트를 개발하는 주기입니다. 일반적으로 2~4주 동안 진행됩니다.
3. 프로젝트 종료 단계 (Project Closure Phase)
   • 프로젝트 마무리: 프로젝트를 정리하고, 필요한 문서를 완성하며, 프로젝트에서 얻은 교훈을 평가합니다.

---

스크럼의 스프린트 사이클 (Scrum Sprint Cycles)

 

스프린트(Sprint)는 스크럼에서 정해진 기간 동안 수행되는 개발 주기입니다. 주요 특징은 다음과 같습니다:

• 고정된 기간: 일반적으로 2~4주로 설정되며, 스프린트가 시작되면 그 기간 동안 동일한 기간을 유지합니다.
• 제품 백로그(Product Backlog): 스프린트 계획의 출발점으로, 프로젝트에서 수행해야 할 작업 목록입니다.

스프린트 계획 단계

1. 제품 백로그에서 작업 선택:
   • 제품 백로그(Product Backlog)는 프로젝트에서 수행해야 할 모든 작업의 목록입니다.
   • 스프린트 백로그(Sprint Backlog)는 다음 스프린트 동안 수행할 작업을 선택한 목록입니다.
   • 프로젝트 팀은 고객과 협력하여 제품 백로그에서 스프린트 동안 개발할 기능과 작업을 선택합니다.
2. 팀의 자율 조직화:
   • 선택된 작업을 기반으로 팀은 스스로 조직화하여 소프트웨어를 개발합니다.
   • 팀은 스프린트 동안 필요한 역할과 책임을 분담합니다.
3. 스크럼 마스터(Scrum Master)의 역할:
   • 팀은 고객과 조직으로부터 격리되어 스프린트 동안 개발에 집중합니다.
   • 모든 커뮤니케이션은 스크럼 마스터(Scrum Master)를 통해 이루어집니다.
   • 스크럼 마스터는 개발 팀을 외부의 방해 요소로부터 보호하고, 팀이 효율적으로 작업할 수 있도록 지원합니다.

스프린트 종료 및 리뷰

• 스프린트 리뷰: 스프린트가 끝나면 개발된 작업을 검토하고, 이해관계자들에게 발표합니다.
• 피드백 수집: 리뷰를 통해 얻은 피드백을 바탕으로 다음 스프린트를 계획합니다.
• 다음 스프린트 시작: 피드백과 교훈을 반영하여 새로운 스프린트 사이클을 시작합니다.

 

---

스크럼의 주요 구성 요소

1. 제품 백로그 (Product Backlog)

• 정의: 프로젝트에서 수행해야 할 모든 작업과 기능의 우선순위가 매겨진 목록입니다.
• 관리: 제품 소유자(Product Owner)가 주도적으로 관리하며, 지속적으로 업데이트됩니다.
• 내용: 사용자 스토리(User Stories), 기능 요구사항, 버그 수정 등 다양한 항목이 포함됩니다.

2. 스프린트 백로그 (Sprint Backlog)

• 정의: 특정 스프린트 동안 수행할 작업의 목록입니다.
• 선정: 팀과 고객이 협력하여 제품 백로그에서 선택한 작업으로 구성됩니다.
• 관리: 팀이 스프린트 동안 작업을 추적하고 관리합니다.

3. 스크럼 마스터 (Scrum Master)

• 역할: 팀이 스크럼 프로세스를 준수하도록 돕고, 외부의 방해 요소로부터 팀을 보호합니다.
• 책임:
  • 스크럼 회의를 주도하고 조율합니다.
  • 팀의 문제 해결을 지원합니다.
  • 스크럼 원칙과 실천 방안이 제대로 이행되도록 보장합니다.

4. 스크럼 회의 (Scrum Meetings)

• 데일리 스크럼(Daily Scrum):
  • 매일 짧은 시간(보통 15분) 동안 진행됩니다.
  • 팀원들이 자신의 진행 상황, 문제점, 다음 작업을 공유합니다.
• 스프린트 계획 회의(Sprint Planning Meeting):
  • 스프린트 시작 시, 어떤 작업을 수행할지 계획합니다.
• 스프린트 리뷰 회의(Sprint Review Meeting):
  • 스프린트 종료 시, 완료된 작업을 검토하고 피드백을 받습니다.
• 스프린트 회고 회의(Sprint Retrospective Meeting):
  • 스프린트 종료 후, 팀의 작업 방식을 평가하고 개선점을 논의합니다.

---

스크럼의 장점

• 유연한 대응: 변화하는 요구사항에 신속하게 대응할 수 있습니다.
• 높은 투명성: 팀 내 모든 구성원이 프로젝트의 진행 상황을 명확히 이해합니다.
• 지속적인 피드백: 정기적인 리뷰를 통해 지속적으로 피드백을 받고 개선할 수 있습니다.
• 팀 협력 강화: 스크럼 마스터와 팀원 간의 긴밀한 협력을 통해 효율적인 작업이 가능합니다.
• 품질 향상: 짧은 스프린트 주기와 지속적인 테스트를 통해 소프트웨어의 품질을 높일 수 있습니다.

---

스크럼의 한계 및 고려사항

• 고객의 적극적인 참여 필요: 고객이 지속적으로 참여하고 피드백을 제공해야 합니다.
• 팀의 자율성과 책임감: 팀원들이 높은 수준의 자율성과 책임감을 가져야 합니다.
• 스프린트의 고정된 기간: 스프린트 기간을 잘 설정하지 않으면 프로젝트 진행에 어려움이 있을 수 있습니다.
• 스크럼 마스터의 역할: 스크럼 마스터가 팀을 효과적으로 지원하고 외부 방해 요소를 관리해야 합니다.

---

결론

애자일 프로젝트 관리는 전통적인 계획 중심 접근 방식과는 달리, 유연하고 적응적인 방법을 통해 소프트웨어 개발을 효과적으로 관리합니다. 그 중 스크럼(Scrum)은 반복적 개발을 관리하는 프레임워크로, 팀의 협력과 투명성을 높이고, 지속적인 피드백을 통해 소프트웨어의 품질을 향상시킵니다.

스크럼을 성공적으로 적용하기 위해서는 팀의 높은 협력 수준, 고객의 적극적인 참여, 스크럼 마스터의 효과적인 역할 수행 등이 필수적입니다. 이를 통해 변화하는 비즈니스 요구사항에 신속하게 대응하고, 고품질의 소프트웨어를 지속적으로 제공할 수 있습니다.