Game Design & Marketing : 스크럼 프로세스 도입 1주차에 들어서다.

2007년 09월 06일

한 달도 채 되지않은 짧은 스크럼 분석 기간을 거치고 나서 이번 주부터 시작된 스프린트 #1.

좀더 솔직하게 이야기하자면 현재 진행되고 있는 스프린트가 긍정적인 방향으로 가는지에 대해서도 아직은 판단이 서지 않는다. 다만 이전의 전통적인 개발 방식을 따랐을 때 보다는 커뮤니케이션이 활발해지고 스크럼 팀원들간의 co-work 가 눈에 띄게 많아졌다.

가이드라인이 제시하는 대로 아침마다 데일리 스크럼 미팅을 하고, 태스크보드를 업데이트하며, 번다운챠트를 기입해 나가고는 있다. 하지만 이번 스프린트에 참여한 프로그램 팀원들은 '100% released code' 라는 원칙에는 다소 회의적이기도 한 것 같다. 하지만 이전보다 달라진 팀의 분위기라던지 의사소통의 향상으로 인해 반신반의하는 느낌을 가진 듯..

아무튼 이번 스프린트의 결과물 성과가 좋다면 스크럼의 적용 범위를 지금보다 늘릴 계획.

PS: 이번 스프린트의 네트워크다이어그램을 뽑다보니 Critical Path가 3개나 된다. 스크럼 동기화 면에서 서브 아이템이나 백로그의 범위를 조정하다보니 발생한 리스크인데 가이드라인에는 CPM에 대한 적용 조언을 찾을 수 없었다.

스크럼, 애자일, agile, scrum, CPM

# by 야드 | 2007/09/06 19:03 | [자기 이야기] | 트랙백(3) | 덧글(9)

트랙백 주소 : http://yadd.egloos.com/tb/3375314
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

Tracked from There Must B.. at 2007/09/07 09:58

제목 : T 사에서 Scrum을 시작하다.
T 사에서 근무하시는 Yadd 님께서 현재 프로젝트에서의 Scrum에 대한 포스팅을 올려주셨습니다: 스크럼 프로세스 도입, 1주차에 들어서다. 이번 포스팅에서 흥미로운 점은, 명시적인 프로세스(a defined process)에서 Agile과 같은 경험주의적인 프로세스(an empirical process)로 이행하고 있다는 점입니다: "이번 스프린트의 네트워크다이어그램을 뽑다보니 Critical Path가 3개나 된다." 대게의 한국 게임 개......more

Tracked from Effortless -.. at 2008/04/08 08:52

제목 : 스크럼(Scrum) 회의 - 컨퍼런스콜
스크럼(Scrum) 회의 - 컨퍼런스콜 애자일(Agile) 법론 중에 가장 가벼워 보이는 극단적인 방법론으로 스크럼(Scrum)이 있습니다. 단순함과 실천의 용이함 때문에 이 방법을 꼭 적용해 봐야겠다 맘을 먹고 있었는......more

Tracked from Younghoe.Info at 2008/04/08 14:07

제목 : 스크럼(Scrum) 적용 일지
스크럼 적용 3주째. 폭포수(waterfall) 모델과 같은 선형적인 기존 모델에 기반한 다른 관리 기준과 스크럼의 공정 측정 사이의 점접을 찾는데 시간이 다소 필요했다. 스프린트 계획 회의 없이 PM이 미리 준비한 작업 목록으로 시작한 '스프린트0'에 대해서 회고를 진행해보았다. 얼음을 깨는 일에 대해 다소 우려감이 있어 짧은 시간 동안 맛뵈기로 진행하려고 했는데, 의외로 많은 이야기들이 쏟아져나왔다. 애자일 회고를 읽으면서 리듬감을 중요시하......more

Commented at 2007/09/06 22:47

비공개 덧글입니다.

Commented by 김기웅 at 2007/09/06 23:08

제가 알기로도 Agile Software Development with Scrum에서는 임계경로관리(CPM)에 대한 언급이 없습니다. 제가 추정컨데, Scrum의 기본 원리와 실천사항으로 감당 가능하기 때문이며, 좀더 자세히 설명하면 다음과 같습니다:

1. Scrum(을 비롯한 Agile)에서는 사전에 누가 무슨 일을 할지 정하지 않으므로, 임계경로를 미리 추정하는 것은 의미가 없다.

2. Scrum은 다양한 경로로 프로젝트의 투명성과 가시성을 증가시켜서, 만약 병목 현상이 일어나면 그것을 즉시 포착한다. (예: 일일 소멸 차트에서 기울기가 갑자기 완만해진다.)

