birdkr's home

예전에 몇차례 우리팀의 개발 프로세스에 대해서 글을 썼었는데 그때 이 후 변화한 개발 프로세스에 대해서 간단하게나마 적어보고자 한다. 사실 그 후에 프로세스가 크게 달라진 게 없고, 초기에 많은 도전과 실험이 있었던 것에 비해 지금은 많이 안정화되었기 때문에 딱히 블로그에 적을게 별로 없었다. 우리 팀이 어떻게 돌아가고있나 궁금해하시는 분들도 있고 또 낼모레 KGC도 있고 해서 간단하게나마 다시 한번 작년 이후 바뀐 것들 위주로 적어본다.

예전엔 이런 글들을 올렸었다.

• 애자일 게임 개발 적용 사례
• 우리팀의 바뀐 일정판
• 5월 이후 변화된 개발 프로세스
• 사례 중심의 SCRUM & XP
  

○ 스크럼

• 크게 바뀐 것 없이 잘 운영되고 있다.
• 여전히 제일 잘 지켜지고 있는 아침의 일일 스크럼 회의..
  
• 퇴근 무렵 않은 자리에서 5분 정도 짧게 그날을 회고하면서 정리하는 회의를 갖고 있다. 특별한 이야기는 별로 없고 그날 무슨 일을 했나 정도 이야기한다. 이 회의로 뭔가 얻는다기보다 업무를 다같이 마무리한다는 데 의미가 있는듯..
• 얼마 전부터 스프린트 주기가 한달에서 2주로 짧아졌다. 처음엔 픽스안된 기획이 많아 한달에서 2주로 줄인건데 하다보니 이게 더 우리한테 잘 맞는 것 같다. 좀 더 타이트한 느낌.. 일정 추정도 훨씬 수월하다.
• 정보방열판도 예전이나 지금이나 달라진 게 별로 없다.
  
• 추정 능력도 조금씩이지만 좋아지고 있다. 최근엔 처음으로 포커 플래닝을 해봤는데 일단 재밌고, 각 작업별로 각각 팀원들끼리 의견을 많이 나누니까 훨씬 현실적으로 추정하게 되는 것 같다.
• 우선 순위 할당도 '불확실성과 화해하는 프로젝트 추정과 계획'에 나온 칼 위거스의 방법을 이번 스프린트 때 사용해 봤는데 객관적이면서 현실적인 느낌? 마음 속으로 생각했던 우선 순위와 많이 달라 내심 놀랬다. 이게 바로 이상과 현실의 괴리인듯.. ㅠ.ㅠ
  
• 스프린트 마지막 평가는 제대로 이뤄지지 않고 있다. 결과가 좋지 않아도 다음에 잘 하면 되지.. 이런 느낌?
• 긴 회의 시간에 대해선 회의적인 시각이 많다. 전체 회의 시간을 따져보면 스프린트(2주) 처음 추정하면서 4시간, 스프린트 마지막 평가 1~2시간, 첫 이터레이션(1주일 주기) 정리 1시간, 매일 아침에 10분, 오후에 5분.. 어떻게든 각 회의 시간을 줄이려고 하는데 쉽지가 않다.

○ 프로그래밍

• 현재까지 만들어진 유닛 테스트 갯수는 1100여개... 이제 좀 보호막으로서의 역할을 하고 있다는 느낌이 든다. 그래도 여전히 버그는 많은 편이다..ㅠ.ㅠ 그나마 위안이 되는 것은 버그가 주로 테스트 코드가 없는 부분에서 난다는 것.. ㅠ.ㅠ
• 예전엔 서버만 유닛 테스트를 만들었는데, 클라이언트도 적극적으로 만들기 시작했고 얼마 전부터는 데이터베이스도 유닛 테스트를 만들기 시작했다.
• TDD는 하는 사람 있고, 안하는 사람 있고 제각각.. 안하는 사람이 더 많다.
  
• 페어 프로그래밍은 거의 사용하지 않는다. 모두들 페어 프로그래밍의 장점은 잘 알고 있지만 몸에 베이기가 쉽지 않다. 꼭 필요할 때에만 페어 프로그래밍을 한다.
• 많은 공을 들인 CruiseControl.Net을 이용한 자동화 테스트나 빌드 자동화도 잘 돌아가고 있다.

○ 기타

• 악의 축이나 지각 벌칙 등 팀원을 괴롭히는 요소는 모두 사라졌다. 이유는 이제 모두들 잘지켜지기 때문...
• 점심 시간에 서적 스터디는 꾸준히 진행중이다. 모두들 만족도가 높은 편.. 다만 부실할 수밖에 없는 먹거리 문제는 계속해서 고민꺼리..
  
