birdkr's home

KGC2008 세션중 하나인 '애자일 게임 개발 도입하기' 월드까페에서 하고 싶은 얘기들 정리하면서 최종적으로 남는 몇가지 키워드들...

• 결과를 위해 일하기
• 시스템보다는 사람에 집중하기
• 우선 보여주기
• 천천히, 지속적으로..
• 팀에서 가장 부족한 부분부터 실행..~

오늘 월드 카페 기대됩니다..ㅎㅎ

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

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

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

○ 스크럼

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

○ 프로그래밍

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

○ 기타

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

'불확실성과 화해하는 프로젝트 추정과 계획' 에서 설명한 카노 모델을 정리해봤다. 꽤 객관적으로 우선순위를 추릴 수 있을 것 같은데, 나중에 유저에게 피드백이 필요할 때 꼭 적용봐야겠다.


○ 카노 모델이란?

제품의 기능을 다음의 세 가지 범주로 구분한다.
 - 임계(threshold) 혹은 필수 기능들
 - 선형(linear) 기능들
 - 감동요인(Exciter or Delighter)을 제공하는 기능들

필수 기능 : 성공적인 제품이 되기 위해서 반드시 포함되어야 하는 기능이다. (예: 아이템 루팅, 레벨업) 임계 기능의 성능이나 양을 개선하는 것은 고객 만족에는 큰 영향을 미치지 못한다. 가령, 레벨업을 할 수 있어 기본적인 필요를 충족시키기만 하면, 바로 레벨업이 될지 특정 NPC에게 말을 걸어야 레벨업이 될지 같은 문제는 크게 신경쓰지 않는다.
선형 기능 : "더 많을수록 좋다."는 말이 들어맞는 기능이다. (예: 더 좋은 그래픽, 더 많은 직업) 이들 기능들이 더 나은 성능을 보이면 고객 만족도는 더 커진다.
감동요인 : 감동요인에 해당하는 기능들은 고객에게 큰 만족을 주는 기능일 뿐 아니라, 제품 경쟁력에 프리미엄을 더하는 요인이다. (예: 블러드앤소울에서의 암바 기술) 하지만 이런 기능들이 구비되어있지 않더라도 고객 만족도는 적정선 아래로는 내려가지 않는다. 사실 감동요인은 '미지의 수요(unknown needs)'라고 불리기도 하는데, 직접 보기 전에는 그런 것들이 필요한지 사용자들이 알지 못하기 때문이다.

다음은 이 세 가지 종류의 기능들 간의 관계를 나타낸 그래프이다.


필수 기능들은 제품을 시장에 내놓으려면 반드시 있어야 하므로, 이런 기능들을 구현하는 작업의 우선순위는 높게 매겨져야 한다. 그 다음으로 우선순위가 높게 매겨져야 할 부분은 가능한 많은 선형 기능들을 구현하기 위한 작업들이다. 선형 기능들을 제품에 더 많이 포함시키면 고객 만족도는 그에 따라 상승한다. 그 뒤에 시간이 허락한다면 적어도 몇 개의 감동요인 기능들이 릴리즈 계획에 포함될 수 있도록 적절한 우선순위를 부여하여야 한다.

어떤 기능이 카노 다이어그램의 어디에 위치할 것인지는 시간에 따라 변한다는 것에 유의하자. 가령 얼마 전까지 HDR은 감동요인이었으나 지금은 선형 기능이 되었으며, 나중에는 결국 필수 기능이 될 것이다.


○ 카노 모델이 따른 테마 평가

카노 모델을 적용하는 가장 쉬운 방법은 각각의 테마를 놓고 그 테마가 어떤 타입일지 추측해 보는 것이다. 하지만 더 좋은 방법은 고객이나 사용자와의 대화를 통해 그 테마의 타입을 결정하는 것이다. 이 방법은 간단한데, 사용자에게 설문지를 주어 그 요구사항 간의 우선순위를 매겨달라고 하는 정도로 충분하기 때문이다.

설문지에는 두가지 질문을 통해 기능의 범주를 결정한다. 첫 번째 질문은 만일 해당 기능이 제품에 존재한다면 사용자는 어떤 기분을 느낄 것인가 하는 것이고, 두 번째 질문은 만일 그 기능이 없다면 사용자는 어떤 기분을 느낄 것이냐 하는 것이다. 첫번째 형태의 질문을 '기능 설문항(functional form)'이라고 부르며, 두번째 질문은 '비기능 설문항(dysfunctional form)'이라고 부른다. 사용자는 각각의 질문에 대해 1에서 5점까지의 점수를 매긴다.

  1. 만족한다.
  2. 그럴 거라고 예상했다.
  3. 중립.
  4. 그렇더라도 쓸 수는 있다.
  5. 그렇게 되면 불만이다.

간단한 퍼즐 게임의 사례를 통해 실제 적용 방법을 살펴보도록 하자. 다음의 세 가지 새로운 기능들의 범주를 결정하도록 할 것이다.

