다시 스크럼을 고민해 보려고 한다.

NHN에서 받은 마지막 YES24 쿠폰으로 책을 4권 샀다.

여러 곳에서 최고의 프로그래밍 책으로 뽑힌 ‘Alice’s adventures in Wonderland & Through the Looking-glass’를 읽으면 나는 무엇을 볼 수 있을까? 아마도 언어의 제약을 뛰어넘는 언어의 사용을 통한 상상력을 볼 수 있어야 할텐데 외국어의 한계로 겉만 핥는 것은 아닐지…

그 외에 ‘이기적인 유전자’를 읽고 다시 찾은 또 하나의 진화론에 관한 책 ‘풀하우스’, ‘엘러건트 유니버스’ 이후의 이야기를 쓴 ‘우주의 구조’, 그리고 최근에 번역된 또 하나의 애자일 시리즈 ‘스크럼‘을 샀다.

아직 책을 읽지는 않았지만 스크럼에 읽고 적용해 보고 싶은 것이 있어서 이 글을 쓰게 되었다. (물론 스크럼을 적용하는 것이 목적이여서는 안되고 프로젝트의 성공을 위해 팀에 맞는 방법을 사용하는 것이 중요하다.) 스크럼은 ‘일일 스탠딩 회의’, ‘번다운 차트’, ‘짧은 반복 주기’ 등 그 원리는 단순하지만 이를 적용하려는 조직의 특성에 맞춰 새롭게 적용 방법을 고민해야 한다.

그렇다면 결국 현재의 조직의 특징을 파악해야 하는데, 내가 한달 동안 경험한 B 파트의 모습은 다음과 같다.

• PP(페어 코딩?)는 아니지만 페어 작업을 선호한다. 매우 유연한 또는 덜 엄격한 PP
• 매일 아침 그날 할 일을 계획한다. TASK 형태로 할 일과 예상 작업 시간을 포스트 잇에 정리한다.
• TO DO, DOING, DONE, QUEUE, SOMEDAY 로 나눠진 커다란 화이트 보드를 사용한다.
• 프로젝트 구성원, 파트원, 관련자(기획자)와 자주, 많이 의사소통한다. (메신져, 미팅 등)
• 중요한 안건은 아이디어 회의를 통해 결정한다. 결정은 유연한 편이다. (외부 조직의 압력이 적다.)
• 당직 제도를 통해 상시적 업무는 매주 돌아가면서 처리한다. (context switching 비용이 적다.)

전체적인 느낌은 ‘열린 사고’, ‘커뮤니케이션’을 중시하고 ‘협업’의 이점을 잘 살리고 있다는 것이다. 하지만 개인적으로 이전에 애자일 방법론을 도입하면서 항상 부딪혔던 ‘타성화’의 문제라던가 열린 커뮤니케이션의 노이즈 같은 문제를 개선할 필요는 있을 것 같다. 즉, PP를 하면서 서로 배우는 것이 없다거나, 일일 스탠딩 회의가 친목 활동과 혼재되는 경우라 하겠다.

그래서 스크럼을 통해 다시 한번 간단한 규칙을 통해 팀 효율화를 크게 향상시킬 수 있는 방법을 찾아보고자 한다. 그리고 이 방법을 통해 ‘웹 개발’ 직군이 지향해야 하는 모습을 그려 보고자 한다. (이전에 ‘미들웨어’에 관한 글을 썼었는데, 웹 개발은 UI 개발과 인프라, QA, 모듈화(OSGi) 등을 통해 세분화되고 전문화되고 있다. 그렇다면 ‘코어 웹 개발자의 역할’은 무엇일까? 이에 대해서는 다음에 다시 정리해 보면 좋을 것 같다.)