Archive for December, 2009
스크럼과 평가
http://blogs.seattleweekly.com/dailyweekly/2009/07/the_mayoral_campaign_scrum_in.php
스크럼 이렇게 했습니다
올해 하반기 6개월동안 스크럼으로 프로젝트를 진행했습니다. 온라인 게임을 위한 라이브러리를 만드는 프로젝트였고, 개발자는 한국인이 4분, 일본인이 1분 참가했네요.
- 노예형 스크럼 마스터
- 개발자중 1명
- 스크럼 마스터로서의 권한은 부족하고, 의무만 많았으므로 노예형이라 부르기로함 ^^;;
- 리더
- 개발자중 1명(나)
- 스크럼에는 없는 역할이지만 아키텍트, 테크니컬 리더, 관리자의 짬뽕 역할. (나는 하기 싫었음 -_-;;)
- 프로젝트 오우너
- 팀장님겸 실장님이 해주심
개인별 성과 평가는 어떻게 하나요
회사에서는 개인별 성과평가를 원하는데, 스크럼에서는 평가와 관련된 가이드가 적어서 고민이었습니다. 개인별 성과를 평가한다는 것의 의미, 목표, 효과는 스크럼의 철학과는 반대되는 것이었지요. (이 부분은 아래 부록에서 설명) 그래도 왠만한 회사에서는 개인별 성과평가를 원할테니 선배님들의 노하우가 있지 않을까하고 Xper 뉴스 그룹에도 질문을 드렸습니다.
Xper 뉴스 그룹에 올린 질문 과 스레드http://groups.google.com/group/xper/browse_thread/thread/64b2986c3c5848cb/0a98b48a81cd2fba
일단 이렇게 평가합시다
어쨌든 반기가 시작하기 전에는 평가방식을 공유, 합의할 필요가 있었으니, 아래와 같이 정해봤습니다.
- 모두 동일한 성과평가 등급을 받는다. ( 프로젝트의 평과를 적용)
- 투표에 의해 MVP를 뽑아서 개인 평가에 반영한다.
모두가 같은 평가를 받는 것은 너무나 아름다운 시나리오라는 생각이 들었습니다. 개발자분들이 싫어하지 않을까 걱정했지만 모두들 아무런 이견없이 잘 받아들여 주셨습니다. 착하고 능력있고 잘생긴 분들을 만난 제 복이라고 생각해야겠지요. ㅎㅎ
MVP를 뽑는 것은 혹시나 있을지 모르는 어뷰징, 혹은 사기저하를 방지하기 위한 장치였습니다. 평가방식의 허점을 노려서 놀고먹는 개발자가 생기거나, 엄청난 공헌을 한 개발자에게 실망을 안겨주는 상황을 막아보자는 의도였습니다.
동일한 평가를 받으니 좋네요
2009년이 저물고 평가의 시간이 돌아왔습니다. 이제와서 돌이켜보니 모두 동일한 평가를 받기로 한 것은 참 잘한 일이었습니다. 내 일, 네 일 가리지 않고 모두가 다같이 열심히 해왔기 때문이지요. 누가 더 잘했고, 누가 더 못했고를 따지기에는 사람과 사람의 역학관계가 너무나 복잡하다는 생각이 들었습니다.
설사 어뷰징이 일어나서 누군가 팀에 폐를 끼쳤다고 해도, 이런 평가 방식 때문은 아니라는 걸 깨달았습니다. 기존의 평가방식이 반년을 돌이켜보며 누구는 잘했으니까 칭찬해주고 누구는 못했으니까 야단치는 식이었다면, 스크럼의 방식은 잘못한 그 시점에 피드백을 주고 잘 할 수 있도록 격려해주는 식입니다. 다시 말해, 잘못하는 것 지켜보다가 나중에 혼내는게 아니라, 바로 지적해주고 올바른 방향으로 이끌어 주는 식입니다. 반년 후에 모두가 칭찬받도록 만드는 방법입니다.
MVP는 좀…
그래서인지 MVP를 뽑는 것은 괜히했다는 생각이 들었습니다. 다들 열심히 했으니 MVP라고 부를만큼 눈에 띄게 공헌한 개발자도 없을뿐더러, 이런 상황에서 도토리 키재기로 1등을 뽑는게 팀웍을 훼손할 수도 있겠다 싶었습니다.
MVP 선출방식을 미리 정해두지 않았다는 점도 큰 실수였습니다. 평가 시즌이 되어서 평가 기준을 바꾸는 건 말이 안되는 일이니까요. 그래도 어찌어찌 논의를 통해서 선출방식을 정하고 투표를 진행했는데, 신기하게도 5명 모두 동률로 1등이 되어서 모두가 MVP가 되는 사상초유(처음 했으니까요-_-;;)의 사태가 발생했습니다. 다행이 큰 출혈없이 MVP 투표를 마감할 수 있었습니다.
역량레벨 조정은 어렵네요
역량레벨은 회사에서 각 개인별 역량을 정의해 놓은 레벨입니다. 회사마다 이름은 달라도 이와 비슷한 시스템이 있어서 연봉 테이블에 영향을 준다던지 하고 있지요.
똑같은 일을 해내더라도 역량레벨이 낮은 사람은 더 높은 평가를 받아야 한다던가, 성과평가가 역량레벨 재조정의 근거자료로 쓰인다던가, 실제 역량에 맞지않는 역량레벨을 가지고 있다던가 하는 복합적인 문제가 있습니다.
제일 참고가 되었던 아티클
Should a ScrumMaster Give Performance Appraisals?http://www.scrumalliance.org/articles/8-should-a-scrummaster-give-performance-appraisals
스크럼 마스터를 대상으로 작성된 글이지만 스크럼의 철학과 기존의 평가 시스템의 충돌을 이해하는데 많은 도움이 되었습니다. 여기서 간단히 내용을 소개하고, 제 견해를 살짝 붙여보겠습니다.
- 스크럼마스터가 피드백을 주는 것은 가능하지만, 평가에 관여해서는 안된다.
- 평가제도는 계층과 직위의 차이를 만든다. 팀의 자기조직화를 막고 스스로 성과를 관리하는 법을 배우는 것을 방해한다.
- (제가 ‘리더’라는 족보에 없는 역할을 수행하면서 받은 느낌과 비슷합니다.)
- (팀원 개인의 자율성과 책임감을 해치는 것 같습니다.)
- 1년에 한 번만 성과에 대해 진지하게 대화한다면 너무 긴 시간동안 문제가 곪게 내버려두는 것이다.
- 팀에 피해를 주는 사람이 있다면 곧바로 얘기하라.
- 나중에 얘기한다면 왜 일찍 말해주지 않았는지 의아해한다. 이는 신뢰를 갉아먹는다.
- 개인 평가에 관여하는 것은 “내가 우리는 팀이라고 말했지만, 사실은 팀의 성취가 아니라 개인 성과를 주시하고 있어.” 라고 말하는 것이다.
- (자신의 성과를 주시하고 있는 사람하고는, 아무래도 편하게 대화하기가 힘들지요.)
- 이는 생산성을 높이고, 팀의 자기조직화를 돕고, 팀의 생활을 개선하는 스크럼마스터의 역할을 손상시킨다.
- 매일매일 퍼포먼스와 행동방식에 대한 피드백을 주라.
- 무엇을 배워야 할지 코치하고, 스스로 생각하고 결정할 수 있도록 코치하라.
- 스크럼마스터와 팀 멤버는 서로의 행동을 잘 알고 있으므로, 스크럼마스터와 팀이 각자에게 피드백을 주면 성과 평가를 할 필요가 없다.
- 사람들은 자신이 어떻게 하는지 알고, 매일 개선하고 있기 때문이다.
- (저도 이부분에 공감하고 있습니다. 평가가 필요없도록 하는 것이 더 훌륭한 일이라는 생각이 드네요.)
- 일은 상호의존적이며 개인의 공헌을 따로 분리하는 것은 불가능하다.
- 스크럼마스터는 팀의 퍼포먼스 개선에 집중하고 있으며, 개인의 성과 평가는 이 초첨에서 멀어지게 한다.
스크럼 초간단 PT
스크럼 책을 처음 읽고 팀에 소개하기 위해서 만들었던 초간단 PT입니다. 조금 꾸질꾸질하지만 참조해주세요~
스크럼 초간단 PThttp://altprog.com/blog/684
가상서버에서 클라이언트 IP 확인하기
문제상황
가상서버에서 블로그를 돌리고 있는데, 클라이언트 IP가 제대로 나오지 않는다. 물리적 서버의 Apache를 거치기 때문에 동일한 IP만 잔뜩 찍히고 있다. 그러다보니 IP 기준으로 댓글을 차단할 수도 없고, 통계 기능도 먹통이다.
X-Forwarded-For
이런 상황을 해결하기 위해 X-Forwarded-For라는 HTTP 헤더가 존재하는데, RFC 표준은 아니지만 거의 표준처럼 쓰이고 있다고 한다. (de facto standard)
X-Forwarded-For: client1, proxy1, proxy2
위와 같은 포멧으로, 클라이언트부터 각 프록시의 IP가 기록되기 때문에 최종 서버가 클라이언트 IP를 확인하는 것이 가능하다는 얘기. 대부분의 프록시 서버와 웹서버에서 지원하고 있다고 한다.
위키피디아 – X-Forwarded-Forhttp://en.wikipedia.org/wiki/X-Forwarded-For
해결 방법
웹 어플리케이션에서 이 헤더를 해석하는 것도 방법이겠지만 이미 아파치 플러그인이 존재하므로 가볍게 설치하면 상황 종료다. 플러그인을 설치하면 아파치 로그에도 실제 클라이언트의 IP가 남기 때문에 유용하다.
mod_rpafhttp://stderr.net/apache/rpaf/
아직 버전은 0.6이지만 내 블로그에서는 문제없이 잘 동작하는 것 같다. 페도라에서의 설치 방법을 요약하면.
# 플러그인 소스코드 받고
wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# 압축풀었다고 가정하고
# 플러그인 빌드에 필요한 패키지를 설치하고
yum install httpd-devel
# 빌드하고 설치하고
apxs -i -c -n mod_rpaf-2.0.so mod-rpaf-2.0.c
# /etc/httpd/conf/httpd.conf에 아래 설정을 추가하면 끝.
# 10.0.0.128은 자신의 프록시 서버 IP에 맞게 수정
LoadModule rpaf_module /etc/httpd/modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 10.0.0.128
RPAFheader X-Forwarded-For
뇌를 자극하는 C++
http://www.yes24.com/24/goods/2122932
6년이나 되어서 조만간 폐간되려나 생각하고 있었는데 7쇄를 인쇄하게 되었다고 한다. 경제도 어려운데 고마운 일이다 ^^
4년전에 개정판이 나온 이후로 아주 오랜만에 오탈자를 검토하느라 책을 한 번 읽어보았다. 부족한 부분이 많이 보인다. 집필 당시보다 3배 가까이 경력이 늘어났으니 그럴만도 하다. 이 부분은 이렇게 하는 것이 좋았을텐데, 라고 몇 군데 메모를 적어봤다.
그래도 최선을 다했음이 느껴진다. 병특이 끝나고 대학 4학년을 보내면서 수업시간, 숙제시간 이외에는 기숙사에 틀어박혀 글을 쓰던 생각이 난다. 마감이 항상 늦어져서 가슴 졸이던 기억이 난다. 시험 전날 새벽에 목덜미를 부여잡고 벼락치기를 하면서 가슴 졸이는 그런 느낌이다.
내가 책을 썼었는지 가끔 까먹기도 하지만, 책을 펼쳐보니 당시의 고민과 진심이 묻어나온다.
풍경사진을 잘 만드는 비결
http://www.yes24.com/24/goods/1814564
이병헌과 김태희가 뛰놀았다던 아키타秋田 여행을 준비하기 위해서 다시 한 번 꺼내 들었다.
친구에게 설명해준다고 생각하고 그곳을 표현하는 데 사용하고 싶은 형용사들을 생각해보라. 위엄이 있는 참나무, 쓸쓸한 등대, 싱그러운 정원, 광활한 평원 등등. 그 다음으로 당신이 표현하기로 결정한 느낌을 강조해 줄 수 있는 방법들을 찾아보라.
p.15
‘그래 형용사를 떠올리는 거야!’라고 다짐하며 여행을 떠났지만 형용사는 무슨. 형용사는 온데간데 없고 노출 맞추느라 급급해하다가 돌아왔다.
우리는 모두 이런 경험을 가지고 있다. 당신은 지금 아름다운 시골길을 따라서 차를 몰고 있다. 멋진 풍경이 나올 때마다 차를 세우고 사진을 찍는다. 당신은 그 사진들이 당신이 보는 장대한 풍경들을 포착해줄 것이라고 확신한다. 그러나 집으로 돌아와서 필름을 현상해보고는…… 실망한다. 이미지들이 너무 밋밋하고 지루하기 때문이다. 그 풍경을 바라볼 당시에 당신을 사로잡았던 모든 요소들은 분명히 빠짐없이 그 이미지에 담겨있다. 그런데 당시의 그 느낌이 없다. 왜 그럴까?
p.10
이건 정말 내 얘기다. ㅎㅎ
우리가 어떤 광경을 볼 때 우리의 눈은 그 장면을 따라서 이리저리 움직이며, 매력을 느끼는 요소들에만 선택적으로 관심을 집중시킨다. 우리의 시야에는 그 장면의 많은 요소들이 포괄되어 있지만, 우리의 눈과 뇌는 가장 매혹적인 디테일들을 제외하고 다른 모든 것들은 무시해 버린다. 그러나 렌즈와 필름은 우리의 눈과 뇌처럼 스스로 선택하고 무시하는 작업을 할 수 없다. 렌즈와 필름은 당신의 도움이 필요하다.
p.10
이 밖에도 세번째 차원이 제거된다던지 소리, 냄새, 공기, 바람의 느낌등과 같은 요소가 제거되기 때문에 현장감을 전달하려면 시각뿐만 아니라 다른 감각들도 환기시킬 필요가 있다는 얘기다. 정말 맞는 말인데 왜 자꾸 까먹을까.
맥미니 서버 구입!
