Agile Development Overview
Agile Team Roles and Responsibilities
애자일(Agile) 팀을 위한 “마법의” 구조는 없다. 하지만 팀의 주요 멤버들의 역할을 이해하는 것이 중요하다.
스크럼(Scrum)과 같은 모든 애자일 방법들은 몇 가지 공통 역할 및 책임(Roles and Responsibilities)을 다음과 같이 정의한다.
-
Scrum Master or Agile Team Leader 스크럼에서는 스크럼 마스터가 핵심 역할이 되기 때문에, 이에 대해 매우 구체적인 정의를 갖고 있다.
Key Responsibilities
- Road Block 제거: 팀이 마주하는 장애물들은 그들의 통제 및 권한 밖의 일들일 수도 있다. 따라서 이러한 장애물을 제거하여 팀원들이 모멘텀을 유지하여 목표를 이룰 수 있도록 하는 것이 스크럼 마스터의 역할이다.
- Facilitating: 팀이 최종 목표를 향해 나아갈 수 있도록 하는 핵심 기술이다.
- Enforcing the rules: 애자일은 가볍고 유연하지만 그래도 규칙은 있다. 스크럼 마스터는 팀원들이 애자일 프로세스에 대해 숙지하도록 해야한다.
- Protecting the team: 스프린트 목표를 이루는데 방해가 되는 외부 요청에 대해 스크럼 마스터는 책임지고 방어해야 한다.
-
Product Owner Product Owner는 고객 및 이해 관계자들과 같이 소통하며 그들의 요구사항을 이해하고 세부 사항을 팀에게 전달하는 것을 책임지는 역할이다.
NOTE: 스크럼에서는 Product Owner의 역할을 강하게 강조하지만, 이를 맡은 사람은 비즈니스 애널리스트, 프로젝트 매니저 등의 다른 비즈니스 타이틀을 가진 사람이 될 수도 있다.
Key Responsibilities
- 유저 스토리(User Story)를 작성한다.
- 반복 주기마다 구현될 유저 스토리의 우선순위를 설정하여 가장 중요한 스토리가 먼저 수행되도록 해야한다.
- 스토리에 대한 추가 설명이 필요할 때 항상 응해야 하고, 지식을 사용하여 시스템 상에서 스토리가 무엇을 해야하는지를 완전히 파악해야한다.
- 각 반복 주기에 구현되는 스토리들의 Acceptance Testing에 참여한다.
-
Development Team 개발팀은 제품을 만들어서 전달하는 역할을 맡는다. 이 팀에는 프로젝트나 조직의 필요에 맞게 개발자, 테스터, 디자이너, 설계자 등으로 구성되어 있다.
Key Responsibilities 개발자:
- 코드 작성
- Product Owner와 테스터들과 협업하여 올바른 코드가 작성되었는지 확인
- 유닛 테스트 작성
- 각 빌드에 대해 버전 컨트롤 시스템에 코드 올리기
테스터:
- 개발자와 Product Owner와 협업하여 유저 스토리가 명확하게 이해되었는지 확인
- Acceptance 테스트가 스토리가 요구하는 기능성(functionality)을 시험하는지 확인
- 코드가 작성되는 동안에 acceptance 테스트 만들기
- 스토리에 대한 코드에 대하여 acceptance test 수행
- 버전 컨트롤 시스템에 테스트 케이스 올리기
Scrum Process & Events
다음 그림은 전형적인 스크럼 프로세스이다.
스크럼 이벤트와 관련 아티팩트들은 다음과 같다.
출시 계획 회의
- 출시 태스크 보드
- 제품 백로그(Product Backlog)
- 출시에 대한 high-level 계획
- Story point들을 사용한 high-level 추측
스프린트 (Iteration) 계획 회의
- 제품 백로그를 iteration으로 분할
- 유저 스토리를 명확히하고 현재 iteration에 대해 확장
- Product Owner가 유저 스토리 우선순위 설정
- 스프린트 목표와 선택된 유저 스토리들에 대한 팀 의견 교환
일일 스크럼 회의
- 스프린트 기간 동안 매일 같은 장소 & 시간에서 진행
- 최대 15분 동안 진행 상황 및 애로사항 공유
- 다음과 같은 질문들에 대해 대답
- 어제 무슨 일을 하였나?
- 오늘은 무슨 일을 할 것인가?
- 애로사항/장애물이 있는가?
NOTE: 여기서 애로사항/장애물이 해결되는 시점은 아니다. 팀에게 공지를 하는 것이고, 이제 스크럼 마스터가 해당 문제를 해결하기 위해 적절한 조치를 취하는 것이 그의 목표이다. 단, 스크럼 마스터는 문제 해결을 용이하게 하는 것뿐이지 꼭 그것을 고치는 사람을 아니다.
스프린트 리뷰
- 완료된 유저 스토리들을 클라이언트/이해 관계자들에게 보여준다.
- 클라이언트는 수용하거나 거절한다.
- 피드백이 나오고 백로그가 업데이트되거나 우선순위가 재설정 된다.
회고
- 팀에 의해 진행 (클라이언트 없이)
- 다음과 같은 질문들에 대해 의논
- 어떤 것이 잘 진행 되었는지
- 어떤 것이 잘 진행 되지 못했는지
- 어떤 것이 어떻게 개선될 수 있는지
- 이러한 질문들에 대한 조치를 다음 스프린트에 적용
이론은 이정도면 충분하고, 예제를 통해 한 번 알아보자.
우리의 클라이언트/이해관계자의 요구사항은 다음과 같다:
신체적으로 불편한 사람들을 하루종일 집과 직장에서 도와줄 수 있는 로봇을 만들어 주세요.
현재 스프린트: 클라이언트가 아침에 출근 준비를 할 수 있도록 로봇에 프로그래밍할 다양한 태스크를 적어본다.
이 예제에서 우리의 스프린트는 1주의 타임박스(timebox)를 갖는다고 가정하자. 여기서 타임박싱(timeboxing)은 특정한 활동에 대해 정해놓는 고정된 최대 시간을 말한다.
자, 이제 화이트보드나 종이에 간단한 태스크 보드를 만들어보자.
![Task Board]](/assets/img/task_board.png)
역할 설정 (5분) 다음 역할들을 누가 할지를 정해야 한다.
- Product Owner (1명)
- Scrum Master (1명)
- Team (1-2명)
- Client/Stakeholder (1명)
백로그 다듬기 (15분)
- 목표: 모두가 같이 협업하여 위에 언급된 이해관계자의 요구사항에 맞게 제품 백로그를 만든다.
- Product Owner는 클라이언트/이해관계자로부터 전체 제품에 대한 요구사항을 물어보고 각 태스크를 별도의 카드로 태스크 보드의 백로그 열에 추가한다.
- Product Owner는 각 카드를 클라이언트의 니즈에 맞게 High, Medium, Low로 우선순위를 정한다.
- 생성된 아티팩트: 제품 백로그
스프린트 계획 (10분)
- 스프린트 목표: 신체적으로 불편한 사람의 출근을 준비해준다.
- 팀에서 10분 동안 스프린트 계획 세션을 진행하여, 우리의 스프린트 목표에 부합하는 스토리들을 제품 백로그에서 꺼내서 태스크보드의 “Sprint Plan/To-do” 열에 추가한다.
- 생성된 아티팩트: 스프린트 백로그
일일 스크럼 회의/ 스탠드업 미팅 (10분)
- 팀에서 10분 동안 스탠드업 미팅을 진행한다.
- 스크럼 마스터는 일일 스크럼 미팅이 수월하게 진행될 수 있도록 준비한다.
- 스프린트의 Day 2에 일일 스탠드업 미팅을 가졌다고 생각하고 다음 질문들에 대해 대답을 해보자.
- 어제 무슨 일을 하였나?
- 오늘은 무슨 일을 할 것인가?
- 애로사항/장애물이 있는가?
스프린트 리뷰 (10분)
- 스프린트의 마지막 날이고, 현재 스프린트에 대한 모든 스토리들을 완성하였고 ‘done’ 열로 이동시켰다고 생각해보자.
- Product Owner는 팀과 함께 완성된 제품을 클라이언트에게 보여준다. 이 예제에서는 클라이언트, 즉 신체적으로 불편한 사람에게 로봇이 출근을 돕기 위해 할 수 있는 태스크들을 보여준다.
- 클라이언트 입장에서 수용할 수 있고, 혹은 피드백을 주며 거절할 수 있다. 만약 거절한다면 product owner는 새로운 요구사항을 적어서 제품 백로그에 추가한다.
스프린트 회고 (10분)
- 스크럼 마스터와 Product Owner 및 팀원들은 브레인스토밍하여 다음 질문들에 대답한다.
- 어떤 것이 잘 진행 되었는지
- 어떤 것이 잘 진행 되지 못했는지
- 어떤 것이 어떻게 개선될 수 있는지
Leave a comment