그리하여 해당 프로젝트의 칸반을 하기와 은 형식의 칸반 보드로 진행하였다. SW release에 포함되는 변경점, 이슈들의 양이 많아 화이트 보드로 진행하기에는 힘들어 excel로 칸반 보드를 만들고 진행하였다.
| Parking List | 9월 28일 | 9월 29일 | |
| 찌롱 | 퇴근하기 | ||
| 아기 목욕 시키기 | |||
| 집 청소 | |||
| 마나님 | 장보기 | ||
| 이유식 만들기 |
칸반 보드의 사용법은 하기와 같다.
1. PM (Project Manager)은 이번 SW release에서 각 개발자가 해야 할 일 (구현해야 할 기능, bug fix 등)을 Parking List (Back log)에 우선순위를 정하여 기입
2. 각 개발자는 매일 해당 칸반 보드에 현재 진행되는 일의 상태를 update 함
3. 일의 상태는 SW 개발에 맞도록 세분화되어 있음 (In analysis, analyzied, in implementation, blocked.. 등등)
4. 현재 진행 중인 일을 완료해야만 Parking list에서 새로운 일을 가져올 수 있음
- 칸반 회의는 매일 아침 모여, 칸반 보드에 자신의 진행 상태를 update 하는 것으로 진행
- 칸반 회의 참석자는 해당 프로젝트의 SW PM과 SW 개발자들
뭔가 그럴듯 해 보인다. 관리가 잘 될 것 같은 느낌적인 느낌이 든다!
하지만 몇 개월이 지난 지금은 위에서 하라니깐 어쩔 수 없이 기계적으로 하고 있다. 칸반에 들어오는 사람들의 눈에 어떤 긍정적인 기운도 느껴지지 않는다. 칸반을 위한 칸반... 이 말이 딱인 듯 싶다. 도구가 목적이 되어 버렸다.
칸반 활동을 하면서 마주한 문제점은 몇가지가 있다.
1. 매일 아침하는 칸반 회의가 길어질 때가 많다. 심지어는 1시간이 넘어갈 때도 있었다.
=> 현재는 되도록 질의 사항이 있을 경우는 칸반 회의가 끝난 후 PM이 담당자에게 따로 문의하도록 하고 있다.
2. 매일 하는 칸반 회의가 PM에게 하는 일일 업무 보고 그 이상도, 그 이하도 아니라는 생각이 든다.
=> 칸반 daily meeting에 참석하는 의미와 동기가 개발자에게 너무 부족하다.
3. 각 개발자들의 담당 기능이 서로 독립적이고 분화되어 있는 편이어서, 나와 다른 기능을 맡고 있는 개발자가 문제를 공유해도 아! 그런 문제가 있구나! 라고 정도만 생각되지 실질적으로 도움 주기가 어렵다.
4. 1명의 개발자가 보통 여러개의 프로젝트를 동시에 수행하는데, 칸반 회의는 프로젝트 별로 진행한다. 그것도 매일.... 프로젝트가 많아질 수록 그에 비례하여 매일 참여해야 하는 칸반 회의 횟수와 시간도 늘어난다. 하루의 반을 칸반 회의로 소비할 때도 있다.
=> 현재는 프로젝트 칸반 회의 진행 시, 해당 참여 개발자들이 모두 모이도록 하고 있지 않다. 같은 기능을 담당하고 있는 개발자 중에서 해당 프로젝트 담당자를 따로 정하여 해당 대표 담당자만 참여하도록 하고 있다.
5. 칸반을 한다고 해서 SW의 버그가 줄어드는 것은 아니더라.... 물론 개발 툴, 개발 방법론이 버그를 줄여주는 역할을 하는 건 아니지만.... SW 개발 시, 대부분의 낭비 비용이 디버깅이라고 볼 때, 결국 최종적으로는 SW delivery가 그닥 좋아지는 것도 아닌 것 같다. 옆에서 고군분투하는 PM이 안쓰럽더라...
6. 최근에 새로 시작한 프로젝트는 베이스 프로젝트에서 약간의 변형만 가한 프로젝트이다. 사실 변경점이 거의 없고, 변경점도 열손가락 안에 든다. 이런 프로젝트를 굳이 칸반을 해야 하는지에 대해서 의문이다. 앞서 말했듯이 프로젝트 별로 칸반을 하다보니, 여러 프로젝트에 투입되는 개발자의 경우 하루에도 몇번씩 칸반 daily meeting에 참석하고 있다.
8. 칸반 daily meeting을 꼭 해야하는가?
현재 칸반 meeting의 참석자는 같은 SW 팀, 같은 공간 안에 있는 사람들이다. 테스트 중에 문제가 나오면 바로 SW PM에게 리포트 하고, 다른 기능과 연관이 있으면 바로 가서 말해주기 때문에 평소에도 팀원 간의 커뮤니케이션은 활발한 편이다.
그런데 굳이 칸반 meeting을 프로젝트 별로, 그것도 매일 할 필요가 있는가? 개발자가 개발할 시간도 없는데 하루에 2,3번씩 칸반 회의를 하면서?
다른 부서의 프로젝트 칸반 meeting의 경우, 참석자를 보면 HW, SW, 기구, PM, SE 등등 여러 부서의 참석자들이 모여서 하는 경우가 있다. 그런 경우에는 참석자들이 각각 다른 공간에서 일을 하므로 평소 커뮤니케이션이 어렵고, 서로 업무 간의 dependency가 크게 존재하고 있기 때문에,daily meeting이 의미가 있어 보인다. (HW sample이 나와야 SW 개발이 진행될 수 있거나, SW release가 되어야 SE에서 테스트를 할 수 있거나)
몇 개월간 칸반을 진행하였는데 현재 상태는, 결국 개발을 효율적으로 하기 위한 툴로서 칸반을 사용하는게 아니라 칸반이 목적이 되어버린 상황인 것 같다. 좀 더 효율적으로 활용할 수 있는 방안을 생각해야 할 것 같다. 하기 Dilbert가 나의 마음을 대변해 준다.
 |
<일을 진행하기 위한 계획이 아닌, 계획을 위한 계획....>
|
1. 나는 우리 소프트웨어를 변경하는데 얼마나 리소스가 필요한지에 대한 프로젝트 "계획서"가 필요하네.
2. 그 소프트웨어 수정은 10초면 됩니다. 다 됐습니다.3. 좋아 잘 했어. 이제 우리에게 필요한 건 방금 자네가 한 일에 대한 "계획서"네.
블로그 내 관련글
1. 칸반 (Kanban) (2) - 진행 중인 업무량 제한
2. 칸반 (Kanban) (3) - 지속적 개선과 여유 시간
0 개의 댓글:
댓글 쓰기