스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다.
목차
1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다.
2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다.
3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다.
4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다.
5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다.
6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다.
몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다.
이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
Periodic Table of Agile Principles and PracticesJérôme Kehrli
Recently I fell by chance on the Periodic Table of the Elements... Long time no see... Remembering my physics lessons in University, I always loved that table. I remembered spending hours understanding the layout and admiring the beauty of its natural simplicity.
So I had the idea of trying the same layout, not the same approach since both are not comparable, really only the same layout for Agile Principles and Practices.
The result is in this presentation: The Periodic Table of Agile Principles and Practices:
목차:
1 왜 애자일 게임 개발이 필요한가?
2 애자일 게임 개발이란 무엇인가?
3 애자일 게임 개발은 기본 개발과 어떻게 다른가?
4 애자일 게임 개발 사례들
5 애자일 게임 개발을 도입하려면 어떻게 해야 하지?
6 애자일, 그래서 한 마디로 하면 뭔데?
7 참고 자료 목록
출처: http://betterways.tistory.com/277
Getting Started - Introduction to Backlog GroomingEasy Agile
Overview
- What is backlog grooming?
- Who should be involved in backlog grooming sessions
- Benefits of backlog grooming
- Guidelines for effective backlog grooming sessions
- Difference between backlog grooming and sprint planning
- Apple TV example
OKRs and Agile Sitting on a Tree - Agile Austin.pdfYuval Yeret
Struggling to create a healthy synergy between OKRs and Agile/Scrum/SAFe? You're not alone. In this session, we provide a high-level overview of OKRs, identify some common OKR usage issues/anti-patterns, and suggest improvements leveraging Lean/Agile principles and practices. You will learn how to organize around value through an OKR lens. We will understand the connection between OKRs, KPIs, Products / Value Streams, and what that means for leveraging OKRs in the different Scrum/SAFe elements. We will discuss how Evidence-based Management (EBM) can amp up OKR empiricism. By the end of this session, you will understand the relationship between OKRs, Agile, Scrum, SAFe, and EBM and have concrete ideas for how to help your organization leverage them in synergy.
Introduzione alla gestione del progetto softwareGiulio Destri
Introduzione alla gestione del progetto di sviluppo informatico. Parte dalle basi, presentando metodologie e strumenti di Project Management e la loro applicazione al progetto software. UML ed alcuni esempi reali del suo uso completano il quadro. Usata in corsi universitari, ma anche in formazione aziendale e scuole.
TA가 뭐예요? (What is a Technical Artist? 블루홀스튜디오)valhashi
게임 개발 프로젝트에서 TA(테크니컬 아티스트)의 역할, 업무, TA가 되기 위해 필요한 역량과 커리어패쓰에 대해 가볍게 설명한 문서입니다. 주로 블루홀스튜디오의 TA, TERA의 TA를 기준으로 설명되어 있습니다.
국내에서도 여러 게임 프로젝트에서 TA들이 중요한 역할을 하고 있지만, TA직군의 짧은 역사(약 10년)와, 업무의 다양성 때문에 아직도 업계 전반에 TA에 대한 이해는 부족하다고 보여집니다. 때문에, 프로젝트에서 TA의 역량을 충분히 활용하지 못하거나, TA로서 훌륭한 재능을 갖춘 인재들이 자신의 역량을 펼치지 못하는 일들이 있습니다. 그런 상황의 해소에 조금이라도 도움이 되기 위해, 그리고, 블루홀스튜디오 TA 채용에 도움이 되기 위해, 이 문서를 작성하였습니다.
게임 개발 업계에 계신 분들, 게임 개발자를 지망하시는 분들께서 TA에 대해 이해를 하시는데, 조금이라도 도움이 되었으면 좋겠습니다.
블루홀스튜디오 채용 페이지: http://www.bluehole.net/recruit/information.html
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
Periodic Table of Agile Principles and PracticesJérôme Kehrli
Recently I fell by chance on the Periodic Table of the Elements... Long time no see... Remembering my physics lessons in University, I always loved that table. I remembered spending hours understanding the layout and admiring the beauty of its natural simplicity.
So I had the idea of trying the same layout, not the same approach since both are not comparable, really only the same layout for Agile Principles and Practices.
The result is in this presentation: The Periodic Table of Agile Principles and Practices:
목차:
1 왜 애자일 게임 개발이 필요한가?
2 애자일 게임 개발이란 무엇인가?
3 애자일 게임 개발은 기본 개발과 어떻게 다른가?
4 애자일 게임 개발 사례들
5 애자일 게임 개발을 도입하려면 어떻게 해야 하지?
6 애자일, 그래서 한 마디로 하면 뭔데?
7 참고 자료 목록
출처: http://betterways.tistory.com/277
Getting Started - Introduction to Backlog GroomingEasy Agile
Overview
- What is backlog grooming?
- Who should be involved in backlog grooming sessions
- Benefits of backlog grooming
- Guidelines for effective backlog grooming sessions
- Difference between backlog grooming and sprint planning
- Apple TV example
OKRs and Agile Sitting on a Tree - Agile Austin.pdfYuval Yeret
Struggling to create a healthy synergy between OKRs and Agile/Scrum/SAFe? You're not alone. In this session, we provide a high-level overview of OKRs, identify some common OKR usage issues/anti-patterns, and suggest improvements leveraging Lean/Agile principles and practices. You will learn how to organize around value through an OKR lens. We will understand the connection between OKRs, KPIs, Products / Value Streams, and what that means for leveraging OKRs in the different Scrum/SAFe elements. We will discuss how Evidence-based Management (EBM) can amp up OKR empiricism. By the end of this session, you will understand the relationship between OKRs, Agile, Scrum, SAFe, and EBM and have concrete ideas for how to help your organization leverage them in synergy.
Introduzione alla gestione del progetto softwareGiulio Destri
Introduzione alla gestione del progetto di sviluppo informatico. Parte dalle basi, presentando metodologie e strumenti di Project Management e la loro applicazione al progetto software. UML ed alcuni esempi reali del suo uso completano il quadro. Usata in corsi universitari, ma anche in formazione aziendale e scuole.
TA가 뭐예요? (What is a Technical Artist? 블루홀스튜디오)valhashi
게임 개발 프로젝트에서 TA(테크니컬 아티스트)의 역할, 업무, TA가 되기 위해 필요한 역량과 커리어패쓰에 대해 가볍게 설명한 문서입니다. 주로 블루홀스튜디오의 TA, TERA의 TA를 기준으로 설명되어 있습니다.
국내에서도 여러 게임 프로젝트에서 TA들이 중요한 역할을 하고 있지만, TA직군의 짧은 역사(약 10년)와, 업무의 다양성 때문에 아직도 업계 전반에 TA에 대한 이해는 부족하다고 보여집니다. 때문에, 프로젝트에서 TA의 역량을 충분히 활용하지 못하거나, TA로서 훌륭한 재능을 갖춘 인재들이 자신의 역량을 펼치지 못하는 일들이 있습니다. 그런 상황의 해소에 조금이라도 도움이 되기 위해, 그리고, 블루홀스튜디오 TA 채용에 도움이 되기 위해, 이 문서를 작성하였습니다.
게임 개발 업계에 계신 분들, 게임 개발자를 지망하시는 분들께서 TA에 대해 이해를 하시는데, 조금이라도 도움이 되었으면 좋겠습니다.
블루홀스튜디오 채용 페이지: http://www.bluehole.net/recruit/information.html
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
The better ways of developing software
Software Development Methodology
Agile
Scrum Methodology
eXtreme Programming(XP)
Waterfall
Kanban
When to Use Scrum
When to Use Kanban
하얀 눈 위에 발자국은 반갑고 친구와 같은 느낌이었던 것 같습니다. 애자일 적용에 첫발을
내딛으려는 팀에게 도움이 되었으면 좋겠네요.
경기원, LG CNS
애자일을 통해 내가 하고 있는 무엇인가를 더 낫게 만들려는 욕심 있는 분들께 추천합니다.
신황규, 삼성SDS
현실을 부정하지 말고 일단 작게 시작하세요.
관찰하고 적응하세요. 특정 방법에 얽매이지 말고 애자일 선언문을 기억하세요. :-D
심우곤, LG전자
어제보다 나은 오늘을 만드는데 도움이 되었으면 좋겠습니다.
이승룡, 삼성SDS
애자일을 적용하려는 팀에 도움이 되었으면 좋겠어요!
채수원, NHN
여러분들이 애자일과 더 친해졌으면 합니다.
황상철, NHN
1) Define Our Own Agile:
시중에 나와 있는 애자일 관련 도구와 방법론들을 간략하게 살펴보고 이들을 관통하는 주요 특징과 컨셉을 이해한 후, 내가 속한 조직 환경에 맞는 애자일의 모습에 대해 고민하고 논의해 봅니다.
2) Personal Agile:
퍼스널 애자일(Personal Kanban)에 녹아 있는 TOC(Throughput Account, DBR, CCPM, 집중개선5단계)의 간단한 개념들에 대해 소개하고, 퍼스널 애자일 및 다이어리를 활용하여 개인 업무 관리 및 Agility를 향상시킬 수 있는 방법에 대해 논의해 봅니다.
"린과 애자일 개발"이라는 책에 대한 리뷰.
본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다.
처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.
Similar to 스타일쉐어의 스크럼이 지나온 길 (20)
2. 이 슬라이드를 만드는 이유
● 약 6개월 동안 Scrum Master를 겸직함으로써 개선/변경하고 그에 따라 느
낀 부분을 기록하기 위함
● 스타일쉐어팀에 새롭게 참여할 멤버와 후속 Scrum Master의 가이드가 되었
으면 하는 바램
● 우리와 비슷한 경험을 하고 있는 조직에 약간이나마 도움이 되었으면 하는
바램
3. 간단한 정리
● 스크럼이란? :
○ 각 일감에 대한 우선순위를 부여한다.
(Product Backlog)
○ 각 개발주기마다 적용할 기능 혹은 개선
에 대한 목록을 작성한다. (Sprint
Backlog)
○ 상황에 맞는 개발주기(1주~4주)를 설정
하고 목록의 일감들을 한 주기 동안 개발
한다. (Sprint)
○ 매일 5~10분 동안 회의를 가지고 한일/할
일/문제점에 대해 각자 공유한다.
출처 : 위키피디아
프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 공학 중
의 하나이다.
4. 스타일쉐어팀의 기본 스크럼 방식
● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
● 스토리 포인트 기준 : 일 2점 (= 2시간)
● 데일리 미팅 / 스프린트 회고 진행
5. 스타일쉐어팀의 기본 스크럼 방식
● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
○ 스프린트 주기에 따른 장단점
■ 짧은 스프린트 주기(1~2주 이내)
● 빠른 피드백 및 유연한 일감 우선순위 선정
● 일감 추정회의 시간의 단축(추정 대상일감의 수가 적음)
● 영업일이 짧다보니 한 스프린트내에 한 단위를 개발완료하기 어려움
■ 긴 스프린트 주기(3~4주)
● 일감이 많아 추정회의 시간은 길지만 3~4주에 1회만 필요
● 스프린트 도중 갑자기 일감이 추가되는 상황이 다수 발생할 수 있음
6. ● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
○ 스타일쉐어의 경우 스프린트 주기를 7일로 가져가고 있음(QA주간은 4
일)
■ 상황에 따른 변화를 빠르게 가져가기 위해 짧은 스프린트 주기를
운용
스타일쉐어팀의 기본 스크럼 방식
스프린트 1 스프린트 2
스프린트 3
(QA)
App 릴리즈
7일 7일 4일
7. 스타일쉐어팀의 기본 스크럼 방식
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
○ 일감 생성/우선순위/추정/스프린트 생성 및 진행과정 확인
8. 스타일쉐어팀의 기본 스크럼 방식
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
○ Velocity Chart, Burndown Chart를 이용해 현황 파악 및 개선점 탐색
9. 스타일쉐어팀의 기본 스크럼 방식
● 스토리 포인트 기준 : 1일 2점 (2점 = 2시간)
○ 스토리 포인트 : 각 일감(스토리)을 해결하는데 예측되는 점수
○ 스프린트 주기의 일수에 맞춰 개인별로 스토리 포인트를 가져감
○ 회의시간/버그수정/개발을 위한 리서치 등의 시간은 스토리 포인트에
서 제외 됨
○ 개발에만 온전히 집중하였을때 소요되는 시간을 기준으로 함
10. 스타일쉐어팀의 기본 스크럼 방식
● 데일리 미팅 / 스프린트 회고 진행
○ 데일리 미팅 (매일 10분)
■ 스타일쉐어 개발팀은 매일 오후 4시에 전원(8명)이 모여 오늘 한일/할일/문
제점을 공유하고 있습니다.
■ 그 날 개발하는데 문제가 있거나 고민이 있는 부분을 빠르게 공유하여 팀이
함께 이슈를 파악하고 해결할 수 있도록 도움을 줍니다.
11. 스타일쉐어팀의 기본 스크럼 방식
● 데일리 미팅 / 스프린트 회고 진행
○ 스프린트 회고 진행
■ 매 스프린트 기간마다 1회씩 스프린트 회의를 진행하는데 이때 해당 스프
린트에 대한 회고를 매번 진행합니다.
■ 이번 스프린트에 아쉬웠던 점, 좋았던 점을 공유하여 스프린트 혹은 일하는
환경 개선을 위해 빠르게 피드백을 받습니다.
12. 변경한 규칙 1) 일감 추정 순서
● 일감 추정?
o 백로그에 쌓여져 있는 일감을 추정회의를 통해 해당 일감을 완료하는
데 소요되는 스토리 포인트(작업시간)를 예측합니다.
o 일감을 생성/담당한 개발자가 이 기능의 스펙/목적/개발방식에 대해 설
명하고 담당자와 팀이 필요한 스토리 포인트에 대해 추정합니다.
o 한 스프린트(7일)에서 워킹데이 기준으로 일별 스토리 포인트를 부여하
여 총합을 각자가 일감으로 가져갑니다.
ex : 7일(워킹데이) * 2점(1일) = 14점 스토리 포인트
13. 변경한 규칙 1) 일감 추정 순서
- 기존에는 일감 추정을 일감 등록한 순서로 진행
- 일감에 클라이언트/백엔드/웹프론트 일감 및 여러 주제의 일감이 섞여 있어
컨텍스트 파악이 어려움
- 연결되어 있는 일감(동일 Epic)들을 우선적으로 추정
- 연결된 일감이 없으면 동일한 플랫폼(iOS/Android/Backend/Web)별로 나누
어서 추정 진행
기존
변경
14. 변경한 규칙 1) 일감 추정 순서
● 한 주제내의 일감들을 이어져서 추정을 하니 일감에 대한 전체적인 이해도
증가
● 반복 설명해야되는 상황이 줄어들어 일감 추정회의 시간의 길이가 짧아짐
개선효과
15. 변경한 규칙 2) 담당자 부재시 추정방식
- 스프린트 시작 전 일감추정 및 지난 스프린트 회고를 위한 회의가 필요
- 다만, 휴가일정 및 개인사정으로 인해 스프린트 회의시 담당자가 부재할 경
우 발생
- 스프린트 회의 일정 변경으로 해결하기에는 다른 팀원들의 일정 및 스프린
트 점수 부족등의 상황으로 무리가 있음
- 동일 플랫폼(iOS/Android/Backend/Web)의 개발자가 부재하는 담당자의 스
토리
포인트까지 추가로 받아 추정 후 일감 해당 개발자에게 할당
기존
변경
16. 변경한 규칙 2) 담당자 부재시 추정방식
● 개선효과
● 스프린트 회의를 고정적인 날에 진행할 수 있어 스케쥴 예측에 효과적
● 개인 휴가일정을 스프린트 회의에 상관없이 유연하게 사용가능
개선효과
17. 변경한 규칙 3) 스프린트 회의날은 일감파악만
AS-IS
- 스프린트 회의 시간 바로 전까지 개인별 스프린트 마감을 위해 배포 및 적용
하느라 다음 스프린트 추정일감의 파악 시간이 적어짐
- 추정할 일감의 이해도가 적어지면서 일감 설명 및 개발 방식이 정해지지 않
아 전체적인 일감 추정회의 시간이 길어짐
- 스프린트 회의일 00시 부터는 기존 스프린트 일감에 대한 개발작업을 하지
않음(Pull Request 및 Merge 금지)
- 스프린트 회의시간(14:00시)까지 다음 스프린트 일감에 대한 파악 및 개발
방식 고민의 시간으로 사용
기존
변경
18. 변경한 규칙 3) 스프린트 회의날은 일감파악만
● 추정할 일감에 대해 개발방식 및 필요성에 고민하는 시간이 많아지면서 추
정회의 때에는 기존 목적인 개발 방식의 공유 및 피드백에 집중할 수 있음
● 개발방식을 미리 고민해 일감 추정회의 시간 단축
개선효과
19. 변경한 규칙 4) 추정이 없는 일감
- 리팩토링 및 코드 분석과 같은 일감의 경우 추정의 오차가 큼
- 일감 완료의 정의가 애매한 일감으로 인해 많은 시간을 한 일감에만 사용해
기존에 가져간 다른 일감들의 진행이 안되는 부분 다수 발생
- 리팩토링 및 코드 분석과 같이 일감의 완료 정의가 어려운 경우 추정을 하지
않고 기준이 될 스토리포인트를 책정함.
- 추정 없이 책정한 스토리 포인트에 맞게 개발을 진행하고, 초과할 경우 데일
리 미팅에서 내용을 공유하고, 추가 개발을 할지 다음 일감으로 넘어갈지에
대해서 논의
기존
변경
20. 변경한 규칙 4) 추정이 없는 일감
● 개발완료가 정의되지 않은 일감의 가이드라인을 제공해 너무 과도한 시간
을 사용하지 않게 기준을 제공
● 한 일감에 과도한 시간을 사용해 다른 주요 일감들이 계속 미뤄지는 부분을
방지
개선효과
21. 변경한 규칙 5) 일감은 모두 5점(스토리 포인트)
이하
- 한 기능의 개발을 하나의 일감으로 작성 및 추정
- 일감의 개발크기가 크다보니 일감 추정의 오차가 다수 발생
- 한 스프린트에 가져가는 일감의 수가 적음으로 인해 완료에 대한 피드백을
받는것이 적음
- 각 일감을 2~3시간 내에 작업완료 할 수 있는 task로 분리하여 등록
- 스토리 포인트 5점이 나오는 경우에도 일감을 더 잘게 나눌 수 있는지에 대
해서 논의 후 진행(가능할 경우 일감을 나누어서 재추정)
기존
변경
22. 변경한 규칙 5) 일감은 모두 5점(스토리 포인트)
이하
● 각 일감의 크기가 작아져 추정 오차가 적어지고 자세한 추정이 가능
● 단계별로 일감이 나누어져 있어 해당 일감의 개발방식에 대한 다른 팀원들
의 이해도 증가
● 각 일감의 빠른 개발완료로 진행상황 및 더 즉각적인 피드백을 받을 수 있음
개선효과
23. 다만, 아직까지 남아있는 고민
1. 인원의 증가
- 개발팀의 인원이 증가함에 따라 일감의 수, 범위, 회의시간이 늘어남
- 팀을 나누기에는 한 제품을 만드는 팀이라 각 일감의 연관성이 있어 구분하
기가 어려움
2. 버그 우선순위에 대한 반영
- 현재 스크럼 방식에서는 버그에 대한 스토리 포인트 부여를 하지 않고 있음
- 스크럼 프로세스의 성과를 보기위해 자주 사용하는 Velocity Chart,
Burndown Chart의 경우 스토리 포인트에 대한 추이만 보여주다 보니 버그
수정에 대한 성과가 표면적으로 나타나지 않음
- 그로인해 버그 수정이 오히려 각 담당자의 우선순위에서 내려가게 되는 상
황 발생
24. 스크럼이 조직에 잘 녹아들기 위한 조건
● 적은 인원 수
o 팀원의 수가 10명 이상 넘어가면 스크럼을 진행하기에 소요되는 다양
한 시간(회의시간, 일감추정, 회고)이 2배 이상 늘어나게 됨
o 소요 시간은 생각보다 매우 중요한 요소 : 소요시간이 길어지면 스크럼
팀 구성원 개개인의 비효율적인 시간이 많아지게 되어 점점 필요성을
못 느끼게 됨
● 연결된 일감
o 스크럼 팀간의 일의 연결성이 있지 않으면 일감에 대한 이해도가 떨어
지게 되어 추정 오차 폭이 커짐
o 자신과 연관이 없는 일감에 대한 논의(데일리 미팅, 스프린트 회의)가
계속되어 집중도가 떨어짐
25. 스크럼이 조직에 잘 녹아들기 위한 조건
● 구성원의 성향
o 결국엔 이 스크럼이라는 것도 각 구성원이 좀 더 나은 환경에서 개발을
하기위한 프로세스
o 스크럼 역시 하나의 개발방식에 불과하기에 팀 구성원들이 어떤 개발
방식/조직문화를 기존에 선호하는지에 대한 파악이 중요
26. 스크럼이 조직에 잘 녹아들기 위한 조건
● 이 프로세스가 왜 필요한지에 대한 논의와 이해
o 스크럼을 새롭게 도입하기 위해서는 이 부분에 대한 논의와 협의가 가
장 중요
o 스크럼의 도입하는 이유는 남이 정한 일정이 아니라 나/팀이 협의하여
정한 일정으로 일하고 해당 일감에만 집중할 수 있는 환경을 만드는 것
이 목적 -> 일정에 따른 관리가 목적이 되면 안됨
o 스크럼은 ‘공유'의 문화이다. 이 문화에 어울리는 조직에 더 적합하지 않
을까. : 스크럼은 내가 지금 어떤 일을 하는지, 어떤 문제가 있는지, 어떻
게 개발하는게 좋은지 팀간에 서로서로 공유하고 발전을 위한 바탕.
27. 끝으로...
아직까지도 개선해야 될 것은 많이 남아있습니다. 그리고 언젠가는 이 스크럼 방
식을 버려야 되는 시기도 오지 않을까 싶습니다.
중요한 것은 어떤 개발방식을 하느냐 안하느냐 보다 우리팀이 좀 더 효율적으로
일하기 위해선 어떤게 필요할지 파악하고 실행해보는 것이 중요한것 같습니다.
더 나은 방법은 항상 존재하니까요.