• 게임 참여자는 낮은 난이도로 컴퓨터와 게임을 할 수 있다.
• 게임 참여자는 누구 차례인지를 시각적으로 확인할 수 있다.
• 게임 참여자는 때로 게임에 대한 힌트를 물을 수 있다.
  

이 기능들이 어떤 범주에 드는 기능인지를 결정하기 위해, 예상 사용자들을 대상으로 설문조사를 진행하여 다음과 같은 질문들을 던져 보았다.

• 낮은 난이도로 컴퓨터와 게임을 할 수 있다면 어떻겠는가?
• 낮은 난이도로 컴퓨터와 게임을 할 수 없다면 어떻겠는가?
• 누구 차례인지를 시각적으로 확인할 수 있다면 어떨 것 같은가?
• 누구 차례인지를 시각적으로 확인할 수 없다면 어떨 것 같은가?
• 때로 게임에 대한 힌트를 물을 수 있다면 어떤 기분일 것 같은가?
• 때로 게임에 대한 힌트를 물을 수 없다면 어떤 기분일 것 같은가?
  

이 질문들 가운데 첫 두개에 대한 사용자 답변이 다음과 같이 주어졌다고 해보자.

• 낮은 난이도로 컴퓨터와 게임을 할 수 있다면 어떻겠는가? ---> (2. 그럴 거라고 예상했다.)
• 낮은 난이도로 컴퓨터와 게임을 할 수 없다면 어떻겠는가? ---> (5. 그렇게 되면 불만이다.)
  

사용자가 한 설문항 쌍에 일관되지 않은 답을 내놓을 수도 있다. 예를 들어 위 질문에서 낮은 난이도로 컴퓨터와 게임을 할 수 있다면 좋겠다고 대답하는 동시에, 그런 기능이 없어도 좋다는 답을 할 수도 있다. 하나의 기능 설문항과 비기능 설문항 쌍에 대해 가능한 답변의 개수는 25개이다. 그러므로 기능 설문항과 비기능 설문항에 대한 답을 동시에 살펴보고 평가할 수 있는 방법이 필요하다.

○ 답변 분류하기

다음은 답변 쌍을 평가하기 위한 평가 테이블이다. 기능 설문항과 비기능 설문항에 대한 답변을 상호 참조하면 예상 사용자가 내놓은 답에서 하나의 단일한 의미를 이끌어 낼 수가 있다.


위 질문을 스무 명에서 서른 명 정도의 사용자에 대해 반복해서 물어보고 그 결과를 다음과 같이 취합한다.


이 표를 보면 '누구 차례인지를 시각적으로 확인할 수 있는 기능은 선형 기능이고, 게임에 대한 힌트를 물을 수 있는 기능은 감동 요인이라는 결론을 내릴 수 있다.
그런데 이런 식으로 평가를 해 나가다 보면 위 표의 '힌트 기능'과 같이 두 개의 범주에서 동시에 높은 점수를 받는 기능이 나올 수도 있다. 이는 고객과 사용자의 유형별로 시스템에 기대하는 것이 서로 다르다는 뜻이다. 이런 경우가 발생하면 사용자나 고객의 부분 모집단(subpopulation)을 분별해주는 요소를 고려하여 고객이나 사용자의 답변을 분석하여야 한다.

○ 구글을 이용한 설문 조사
구글의 스프레드시트를 이용하면 위의 설문 조사를 쉽게 취합할 수 있다.

• 입력 폼 : http://spreadsheets.google.com/viewform?key=ptk_LsGn4834jzc3LFa0gLw
• 결과 : http://spreadsheets.google.com/pub?key=ptk_LsGn4834jzc3LFa0gLw
  

데이터베이스도 리팩토링이 가능하고, 테스트 코드를 만들 수 있고, TDD가 가능하고, 자동화가 가능하다는 것을 보여주는 발표 자료..~

refactoring database

View SlideShare presentation or Upload your own.

  도와주세요! 팀장이 됐어요 

신승환/위키북스
[장면#1]“김대리! 이번 프로젝트는 자네가 맡게나.”“네? 제가 팀장이란 말씀이세요?”눈을 뜨니 유명해졌다는 것은 거짓말이겠지만, 개발자가 어...

'더 골'처럼 소설 형식으로 되어있어 일단 재밌다!!

그리고 읽기 전까진 몰랐는데 문제에 대한 해법 대부분이 애자일 프랙티스 위주로 풀어나가고 있어 그동안 공부하고 경험한 것들을 다시한번 되짚어볼 수 있는 기회가 되었다. 애자일에 관심있는 팀장님들이 보면 좋을듯~


○ 팀장이 하는 일
 - 책임감을 나누기
 - 일정에 가시성을 부여하기
 - 효과적인 의사소통으로 개발 시간을 확보하기
 - 촉매로서 팀원들을 도와주기

이런 일들이 일회성이 아닌 습관이 되어야 한다. 문제가 생겼을 때 누군가에게 비난의 화살을 돌리기보다 근본문제를 찾으려고 부단히 노력해야 하고, 사람을 관리하기보다 목표를 관리해야 한다. 아울러 목표를 달성하려면 팀원들을 어떻게 도와주어야 하는지 고민해야 한다.