일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Book
- programming_book
- web
- Python
- hadoop
- Book review
- UK
- Kuala Lumpur
- Italy
- hbase
- psychology
- agile
- Malaysia
- Software Engineering
- comic agile
- program
- RFID
- France
- Programming
- Linux
- QT
- leadership
- Spain
- Java
- django
- MySQL
- erlang
- history
- management
- ubuntu
- Today
- Total
출근했더니 스크럼 마스터가 된 건에 관하여 본문
'참여자의 커밋먼트 없이 수단이 목적으로 변질되어 강행됐기 때문'
악몽으로 변한 건 조직에서 강제하면서
이론편 스크럼이 뭐야?
모든 것을 예측하고 대비할 수 없다
실천편 스크럼은 어떻게 하는 거야?
Scene No. 01 스크럼을 준비한다 자 시작해 볼까?
프로덕트 오너와 스크럼 마스터를 절대 겸임하지 마라
Scene No. 02 목표를 이해한다 우리는 여기에 왜 모였을까?
목표 goal 는 스크럼 팀이 만들어 주길 바라는 제품에 대한 기대
과제 mission 는 스크럼 팀이 달성하길 바라는 과업에 대한 기대
Scene No. 03 프로덕트 백로그를 만든다 뭘 해야 하는 지 뭘 보고 알지?
중요한 건 개발자 스스로가 괜찮다고 생각하는 계획이 나오는
Scene No. 04 작업량을 추정한다 견적을 냈지만 정확하진 않다고?
Scene No. 05 다 함께 모여서 추정치를 보완한다 정말 내가 견적 내도 되는 거야?
플래닝 포커는 개발자 간의 합의를 쉽게 끌어내기 위해서 사용
Scene No. 06 앞으로 벌어질 상황을 그려본다 언제 어떤 결과물이 나오는 걸까?
릴리스 날짜를 맞추기 위해 일정을 강요받는 상황이라면 벨로시티를 역산해버리는 위험
릴리스 계획은 한 번 정하고 끝나는 게 아니라 상황에 맞게 수시로 보완해야
Scene No. 07 스프린트를 하기 전에 한번 더 계획을 구체화한다 달릴 준비가 되었는지 살펴볼까?
스프린트에 해야 할 일을 프로덕트 오너와 개발자가 함께 정하는
Scene No. 08 위험에 재빠르게 대응한다 스프린트는 순조로운가?
스크럽을 지탱하는 세 가지 핵심축(3 pillars)은 투명성(transparency), 점검(inspection), 보완(adaptation)입니다. 정보를 투명하게 유지해야 점검할 수 있고, 점검하며 문제가 발견되면 빠르게 보완하는 것이 스크럼의 핵심
Scene No. 09 상황을 투명하게 가시화한다 납기는 맞출 수 있는 거야?
Scene No. 10 완료의 의미를 명확히한다 대충 다 된 것 같아요!
개발자가 완성된 결과물을 가져와서 시연
Scene No. 11 예측을 쉽게 하기 위해 시간을 엄수한다 시간이 하루만 더 있었으면
스크럼의 모든 활동은 미리 정한 시간 안에 끝내는 게 원칙. 타임박스(timebox)
중요한 건 다뤄야 할 내용을 작게 쪼개는
해결 방법을 검토할 때는 SMART 하게 생각
• Specific 구체적인가
• Measurable 측정할 수 있는가
• Achievable 달성할 수 있는가
• Relevant 문제와 관련이 있는가
• Timely / Time-bounded 즉시 할 수 있는가 / 기간이 있는가
Scene No. 12 다음에 할 일을 구체화한다 생각보다 빨리 끝났는데?
프로덕트 백로그는 누구라도 추가 가능
순서를 최종적으로 결정하고 책임지는 건 다름 아닌 프로덕트 오너
Scene No. 13 스스로 원칙을 지킨다 모두 모인 건 아니지만...
진짜 어려운 건 지속
Scene No. 14 벨로시티를 높인다 더 빨리 끝낼 수 있어?
Scene No. 15 역할 구분은 문제를 발견하기 쉽게 만든다 프로덕트 오너가 바쁘다고?
Scene No. 16 사용자의 관점에서 의도를 명확히 한다 의도가 제대로 전달되고 있을까?
의도를 전달하는 게 그리 쉬운 일은 아니죠
사용자의 관점에서 이야기
일부러 문장을 짧게 쓰게 해서 팀원 간의 빈번한 대화를 유도
- 여유가 있어야 가능한 환경
Scene No. 17 어려움에 처한 팀원을 돕는다 개발자에게 위기가 온 것 같아!
기술 부채(technical debt) 사고를 방지하려면 미리부터 원인을 제거해야
이전의 사고방식에 사로잡히지 않도록 충분히 주의하고 경계
Scene No. 18 더 나은 상태로 만든다 지금 당장 해결할 순 없지만...
팀원을 움직이는 데는 스크럼 마스터의 끈기와 용기가 필요
Scene No. 19 다음에 할 작업을 명확히 한다 다음에 뭘 해야 할지 모르겠다고?
Scene No. 20 재작업을 없앤다 정말 스프린트를 시작해도 되는 거야?
뭘 실현해야 하는지 모호한 상태에서 작업에 착수했다면 결과가 나왔다고 하더라도 기대를 충족했다고 할 순 없을
Scene No. 21 목표에 다가선다 이런, 일정을 맞추지 못할 것 같아
프로젝트에 영향을 주는 요소
품질 예산 기간 범위
- The Iron Cross — What I just learnt #3 | by Abderrahim Benmakhlouf | Medium
- Project management triangle - Wikipedia
Scene No. 22 다양한 상황에 대처한다 이 작업은 제게 너무 어려워요
드러커 엑서사이즈 (the drucker exercise)
Scene No. 23 책임감을 가지고 약속하고 행동한다 이 정도는 더 할 수 있잖아?
할 수 없는 건 할 수 없다고 거절하는 것이 올바르게 책임지는 자세
- 심리적 안정감을 갖고 자유롭게 말할 수 있는 환경이냐가 우선
Scene No. 24 릴리스 준비에 만전을 기한다 혹시 빠진 건 없나?
Scene No. 25 이제까지 말하지 못한 또 다른 이야기 지금부터가 진짜 시작이야!
현장의 실무자가 중심이 되어서 문제를 찾고 해결하는 과정 카이젠
참고 자료
- Home | Scrum.org
- Scrum Alliance Certification | Transform your workplace
- ふりかえり実践会 - BOOTH
- М'яч на полі "Укрзалізниці": потяг ІНТЕРСІТІ + можуть пустити через Кіровоград
- ふりかえりam • Anchor 팟캐스트
- The Agile Inception Deck | The Agile Warrior
- The Drucker Exercise | The Agile Warrior
- Chickens and Pigs | Scrum.org
- 5분만에 애자일(Agile)의 대표주자 스크럼(Scrum) 완벽 마스터하기 | 일하는 우리 | - YouTube
- 스크럼, 입고팀이 애자일하게 일하는 법 1부 - 컬리 기술 블로그
- 스크럼, 입고팀이 애자일하게 일하는 법 2부 - 컬리 기술 블로그