Recommended
More Related Content
What's hot
What's hot (20)
Similar to [해줌] 애자일 스크럼 교육 자료
Similar to [해줌] 애자일 스크럼 교육 자료 (20)
[해줌] 애자일 스크럼 교육 자료
- 1. ㈜이든스토리 | HAEZOOM 해줌 Goal 을 넣어보자 (What is Scrum?) HAEZOOM 해줌 (발표 : 오우주) 2019.05.09
- 2. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 2 - ME? 웹개발 (9년차 쪼렙) ● 8개 제품 오픈 ● 4년 시스템 유지보수 경험 ● DEV / PL / PM / SCRUM MASTER
- 3. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 3 - 순서? ● 폭포수 모델 ● 애자일 ○ Value ○ Principles ○ Practices ● 스크럼 ○ 정의/사용/이론 ○ 구성 (3355)
- 4. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 4 - # 폭포수 모델 (waterfall model) ?
- 5. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 5 - # 폭포수 모델의 문제점
- 6. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 6 - # Agile? - Agile is a state / mindset / competence (“Not doing agile, but being agile”) - It’s NOT a single methodology, process or framework “using no way as way”
- 7. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 7 - # Agility Tree ● 열매 : Practices ○ xp, scaling, lean, less, kanban, devops, DT, Scrum … ● 줄기 : Principles ● 뿌리 : Values
- 8. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 8 - # Agile Values (Manifesto for Agile Software Development) 1. 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다. ( Individuals and interactions over processes and tools ) 2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다. ( Working software over comprehensive documentation ) 3. 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다. ( Customer collaboration over contract negotiation ) 4. 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다. ( Responding to change over following a plan ) http://agilemanifesto.org/
- 9. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 9 - #Agile Principles
- 10. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 10 - # Agile Practice - Scrum : 정의 가장 가치 있는 제품을 생산적이고 창의적으로 배포하기 위하여 복잡하게 얽힌 적응적 문제들(complex adaptive problems)을 다룰 수 있도록 하는 프레임워 크. 스크럼은: • 간단하고, • 이해하기 쉽지만, • 마스터하기는 어려운 프레임워크 입니다
- 11. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 11 - # 스크럼의 사용 ● 스크럼은 개인과 사회에서, 소프트웨어 개발뿐 아니라 하드웨어, 임베 디드 소프트웨어, 상호 작용 기능의 네트워크, 자율주행 차량, 학교, 정 부, 마케팅, 조직 운영 및 일상생활에서 사용 ● 기술과 시장, 환경의 복잡성과 그들 간에 상호 작용이 급격하게 증가 함에 따라 복잡성을 다루는 스크럼의 유용함이 매일 증명
- 12. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 12 - # 스크럼 이론 • 경험주의 (empiricism) • 반복적 (iterative) • 점진적 (incremental) • 투명성 (Transparency) • 검토 (Inspection) • 적응 (Adaptation)
- 13. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 13 - # 스크럼의 구성 3355 • 3 역할 (Roles) • 3 산출물 (Artifacts) • 5 이벤트 (Event) • 5 가치 (Values)
- 14. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 14 - # 3355 : 스크럼의 가치 5 • 약속 (Commitment) • 용기 (Courage) • 집중 (Focus) • 개방성 (Openness) • 존중 (Respect)
- 15. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 15 - # 3355 : 스크럼 팀 스크럼 팀 키워드 • 자기 조직화 (self-organizing) • 유연성, 창의성, 생산성을 최적화 • 피드백 기회 극대화 : 반복적 (iteratively), 점진적 (incremental)
- 16. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 16 - # 3355 : 스크럼 팀 Scrum Master Product Owner Dev Team
- 17. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 17 - # Characteristics ● 구성원은 3~9 명이 적당 ● 교차 기능적 (cross-functional) : T-shape team member ● 팀 주기 : 프로젝트 ● 수평적 관계 (& 하위팀 없음) ● 자기 조직화 (Self-organized) Dev Team
- 18. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 18 - # Mission ● 매 스프린트에서 “완료”된 기능을 지속해서 추가 (Deliver Product Increment s) ● 제품의 품질과 방법에 대한 책임과 권한 ● Sprint Backlog 작성, 관리 ● Sprint event 참석 ● 다른 팀이나 부서와 협력 ● 함께 일하는 가장 좋은 방법 찾기 ● 끊임없는 자기개발 Dev Team
- 19. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 19 - # Characteristics ● 1명 (위원회 아님) ● 이해관계자(stakeholder)들에게 프로젝트를 대표하는 역할 & 팀에게는 이해 관계자들을 대표하는 역할 ● “무엇”을 “Impact” 있게 고객에게 전달할지 결정할 권한 ● 제품에 대한 리더쉽 발휘 ● 모든이와 협업 Product Owner
- 20. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 20 - # Mission ● 제품의 가치를 최상으로 만들 책임과 권한 ● “왜” ● 제품의 특징, 기능을 정의 ● 투자받을 책임 (ROI) ● 제품 백로그 관리 (우선순위 설정 및 재조정) ● 릴리즈 날짜와 범위 결정 ● Sprint events 에 참여 ● 작업결과에 대한 수락/거부 Product Owner
- 21. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 21 - Product Owner Example - 그리운 짭스옹
- 22. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 22 - # Characteristics ● 전통적인 PM 아님 주의 ● 관리 안함 (팀을 대표하여 결정을 내리지 않음) ● 섬김 리더쉽 (servant leader) ● 양치기 개 (지원, 보호, 서비스, 촉진) ● 관리자보다 코치 역할에 가까움 ● 말하기보다는 듣기 ● 열린 마음 유지하기 ● 스크럼 가치들을 지닌 롤모델 되기 ● 다른 스크럼 마스터들과 협력 Scrum Master
- 23. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 23 - # Mission ● 훌륭한 스크럼 팀과 민첩한 조직 육성 ● 스크럼 및 agile 변화를 위한 가치, 원칙 및 규칙 제정 담당 ● Product Owner and Development Team 지원 ● 장애 제거 ● 효과적인 코칭으로 팀 발전을 돕고 의미 있는 질문을 던짐 ● 팀을 보호 ● 팀 협업/생산성 향상 촉진 ● 팀의 동기 부여 및 도전 ● 조직 내 스크럼 효과 개선 작업 Scrum Master
- 24. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 24 - Scrum Master Example
- 25. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 25 - # 3355 : 5 Events • Sprint • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective
- 26. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 26 - Sprint • 스크럼의 핵심 • 한 달 이하의 기간 (고정) • 구성 : 스프린트 계획, 일일 스크럼, 개발 작업, 스프린트 리뷰, 스프린트 회 고 • 변경허용x, 품질 목표 유지, 개발범위 재협상 가능
- 27. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 27 - Sprint Planning • 8h/1M sprint • What (이 스프린트에서 배포 가능한 제품 증분은 무엇인가?) – 스프린트 목표를 작성 – 제품 백로그 우선순위 정하기 (PO) – 개발할 제품 백로그 항목 수는 전적으로 개발팀이 결정 • How (제품 증분을 성공적으로 배포하는 데 필요한 작업이 무엇인가?) – sprint backlog – 스프린트 계획 미팅을 끝나기 전에, 개발팀은 스프린트 목표를 달성하기 위해 어떻게 작업할 것이고 어떻게 예상 되는 제품 증분을 만들어 낼 것인지 제품 책임자와 스크럼 마스터에게 설명
- 28. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 28 - Daily Scrum • 매일, 같은 시간, 같은 장소, 15분, 서서, 개발팀 (필요따라 PO, SM) • 자세한 문제 해결토론 아님주의 • 어제 뭐했고 오늘 뭐할꺼다. 방해 요소가 뭐가 있다. (Self-Management 를 동료들 앞 에서 공유하는 개념) • “이 스프린트 목표를 달성하기 위해 전체적으로 어떻게 하고 있는가?”를 함께 살펴봄 으로써 데일리 스크럼을 마무으리
- 29. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 29 - Sprint Review • 4h / 1M sprint • 증분 확인 : – Scrum Team + All stakeholders 함께 “완료” 확인 (경과보고 아님 주의) – 제품 책임자 : “완료”된 제품 백로그 아이템 / “완료”되지 못한 아이템을 설명. 남아있 는 제품 백로그 설명, 예상 목표 및 제품 전달 날짜 계획 – 개발팀 : 스프린트 동안 잘 진행된것, 문제점, 어떻게 문제 해결 공유. “완료”된 작업 시 연 및 질문 답변 • 다음 계획 : – 다음에 무엇을 할지 함께 의논, 다음 스프린트 계획에 가치 있는 조언을 제공 – 제품의 시장이나 잠재적 사용처가 어떻게 변했는지, 다음에 해야 할 가장 가치 있는 일 들은 무엇인지 검토 – 다음 제품 출시 기능이나 성능에 대한 - 일정, 예산, 잠재적 기능, 그리고 시장에 대해 검 토
- 30. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 30 - Sprint Retrospective • 3h / 1M sprint • 스크럼팀 참석 • 스프린트 리뷰 미팅 후 그리고 다음 스프린트 계획 미팅 전에 수행 • 목적 : – 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토 – 잘 된 것들 그리고 개선의 여지가 있는 주요 항목들을 알아내고 순위화 – 작업을 수행하는 방법에 대한 개선을 실천할 수 있도록 계획을 수립 • One popular format : for instance – Start doing – Stop doing – Keep doing
- 31. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 31 - # 3355 : 스크럼 산출물 (Scrum Artifacts) • 제품 백로그 (Product Backlog) • 스프린트 백로그 (Sprint Backlog) • 제품 증분 (Product Increment)
- 32. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 32 - Product Backlog • 제품 책임자(PO)가 제품 백로그에 대한 책임 및 권한을 가짐 • 다음 배포에 포함될 요구사항(완성본 아님주의), 피처, 기능, 개선사항, 버그 • 각각에 대한 설명, 우선순위, 예상 견적 등을 포함 • 유동적 (시장에서 적합하고 경쟁력 있고 유용하도록 지속변화)
- 33. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 33 - Product Backlog As a [a specific user role], I want to [accomplish a result/ feature], So that [Impact/Goal]. ex) “As a web user, I want to sign in the system, so that I can access the landing page”
- 34. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 34 - Acceptance Criteria
- 35. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 35 - Product Backlog • User Value • Size • Risk • Time-to-market • Dependencies • Learning Value
- 36. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 36 - Product Backlog Refinement • Purpose? • When to do? • Who to do? • Max 10% of total Sprint efforts spending on refinement
- 37. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 37 - Sprint Backlog • 스프린트를 위해 선택된 제품 백로그 항목들의 집합 • 제품 증분을 배포하고 스프린트 목표를 실현하기 위해 충분 히 상세화된 계획서 • 개발팀이 예상한 작업 목록 (스프린트 중 수정/추가 가능) • 개발팀이 소유/변경 가능 • 가시화된 도구로 스프린트 기간동안 그 자체가 관리역할을 하도록 함
- 38. Copyright ⓒ 2019 HAEZOOM INC. All Right Reserved. - 38 - Increment • 스프린트에서 완료된 모든 제품 백로그 항목들의 집합 • 제품 출시 여부와 관계없이 사용 가능한 상태여야함 • Velocity of Sprint : how many story points the team can deliver in one sprint (Estimating : Absolute VS Relative)
- 39. Thank you
Editor's Notes
- 개발 공정을 요구 사항 분석, 설계, 구현, 시험 및 유지 보수의 몇 단계로 구분하여 각 단계의 성과를 문서로 명확하게 확정한 후에 다음 단계로 넘어가는 체계적이며 순차적인 접근 방법 저는 개인적으로, 경력의 대부분을 이 방식을 따라 개발 해왔습니다. 제가 느낀 이 방식의 장점은 모든과정이 문서화 되어서 문제가 생겼을때 책임소재를 분명히 가릴 수 있고, 설계에 따라 개발만 하면 되기때문에 개발자 입장에서는 따로 신경쓸 것이 없어서 편한면도 분명 존재합니다. 각자 맡은바의 롤만 충실히 잘 해내면 납기, 비용, 원하는 프로덕트를 얻을 수 있다는 희망찬 모델이지요. 문제점? 문제점 발견시 전단계로 다시 가는것이 불가능 (중간에 요구사항을 바꾸기 힘들다) 최초 요구사항을 낸 실무자는 테스팅 단계 이후에서 실제 제품을 처음 접한다 문서 작성에 시간을 많이 사용한다 프로젝트를 진행하며 예상하지 못한 여러가지 문제점들이 고려되지 않음 (개발팀의 역량, 기술적 리스크, 요구사항의 불확실성. 공수산정도 잘 못해서 납기 맞추기가 힘든 경우가 많이 발생. 애자일에서는 프로젝트를 이런 요소로 인해 비용과 일정을 정확하게 예측하기 힘든 ‘복잡적응계’로 인식한다. *복잡적응계 : 많은 구성 요소가 상호작용하면서 경험과 학습으로 상황에 적응해 나가는 시스템) -> 이런 문제점이 제품에 어떤 영향을 미칠까요?
- 각 단계별로 각자의 롤을 확실히 할 경우 어느정도 이런 결과를 방지할 수 있음 그러나 시장변화까지는 컨트롤 할 수 없고, 폭포수 모델은 시장 변화에 대응하기 힘든 모델. 세상은 점점 빠르게 변하고 있고, 정보의 양은 기하급수적으로 늘고 있고, 소비자의 취향에 따라 제조업도 다품종 소량생산으로 변했듯 소프트웨어 프로덕트도 시장변화에 기민하게 대처할 필요가 이미 요구되었고 그 와중에 폭포수 모델은 그 한계점을 가감없이 드러내고 있음
- 나무는 이해를 돕기 위한 그림이고, 사실상 Practice 들이 먼저 개별적으로 발표되어 업계의 주목을 받았고 2001년 애자일 전문가 17명이 한 장소에 모여 함께 토론하면서 이런 프레임워크/프로세스들에 내포된 공통적인 개발 철학을 정리했습니다.
- 왜? 결국 제품 성공이 목적
- 애자일 원리 12가지 Satisfy the customer (고객 만족) : 소프트웨어 개발을 수행하는 최우선 목표는 빠르고 지속적으로 가치있는 소프트웨어를 전달하여 고객을 만족시키는 것이다. ( Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ) Welcome change (변경사항 환영) : 애자일 프로세스는 고객의 경쟁력을 위해서라면 비록 개발 후반일지라도 요구사항의 변경을 환영한다. ( Welcoming changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. ) Deliver frequently (업데이트 자주) : 동작하는 소프트웨어를 2주일에서 2개월까지 짧은 간격으로 자주 전달하라. ( Delivery working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.) Work together (함께 일) : 요구사항을 내는 고객과 개발자는 전체 프로젝트에서 매일 함께 일해야 한다. ( Business people and developers must work together daily throughout the project ) Trust and support (신뢰와 지원) : 동기가 부여된 개인들 중심으로 프로젝트를 구성하고, 그들에게 필요한 환경과 지원을 제공하고, 일을 잘 끝낼 수 있도록 신뢰하라. ( Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. ) Face-to-face conversation (대면 소통) : 개발팀 내부에서 정보를 전하는 가장 효율적인 방법은 서로가 얼굴을 마주보면서 대화하는 것이다. ( The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. ) Working software (동작하는 소프트웨어) : 작동하는 소프트웨어는 진척의 주된 척도다. ( Working software is the primary measure of progress.) Sustainable development (지속 가능한 양의 코딩) : 애자일 프로세스는 지속 가능한 개발을 장려하며 스폰서, 개발자, 사용자는 일정한 개발 속도를 계속 유지해야 한다. ( Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. ) Continuous attention (지속 발전-코드,디자인..) : 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다. ( Continuous attention to technical excellence and good design enhances agility. ) Maintain simplicity (단순화. 선택과집중. 불필요제거..) : 간단함, 즉 하지 않아도 될 일의 양을 최대한 줄이는 기술이 필수적이다. ( Simplicity - the art of maximizing the amount of work not done - is essential. (Decluttering of products. Decluttering your mind. Not being manipulative – being honest, open and trustworthy. Decluttering your workspace, working in open spaces.) 예) 설계를 숙고하여 꼼꼼히 해서 개발에서 수정이 일어나는 빈도를 줄인다. Self-organizing teams (자기 조직화 팀) : 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 창발한다. ( The best architectures, requirements, and designs emerge from self-organizing teams. ) * 자기조직화 팀 : 구성원이 누군가의 지시 없이도 자기 주도적으로 업무를 수행하고 유기적으로 협력하는 팀 Reflect and adjust (조정 및 반영) : 정기적으로 어떤 방법이 팀에 더 효과적일지 숙고하며 이에 따라 팀의 행동을 조율하고 조정한다. ( At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. )
- 켄 슈와버(Ken Schwaber)와 제프 서더랜드(Jeff Sutherland)가 스크럼을 개발 (1995) 공을 주고 받으며 팀 전체가 나아가는 모습과 비슷하다고 하여 미식축구의 Scrum 이란 이름이 붙음
- 스크럼 이론의 핵심 키워드 (스크럼은 경험적 프로세스 관리 이론, 혹은 경험주의(empiricism) 이론에 기반을 두고 있습니다. 경험주의 이론에 의하면 지식은 경험과 우리가 이미 알고 있는 것에 기반을 둔 의사결정으로부터 온다고 여겨집니다. (cf. defined - 폭포수))
- 스크럼을 잘 사용하는 것은 이 다섯 가지 가치들을 얼마나 더 잘 터득하느냐에 따라 좌우됩니다. 스크럼 팀의 개개인들은 팀의 목표를 달성하고자 책임감을 느끼고 일을 합니다. 스크럼 팀원들은 올바른 것을 수행하기 위한 용기를 가지고 어려운 문제들을 해결합니다. 모든 사람은 스프린트의 일과 스크럼 팀의 목표에 집중합니다. 스크럼 팀과 프로젝트에 관련된 모든 사람은 프로젝트에 필요한 일들과 그것을 달성하기 위해 넘어야 할 난관들이 투명하게 공유될 것을 함께 동의합니다. 스크럼 팀원들은 각자가 독립적이고 일을 성취할 능력이 있음을 서로 존중합니다.
- * 자기조직화 팀 : 구성원이 누군가의 지시 없이도 자기 주도적으로 업무를 수행하고 유기적으로 협력하는 팀
- Product Owner : 방향을 정하는 주체, 결정하는 주체 Develop team : 실제 제품을 개발하고 발전시키는 주체 Scrum Master : 팀을 바라본다. PO를 바라본다. 조율하고 독려하는 역할
- 민첩하게 대응할 수 있도록 충분히 작고, 한 스프린트 안에서 의미 있는 작업을 끝낼 수 있을 정도로 충분히 커야 됨
- 조직의 모든 사람이 제품 책임자의 결정을 존중
- # 제품 백로그 • 제품 백로그 항목들을 분명하게 설명 • 목표와 미션을 가장 성공적으로 달성할 수 있도록 제품 백로그에 있는 항목들을 우선 순위화 • 개발팀이 수행하는 작업의 가치를 최적화 & 올바르게 이해하고 있는지 확인 • 스크럼 팀이 다음 스프린트에 무슨 작업을 해야 하는지 제시
- 스크럼 가이드에 따라 스크럼을 장려하고 지원할 책임을 갖습니다. 이를 위해, 스크럼 마스터들은 모두가 스크럼의 이론과 실천, 규칙, 그리고 가치들을 잘 이해할 수 있도록 도와야 합니다. 스크럼 마스터는 스크럼 팀 외부에 있는 이들이 스크럼 팀과 어떤 상호작용이 도움 되고, 어떤 것이 도움 되지 않는지에 대한 이해를 돕는 역할을 합니다. 스크럼 마스터는 이러한 사람들 간의 상호작용이 스크럼 팀에서 만들어낸 제품의 가치가 최상이 되는 방향으로 바뀔 수 있도록 도움을 줍니다.
- 스크럼은 정해진 이벤트 미팅을 정기적으로 가짐으로써 스크럼에 정의되지 않은 다른 미팅을 최소화합니다 모든 이벤트 모임은 정해진 시간(time-boxed) 안에 끝내야 합니다. 각각의 스크럼 이벤트들은 무엇인가를 검토하고 적응하기 위한 공식적인 기회입니다. 이들 중 하나라도 빠진다면, 투명성이 감소하고 검토와 적응할 기회를 잃게 됩니다.
- 스프린트는 최대 한 달로 제한됩니다. 스프린트 기간이 너무 길어지면 무엇을 만들어야 하는지에 대한 정의가 변하거나, 복잡도가 증가하거나, 위험이 증가할 수 있습니다. 스프린트는 적어도 매달의 진행 상황에 대한 검토와 적응을 보장하기 때문에 제품에 대한 예측이 가능합니다. 또한, 스프린트는 한 달 미만의 비용으로 위험을 제한할 수 있습니다. 스프린트 동안, • 스프린트 목표를 이루는데 위협을 줄 수 있는 어떠한 변경도 허용되지 않습니다. • 제품의 품질 목표를 낮추지 않습니다. • 스프린트가 진행되면서 개발 범위에 대한 이해가 커짐에 따라, 개발팀은 제품 책임자와 함께 개발 범위를 명확히 하거나 재협상할 수 있습니다.
- 일일 스크럼은 커뮤니케이션을 증진하고, 다른 추가적인 미팅들을 제거하고, 개발에 방해되는 요소들을 확인하여 없애고, 빠른 의사결정을 강조하고 촉진하며, 개발팀의 견문을 높여줍니다. 이것이 바로 스크럼의 핵심인 “검토와 적응” 미팅입니다.
- 제품 백로그는 제품에 필요하다고 알려진 모든 요구사항에 대한 우선 순위화된 목록입니다. (변경된 요구사항 포함)
- 완료 기준 (Acceptance Criteria) 을 명시
- 상세화 작업을 위해서 보통 개발팀 전체 가용 시간의 10% 미만을 사용 개발팀은 모든 개발 견적에 대한 설정 권한과 책임을 집니다. 상세화가 충분히 되어 완료될 수 있는 제품 백로그들은 “준비된” 항목들로 여겨짐
- 스프린트 백로그는 스프린트를 위해 선택된 제품 백로그 항목들의 집합이며 더불어 제품 증분을 배포하고 스프린트 목표를 실현하기 위한 계획서입니다. 스프린트 백로그는 무슨 기능이 다음 제품 증분에 포함될지, 그 기능을 “완료”된 제품 증분으로 배포하는 데 필요한 작업이 무엇인지를 개발팀이 예상한 작업 목록입니다
- 제품 증분이 “완료”되었다고 할 때, 모든 사람이 “완료”의 의미가 무엇인지 이해하고 있어야 합니다. “완료”의 정의가 스크럼 팀에 따라 매우 다양할 수 있지만, 스크럼 팀의 멤버들은 작업이 완료된다는 것에 대해 공통된 이해를 하고 있어야 투명성을 보장할 수 있습니다. 이것이 스크럼 팀의 “완료”의 정의이며, 작업이 제품 증분으로서 완료되었을 때 확인하기 위해 사용됩니다. Absolute Estimation : Number with a ‘unit’, like MD/Hours, Line of Code etc Relative Estimation : Number WITHOUT a unit - number of times we compare one against another. (T-shirt sizing or planning poker with story point)