Kanban 도입

• 어디나 마찬가지 이겠지만 IT쪽 일을 하다 보면 인력은 필요한 때에 충원되지 않고, 일은 밀려 오고, 요구 사항은 계속 변경되는 경우가 일상적인 상태일 것이다. 인력이 충원된다 하더라도 일이 많아 그 인력을 제데로 활용할 수 없는 경우가 대부분이다.

• 파트구성은 나 포함 7명이고 파트장으로 개발 생산성을 더 높이고 좀 더 파트원들과 즐겁게 일하고 싶었다. 그러나 파트원들의 기술 스택 깊이와 성격까지 모두 제각각이었고, Embedded Client 개발자로 구성된 인원들이 서버 개발과 AWS 구축 및 운영을 해야 하는 업무라 기술 스택이 완전 다른 신세계였다.

• 개발 방법론 중 좋다고 하는 Scrum을 도입해 보았지만, Scrum Master, Production Owner, Iteration, 추정 등 이전 방법론에 비해서 간략화 되었다고는 하지만 이마저도 제데로 갖추어서 진행하기 쉽지 않았다. 그래도 무식하게 해 용기를 내어 파트내에서 할 수 있는 건 다 해보자는 각오로 임하였지만, 내부 내구성이 갖추어져 있지 않은 상태에서 외부 요구 사항은 자주 변경되어 Sprint 기간 동안 격리되어야 할 작업 우선 순위 및 작업항목은 수시로 변경되어 절름발이 Srum을 진행 할 수 밖에 없었다.

• 또한 내부적으로 추정이 정말 어려웠다. 내/외부확인 요구 사항을 해결하기 위한 솔루션을 단번에 선택하여 추정하기가 쉽지 않았으며, 당장은 어렵더라도 진행하다 보면 내부적인 강구책이 자연스럽게 생길거라는 막연한 확신을 가지고 진행해 보았지만, 매번 크게 빗나가는 추정의 반복이었고, 작업 계획에 대한 스트레스와 파트원들의 불만만 증가 되는 상태였다.

• 그러던 중 Scrum보다는 유연하다고 하는 Kanban을 알게 되었고, 이것을 2015년도 초에 파트내에 도입을 하였다.
  처음 도입시에는 Scrum보다 꽤 유연하다고 생각하였고(물론 추정은 그데로 였지만), 대표적으로 WIP만 제약하여 관리하면 Scrum비해서 스트레스 받지 않고 관리 할 수 있을 거 같았다.