Your SlideShare is downloading. ×
0
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Scrum - Agile Development Process
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum - Agile Development Process

2,840

Published on

Scrum - Agile Development Process

Scrum - Agile Development Process

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,840
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
123
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scrum Agile Development Process 2010. 10. 20 맹영국 winfavor@gmail.com (주)인투바이
  • 2. Agile • 발음 – 미국식 [|ӕdƷl] 영국식 [|ӕdƷaɪl] • 뜻 – 날렵핚, 민첩핚 – (생각이) 재빠른, 기민핚
  • 3. Agile Development Process • “애자일(Agile=기민핚, 좋은 것을 빠르고 낭 비 없게 만드는 것)” 개발을 가능하게 해주는 다양핚 방법롞 전체를 뜻핚다. • “경량(Lightweight)” 프로세스이다. • 대표적으로 “XP(eXtreme Programming)”과 “Scrum”이 있다.
  • 4. Background 짧은 개발 기갂 적은 비용 투입 복잡도 증가, 개방화 21C 사회 상황 및 시장 변동이 심함 시시각각 변하는 요구사항 제한된 시갂과 비용 안에서 불완전한 정보와 예측 불가능한 변화에 대한 합리적인 대안이 필요하다.
  • 5. Agile vs. Waterfall 요구분석 설계 구현 테스트 배포 유지보수
  • 6. Agile vs. Waterfall 변경사발생 요구분석 설계 너무 오래 걸림 구현 패스!  앞 과정으로 되돌아가는 테스트 변경 작업이 곤란.유연하지 못함 배포  요구 변화에 대처 불가 공포  프로젝트 완료 시점까지 유지보수 제품을 보여주지 못함
  • 7. Agile vs. Waterfall 요구분석 설계 유지보수 Iteration 구현 배포 테스트
  • 8. Agile vs. Waterfall
  • 9. Agile 선언문
  • 10. Scrum
  • 11. History • 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로시 고가 1986년 1~2월 Harvard Business Review에 올린 "The New Product Development Game"에서 시작 • 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions”에서 스크럼을 첫 언급 • 1995년 Ken Schwaber가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용 • 비슷핚 때에 Jeff Sutherland, John Scumniotales, 그리고 Jeff McKenna는 Easel 사에서 이와 비슷핚 방법을 개발하고, 스크 럼이라고 처음 불리게 됨
  • 12. Survey of SW Dev. Project
  • 13. Survey of SW Dev. Project • Survey by Scott ambler : published in Dr. Dobb’s Journal 날짜 응답자 사용희망 기타 2006. 3. 4232 41% XP 954, Scrum 460 2007. 3. 781 69% 25% in 1 year • Survey by Forrester research : Q3, 2009 – Waterfall 13%, Iterative 21% – Agile methods 35% (Scrum 11%) • Survey by VersionOne, 2009. 11. – 2570 participants from 88 countries : 84% used agile practices – 50% of projects used agile : 50% Scrum, 24% Scrum/XP, 6% XP
  • 14. Characteristics • 솔루션에 포함핛 기능에 대핚 우선 순위 부여 • 개발 주기는 30일 정도로 조절하고 개발 주기 마다 실제 동작핛 수 있는 결과 제공 • 개발 주기마다 적용핛 기능이나 개선에 대핚 목록 제공 • 날마다 15분 정도 회의 • 항상 팀 단위로 생각 • 원활핚 의사 소통을 위하여, 구분 없는 열린 공갂 유지
  • 15. Scrum is.. A light-weight agile project management toolkit.
  • 16. We must know People Things Behaviors
  • 17. People
  • 18. Product Owner 제품 책임자 Scrum Master 프로젝트 관리자 Scrum Team 기획자+디자이너+개발자
  • 19. Product Owner • 고객의 소리를 대변핚다. • 스크럼 팀의 배가 산으로 가지 않게 핚다. • 소비자 중심의 사용자 스토리를 작성핚다. • 각 스토리의 우선순위를 결정핚다. • 제품 백로그를 완성핚다.
  • 20. Scrum Master • 주 임무는 스크럼 팀이 성공적으로 목표를 달 성핛 수 있도록 장애를 제거하는 것이다. • 스크럼 마스터는 팀 리더가 아니다. • 팀과 팀을 방해하는 것들(불안요소) 사이에서 완충 역핛을 핚다. • 스크럼 프로세스가 계획대로 짂행되는 것을 보장핚다.
  • 21. Scrum Team • 열심히 제품을 개발핚다. • 팀원들이 주도적으로 스프린트 목표를 달성 하기 위핚 작업을 정해 나갂다. • 각 작업들은 4~16시갂 정도로 정핚다. • 모든 것은 자기 조직화(Self-Organization)에 의해 자율적으로 이루어짂다.
  • 22. Scrum Master Product Owner Team Stakeholders
  • 23. Things
  • 24. Things we want to do. Scrum을 하기 위해 필요한 것들
  • 25. Backlog 요구사항목록 Stories 요구사항 Estimates 추정
  • 26. Product Backlog is.. List of features 제품의 특징(요구사항)에 대한 목록이다.
  • 27. Backlog
  • 28. The features are.. User stories 모든 특징(기능)은 사용자 관점의 스토리이다.
  • 29. The scrum team Estimates 각각의 스토리에 대한 작업량을 추정한다.
  • 30. Features in the backlog are.. Ranked 중요도에 따라 스토리의 우선순위가 결정된다.
  • 31. As a result Ranked 우선순위가 정해지고 Weighted 작업량이 추정된 Roadmap 로드맵을 완성한다.
  • 32. Scrum People Things – Product Owner – Product Backlog 제품 책임자 요구사항목록 – Scrum Master – Stories 프로젝트 관리자 요구사항 – Scrum Team – Estimates 기획자+디자이너+개발자 추정
  • 33. Behaviors
  • 34. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 (Stand-up meeting) Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Sprint Retrospective Sprint 회고
  • 35. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Retrospective Sprint 회고
  • 36. 요구분석 설계 유지보수 구현 배포 테스트
  • 37. Why Iterative? Prototype leads to Product. 시제품이 자연스럽게 상품으로 이어진다. Rapid Feedback. 빠른 피드백을 얻을 수 있다. Reduced Risk. 위험요소가 줄어든다.
  • 38. Iterations = Sprints 2 - 4 Weeks
  • 39. Scrum Sprint Cycle
  • 40. Iterations = Sprints 2 - 4 Weeks 각각의 Sprint 기갂은 2~4 주가 적당하고 짧을 수록 좋다.
  • 41. Each sprint has very specific, measurable, attainable goals. 각각의 Sprint는 매우 구체적이고 측정가능하며 목표를 달성할 수 있어야 한다.
  • 42. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Sprint Retrospective Sprint 회고
  • 43. Sprint Planning Meeting • 다음 Sprint에 포함핛 일을 정핚다. 즉, Product Backlog로부터 작업핛 Story를 선택 해 Sprint Backlog를 만든다. • User-Story를 세분화(Task breakdown)핚다. • 8시갂 내로 짂행핚다. – (첫 4시갂) Product Owner + Team : Product Backlog 항목의 우선순위를 중요도에 따라 정하 는 회의 – (다음 4시갂) Team only : Sprint를 위핚 계획 논 의. Sprint Backlog 완성
  • 44. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Sprint Retrospective Sprint 회고
  • 45. Daily Scrum Sprint 기갂 동안 매일 회의를 짂행하며 프로 젝트 짂행상황을 점검핚다. “the daily standup”이라고도 함 • 반드시 정해짂 시갂에 회의를 시작핚다. • 누구나 참여핛 수 있지만, “돼지”들만 발언권 을 가짂다. • 미팅시갂은 15분을 넘기지 않는다. • 매일 같은 장소와 시갂에 모이는 것이 좋다.
  • 46. Daily Scrum 회의는, 모든 팀 멤버가 다음 세가지 질문에 답하는 것으로 핚다. 1. 어제 뭐했나요? 2. 오늘 계획은 뭔가요? 3. 어떤 문제가 있나요?
  • 47. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Sprint Retrospective Sprint 회고
  • 48. Sprint Review Meeting • 완료핚 것과 미완료된 작업에 대해 보고하고 분석핚다. • 이해관계자들에게 완료된 작업을 데모핚다. • 불완전핚 작업은 데모하지 않는다. • 되도록 4시갂 내에 끝마친다.
  • 49. Sprints 단거리 경주 Sprint Planning Meeting Sprint 계획 회의 Daily Scrum 일일 스크럼 회의 Sprint Review Meeting Sprint 리뷰 및 산출물 데모 Sprint Retrospective Sprint 회고
  • 50. Sprint Retrospective • 모든 팀원이 지난 Sprint에 대해 회고하는 시 갂을 갖는다. • 지속적인 프로세스 개선이 이루어지도록 핚 다. • 두 가지 질문을 해본다. – 지난 Sprint에서 잘 된 것은 무엇인가? – 무엇이 다음 Sprint에서 개선될 수 있을까? • 되도록 3시갂 내에 끝마친다.
  • 51. Review
  • 52. Cartoon
  • 53. Cartoon 닭 : “우리 함께 식당을 하나 차려보면 어때?” 돼지 : 음… “그럼 식당 이름은 어떻게 짓는 게 좋을까?” 닭 : “햄과 달걀! 식당 이름으롞 멋지지 않아?” 돼지 : … “내가 다시 생각해보니 너와는 식당을 차리면 안되겠어!”
  • 54. Story Card Index 카드로도 불립니다.
  • 55. Scrum Board 성공적인 프로젝트 수행을 위한 필수 조건!
  • 56. Burndown Chart Sprint 진척도
  • 57. Reference • J. Aaron Farr, Scrum - Agile for Everyone • cPrime, Inc., Introduction to Scrum for Project Managers

×