GDC 2007에서 있었던 Agile Game Development Tutorial의 일부인 'Agile의 의미'와 'Agile 계획 수립'의 한글 번역입니다:
강연자는 Mike Cohn으로, '사용자 스토리'와 'Agile Estimating and Planning'의 저자입니다.
Agile 개발에서 (사용자 스토리의) 일정을 추정하는 방법에 대해서 다루고 있습니다.
자세한 것은
http://betterways.tistory.com/177 참조
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay Kim
Noel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
GDC 2007에서 있었던 Agile Game Development Tutorial의 일부인 'Agile의 의미'와 'Agile 계획 수립'의 한글 번역입니다:
강연자는 Mike Cohn으로, '사용자 스토리'와 'Agile Estimating and Planning'의 저자입니다.
Agile 개발에서 (사용자 스토리의) 일정을 추정하는 방법에 대해서 다루고 있습니다.
자세한 것은
http://betterways.tistory.com/177 참조
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay Kim
Noel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
"린과 애자일 개발"이라는 책에 대한 리뷰.
본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다.
처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.
스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다.
목차
1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다.
2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다.
3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다.
4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다.
5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다.
6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다.
몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다.
이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.
목차:
1 왜 애자일 게임 개발이 필요한가?
2 애자일 게임 개발이란 무엇인가?
3 애자일 게임 개발은 기본 개발과 어떻게 다른가?
4 애자일 게임 개발 사례들
5 애자일 게임 개발을 도입하려면 어떻게 해야 하지?
6 애자일, 그래서 한 마디로 하면 뭔데?
7 참고 자료 목록
출처: http://betterways.tistory.com/277
"린과 애자일 개발"이라는 책에 대한 리뷰.
본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다.
처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.
스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다.
목차
1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다.
2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다.
3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다.
4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다.
5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다.
6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다.
몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다.
이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.
목차:
1 왜 애자일 게임 개발이 필요한가?
2 애자일 게임 개발이란 무엇인가?
3 애자일 게임 개발은 기본 개발과 어떻게 다른가?
4 애자일 게임 개발 사례들
5 애자일 게임 개발을 도입하려면 어떻게 해야 하지?
6 애자일, 그래서 한 마디로 하면 뭔데?
7 참고 자료 목록
출처: http://betterways.tistory.com/277
4. 스크럼에서의 역할
• 제품책임자
고객을 대변하면서 팀이 개발할 기능에 대한 백로그를 작성하고, 우선 순위를 결정
한명만 존재해야 함.
• 스크럼마스터
팀에 스크럼을 소개하고 제대로 수행 할 수 있도록 장애를 제거해 나가는 조력자
외부의 간섭으로 부터 팀을 보호하는 역할을 하며, 개발에 깊이 참여해서는 안된다.
• 팀
스크럼을 수행하면서, 기능을 개발하는 조직
7 ± 2 명으로 구성
높은 수준의 자율권과 책임감을 가지며, 스스로 해야 할 일을 결정.
상호보완 기능팀으로 구성하며, 제품 구현이 필요한 모든 일을 수행. ( 분석, 설계, 코
딩, 테스팅, 문서화 )
5. 제품 백로그
• 스크럼의 핵심
• 우선순위가 매겨진 요구사항 목록으로 제품당 한개의 목록만 존재함. ( 여러팀이
구성되어 있어도 제품 백로그는 하나만 존재 )
• 스토리나 기능 혹은 다른 어떤 이름도 상관 없음.
• 고객이 원하는 것을 고객의 용어로 설명한 것이면 됨.
• 스토리 또는 백로그 아이템 이라고도 함.
6. 제품 백로그
• 중요도 (Value Point) 및 추정치 (Story Point) 는 Planing Poker 를 통해 산출
• 우선순위는 중요도/추정치 로 계산하여 산정함.
절대적이지 않으며, 제품책임자의 결정이 가장 중요함.
우선순위로 Planing Board를 작성함.
7. 플래닝 포커
• 모든 사람들은 카드를 한 벌씩 나누어 가짐.
모든 팀원들이 같이 추정을 함.
이해하기 전에는 추정할 수 없습니다.
• 추정할 작업을 가장 잘 이해하는 사람이 작업에 대해 설명함.
보통 제품책임자가 작업에 대해 추정이 가능한 만큼만 설명함.
• 다른 사람들은 추정을 위해 필요한 질문을 하고 의논을 함.
추정하는 사람들은 구현하기 위해 확인할 내용을 질문할 수 있음.
주로 제품책임자가 답을 하겠지만 누구라도 질문에 대한 답을 할 수 있음.
팀원1: 이 작업의 키워드 검색기능의 범위가 어떻게 되나요? 자연어 검색도 되어야 하나요?
제품책임자: 자연어 검색까지는 필요하지 않습니다. 키워드로 제목과 본문내용이 검색되는
수준이면 충분합니다.
팀원2: 검색을 위해 검색엔진 구현이 필요한 부분일까요?
팀원3: 우리는 이미 사용할 수 있는 검색엔진이 있습니다. 검색엔진 구입이나 구현은
필요없어요.
8. 플래닝 포커
• 질문이 끝나면 각자 자신이 추정한 점수를 선택하고 동시에 카드를 뒤집어 확인.
모든 팀원들이 각자 자기가 이해한 수준에서 결정.
다른 사람의 눈치를 볼 필요는 없음.
• 모두 같은 점수가 나오면 그 점수로 작업의 점수를 결정.
• 가장 낮은 점수 또는 가장 높은 점수를 제시한 사람부터 그 점수를 제시한 이유를
설명.
예를 들어 모두 3점을 제시했는데 누군가 1점을 제시했다면 다른 사람이 모르는 중요한
정보를 알고 있을 가능성이 있음.
반대의 경우 아무도 모르는 작업의 위험을 알고 있을 가능성이 있음.
9. 플래닝 포커
• 모든 사람이 자신이 제시한 점수에 대해 논의한 후 다시 점수를 제시.
모든 사람이 자신의 점수를 제시한 이유를 논의함으로써 작업에 대한 이해를 공유할 수
있음.
이 때 제품책임자가 작업에 대한 중요한 의사결정을 내릴 수도 있음.
작업카드 뒷면에 중요한 내용을 기입할것!
팀원1: 로그인을 하지 않은 상태에서 장바구니의 내용을 다시 접속할 때 기억하려면 특별한
장치가 필요합니다. 이를 위해서는 이틀의 시간이 더 필요합니다.
제품책임자: 아 그렇다면 로그인을 한 상태에서만 장바구니 내용을 보관하도록 하죠.
10. 플래닝 포커
• 모두 동일한 점수를 제시할 때까지 반복.
모두의 점수가 합의될때까지 반복.
익숙해지면 보통 2~3회 반복으로 점수가 합의됨.
이러한 과정을 통해 작업의 내용을 더 구체화되고 공유됨.
이러한 의논을 통해 반드시 확인할 내용이 나오면 카드 뒷면에 테스트케이스로 기록할것.
11. 실전! 제품백로그 & 플래닝 포커
• DEMO - http://www.youtube.com/watch?v=0FbnCWWg_NY
• 제품을 정해서 5가지 정도의 제품 백로그를 만들어 보세요.
• 만들어진 백로그를 플래닝 포커를 통해 우선순위를 산정해 보세요.
12. 스프린트 계획 회의
• 1차
스프린트 계획회의 이전에 제품 백로그를 깔끔하게 정리해야 함.
매 스프린트 마다 제품 백로그의 우선순위를 제 정의해야 함.
제품 책임자는 각 스토리를 이해하고 있어야 함.
• 2차
재 정의된 제품 백로그를 기준으로 스프린트를 진행할 항목 검토
매 스프린트시 개발할 항목에 대해 구현할 내용 구체화 ( 스프린트 백로그 )
구체화된 구현항목에 대해 추정치(Story Point) 를 Planing Poker 를 통해 산출
13. 스프린트 요점
• 하나의 스프린트 목표
• 팀원의 목록
• 스프린트 백로그
• 확정된 스프린트 데모 날짜
• 확정된 일일 스크럼을 위한 시간과 장소
14. 스프린트 백로그
• 할일: 아직 아무도 하지 않고 있는 작업
• 진행중: 누군가 하고 있는 작업
• 완료: 완료한 작업
• 소멸차트: 일일 스크럼을 마친 뒤 바로
소멸차트에 새로운 점을 찍는다.
• 계획에 없던 일: 스프린트 백로그에 없으
나, 추가 요청이 들어온 항목. 다음 스프
린트 시작전 이 항목을 가지고 제품 백로
그 정의를 다시 해야 함.
• 다음에 할 일: 스프린트가 끝나기 전에
백로그 항목을 모두 완료하면, 다음 스프
린트 항목에서 할 일을 가져와서 진행한
다.
15. 스프린트 백로그
• 제품 백로그에서 하나를 선정하여, 스프린트를 진행할 구체화된 항목을 5개 정도
로 뽑아주세요.
• 플래닝 포커를 사용하여 구체화된 항목의 추정치를 산정해 주세요.
16. 일일 스크럼 진행
• 정시에 매일 같은 장소에서 15분 이하로 서서 진행.
• 한 사람씩 자신이 어제 한 일과 오늘 할 일을 말하면서 현황판을 직접 업데이트 한
다.
• 토론은 금지이며, 추가적으로 할 말이 있을 경우 스크럼 회의가 끝난 후 개인적으
로 한다.
• 일일 스크럼 진행 후 소멸차트를 업데이트 한다.
17. 스프린트 데모하기
• 성취감.
• 다른 사람에게 일한 것을 알림.
• 이해 당사자들로부터 아주 중요한 피드백을 이끌어 낸다.
• 여러 다른 팀들이 교류하며 서로의 일에 대해 토론할 수 있는 사회적 이벤트이고
또 그렇게 운영되어야 한다(가치있는일).
• 릴리즈를 유도하는 데모를 하므로써 일이 정말로 마무리 된다.(쌓아두지 않게 된
다)
18. 스프린트 회고하기
• 스크럼에서 두번째로 중요한 행사. 개선을 할 수 있는 최고의 기회.
• 아이디어 개진. 같은 실수를 반복하지 않기 위해.
• 예상되는 토론 분량에 따라 1 ~ 3시간을 잡는다.
• 참석자는 모두 (팀)
• 밀폐된 방보다 아늑한 소파, 옥상 테라스등 오랫동안 토론에 방해 받지 않을 장소
로 이동
• 팀방에서하면 집중이 분산됨.
19. 스프린트 회고하기
• 도우미 역할을 한명 정한다.
• 스크럼 마스터는 스프린트 백로그를 보여주고, 팀원들의 도움을 받아 가며 스프
린트 동안 어떤 중요한 사건과 결정사항이 있었는지 요약한다.
• ‘한 명씩 돌아가면 이야기’ 한다. 모든 사람들은 방해 받지 않고 말할 기회를 가진
다. 각자 좋았던 것과 더 잘할 수 있었던 것, 다음 스프린트에서 다르게 해보고 싶
은 것들을 이야기 한다.
• 추정 속도와 실제 속도를 살펴본다. 크다면 왜 그런지 분석해 본다.
20. 스프린트 회고하기
• 마칠 즈음에 스크럼 마스터는 다음 스프린트를 더 잘하기 위해 우리가 무엇을 할
수 있을지 구체적인 제안을 요약해 본다.
형식에 얽매이지 않고, ‘다음 스프린트를 더 잘하기 위해 우리가 무엇을 할 수 있는지’가
주제다.
• 만족, 반성, 개선 으로 스프린트를 평가한다.
개선안들 중 다음 스프린트 기간에 집중할 것들을 ‘점 투표(dot voting)’로 결정하곤 한다.
집중할 5개의 프로세스 개선안을 선택했고, 다음 회고 때까지 지켜나가 보도록 한다.
욕심 내지 말고, 소수의 개선안에만 집중하라.
• 회고가 끝나면, 팀원에게 쉬면서 재충전할 수 있는 시간을 줘라. 1일정도.