2007년 11월 12일
Agile 이 우리의 목표가 아니다.
Agile 이 목표가 아니다.
좋은 제품(나 같은 경우에는 게임)을 만드는 것이 우리 팀의 목표다.
팀의 효율을 높이기 위해 Agile 을 도입하는 거지, Agile 을 위해 팀의 효율을 고민해서는 안 된다.
꼭 책에서 나오는 방법이 아니더라도, 팀의 효율이 높아져서 제품의 질이 향상되고, 팀원들이 단순 노가다 대신 즐거운 두뇌 노동을 할 수 있다면, 충분히 Agile 하다고 말할 수 있다.
게다가 Agile 보다는 팀의 생산성 향상이 정량적으로 분석되기 쉬우므로 도입하기도 쉽다.
(컴파일 시간이 100% 줄어드는 건 눈으로 확인하기 쉽지만, 페어 프로그래밍을 한다고 해서 능률이 100% 오른다고 말하기는 어렵다.)
현재 팀의 병목이 어디인지 확인해 보자.
컴파일 시간이 오래 걸린다면 병렬 컴파일이나 Header 파일 정리를 해 보자.
기획팀의 스크립트 데이타 에러 때문에 작업이 느려진다면 스크립트 데이타 검증 툴을 만들어서 제공해 주자.
그래픽 팀의 작업속도가 느리다면, 어떤 툴이, 어떤 기능이 있으면 좋을지 물어보고 그걸 추가해 주자.
PS : 트랙백 추가했습니다. 원래 이렇게는 잘 안 합니다만,
요즘 들어 애자일이 유행하면서, 그와 동시에 많은 분들이 애자일에 대해서 오해를 하시는 듯 합니다.
확실히 애자일은 시스템이라기 보다는 마인드... 라는 느낌입니다만, 기존 방식에 지쳐 있던 사람들이 애자일에 열광하는 이유가 단순히 '새로운 것'이기 떄문인지, 아니면 정말 '뭔가 특별한 것이 있어서'인지는 생각해 봐야 합니다.
왜 사람들은 기존 방식에 지쳐 있을까요? :) 애자일이 팀을 변화시키고, 팀의 생산성을 향상시킨다는 얘기는 정말 거짓일까요?
http://whtdrgon.egloos.com/1667482
http://jx3.org/blog/?p=33
# by | 2007/11/12 07:48 | 개발 이야기 | 트랙백 | 덧글(10)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
저도 Lean을 읽고 많은 것-낭비를 없애고, 낭비 제거에 필요한 조직차원의 학습-을 배웠습니다.
팀이 잘되게 한다는 공동의 목표안에서 융합되는 하나의 계기가 애자일이 아닐까 싶네요.
행동지침서 같은...
융합되지 않은, 그리고 신뢰성이 없는 팀에서는 애자일이던 뭐던 안먹고 좋은 제품도 안 나올듯 싶습니다.
팀 + 애자일 = 좋은 팀 = 좋은 제품
ToC(제약이론)에서도 비슷한 방법을 제시하고 있습니다. 프로세스 중에서 현재 병목이 되는 부분을 찾아서 해결한다면 전체 생산성이 크게 증가할 수 있죠. 린은 아직 책으로 접해보진 못했지만 TPS 방식을 접목시켰다면 낭비를 제거하는 지속적인 노력을 통해 생산성을 향상시킬 것 같네요.
생산성이나 효율에 대한 입장이 개인과 회사가 다를 것 같습니다. 이러한 관심의 불일치가 Agile이 실패하는 이유 중 하나일 것 같은데, 이 둘을 융합시킬 수 있는 방법을 찾는 것이 중요하다고 생각됩니다.
김현만 : 그런 목표를 공유하는 게 시작이면서도 가장 어려운 부분이겠지요.
따지크 : 끝날 쯤에 OPPSLA 관련 링크 부탁드렸던 게임 회사 다니는 사람입니다. 결국은 자기 회사에 맞는 방법을 스스로 찾아야 하는 거 같아요.
아... 글이 좀 묘하게 쓰여져서 자칫 애자일 자체를 쓸데없는 짓이라고 하는 것 처럼 보였습니다만...
조금 정리를 하자면, 애자일은 '개발방법론'이 아니라 '개발정신과 실천강령'같은 것이다.
그러니 개발방법론이랍시고 '애자일거리지' 마라... 라는 말이었습니다.
앞서 기존의 방법론이 '필요에 의해 수십년간의 노하우가 쌓이며 변화해온 것' 이라는 전제에서 애자일도 그런 변화의 방법론 중 하나라고 생각합니다.
애자일 자체가 무의미하거나 쓸모없다라는 것은 아닙니다. 변화가 이렇게 구체적으로 형성되는데 얼마나 큰 노력이 필요한지도 알고 있습니다. 돌파구를 찾으려는 수많은 노력이 결집되고, 또 그게 적용되면서 지식과 사례가 모여 애자일2.0이 되는거겠죠.
그에 반하여 단지 마치 모든 회사의 오너나 결정권자 투자자들, 그리고 모든 사업기획서에 최면이라도 걸린듯 블루오션~ 이라는 단어가 트랜드가 되듯, 애자일이 트랜드처럼 함부로 이야기되는 것에 대한 경계였을 뿐입니다.
마치 사장님이 어디선가 서번트 리더쉽이라던가 하이퍼포밍같은 책을 뜩 던져주면 갑자기 팀이 그것을 '흉내내기' 시작하는 것처럼 말이죠. 이래서야 어처구니없이 '애자일의 실패사례'가 양산되버리는 것도 걱정이긴 했습니다.
Agile에도 관심이 많았고, 개발자들의 의지와 저의 삽질이 더해져 얼핏 비슷하게 끌고가고있으나,
결국 바빠지니 이것저것 눈에 안뵈고 무작정 달리게 되네요 ㅠ_ㅠ
그런데 중요한건, 무작정 달리는 상황하에서도 꽤나 유기적으로 저희 팀의 퍼포먼스가 유지되고 있다는 사실입니다. 윗 선배님들의 말씀대로, 결국 (저를 제외한) 개발자들의 능력이 출중하고, 서로 많은 대화와 이해수렴과정을 거치니 가능한 일이겠죠 =)
앞으로도 블로그 자주 찾아뵙겠습니다^^
즐겁게 개발하시고, 좋은 얘기 많이 들려주세요. 감사합니다.