[업무지식] 애자일(Agile), 스크럼(Scrum) 이해하기 - 1편

안녕하세요 서후아빠입니다. ^_^

이번 세션은 애자일 방법론과 대표적인 스크럼에 대해서 업무적으로 필요한 최소한의 개념에 대해서 간단히 정리해 보았습니다. 

---

애자일 방법론 기원

구분	설명
군사 국방 분야 프로젝트 (Waterfall)	계획한 절차대로 진행, 큰 변경사항 없음 : 프로젝트 말미에 결과물 도출 ※ 미사일 제작 의뢰 시 : 추가적인 디자인 변경 요구는 반려
민간 프로젝트	욕구 및 트랜드에 의해 제품 Life Cycle 점점 짧아짐에 따라 잦은 변경 필요 계획된 절차대로 진행 시 비효율적으로 경량 방법론 대두
경량 방법론	계획 중심이 중간점검 방식 (프로젝트 진행 중 고쳐 나가는 방식) 17인(Agile Alliance라고 지칭)의 방법론의 공통 사항을 발표 : 애자일 소프트웨어 개발 선언문  ※ 애자일 선언문은 추후 애자일 프로젝트 방법론으로 이어짐

방법론 종류 : 익스트림 프로그래밍(XP), 스크럼, 동적 시스템 개발 방법론, 적응형 소프트웨어 개발 방법론, 크리스탈, 기능 주도 개발론

애자일 방법론 핵심 가치 

구분	설명
프로세스/도구보다는 개인과 상호작용	성공적인 프로젝트 수행의 3가지 요소(프로세스, 도구, 사람) 중 사람이 중요   - 이해관계자간 상호작용 또는 적극적인 의사소통
포괄적인 문서보다는 작동하는 소프트웨어 (소프트웨어 = 결과물)	목적없는 문서 양산 및 문서화 자체가 목적이 되어서는 안됨   - 문서 자체가 불필요하다는 의미가 아님   - 전통적인 프로젝트 : 산출물 비중 높음 (고객요구정의서, 데트스 결과서 등)
계약에 의한 협상보다는 고객과의 협력	시장상황 변화, 시제품 보고 변경사항 요구 발생 시   - 일정, 예산에 대한 고객과의 협상
계획을 고수하기보다는 변화에 대응	프로젝트는 점진적 구체화 특성   - 초기 설정된 업무범위, 일정, 예산은 가급적 준수   - 변화에 적절히 대응하면서 제약조건(QTC 등) 조정

애자일 방법론 원칙

구분	설명
1. 최우선 가치는 미리 그리고 지속적으로  가치 있는 소프트웨어를 전달하여 고객을  만족시키는 것	Waterfall : 요구사항 > 디자인 > 개발 > 테스트 > 배포 Agile : "계획 > 디자인 > 개발 > 테스트 > 배포" 과정을 지속적으로 반복   - 개발 가능한 항목, 모듈을 개발하고 고객에게 전달
2. 고객의 경쟁력을 위해서 개발 후반기라도  요구사항 변경 환영	개발 후반기 변경 요청 대응 가능토록 미리 프로세스 구축 필요
3. 작동하는 소프트웨어를 2주일~2개월  짧은 주기로 자주 전달 (1. 내용 구체화)	고객 요구사항 분석 최고 방법 : 말&글 > 그림 > 시제품 > 실물
4. 이해관계자와 개발자는 프로젝트 기간 중 같은 공간에서 함께 업무 공유	이해관계자간 상호작용 또는 적극적인 의사소통
5. 동기부여된 개인들로 프로젝트를 구성,  그들이 필요로 하는 환경과 지원을 제공하고  일을 끝낼 수 있도록 신뢰	참여 의지 있는 사람들로 구성하고, 개인 의사 최대한 존중 편안하게 일할 수 있는 환경 조성
6. 가장 효과적/효율적인 정보전달방법은 대면 대화	읽기 방식(문서, 메일 등)보다는 말하기/듣기 방식(회의)
7. 프로젝트 진척도의 주된 척도는  작동하는 소프트웨어	문서보다는 개발하는 소프트웨어(결과물) 자체가 중요
8. 지속 가능한 개발 장려, 스폰서/개발자/사용자는 일정한 속도를 유지	성과물 도출 시기에 과도한 업무로 인한 번아웃 발생 주의 일과 삶의 균형 가지고 프로젝트에 몰입할 수 있도록 환경 조성 (작업의 결과물로 팀원 관리 및 통제)
9. 기술적 우수성과 좋은 설계에 대한 관심이  민첩성을 높임	관심에서 이어진 학습 등으로 습득한 지식은 더 좋은 결과물 산출
10. 간결함 (불필요한 업무 최소화)	프로세스/도구에 지나치게 의존하면 결과물보다 과정에 집착하게 됨 요구사항 분명하면 분석에 시간 할애하지 않고 바로 개발 착수
11. 최고의 아키텍처, 요구사항, 설계는  "자기 조직화된 팀"에서 나옴	자기 조직화된 팀 : 지시 없어도 자기 주도적으로 업무수행/유기적 협력  - 팀원 스스로 계획/수행하도록 자율성/책임감 부여  - 프로젝트 매니저는 관리/감독/통제가 아닌 팀원 잠재력 발휘하도록 지원
12. 정기적으로 더 효과적인 방법 논의하고, 이를 바탕으로 팀 조정/조율	Waterfall : 프로젝트 종료 후, 평가(잘한 부분, 잘못한 부분)하고 공유 Agile : 프로젝트 중간중간 지속적으로 평가 수행