• 코딩 도장도 운영했었는데 어느 순간 흐지부지됬다. 점심 시간에 스터디도 병행하면서 코딩 도장까지 하려니 지치더라는...
• 새로 들어온 팀원에게 팀의 개발 문화나 테스트 코드를 만들거나 하는 것들을 이해시키기가 쉽지 않다. 요즘 제일 큰 고민거리중의 하나..OTL
• 만약 다른 팀에서 애자일을 도입한다고 할 때 제일 추천하고 싶은 프랙티스는 아침 일일 회의와 빌드 및 테스트 자동화, 유닛 테스트 만들기이다. 다시 얘기해서 이 세가지가 우리 팀에 제일 큰 도움이 되었음..

예전에 적어놓은 개발 프로세스 이후 변화된 것만 간략하게 적어본다.

예전글
 - 애자일 게임 개발 적용 사례
 - 우리팀의 바뀐 일정판


변경된 프로세스

- 스크럼 일일 회의에 디렉터, 아트디렉터, 그래픽팀 팀장이 참여하기 시작함. 업무 흐름이 배 이상 좋아졌다.

- 그래픽 팀도 독자적으로 스크럼 팀을 구성. 그러나 잘 진행되고 있지는 않다. 특히 아침 일일 회의가 제일 문제. 업무의 성격상 어제 하던 일과 오늘 할일이 크게 다르지 않고(어제도 캐릭터 그리고, 오늘도 캐릭터 그리고, 내일도 캐릭터 그리고..-_-;), 서로의 업무 흐름을 맞춰야 할일이 별로 없기 때문인데, 때문에 팀원들 대다수가 일일 회의를 지겨워 한다. 계속 이대로 진행할지 프로그램팀과 합쳐야할지, 아니면 다른 방법을 택해야 할지는 좀 더 고민해봐야 한다.

- 다른 프로젝트 팀에서는 스크럼 대신 XPlanner라는 웹툴을 시험적으로 사용하기 시작했다. 손으로 작업 카드를 작성하는 것에 부담이 되는 팀이라면 도입해보는 것도 나쁘지 않을듯. 단 XPlanner 툴 자체가 사용하기에 썩 편리하진 않다. 있을 것은 다 있는데 UI 등 불편한 게 많고, 게다가 JSP..-_-

- 서버 파트에 UnitTest를 도입했다. 라이브러리는 UnitTest++을 사용함.

- 일부 팀원은 짝 프로그래밍 시범적으로 실시. 효과적인지는 시간이 좀 더 지나봐야 알 것 같다.

- 매주 금요일 오후 2시부터 6시까지 정기적으로 버그 리스트에 올라온 버그를 잡거나 안좋은 냄새를 없애는 집중 코드 정리 시간을 가짐.

- 일일 회의 시간에 지각을 하거나 작업 카드를 잘못 적었거나 적지 않았을 경우가 세번 누적되면 벌칙 부여(아이스크림 쏘기)

- 매일 새벽 6시에 액티브 버전을 빌드 서버에서 자동으로 빌드하고 배포함.

- 매주 월요일 오후 2시에 안정 버전을 자동으로 빌드하고 배포함.

- 위키로 버그 리스트를 관리함. 우선 순위를 최우선, 필수, 희망, 선택, 보류로 분류하며, 누군가 버그를 올리면 팀장이 읽고서 적당한 팀원에게 할당해 준다. 최우선,필수 항목이 10개를 넘지 않도록 유지하려고 노력함. 서비스 중에는 체계화된 버그 관리가 필요하나 개발중에는 위키로도 충분한 것 같다. Mantis는 너무 무겁다.

- 일정을 맞추기 위해 초과 근무하는 경우가 생김. (6월중 5일간 하루 2시간씩 초과 근무)

- 매달 열리는 회식의 주최자를 팀원끼리 2명씩 짝지어 돌아가며 담당하기로 함. 예산안에서 미풍양속을 해치지 않는 한도내에 하고 싶은 것을 정하기로 했는데 꽤 재미있을 것 같다.


기타 생각

- 작업 관리 프로세스는 어느정도 정착되어 가고 있는 것 같다. 그러나 아직 일정을 맞추는 것이 쉽지가 않다. 작업 시간 추정이 여전히 힘들고, 생각지 못한 일이나 중간 변경이 예상보다 더 많이 일어난다.

- 개인적인 관리 비용을 줄이려고 계속적으로 노력하고 있다. 자동화할 수 있는 것은 최대한 자동화하고, 게임의 각 요소별 책임자를 부여했다.

- '실천가를 위한 실용주의 프로젝트 관리 7WEEKS' 책대로 팀원과 일대일 회의를 할까 생각중.