11월 2, 2015 
“[단독]삼성전자, 갤럭시S7에 ‘애자일’ 첫 적용”에서도 보듯이 Waterfall 모델의 대명사 삼성전자에서도 SW 부분에 대해서는 Agile로의 체질을 변화하고 있는 중입니다. 저희 프로젝트리서치(주)도 삼성전자 개발 파트장 이상 및 PM/PL 대상으로 Agile PM 워크샵을 여름 부터 진행하여 동참하고 있습니다. 이를 기념하며, 올바른 Agile 문화를 확산하기 위해 Agile PM 및 Agile PMO를 주제로 연재를 개시하고자 합니다. 본회는 7회로써 Agile 을 실행함에 있어서 올바름 흐름을 제시함으로써, 누구나 쉽게 글로벌 표준 흐름대로 쉽게 적용할 수 있는 실사구시 Agile 모델을 제시하고자 합니다.
[Agile PM/PMO 연재 순서]
- 1. Agile 핵심 – Agile은 인본주의 협업 문화 입니다.
- 2. Agile 체크리스트 – 애자일을 올바르게 적용하고 있는지에 대한 자가진단 Kit
- 3. Agile 가치 관리 – 무엇을 먼저해야 의미가 있을까?
- 4. Agile 역할과 책임 – 업무에 책임지고 집중할 수 있는 환경을 구축
- 5. Agile 지식체계 – 목적에 적합한 방법론 및 프레임워크를 맞춤식으로 도입하여 꾸준한 개선을 하는 것이 올바른 방식입니다.
- 6. Agile 도구와 기법 – 처해진 환경에 적합한 연장을 올바르게 사용 하기
- 7. Agile 10 실천 흐름 – 글로벌 표준 흐름으로 프로젝트의 경장 유지
- 8. Agile PMO 핵심 – Enterprise Agile도 PMO 관점으로 접근해야 합니다.
- 9. Agile PMO 체크리스트 – 향후 10년 Enterprise Agile 도약을 위한 반석 체계
- 10. Agile PMO 모델 비교 – 전체적인 거버넌스 체계 안목이 있어야 올바른 관리 체계 이행이 가능합니다.
- Project Charter
- User Story
- Backlog
- Definition of Done
- Definition of Ready
- Story Point
- Burn-down chart
- Sprint Plan
- Daily Scrum
- Sprint Review
1. Project Charter
Project Charter, 즉 프로젝트 헌장이란 프로젝트의 핵심 가치가 담겨있는 요약서 입니다. 이 프로젝트가 어떠한 가치 혹은 혜택을 내포하고 있으며, 마일스톤, 예산, 투입구성원, 특히나 PM 의 역할과 책임, 아울러 이를 승인하는 스폰서의 서명이 포함되어 있는 문서입니다. 사람에게 주민등록증이 있다면, 프로젝트는 차터가 이 주민등록증 처럼 고유 식별을 할 수 있는 것이죠. 차터는 일종의 암행어사의 마패 처럼, 암행어사/PM으로 하여금 왕/스폰서의 권한으로 추진하는 권한 위임장인 문서라 요약할 수 있습니다.
2. User Story
프로젝트 관리의 본질을 “고객의 요구사항을 만족시키는 것”입니다. 이를 위해 프로젝트 관리의 첫 단추인 요구사항을 체계적으로 수집하고 관리하고 갱신하는 것은 매우 중요한 업무입니다. Agile에서는 이러한 요구사항을 User Story라는 명세로 관리하고 있습니다. 철저하게 고객 관점에서 “나는 OO로서 OO을 해야한다. 그럼으로 인해서 OO을 얻는다”라는 사용자/고객의 시각으로 정리하는 것입니다. 서술식으로 누구나 쉽게 이해할 수 있도록 작성 되며, 후에 단위 업무 설계의 기초/반석이 됩니다.
3. Backlog
모든 프로젝트에 없어서는 안되는 소통 기준선이 WBS(Work Breakdown Structure)입니다. WBS가 없는 프로젝트는 프로젝트가 아니죠. 애자일 진영에서는 WBS 역할을 해주는 프로젝트 기준선이 Backlog 입니다. 차이는 WBS 경우 업무 기준으로 분류가 된다면, Backlog는 형상 기준으로 분류가 된다는 점입니다. 다른 말로 이야기하면 자전거를 만들때 WBS는 자전거 부품을 준비한다 > 자건거를 조립한다 > 자전거를 검수한다 > 자전거를 납품한다 형태로 계층구조도가 만들어지는 반면, Backlog는 프레임, 핸들, 안장, 앞바퀴, 뒤바퀴, 체인, 브레이크 등 제품을 형상하는 구조화를 시키는 것이 다르죠. 어찌보면 Backlog 자체를 구체적으로 시각화 할 수 있습니다. 이러한 백로그는 프로젝트 팀원들과 소통하는 기준이 됩니다. User Story는 고객과의 소통 기준이라면, Backlog는 엔지니어와의 소통 기준인 것이죠. 즉 PM은 고객언어와 엔지니어 사이에서 이 Backlog를 기준으로 명확하게 소통해주어야 합니다.
4. Definition of Done
앞서 Backlog 기준의 단위 업무 (Work) 혹은 단위 기능 (Feature)도 중요하지만, 이의 완벽성을 기하기 위해 필!수!적!으로 Definition of done , 즉 검수조건이 중요합니다. 해당 기능이 다 되었는지 아닌지를 판단할 수 있는 판단 근거가 되는 것이죠. 애자일의 성숙도가 높은 기업은 이러한 검수조건을 상당히 체계적으로 관리하고 있습니다. ICT 분야에서는 이러한 항목이 테스트케이스, 테스트셋 (단위시험, 인수시험) 등으로 불리기도 합니다.
5. Definition of Ready
단위 업무를 수행, 혹은 단위 기능을 개발하게 될 때 유사한 것을 먼저 개발하는 것이 효율적일 것입니다. 기 정의된 Backlog 와 Definition of done을 기준으로 유사한 것을 그룹화하여 묶어 놓고, 이의 친화성 및 우선 순위를 매기는 작업을 해야, 향후 프로젝트를 수행 일정을 수립할 때 기준 자료가 될 수 있습니다.
6. Story Point
보통 PM 진영에서는 프로젝트 일정을 Delphi , PERT, Parametric Estimation 기법을 이용해서 수립하는데 반해서, Agile 에서는 이를 팀원들이 Backlog와 검수조건을 기초로 하여 팀원 모두가 개발 시간이 얼마나 걸릴 것인지를 서로 이야기하여, 이를 평균값으로 구해줍니다. 이렇게 함으로써 팀원 모두가 프로젝트 전체 형상과 업무에 대해 모두 이해하게끔 되는거죠. 초기에 시간은 걸리더라고 팀원 모두 프로젝트의 가치와 구체성을 형상화하는 과정에 참여한다는 의미가 있습니다.
7. Burn-down chart
프로젝트 진척은 일반적으로 Gantt 차트를 많이 사용합니다. Gantt 차트의 구성을 보면 할일(WBS)과 이의 연계성, 시작예정일과 종료예정일을 기준으로 일정(Bar Chart) 계획 및 실적을 관리하게 끔 되어있습니다. 즉 일정을 기준으로한 진도율이 기준이라는 것이죠. 애자일에서는 일정 기준 진도율이 아닌 Backlog가 총 몇개이고 몇 개가 남았는지를 가지고 이야기 합니다. 다시말해 작업의 개수, 혹은 형상/기능의 개수를 가지고 프로젝트를 관리하게 되고 이를 시각적으로 표현한 것이 Burn-down 차트(소멸도) 입니다. 프로젝트 관리를 아주 깔끔하게 시각적으로 관리해주는 도구요. Burn-down 차트는 일정을 기준으로 작성되고 앞서 범위에 대한 user story, backlog, definition of done 항목은 칸반보드 (간판보드, Kanban, Information-radiators)에서 시각적으로 관리합니다.
8. Sprint Plan
일반적인 프로젝트가 주간 < 월간 < 마일스톤 계층 개념으로 계획 수립이 이루어 진다면, 애자일에서는 2주에서 3주 단위로 업무를 균등하게 계획 수립을 하게 끔 됩니다. 즉, 주간이라는 단어보다는, 2-3주 단위를 하나의 Iteration 혹은 Sprint라는 단어로 사용하게 됩니다. 그리고 이러한 2-3주 기간 동안에 해야할 사항에 대해 구체적으로 명세화 하되, 최대 4시간을 넘지 않는 범위내에서 기획하게 되며, 이 기획에는 Risk에 대한 기획 또한 포함됩니다. 이 과정을 통해 범위는 칸반/Kanban, 일정은 소멸도/Burn-down에 정밀하게 표현이 되며, 단기적인 업무 계획/목표가 되는 것입니다.
9 Daily Scrum
프로젝트 일정 현황 공유를 매일매일 기립 회의 형태로 하루 15-20분을 넘지 않는 범위로 수행합니다. 서서하는 이유는 회의를 효율적으로 하기 위해서이고, 이때의 진행 방법은 PM이 팀원들에게 지시하는 것이 아닌, 팀원 스스로가 본인이 작성한 Backlog와 Definition of done을 스스로 일일의 완료사항과 계획사항을 돌아가면서 이야기하도록 가이드 합니다. 이 행위는 결국 팀원 스스로의 동기부여/Self-motivation 정신으로 업무를 수행할 수 있는 환경을 만들어줍니다. PM은 단지 질문으로 팀원들이 자각할 수 있게만 하면 됩니다.
10. Sprint Review
프로젝트에서 중요한 것은 꾸준한 개선입니다. WBS/Backlog는 Rolling Wave라는 항목을 써서 점진적으로 구체화 하듯이, 프로젝트의 경험은 쌓이고 쌓여서 점진적으로 효율성이 개선되어야 합니다. 이에는 좋은 점은 계승 발전시키고, 개선한 점은 도출하여 개선, 안좋은 점은 재발되지 않도록 모든 팀원이 인지하고 동반성장해야 합니다. 이러한 분위기, 개선/Kaizen 환경에서 프로젝트를 수행할 수 있도록 해주는 것이 스프린트 리뷰활동입니다. 이의 핵심 activity는 회고/Retrospective인데, PM쪽에서는 이를 교훈/Lessons Learned라고 불르기도 합니다. 애자일을 잘 수행하는 조직은 이러한 교훈/회고/리뷰 문화가 잘 구현되어 있고, 이를 언제라도 열람/조회/활용할 수 있도록 KM/지식DB 화 하여 관리하고 있습니다.
Project Research 
아직 댓글이 없습니다... 첫 번째로 댓글을 작성하세요!