적극적인 소통 > 협력 > 즉각적인 피드백(중간 산출물, 지속/반복) > 최종 산출물

방법론 비교

구분	전통적인 방법론 (Waterfall 모델)			애자일 방법론
개념	폭포수가 위에서 아래로 떨어져 내리는 것처럼 순차적으로 진행 확정된 요구사항은 가급적 변경하지 않음			계획보다는 고객이 중요하게 여기는 기능 먼저 개발 요구사항은 상황에 따라 변경될 수 있음
과정	요구사항 분석 > 설계 > 개발 > 테스트 > 수정/보안 ※ Bing bang Release : 프로젝트 후반에 결과물 도출			전체 요구사항 분석 > 여러 개 단위로 구분 > 단위별 수행 ※ 단위(스프린트)    - 우선순위 기능 개발 > 리뷰 > 피드백   - 제품 개발에 초점   - 점진적으로 프로젝트 결과물 완성
프로젝트 매니저	프로젝트 초기에 팀원들 역할과 책임 명확하게 구분 때때로 적절할 작업지시 및 관리감독			자율과 책임감이 부여되도록 운영 프로젝트는 공동 책임 인식되도록 운영
프로젝트 팀원	WBS에 근거하여 R&R 기반으로 맡은 분야 작업			R&R에 얽매이지 말고 아이디어 도출 및 공유 고객과 적극적인 소통 (피드백)
장점	단계 및 R&R 명확 상대적으로 관리 쉬움			중간 결과물 리뷰를 통해 재개발 방지 변화에 대응하기 쉬움
단점	결과물 보고 많은 변경사항 발생 (프로젝트 초기에 요구사항 모두 분석하기 어려움)			계획의 불확실성 잦은 수정으로 최종 결과물이 다를 수 있음 상대적으로 관리 어려움

애자일 방법론의 전체 프로세스

