한때, 애자일에 심취하여 '애자일' 이란 용어가 들어간 책들은 모두 찾아 읽었던 적이 있었다. 지금 생각해보면 그 때가 나름 열정을 가지고 업무에 대해 효과적으로 성과를 내기위한 여러가지 시도를 했던 것 같다.
하지만, 소위 소프트웨어 공학 관련 책들은 자기 개발서와 같아서 읽으면 읽을 수록 공허감이 켜져만 갔다.
책에서 말하는 개발방식을 실제 업무에서 적용하기란 “이 책을 읽는 당신부터 실천해 보세요!” 란 말로는 충분한 동기부여가 되지 않았다.
회사(사회)생활을 해오면서, 드는 생각은 한 회사의 분위기, 개발방식을 바꾼다는 것은 사장이 바뀌어야 할 만큼의 어려운 일이라는 것이다. 이러한 생각이 확신으로 바뀌면서 더 이상 이러한 부류의 책을 읽는 다는 것이 큰 의미가 없다는 느낌이 들었다.
그럼에도 불구하고 이 책을 읽게된 이유는 크게 두 가지다.
책의 내용을 3가지로 요약하자면,
마지막 부분이 가장 기억에 남았다. 지금껏 알고 있던 여타 다른 방식들과는 달리, 각 단계별로 동시에 처리할 수 있는 작업의 갯수를 제한하여, 이를 수행하는 팀이 현재 작업에 몰두할 수 있도록 도와주고, 오버헤드가 걸리지 않도록 해주는 개념이다.
물론 WIP 의 제한을 정하는 과정과 이후 제한 이상의 요구가 들어왔을 때, 이를 어떻게 할 것인가에 대한 여부가 훨씬 중요하긴 하지만 말이다. 모든 개발 방식의 목표가 결국에는 사람답게 일하자는 것이 아니겠는가.
어쨋든 다른 여타 책들에 비해 적은 분량에도 불구하고 저자들이 말하고자 하는 바를 쉽게 이해할 수 있어서 좋았다.
스크럼 | 칸반 |
---|---|
기간이 고정된 이터레이션을 규정한다 | 기간이 고정된 이터레이션은 선택 사항이다. 계획하기와 출시, 공정 개선을 위한 리듬(주기)을 개별적으로 가질 수 있다. 고정된 기간이 아닌 이벤트 중심으로 운영할 수 있다 |
팀이 이번 이터레이션에서 할 일의 양을 결정, 약속(commitment)한다 | 약속은 선택 사항이다 |
계획하기와 공정 개선에 속도를 기본 지표로 사용한다 | 계획하기와 공정 개선에 리드 타임을 기본 지표로 사용한다 |
교차 기능 팀을 규정한다 | 교차 기능 팀은 선택 사항이다. 전문가 팀도 허용한다 |
아이템들을 한 스프린트 안에 완료될 수 있을 정도의 크기로 잘게 쪼개야만 한다 | 아이템 크기를 특별히 규정하지 않는다 |
번다운 차트를 규정한다 | 특별히 차트 사용을 규정하지 않는다 |
WIP 리밋을 간접적으로 한다(스프린트 마다) | WIP 리밋을 직접적으로 한다(작업 흐름 단계마다) |
추정을 하도록 규정한다 | 추정은 선택사항이다 |
이터레이션이 진행 중일 때는 아이템을 추가할 수 없다 | 수용 능력이 허용한다면 새로운 아이템을 추가할 수 있다 |
스프린트 백로그는 특정 팀이 소유한다 | 칸반 보드는 다수의 팀이나 개인들 간에 공유하기도 한다 |
세 가지 역할을 규정한다(제품 책임자, 스크럼 마스터, 팀) | 어떠한 역할도 규정하지 않는다 |
이터레이션마다 스크럼 보드를 초기화한다 | 칸반 보드는 계속 유지한다 |
제품 백로그에 우선순위를 매길 것을 규정한다 | 우선순위 매기기는 선택 사항이다 |