스크럼을 이용한 게임 개발
•
75 j'aime•12,106 vues
사내 발표를 위해 제작한 자료입니다. 기존에 작성한 '스크럼 이걸 왜 하나요'가 스크럼에 대한 일반적인 시각에서의 소개였다면 이번 자료는 게임 개발에 접목시켜보았습니다. 조금이나마 도움 되셨으면 좋겠습니다.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 스크럼을 이용한 게임 개발
Similaire à 스크럼을 이용한 게임 개발 (20)
스크럼을 이용한 게임 개발
- 1. 스크럼을 이용한 게임 개발 Agile Game Development with Scrum Reid Lee reid@socialinus.com
- 2. 게임을 만드는 과정을 떠올려봅시다.
- 3. 제일 먼저 뭘 해야 할까요? ! 기획을 먼저 할까요? ! 코딩은 기획이 끝나야 시작하나요? ! 테스트는 언제 해야 할까요? ! 기획이 중간에 바뀌면 어떻게 하죠?
- 4. 지금 여러분은 ‘개발 프로세스’가 필요한 이유를 보셨습니다. 개발 프로세스는 절차를 이야기합니다.
- 5. 이번에는 조금 다르게 묻겠습니다. 여러분이 만들고 있는 게임은 어떤 ‘개발 프로세스‘를 따르고 있나요?
- 6. 모든 업무가 그렇듯이 소프트웨어 개발에도 프로세스가 있습니다.
- 7. 폭포수 모델waterfall model 일의 흐름이 층을 이룬 폭포에서 물이 떨어지는 모습을 닮았어요.
- 9. 건물 한채를 지어봅시다. ! - 거주자의 요구사항을 수집/분석하고 - 설계도를 그리고 - 미장하고 공구리쳐서 완성을 시킨 후, - 마감이 잘 되었는지 확인합니다. - 이후, 시공 업체는 지속적으로 유지보수하겠죠.
- 10. 완공 된 아파트의 설계에 결함이 발견되었습니다. 부수고 다시 만들까요? ! 공구리를 치기 전에 설계가 완벽해야 합니다.
- 11. 폭포수 모델은 공학 분야에도 잘 적용되어 왔습니다. 소프트웨어 개발에도 물론 문제 없습니다.
- 12. 소프트웨어를 만들어봅시다. ! - 고객 요구를 수집하여 기획서를 완성하고 - 코딩하여 구현 한 후, - QA 테스트를 거쳐 완성. - 이후 개발사는 지속적으로 유지보수합니다.
- 13. CRM, ERP... 폭포수 모델에 딱 들어맞는 프로젝트들입니다. ! 이들은 코딩을 시작하기 전에 설계가 완벽해야 합니다.
- 14. 그렇다면...
- 16. 게임은 기능이 아니라 재미를 설계해야 합니다. ! 기능은 누가 보아도 확실한 정답이 있지만, 재미는 보는 사람마다 다른 정답을 가지고 있습니다.
- 17. 게임은 만들어 보지 않고 설계를 완성시키기 매우 어렵습니다.
- 18. 지금까지의 개발 방법론으로는 문제가 해결되지 않습니다. ! 그 때, 소프트웨어 개발 전반에 걸쳐 새로운 바람이 불었습니다.
- 19. 애자일 소프트웨어 개발 선언 ! 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었 다: ! 공정과 도구보다 서로의 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 ! 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것 들에 더 높은 가치를 둔다는 것이다.
- 20. 게임에 빗대자면, ! 재미있는 게임을 만들기 위해 변화를 적극적으로 수용하고 더 많은 대화로 서로 협력하며 문서를 작성하기 보다 실제 로 작동하는 게임을 만들어 확인하자.
- 21. 애자일이 가져다 준 변화 ! ! 생산성이 향상되었다 ..... 87% 원하는 시점에 시장에 내놓게 되었다 ..... 86% 버그가 없어졌다 ..... 86% 비용이 절감되었다 ..... 63% ! ! http://www.versionone.com/pdf/stateofAgiledevelopmentsurvey.pdf
- 22. 애자일이 가져다 준 변화: ! ! ! ! ! ! ! ! ! 2005년 waterfall software .... 72% scrum agile ..... 28% 2013년 waterfall software ..... 22% scrum agile ..... 78% ! http://yusufarslan.net/agile-and-scrum-really-better-waterfall
- 23. 요구사항 수집 개발 피드백 출시/유지보수 폭포수 모델이 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있었던 문제 가 있었던 것에 반해서, ! 애자일은 이 일련의 과정을 잘게 나누어 여러번 반복합니다.
- 24. 그리고 개발 프로세스로 ‘스크럼’을 제시합니다.
- 25. 스크럼의 핵심: ! - 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물
- 26. 자, 이제부터 스크럼을 게임 개발에 적용해서 차례대로 살펴봅시다.
- 27. 제일 먼저 해야 할 것은 ‘프로토타이핑’입니다. ! 이 아이디어가 정말 괜찮을까? 머리속에 머물던 궁금증을 실제로 풀어보는 과정입니다. ! 프로토타이핑이 성공하면 드디어 프로젝트가 킥오프됩니다.
- 28. 게임이 갖출 기능들을 모아봅니다. ! - 브레인스토밍처럼 추상적인 단계가 아니에요. - 기능을 구현하는데 걸리는 시간도 예측합니다. - 기능을 목록Product Backlog으로 정리해보세요. PLANNING
- 29. 출시일을 계산합니다. ! - 예측한 시간들을 모두 더합니다. - 시간의 압박, 자금의 한계로 출시일을 당겨야 한다면, - 낮은 우선순위의 기능들을 제거합니다. FINAL
- 30. 릴리즈를 구상합니다. ! - 완전한 형태의 결과물들을 만들어 내는 시점입니다. - 마일스톤으로 불리기도 합니다. - 각 릴리즈의 기능을 목록Release Backlog으로 정리해보세요. REL1 REL2 ALPHA CBT OBT FINAL
- 31. 릴리즈를 스프린트로 쪼갭니다. ! - 스프린트는 짧게는 2주에서 길게는 1개월 정도로 잡습니다. - 스프린트의 결과물은 완성된 형태로 동작하는게 중요합니다. - ‘기능’을 ‘태스크’로 쪼개어 목록Sprint Backlog으로 정리합니다. REL1 SP1 SP2 SP3 REL2
- 32. 스프린트 플래닝Sprint Planning ! - 지난 스프린트의 결과를 토대로 기획을 수정합니다. - 스프린트에 완성시킬 기능을 태스크로 쪼갭니다. 스프린트 플래닝 1 2 3 4 5 6 ... SP1 SP2
- 33. 스프린트 리뷰Sprint Review - 결과물을 테스트하고 피드백을 받습니다. ! 회고Retrospective - 이번 스프린트에서 좋았던 점, 아쉬웠던 점을 이야기합니다. - 다음 스프린트에서의 각오를 이야기합니다. 스프린트 리뷰 / 회고 1 2 3 4 5 6 ... SP1 SP2
- 34. 스크럼은 매일마다 커뮤니케이션을 합니다. ! - 매일 스크럼 회의를 합니다. - 한 명씩 돌아가며 한일, 할일, 애로사항을 이야기합니다. - 하고 있는 일을 이야기하는게 아니에요. - 일정에 지장을 주는 애로사항은 바로바로 꺼내놓으세요. 1 SP1 MS1 2
- 35. 번다운 차트burndown chart ! - 스크럼은 현재 작업의 진척 상황을 함께 공유합니다. - 스크럼은 작업의 예측 완료 시각과 실제 완료 시각을 압니다. - 예측에 비해 원활한지 문제가 있는지 쉽게 파악됩니다. 프로젝트 마감 시점에 남은 작업 시간이 0이 되는, 가장 이상적인 기울기입니다. 남은 작업 시간 (hour) 진행 일자
- 36. 번다운 차트burndown chart ! - 팀의 역량에 비해 너무 과도한 일을 하고 있나요? - 다음 스프린트에서는 일정 예측에 조금 더 신경 써봅시다. 남은 작업 시간 (hour) 진행 일자
- 37. 번다운 차트burndown chart ! - 팀의 역량을 과소평가 한 건 아닌가요? - 스프린트가 반복 될 수록 일정 예측은 점점 정밀해집니다. 남은 작업 시간 (hour) 진행 일자
- 38. 여기까지 스크럼이 어떤 방식으로 동작하는지 알아봤습니다. 그런데 잠깐 고민해봅시다. ! ! ! ! ! ! ! ! 스크럼은 우리에게 무얼 강조하고 있는건가요?
- 39. 스크럼이 추구하는 핵심 가치 세 가지를 다시 돌아봅시다: ! - 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물
- 40. 침묵은 위기, 서로 좀 더 이야기를 많이 하자. 기획 변경을 두려워하지 말자. 항상 개발중 개발중 개발중 하지 말고, 실제로 돌아가는 게임을 만들어보자. 스크럼은 사실 이런 가치를 실현하기 위한 도구 일 뿐입니다.
- 41. 스크럼은 무엇이고 어떻게 하는 것인가를 알아보았습니다. ! 이번에는 스크럼이 프로젝트를 어떻게 변화시킬 수 있는지 살펴봅시다.
- 42. 나는 누구인가 여기는 또 어디인가 ! ! ! ! ! ! ! ! ! ! ! 팀원 누구라도 내가 지금 어느 위치에 서있는지 알 수 있습니다. 비전은 언제나 모두에게 동일하게 공유되어야 합니다.
- 43. 전력 질주를 합니다. ! ! ! ! ! ! ! ! ! ! 스프린트와 같은 단기 목표는 전력 질주를 가능하게 합니다. 장기 목표만으로 진행되는 프로젝트는 갈수록 지치게 마련입니다. 스프린트 리뷰마다 목표 달성을 기념하는 파티를 해보세요!
- 44. 야근 없이도 잘 굴러갑니다. ! ! ! ! ! ! ! ! ! ! ! ! 출시 전 철야 작업은 반드시 거쳐야 하는 통과 의례가 아닙니다. 지속적으로 출시에 포함 될 기능을 구상하고 일정을 쪼갭니다. 분할 정복Divide and Conquer은 일정을 준수하기 위한 효과적인 방법입니다.
- 45. 눈총받지 않고 기획을 변경합니다. ! ! ! ! ! ! ! ! ! ! 무턱대고 일정 중에 기획을 변경하면 팀원들은 멘붕에 빠집니다. 기획의 변경은 스프린트의 결과물을 토대로 진행합시다. 팀원들의 공감을 받는 기획 변경은 프로젝트 성공의 청신호입니다.
- 46. 장애물들을 각개 격파합니다. ! ! ! ! ! ! ! ! ! ! ! ! 스크럼 회의에서 가장 중요한 것은 작업 내용 공유가 아닙니다. 일정에 차질을 주는 애로사항을 팀에 공유하는 것이 가장 중요합니다. 프로젝트가 실패하는 큰 원인은 그 누구도 리스크를 이야기하지 않기 때문입니다.
- 47. 순항중인지 폭풍우를 만났는지… ! ! ! ! ! ! ! ! ! 팀원들 모두가 프로젝트의 진행 상황을 잘 이해하게 됩니다. 잘 해내고 있는지, 혹시 암초를 만나서 기우뚱거리고 있지는 않은지… 번다운 차트는 프로젝트의 진행 상황을 한 눈에 보여주는 최고의 도구입니다.
- 48. 일정을 정밀하게 예측합니다. ! ! ! ! ! ! ! 팀마다의 역량은 서로 다르게 마련입니다. 스프린트 플래닝과 회고를 반복하면서 팀의 능력에 맞는 일정 예측이 가능해집니다.
- 49. 이처럼 스크럼은 여러가지 장점을 가져다 줍니다. 이제 단점을 이야기 할 때 인가요?
- 51. 스크럼이 추구하는 바를 이해하는 것은 생각처럼 쉽지 않습니다. ! 아침에 쑥스럽게 작업 보고 하는 것, 포스트잇이 많이 소비되는 것, 그냥 귀찮은 것 ! 으로만 인식하고 있다면 스크럼은 시간 낭비 일 뿐입니다.
- 52. 하지만, 너무 걱정하지 마세요. 그런 상황은 어느 팀에서나 일어난답니다. ! 이를 극복하기 위해 희생하는 사람이 바로 ‘스크럼 마스터’입니다. ! 스크럼 회의에서 팀원들이 리스크를 언급하는게 왜 중요한지 설명 해주어야 합니다.
- 53. 스크럼은 경험을 통해서 얻어진 개발 프로세스입니다.
- 54. 경험 많은 사람들은 소프트웨어 개발이 왜 실패하는지, 왜 성공하는지 이해합니다.
- 55. 스크럼은 우리에게 ‘경험’을 선사합니다.
- 56. 스크럼은 경험이 많지 않은 팀에게 그런 시행 착오를 겪지 않도록 도와줍니다. ! 경험은 열정으로 극복되기도 합니다. 그런 팀에게 프로세스는 거추장스러운 장애물이 되기도 합니다.
- 57. 한번 만 더 가져와봅니다. ! - 원활한 커뮤니케이션 - 반복 개발 - 테스트 가능한 결과물
- 58. 팀원들간의 원활한 소통으로 리스크를 제거하고 테스트가 가능한 결과물을 지속적으로 만들어 우리가 맞는 방향으로 가고 있는지 체크하며, 이 과정을 반복하여 최종 목표를 향해 나아가야 합니다. ! ! ! ! ! ! ! ! 마치 유도탄처럼!
- 59. 스크럼, 해볼 만 하지 않나요?
- 60. 긴 발표를 함께 해주셔서 고맙습니다. ! -끗-
- 61. 스크럼에 대해 제가 작성한 다른 자료들이 있습니다: ! '스크럼, 이걸 왜 하나요?' 블로그 글 ‘스크럼, 이걸 왜 하나요?’ 프리젠테이션 자료