Agile(애자일) 대표 관리 Practice인 Scrum(스크럼)은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크입니다. Scrum은 작은 주기(Sprint)로 개발 및 검토를 하며 효율적인 협업 방법을 제공합니다.
따라서 필요한 분석/설계/개발 가이드는 조직내에서 사용하고 있는 개발방법론, 산출물 가이드 등과 병행해서 활용 가능합니다. 실질적인 도움이 되지 않는 문서를 작성하지 않는 것이 중요하며, 효과적으로 일하는데 필요한 문서는 반드시 작성해야 합니다.
https://agileforall.com/resources/introduction-to-agile/
1. Scrum이란?
1.1. 개요
- 스크럼은 복잡한 제품을 개발(배포)하고, 유지하기 위한 프레임워크
- 1995년에 Ken Schwaber와 Jeff Sutherland가 고안
- 노나카 이쿠지로와 타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 “The New New Product Developement Game”에서 시작 - 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크(기법)
- 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게하여, 복잡하고 정교한 제품을 생산
1. 2. 주요 특징
- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
- 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
(설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요) - 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
(설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음) - 매일 15분 정도의 Scrum meeting 회의를 가져라.
(설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.) - 항상 팀을 우선으로 생각하라.
(설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.) - 원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.
2. Scrum의 추구 가치
- 용기 : 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!
(설명 : 상사에게도 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다.) - 집중 : 공동 목표 달성을 위한 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!
(설명 : Goal/업무에 집중 할 수 있도록 하며, 루틴한 반복 작업이 있다면 제거, 자동화 등 효율적화해야 한다.) - 약속(헌신/책임) : 팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 헌신하고, 필요한 모든 권한을 부여하라!
(설명 : 개인 성과보다는 팀의 성과 달성이 우선이고, 이를 위해 최대한 지원/권한이 필요하다.) - 존중 : 경력과 경험이 사람을 만든다. 팀원과 Idea를 존중하라!
(설명 : 개개인별로 경험과 장단점이 있고, 다른 생각을 하는 사람도 그 이유가 있을것이다.) - 투명성/개방성 : 프로젝트에 대한 모든 작업 내용을 투명하게 공개하라!
(설명 : 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않는다. 그래야 Idea나 문제점이 보인다.)
이미지 출처 : https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage
3. Scrum의 주요 역할자
Product Owner와 Scrum Master는 서로 보완하는 두 가지 역할을합니다.
3.1. 제품 책임자(Product Owner)
비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토합니다.
- 제품 백로그(요구사항) 관리/설명
- 제품 백로그의 우선순위 관리
- 만족스럽게 개발되었는지 확인
이미지 출처 : https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/
3.2. 스크럼 마스터(ScrumMaster)
Product Owner와 Development Team이 민첩한 가치(Value)와 원칙(Principle)을 유지하며 성공적인 제품을 만들고, 조직 변화를 촉진하고 민첩한 작업 방식을 수립하여 성공을 책임집니다.
- 팀을 보호하고 장애 요소를 해결
- 일일 스크럼 회의를 진행
- 모니터링 및 Tracking
이미지 출처 : https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/
3.3. 개발 팀 (Developer)
최선의 기술로 백로그를 개발하여 고객을 만족시킵니다.
4. Scrum 주요 용어
- 제품 백로그(Product Backlog) : 개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리
이미지 출처 : https://www.softwaretestinghelp.com/user-story-acceptance-criteria/
- 사용자 스토리(User Story) : 사용자 관점에서 사용자에게 가치를 제공하는 기능 및 설명 (해설 : PO는 이 기능이 누구에게 무슨 value를 제공하는지를 설명하고, 향후 개발자는 그 기능의 품질을 만족시키기 위한 기술적인 방법을 고민)
- 완료 기준(Definition of Done), 인수 기준(Acceptance Criteria) : 사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)
출처 : https://twitter.com/kickstartpros/status/524414603359686657
- 스프린트(Sprint) : 계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택
- 잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP) : 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품
- 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의
- 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
- 칸반 보드(Kanban Board) : 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판
이미지 출처 : https://agilevelocity.com/scrum/4-advantages-of-physical-task-boards/
- 일일 스크럼 회의(Daily Scrum Meeting) : 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의
(해설:모든 참여자가 보고가 아닌 수평적으로 공유 차원에서 진행해야 하며 팀원이 아니면 발언권은 없다. 개인적인 생각으로는 만약 PO, 관리자 등도 참여한다면 똑같이 3가지를 공유해야 한다. 그렇지 않으면 듣는 자리, 즉 보고 받는 자리로 변질되고, 개발자 관점에서는 관리자가 노는 사람 처럼 보인다. 또한 Sprint Planning에 없는 제3자가 시킨 잡무를 하고 있다는 것도 파악이 가능하다. 장애요소는 화이트보드에 적어놓고 지속적으로 해결한다. 만약 해결보다 쌓이는게 만다면 회사는 팀을 충분히 지원하지 않는 것이며, 일일 스크럼 회의는 생산적이지 않은 낭비로 인식된다.)
이미지 출처 : https://www.slideshare.net/TanaLinback/scrum-training-one-day
- 스프린트 리뷰(Sprint Review) : 스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토
- 스프린트 회고(Sprint Restospective) : 스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선
이미지 출처 : https://www.slideshare.net/TanaLinback/scrum-training-one-day
5. 스크럼 진행 순서
- PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
- PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
- 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
(해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.) - 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
- 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
- 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다.
(해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.) - 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.
6. 요약
- Scrum Framework의 역할 및 Time-Box
이미지 출처 : http://scrumprimer.org/anime
- Scrum Framework의 역할, 산출물, 이벤트
이미지 출처 : https://documentation.cochrane.org/display/WWIRPT/Scrum+process
- 3개월 단위의 Agile 프로젝트의 전체 진행 모습
Agile을 따라하지 말고,
Agile로 얻으려는 Goal에 집중하세요!!!
보시면 유용한 자료
- Scrum Guide :
https://www.scrumguides.org/download.html [English], [한글] - The Scrum PRIMER :
https://scrumprimer.org/primers/ [English], [한글] - Agile project management with Scrum :
https://www.pmi.org/learning/library/agile-project-management-scrum-6269 - [DevOps] JIRA를 활용한 협업(1부)
- [DevOps] JIRA를 활용한 협업(2부)
'개발 관리' 카테고리의 다른 글
| github로 코드리뷰 하기 (0) | 2021.08.28 |
|---|---|
| DevOps와 CI/CD (0) | 2021.06.13 |
| 우리팀 Confluence 사용하는 법 (0) | 2021.04.19 |
| JIRA의 scrum보드 활용법 (0) | 2021.04.15 |
| Jira를 통해 스크럼 관리하기 (0) | 2021.04.15 |