3. 병목 현상이 발생하는 것 자체를 '장애물'로 처리한다.

마지막으로 체험담을 올려주셔서 정말 감사합니다!

Commented by 야드 at 2007/09/07 09:11

김기웅//우선 좋은 정보를 주셔서 진심으로 감사드립니다. 한가지 여쭈어 보고 싶은게, 스크럼에서 제시하는 작업분류체계, 즉 백로그 아이템을 액티비티라고 본다면 작업자 중심의 작업분류체계(WBS)가 아닌 기능위주의 기능분류체계(FBS)로 작업분할이 이루어 진다고 생각합니다.

그렇다면 누가(who)라는 요소보다 기능을 위한 어떤(which) 작업들이 순차적으로 연계되는가를 판단하지 않을 수 없다고 보는데요. 해당 아이템(작업)들의 기간을 산출하고 네트워크다이어그램을 뽑아서 주공정경로를 산출하는 과정에서 사전에 CP를 찾아(사후에 발견하는 것이 아닌) 사전 대응을 할 수 있는 것이 CPM의 핵심이라고 생각합니다.

스크럼 방법론이 제시하는 일정 단축 기법이나 도구는 없는 지, 혹은 타프로젝트 사례에서 그러한 (스프린트의 길이를 조정해 줄 수 있는)일정 단축 기법이 스크럼에 적용된 경우는 없는지 궁금합니다.

Commented at 2007/09/09 21:11

비공개 덧글입니다.

Commented by Connie at 2007/09/11 12:56

야드야...뭐하니? -_-;; 게시글과 상관없는 댓글..

Commented by twiny at 2007/09/26 23:16

트랙백을 걸까하다 그냥 덧글 올립니다. 나중에 생각이 정리되면 제 블로그에도 위의 글과 관련한 내용을 올려보겠습니다.

PMI 가르침대로라면 작업을 분할(Work Breakdown)해서 그 작업에 개별적인 관리가 들어갑니다. 즉, Plan-Driven 하죠. 미리 치밀한 계획을 세우고 변경통계(범위통제)를 통해 관리하는 것인데 Agile은 이에 반대합니다.
- 반대하기보다는 이 방법이 비효율적이기 때문에 효율적인 방법을 제시한다는게 맞을 듯.

팀은, 스토리카드 게임 (또는 플래닝게임) 등을 통해서 현실적인 추정을 할 수 있게되는데, 만약 CP가 많이 나온다면 그 스크럼 팀은 무리 했다고 볼 수 있습니다. 몇 번의 이터레이션을 돌다보면 그 팀이 처리할 수 있는 Velocity (속도)가 나옵니다.

피드백을 기준으로 백로그를 할당해가면 됩니다.

팀이 무리를 해서라도 꼭 해야 한다면 고객에게 제공하는 가치를 기준으로 다음번 이터레이션으로 미루라고 합니다.
- 어떤 엔지니어도 CPU 부하를 100%로 해서 시스템을 운영하지 않죠.

스크럼 방법론은 보셔서 아시겠지만 정말 러프한 가이드라인을 줄 뿐입니다.

애자일의 원칙과 프랙티스를 익히기 위해서는 볼게 많네요.

린 소프트웨어 개발을 다룬 책을 보면 제약이론(TOC)와 애로사슬 (Critical Chain)에 대한 내용이 있습니다. PMP에서도 다루는 내용이지요.

그 내용이 도움이 되실 듯하네요.

Commented by 쿠테 at 2007/09/30 17:13

좋은 적용사례가 되서 널리 퍼지길 기원하겠습니다.

Commented by 야드 at 2007/10/01 13:25

twiny//좋은 지적을 주셔서 감사드립니다. 저희팀은 스크럼을 시작한 지 이제 4주 차에 들어가고 있습니다. 그간 단위테스트와 2번의 이터레이션 배포를 통해 여러가지를 (경험적으로) 습득해나가고 있습니다. 스크럼 도입 이전에 팀원들 개개인의 사전 교육이 왜 필요한 지에 대해서 느꼈습니다. 긍정적인 의미로는 시행착오를 겪은 만큼 팀이 애자일 방법론에 조금씩 다가서고 있는 것 같아 보입니다. 현재로는 4주 차를 마쳐놓고 스프린트 단위의 후기를 올릴까 합니다. 감사합니다.

Commented by Connie at 2007/11/21 16:41

야드. 우리 반지의 제왕 시작했다. -_- 넌 뭐 안하겠지만 말이다. 하면 쫓겨나겠지? ㅋㅋ