2장. 팀#5
#2-4 유지보수팀의 애자일(칸반)
#2-4 유지보수팀의 애자일(칸반)
앞서 필자가 했던 다양한 시도들은 여러 형태로 본사에 보고되었다. 그리고 다양한 SI 프로젝트에 애자일이라는 것이 조금씩 알려지게 된다. 그러면서, 이곳저곳에서 애자일을 적용해보겠다는 프로젝트 관리자들에게 연락을 받게 되었는데, 가장 먼저 연락 온 곳은 어떤 유지보수 팀이었다.
해당 프로젝트에 가서 필자의 프로젝트에서 어떻게 진행했는지를 설명했다. 그런데, 유지보수 프로젝트는 내가 진행했던 개발 프로젝트와는 매우 달랐다. 이터레이션을 기준으로 개발할 수 있는 상황이 아니었다. 하루에도 4~5건의 고객으로부터의 전화가 오고 당장 해달라는 요구사항이 빗발쳤다. '2주 단위로 개발하고 그 내용에 대해 고객에게 시연을 한다'는 것은 현실과 맞지 않았다.
* 칸반이란 무엇인가?
다른 방법이 필요했다. 열심히 인터넷을 검색하여 칸반(Kanban)이라는 프로세스에 대해 찾았다. 애자일 코치인 헨리 크니버그(Henry Kniberg)는 다음과 같이 칸반을 설명했다.
[헨리 크니버그 애자일 + 칸반 설명]“과거 내가 일본에 관광을 갔을 때 일이다. 어떤 신사에 갔었는데, 그 신사에서 특이한 경험을 했다. 신사에 입장하는데, 내게 나무로 된 패를 주는 것이었다. 그 패에는 348이라는 숫자가 새겨져 있었다. 이 패가 뭔지를 물었더니, 신사에서 나올 때 다시 제출해야 한다는 것이었다.
나는 이 패가 무엇인지 더욱 궁금해졌다. 모든 사람에게 나누어주고, 다시 수거하는 이유가 무엇일까. 나중에 그 이유를 듣고 나는 칸반의 완벽한 개념과 일치한다는 생각이 들었다.
이 신사는 매일 아침 1000개의 나무 패를 준비해 놓는다. 그리고 이곳에 다녀간 사람에게 이 패를 돌려받는다. 그리고 1000개가 분출이 되면 더 이상 방문객을 받지 않는다.
이는 신사가, 신성하고 고요한 절로서의 기능을 온전히 수행하기 위해 1000명 이상의 인원을 받지 않는 것을 의미한다. 그러니까 절에 돌아다니는 인원을 1000명으로 제한하는 것이다. 이것을 WIP(Work in Progress) 관리라고 한다. 칸반에서 가장 중요한 것은 온전한 기능을 수행하기 위해 WIP를 관리하는 것이다.”
팀이 칸반을 활용한다는 의미는 모두가 볼 수 있는 현황판을 놓고, WIP를 보면서 병목이 되는 곳을 찾고 이 병목을 해소하는 활동을 말한다.
유지보수팀은 특성상 보통 업무 별로 인력이 할당되기 때문에, 업무에 바쁜 시기가 있는 경우 시기에 따라 바쁜 사람과 바쁘지 않은 사람으로 나뉘게 된다. 이 경우 바쁜 인력을 바쁘지 않은 인력이 돕게 되면, 일의 흐름이 빨라져, 전체적으로 일을 해결하는 팀의 리드타임(Lead Time)이 빨라진다.
나는 이 팀에 칸반 보드를 만들고 칸반 프로세스를 적용해 보았다. 팀원들 대부분이 시기적 업무량의 불균등에 대해 고민하고 있었던 상황이었고, 관리자의 스폰서십도 좋은 이유가 되어 필요성을 설득하는데 어렵지는 않았다.
[유지보수 프로젝트에서 적용해본 칸반 그림]
* 첫 칸반 프로세스 수행
먼저, 대시보드를 만들었다. 코르크 보드를 한쪽 벽면에 크게 붙였다. 색 테이프를 이용하여 구간을 표시했다. 관리자가 팀원들에게 억지로 업무를 강요하는 스타일은 아니었지만 최대한 팀이 자발적으로 선택하여 적용한다는 느낌을 주고 싶어, 관리자에게는 이 보드를 보고 업무 지시하는 것을 최대한 자제해달라고 말했다.
일단 보드를 붙이는 것만으로도 관리자와 고객은 좋아했다. 전시효과가 있었다. 이 보드는 정적인 유지보수 조직에 무엇인가 돌아가고 있다는 모습을 효과적으로 보여줄 수 있었다. (사실 당시 보드의 가독성은 그다지 좋지 않았다.)
코르크 보드에 세로축에 팀원의 이름을 각각 넣고, 한 명 당 5개의 업무 슬롯을 주었다. 그리고, 고객의 요구사항이 시스템으로 들어오면 포스트잇에 해당 요구사항의 내용과 번호를 간단히 적고 백로그 부분에 올려놓았다.
그리고, 개인당 가진 슬롯의 개수(5개)까지만 포스트잇으로 적힌 일을 가져가고, 이것이 넘치는 경우, 다른 사람이 자신의 업무가 아니더라도 도울 수 있도록 합의했다. 모든 사람의 슬롯이 다 찬 경우에는 관리자에게 현재 프로젝트가 감당할 수 없는 정도의 일이 들어오고 있다고 이야기했다. 관리자는 이 상황에 대해 매우 현실적인 의사결정을 했다.
모두의 일이 최대치에 다다랐을 때는, 팀원 모두에게 “저녁 8시까지 이 문제를 오늘 해결하자. 저녁은 내가 쏜다.” 라며 팀원들을 북돋아주거나 또는 고객에게 가서 “우리 정말 너무 힘들다. (칸반 보드를 보여주며) 저거 봐라 우리 개발자들 너무 고생한다. 웬만한 요구사항은 우리에게 넘기지 말고 너희가 좀 알아서 처리해줘라”라는 식으로 고객의 공감을 받아 프로젝트의 일을 줄이기 위해 노력했다.
[칸반 보드 예제(당시 필자의 작업 내용)]이 보드를 사용하는 동안, 2주에 한 번씩 회고를 진행했다. 한 달 정도 지났을까, 팀원 중 한 명이 회고 중 다음과 같은 의견을 제시했다.
“우리가 테스트를 너무 개인의 역량에 의존하는 것 같아요. 뭔가 서로 테스트를 해주면 전체적인 결함을 더 줄일 수 있지 않을까요?”
그들은 액션 아이템을 통해 어떻게 하면, 효과적으로 테스트를 할 수 있을까를 이야기했고, 그들 스스로 ‘테스트 매니저’라는 역할자를 만들어 냈다. 당시 화요일과 목요일에 정기 배포 작업이 있었는데, 이 전에 배포할 모든 기능에 대해 담당 테스트 매니저가 한 번씩 제삼자의 눈으로 확인하기로 했다. 매주 돌아가며 ‘테스트 매니저’의 역할을 담당했는데, 이때는 두 개의 슬롯을 줄여 주는 방법으로 테스트로 인한 공수를 분산시켰다.
[칸반 보드에 테스트 매니저 활용 사례 그림]가끔 필자는 이런 이야기를 듣는다.
'이터레이션이 없는 칸반이 과연 애자일인가?'
1장에서 필자가 내린 애자일은 지속적인 개선을 하는 팀이다. 칸반은 팀이 하루 단위의 이터레이션을 진행하여 지속적인 개선을 하도록 돕는 프로세스이다. 따라서 칸반도 애자일의 한 프로세스이다.
