별로 의미 없는 사진이다. 그냥 사진이 없으면 허전해서... - ㅅ-@

• 좋은 팀장은 투명한 비닐 우산이다. 하늘은 잘 보이되, 빗방울을 잘 막아준다.

• 보통 팀장은 불투명 우산이다. 하늘은 안보이더라도, 비는 맞지 않는다.  

• 안 좋은 팀장은 찢어진 우산이다. 하늘이 찢어진 틈새로 조금씩 보이지만 비에 젖는다.

• 물론, 하늘은 가리면서 빗방울은 아주 잘 투과시켜주는, 도저히 존재할 수도 없고, 존재한다고 해도 아무런 의미를 가지지 못하는 우산 같은 팀장도 있기는 할 것이다. 차라리 그냥 비를 맞는 게 더 좋을 것이다.

• 갑자기 여기에 하나를 추가시고 싶다. 상당히 안 좋은 팀장은 반쯤 찢어진 불투명 우산이 마구 흔들리고, 돌아가는 것이라고. 하늘이 보이기는 하나 온전한 하늘을 보기는 힘들며, 특히 특정 방향만 보이기 때문에 전체를 파악하지 못한다. 물론 비는 맞는다. 여기에 악의가 포함된 "우산 컨트롤 스킬"이 들어간다면 어떻게 될까? 하늘의 일부만 의도적으로 보여준다면? 교묘하게 우산을 돌려, 한 조각 햇살이 비치는 곳만 보이게 한다면 어떤 일이 생길까. 그리고 우산을 교묘하게 돌려, 우산 밑에 있는 여러 사람 중 일부 사람들만 비를 맞게 한다면?

• 물론 최악의 팀장은 위에서 펴진 게 아니라, 사람들 사이에 펴진 우산일 것이다. 사람들을 뿔뿔이 찢어 놓는 것은 조직의 장악력을 높이는 손쉬운 방법이다. 물론 이 것은 눈 가리고 아웅 이고, 진실은 언젠가 밝혀진다. 이쯤 되면 하늘이 보이는 것이라거나, 비에 맞는 것은 신경도 쓰지 않게 될 것은 당연할 것이다.

조금만 부연 설명을 하자면...

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

애자일에 대한 지극히 개인적인 회고 먼저.

  한동안. 애자일에 꽤 열광하던 때가 있었다.

  그게 언제쯤이었냐 하면. T팀에서 B팀으로 옮기고, PM과 디랙터가 없는 팀에서 열심히 해보려던 때였다. 원래 조직, 프로젝트, 스케줄 관리에는 전혀 관심을 가지지 않으려 했으나, 상황은 이러하고, 어찌 되었든 게임을 잘 만들고 싶어서 뭐든 하려고 할 때였다.

  그러나, 뭔가 시도해 보기도 전에 좌절했다. 사람들 (정확히는 관리 성향이 없는 일반 팀원들)이 애자일에 대한 좋지 않은 인식이 생겨 버린 것이다. (아이러니하게도, 김창준님께서 회사에 오셔서 세미나를 한 것이 원인이 되었다. 물론, 김창준님을 비난하려는 것이 아니다. 김창준님의 세미나는 충분히 좋았다. 단지 팀 분위기가 어둡고, 새로운 것을 받아들이는데 매우 부정적이고 까칠하던 상황에 세미나가 열려 버려서, 사람들이 모두 부정적으로 받아들이게 된 것일 뿐.) 애자일은 리더에 의한 방법론이 아니라, 모든 사람들의 마음속에 들어가는 행동 원칙이 되어야 할 텐데... 첫 단추를 끼우기 전부터 좋지 않았다. 뭐 어쨌거나, 도전은 했다. 스탠딩 회의도 해 보고, 나름 상황판도 만들었으나... 역시 결과는 좋지 못했다.

  그 뒤로, 애자일은 쳐다보지도 않았다. 대신 린을 조금 살피다가, 원론적인 전통적인 시스템도 보다가... 그냥 처음처럼 매니징에 신경을 쓰지 않기로 했다.

3Fs : 사실, 느낌, 교훈(Fact, Feeling, Finding)의 세가지 F를 뜻합니다. 예를 들어, "뭐뭐뭐를 해봤다. 그래서 어떤 느낌이 들었다. 그리고 거기에서 어떤 교훈을 얻었다"의 형식을 사용합니다. - 애자일 이야기

다른 분야에서는 이런 것들이 그렇게 새로운 개념이 아니지만 (칭찬일기라던가.. 그런 것 쓸 때도 같은 원칙으로 이와 거~의 유사한 3가지 관점 방법론을 쓴다.) IT분야에 적용시켰다는 점은 무척 멋지다!


감상과 기록들.

• 무척 쉽게 씌여졌으며, 아주 구체적인 방법들이 잘 나와있다. 역시 문제는 적용이겠지. 전반적인 실천은 못하더라도, 상황에 맞게 요소 요소만 따오더라도 도움이 될 수 있어 보인다.
• 이 책의 저자는 회고계의 여신 2분이다. 칭호에서도 나왔지만 여성분이다. 역시 이런 일에는 여성이 좋구나... 라는 생각을 다시 한번 하게 되었다. 고누소프트 시절, 이PM님이 생각난다.
• Facilitator : 회의의 진행자 이상의, 촉진자가 되어야 한다. 모든 사람의 참여를 유도하려면.
• Check-in : 회의에 들어가기 전에, 간단히 모든 사람에게 말을 거는 것. 누구나 대답할 수 있는 질문을 던진다. 마음을 열 수 있게 만들면 더 좋지만, 감정을 이야기 하는 것이 서툰 개발자들을 대상으로 할 때는 우회적으로 질문한다. 꼭 대답을 하는 게 중요하다. 회의 초반에 말을 하지 않으면, 끝날 때까지 말을 하지 않을 가능성이 크다.
• 감사하기 활동. 서로에게 감사하는 말을 해라. 관계의 질이 달라질 것이다.
• Make it so. 스타트랙을 한번 봐야겠다.

중요한 것은 역시 사람이다.
닫힌 마음을 열어 주는 것 만으로도 멋진 일이 생길 수 있으리라 생각한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

waterfall개발 방법론에 한계를 느끼고, 새로운 개발 방법론을 찾던 중 눈에 들어온 Agile.
예전에 관심을 가졌으나, 자료가 부실하여 그만 둔 적이 있었습니다. 그때는 실험적인 개발 방법론으로만 보였고 실제 사례도 거의 없었으니까요.
하지만 최근에는 다양한 문서(국내 번역 문서도!)가 존재하며, 국내에서도 개발에 적용하는 사례가 있다고 합니다. 현재 다양한 자료를 훑어보며, 현재 프로젝트에도 적용할 수 있을까를 고심해 보고 있습니다.

애자일이란 어떤 것인가? 다음 개발 선언문을 보면 그 핵심이 무엇인가 알 수 있습니다.

애자일 게임 개발 선언문
(Manifesto for Agile Game Development)

우리는 다음의 것들을 가치있게 여긴다;

공정과 프로젝트 관리 도구보다, 사람들과 의사소통을 더 중요시한다.

완전한 기획 문서보다, 제대로 작동하는 게임을 더 중요시한다.

마일스톤의 정의보다, 배급사와의 협력을 더 중요시한다.

계획을 따르는 것보다, 변화에 대응하는 것을 더 중요시한다.

다시 말해서, 왼쪽에 있는 것들이 비록 가치있긴 하지만,

우리는 오른쪽에 있는 것들에 더 큰 가치를 둔다는 것이다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.