구분	설명
제품 백로그  (Product Backlog ≒ 요구사항 정의서)	프로젝트 결과물에 바라는 기능이나 특성 등을 정리한 문서 : PC에 저장 or 포스트 잇 프로젝트 결과물 도출에 필요한 모든 업무를 기술한 목록 프로젝트 전체계획 수립 시 활용   - 개략적 추진계획 도출   - 투입 공수 추정   - 개발 우선순위 검토   - 2~4주 단위로 집중 개발 목록 분할 (항목별 크기/난이도 따라 분할) 사용자 스토리 : 유사한 것끼리 묶음
스프린트 (Sprint)	사용자 스토리에서 요구하는 기능 및 특성을 구현하는 단계   - 스프린트 계획 : 팀원들은 최적의 수행 방법 고민   - 데일리 스크럼 : 매일 팀원들의 업무수행 경과 논의 및 공유   - 스프린트 리뷰 : 고객과 결과물 확인 및 피드백   - 스프린트 회고 : 현재 스프린트에서 잘한 것과 잘못한 것 평가
프로덕트 오너 (Product Owner)	프로젝트 매니저가 수행하거나 별도 담당자 지정 제품 백로그 생성, 고객과 협의하여 우선순위 조정, 새로운 항목 추가 프로젝트 계획 수립까지 중요한 역할 스프린트 시작 후에는 가급적 운영 관여하지 않는 것 추천
스크럼 마스터 (Scrum Master)	프로젝트 팀원 업무 진행하도록 지원하고 업무 방해 요소 제거 상사나 관리자가 아니므로 프로젝트 팀원에게 업무 지정하지 않음 필요 시 스프린트 수행 단계 진행 팀 내에서 가장 신뢰받는 팀원이 역할 수행 권장
스크럼 팀  (Scrum Team)	결과물 도출 및 구현 위해 노력 개인 업무는 팀 업무로 인식하고 서로 공유

제품 백로그 vs 요구사항 정의서   - 제품 백로그 : 피드백을 통해 우선순위 변경/추가되므로 우선순위 밀리는 요구사항은 구현하지 못할 수 있음   - 요구사항 정의서 : 전통적인 방법론, 프로젝트 종료시까지 모두 구현 애자일 방법론 특성   - 투명성 : 데일리 스크럼, 소멸차트, 스프린트 리뷰 등을 통해 프로젝트 진행상태 및 문제점 파악하고 해결   - 팀 공동 업무수행 : "개인업무 = 팀업무" 간주, 협력 통해 목표 달성에 최선   - 프로젝트 수행 자체에 초점 : 부가적인 관리 업무와 문서 작업 최소화하도록 환경 조성, 시각적인 도구 활용 스크럼 : 미식축구에서 차용, 쉽게 무너지지 않는 대형, 잘 짜여진 팀(스크럼팀=프로젝트팀)    - Cross-Functional팀 : 전문성을 지닌 다양한 사람들의 모임   - 하나의 목표를 위해 프로젝트 팀원 모두가 일치단결해 효율적으로 움직이는 모습을 형상화한 표현 스프린트 : 전력질주, 특정 업무들이 시작되어 완결되어지는 작은 프로젝트 수행 기간, 명확한 목표, 목표에서 벗어나는 추가 요구는 백로그에 저장

애자일 방법론 적용 시 주의사항

구분	설명
문제점	애자일을 관리도구(관리/감독)로 인식 데일리 스크럼 회의가 목표를 잊고 보고의 장으로 변질 애자일은 문서/보고서 생성하지 않는다는 인식 : 문서/보고서 생성 최소화 원칙 야근하지 않는다는 인식 : 약속한 일정은 지키는 것이 필요 부적절할 사람이 스크럼 마스터 역할 수행하는 경우
적용 방안	초기 단계 : 애자일 방법론 이해, 조직 내부에 어떻게 적용할지 검토   - 기존 프로세스와 방법, 조직구조 등에서 개선사항 도출   - 조직에 맞는 애자일 적용 계획 수립 및 애자일 교육 진행      1) 전사 직원 대상 : 세미나를 통해 애자일에 대한 이해도 높이기      2) 프로젝트 리더 : 워크샵을 통해 이론과 실습 등 구체적인 실천방법론 학습     3) 경영진 : 워크샵을 통해 애자일 프로젝트 철학과 경영자의 역할 등 교육 시범 적용 단계   - 2~3개 팀 선정하여 시범적으로 적용 후 교훈을 정리하여 조직에 맞는 효과적 방법 도출   - 필요 시 애자일 방법론에 대한 교육 진행 확장 시범 적용 단계   - 시범 적용 결과 바탕으로 좀 더 큰 규모 프로젝트 혹은 사업부에 적용 전사 확산 단계   - 애자일 코칭 조직 구성   - 애자일 오피스 : 애자일 프로젝트 원활하게 적용되도록 돕는 팀, 애자일 교육/코칭, 적용 중 발생하는 이슈/갈등 해결하도록 지원