칸반 캔버스 2.0

3년 전에 나는 영국의 칸반 전문가 칼 스코틀랜드가 Kanban Canvas를 처음으로 공개했을 때, 곧바로 한글 버전을 만들었었다. (칸반 캔버스 1.0 한글판)

그런데, 칼에게 며칠 전 워크숍에서 실제로 적용해보면서 나온 몇몇 개선 사항을 추가한 2.0 버전이 공개되었으니 업데이트를 부탁한다는 메일이 왔고, 오늘 아침에는 블로그에 Kanban Canvas 2.0을 알리는 포스팅이 올라왔다. 포스팅 말미에 “The French translation is also already available, and I hope to be able to update the other translations soon.”라는 글을 보니, 한글 버전도 더 이상 늦장부리지 말고 얼른 업데이트를 해야겠다는 생각이 들었다.

살펴보니 크게 바뀐 부분은 별로 없다. 레이아웃이 좀 더 단순하게 바뀌었고 (특히 “영향” 부분), 문구가 몇 군데 바뀐 정도다.

ko_Kanban Canvas v2-0

칸반 캔버스 2.0 다운로드 (PDF)


칸반 캔버스 사용자 가이드

칸반 캔버스는 그룹이 함께 칸반 시스템을 협력적으로 설계할 수 있도록 돕는 도구이다. 그룹을 개방 시스템으로 바라보는 관점이 중요한데, 칸반 캔버스를 활용해서 함께 칸반 시스템을 설계하다 보면 시스템이 어떻게 설계되어 있는지 그리고 그렇게 설계되어 있는 이유는 무엇인지에 대한 이유를 공유할 수 있게 된다.

시스템(System)

제일 먼저 시스템의 범위와 목적을 이해하면서 시작한다.

(1) 시스템의 중요 인물, 문제, 불만, 경계, 인터페이스 등을 찾아본다. 워크숍 참가자들에게 지금까지 있었던 자신의 이야기를 하도록 하고, 왜 칸반 시스템을 설계하는 워크숍에 함께 앉아있는지에 대해 설명하도록 한다. (결과물: 시스템의 필수 요소와 상호작용을 담고 있는 간단한 서술)

 

영향(Impacts)

그 다음으로는 우리가 만들고자 하는 변화가 시스템을 개선시키는지 악화시키는지 평가할 수 있어야 한다.

(2) 바라는 엔딩은 무엇인지, 그리고 피하고 싶은 엔딩은 무엇인지를 다양한 방법으로 탐색해본다. 워크숍 참가자들이 다양한 관점에서 바라볼 수 있도록 흐름(Flow), 가치(Value), 가능성(Potential)이라는 세 가지 측면을 활용해서, 극단적으로 행복한 엔딩(유토피아)과 극단적으로 불행한 엔딩(디스토피아)를 상상해보라고 요청한다. (결과물: 한 가지 이야기에 흐름, 가치, 가능성 모두 관련이 있을 수 있다. 삼각형의 가장 적절한 위치에 배치한다. 유토피아는 초록색 포스트잇, 디스토피아는 빨간색 포스트잇을 사용하면 좋다.)

 

개입(Interventions)

이제 가까운 과거와 바람직한 미래에 대해 충분히 이해하게 되었으니, 긍정적 영향을 줄 수 있는 개입이 시스템과 어떻게 상호작용할 수 있는지 살펴볼 차례이다.

(3) 효과적인 변화를 만들 수 있는 방법을 진정으로 이해하려면,우선 맥락을 학습(Study)할 필요가 있다. 우리가 학습해야 하는 세 가지 영역은 다음과 같다. 고객 또는 이해관계자, 그들로부터 오는 업무 요구, 그 요구가 처리되는 방법. 대개는 어떤 요구가 들어오는지 살펴보는 것으로 시작한다. 그런 다음 그 업무가 어디로부터 오는지, 그리고 정보의 흐름과 그 업무들이 처리되는 방법에 대해 탐색해본다. (결과물: 고객/이해관계자의 욕구, 요구의 분류 또는 서비스 클래스, 주요 업무의 상태 흐름 또는 변화에 대한 요약)

(4) 현재 맥락에 대한 공통의 이해를 갖추고 있다면, 그 지식을 칸반 보드 위에 시각화하여 공유(Share)할 수 있다. 워크숍 참가자들에게 어떤 정보가 공유하기에 가장 적합하며 중요한지에 대해 논의해달라고 요청한다. 그런 다음 칸반 보드 설계 패턴을 소개하고 그룹은 중요한 정보에 대한 시각화 방안을 도출한다. (결과물: 시각화해야 할 중요한 각 정보와 사용할 시각화 기법의 매핑)

(5) 그 다음 단계는 명시적 정책을 통해 현재 시스템을 안정화(Stabilise)시키는 것이다. 지나치게 견고하고 고정되어 있는 경계는 융통성 없는 관료주의로 흐를 것이며, 지나치게 느슨한 경계는 혼돈으로 흐를 것이다. 핵심 정책으로 WiP 제한을 도입하고 설정하는 다양한 전략과 기법을 소개한다. 그런 다음 워크숍 참가자들은 업무가 보드를 가로질러 진행되는 방법과 시점을 합의하는 간단한 품질 체크리스트를 브레인스토밍한다. 이러한 간단한 표준 업무 정의가 나중에는 개선을 위한 출발선이 된다. (결과물: 기본 WiP 제한 전략, 할당, 보드 상의 초기 진입/완료 기준에 대한 결정)

(6) 시스템이 정상 궤도에 오르고 점차 발전해가면서 시스템의 목적 적합성을 평가하려면 시스템의 수용량을 감지(Sense)할 수 있는 방법이 필요하다. 이를 위한 두 가지 주요 수단이 바로 측정과 회의이다. 워크숍 참가자들은 먼저 긍정적인 영향을 주고 싶은 결과(생산성, 신뢰, 반응성, 품질, 고객 만족, 직원 참여 등)를 결정한다. 예상되는 행동과 결과, 그리고 다른 결과와의 트레이드 오프 가능성을 고려하여, 이 결과로부터 지표를 논의하고 결정한다. 그런 다음 수용량과 진척도를 평가할 수 있는 지속적인 회의와 그 케이던스를 결정한다. (결과물: 간단한 지표 정의, 회의 및 회고 케이던스 리스트)

(7) 마지막으로 다른 설계 대안을 탐색(Search)함으로써 시스템의 진화 가능성을 살펴본다. 지금까지 논의한 모든 것을 감안해서, 그룹은 변화에 맞추어 실행할 수 있는 작은 실험을 정의한다. 각 실험은 가설, 근거, 검증을 위한 측정, 안정성 및 가역성 보장 메커니즘 등을 갖추고 있어야 한다. (결과물: 실행 가능하고 간단한 실험 정의)

이 모든 과정이 매우 협력적인 방식으로 이루어지며, 모두가 기여하고 다양한 의견을 주고 받으며 합의에 도달할 수 있도록 다양한 퍼실리테이션 기법을 사용한다. 이 워크숍을 마치고 나면 완성된 캔버스를 기반으로 자신들의 칸반 시스템을 학습하고 발전시키고 개선할 수 있게 된다.

 

NBT(캐시슬라이드) “서비스 기획자” 및 “애자일 코치” 채용

캐시슬라이드를 개발하고 서비스하고 있는 NBT에서 채용을 진행 중에 있습니다.

궁금한 점이 있거나, 관심이 있거나, 추천하고 싶은 분이 있는 분은 언제든지 cho.seungbin@nbt.com 으로 연락주세요!

서비스 기획 및 프로젝트 관리

  1. 미션
    • 좋은 제품을 만들기 위해 아이디어를 구체화하고 함께 실현시킵니다. NBT의 이매지니어 클래스는 제품 개발 조직이 고객에게 훌륭한 가치를 전달하고 실질적 성과를 얻을 수 있도록 다양한 활동을 수행하고 있습니다.
  2. 업무 내용
    • 서비스 기획
      • 캐시슬라이드 모바일 앱의 신규 및 개선 과제를 기획합니다.
      • 서비스 및 운영툴 설계합니다
      • 지표를 설정하고 성과 데이터를 분석합니다.
    • Product Management
      • 담당 서비스에 대한 Market Sensing 및 과제 검토를 수행합니다.
      • 업무 우선순위를 조정하고 이슈를 해결합니다.
      • 과제가 성공적으로 수행될 수 있도록 적극적으로 실행하고 분석합니다.
  3. 핵심 역량
    • 관련 업무 경력 (서비스 기획/UX/Product Manager) 3년 이상
    • 모바일 웹/앱 서비스의 기획 및 출시, 운영에 대한 경험과 높은 이해
    • 리서치 및 데이터 분석에 기반한 탄탄한 문제 해결 능력
    • 비즈니스/운영/마케팅 등 협업 부서와 슬기롭게 커뮤니케이션 할 수 있는 능력
    • 새로운 업무 방식에 주저하지 않고 투명하게 공유하는 것을 즐기는 성격
  4. 우대 사항
    • 모바일 광고 서비스 경험
    • 엑셀, R 등 데이터 분석 툴의 능숙한 활용
    • Lean, Agile, Scrum, Kanban 등에 대한 깊은 관심 또는 경험

린/애자일 코치

  1. 미션
    • NBT만의 훌륭한 개발 문화가 매일매일 성장할 수 있는 환경을 누구보다 먼저 고민합니다. NBT의 엔지니어링 컬처 클래스는 제품 개발 조직이 더 효과적으로 공동의 목표를 달성하고 실질적 성과를 얻을 수 있도록 다양한 활동을 수행하고 있습니다.
  2. 업무 내용
    • 제품 개발 프로세스를 지속적으로 개선합니다.
    • 수평적 리더십을 발휘하여 팀이 스스로 더 나은 방향으로 변화할 수 있도록 돕습니다.
    • 일일 스탠드업 회의, 주간 회고 등 NBT 제품 개발 조직에서 수행하는 다양한 모임에서 퍼실리테이터 역할을 담당합니다.
    • NBT에서 개발하고 운영하는 제품의 품질을 개선하고 유지할 수 있는 각종 프랙티스를 발굴하고 조직에 도입합니다.
    • 제품 개발 생산성을 객관적으로 파악할 수 있는 각종 정량 지표를 설계하고, 측정하고, 관리합니다.
    • 품질 기준을 수립하고 각종 품질 관련 활동을 직접 실행하거나 지원합니다.
  3. 핵심 역량
    • 더 나은 개발 문화에 대한 강력한 비전과 열망
    • 자신의 성장 뿐만 아니라 주변 사람들의 성장에 대한 깊은 관심
    • 소프트웨어 엔지니어링 전반의 품질 활동에 대한 이해
    • 변화를 주도하고 그 변화를 실질적 성과로 연결시킬 수 있는 실행력
  4. 우대 사항
    • 린/애자일 철학에 대한 깊은 이해와 경험
    • 조직 내에서 발생하는 다양한 역동에 대한 이해
    • 개발팀에서 칸반/스크럼/XP 등을 실무에 적용하면서 리더십을 발휘해 본 경험
    • 교육, 워크숍, 코칭 및 프리젠테이션 역량
    • 탁월한 의사소통 역량 및 의견 조율 능력

아울러 안드로이드서버 개발자도 상시 채용 중입니다.

널리 널리 알려주세요!

[NBT가 일하는 방식 #4] NBT 개발 문화 성장의 중심 – 엔지니어링 컬처 클래스

NBT가 일하는 방식

  1. 제품 개발 조직의 구조
  2. 칸반이 진화해 온 과정
  3. 제품 개발의 흐름
  4. NBT 개발 문화 성장의 중심 – 엔지니어링 컬처 클래스

QA 클래스의 탄생

2014년 5월, 조직에 칸반을 도입한지 석 달만에 드디어 우리의 첫 번째 병목 지점이 드러났다. 다름 아닌 “테스트” 단계였다.

20140512_025900363_iOS

처음 NBT 개발 프로세스에는 명시적 테스트 단계가 없었다. 그럼에도 불구하고 굳이 테스트 단계를 칸반 보드 상에 넣었던 이유는 단순한데, 당시 구현 마지막 시점에서 때로는 생략하기도 하고 때로는 매우 제한적으로만 이루어지기도 했던 테스트를, 개발자들이 좀 더 노력을 기울이고 의식적으로 진행하기를 원했기 때문이었다. 테스트 단계의 WIP를 제한하지도 않았고, 테스트 단계의 완료 조건을 엄격히 정의하지도 않았었지만, 이 간접적 변화의 효과가 바로 드러나기 시작했다. 칸반 보드의 테스트 단계에 한 번 발생한 티켓 집중 상태는 해소될 기미가 없었다. 그 때 이런 의견이 팀에서 나오기 시작했다.

“우리도 테스터가 필요한 것 아닐까요?”

누군가 “QA”“테스터”의 정확한 차이를 물어본다면 아직도 정확히 답변하기는 어려울 것 같다. 게다가, 내가 아무리 정확한 정의를 내린다 한들, 사람들이 머릿속에 떠올리는 이미지는 완성된 (또는 완성에 가까운) 제품의 기능을 하나씩 실행해보며 문제점을 찾아내서 보고하는 역할일 것이다.NBT에 테스터로 이루어진 그런 조직을 만들고 싶은 마음은 조금도 없었다. 기획, 개발, 디자인, 테스트 등 모든 기능이 제품 개발의 처음부터 끝까지 호흡을 함께 해야 한다고 믿기 때문이다. 우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애 주기 전반에서 수행하는 역할이 필요하다고 판단했다. (주변 이야기를 들어보면 이런 역할을 보통 QA[Quality Assurance, 품질 보증]라고 부르는 듯하다. 그러나, 나는 이 이름도 전혀 옳지 않다고 본다. 왜 특정 몇몇 사람들만 품질에 대한 보증을 해야 하는가? 품질 보증은 CEO부터 제품 개발에 참여하는 모든 사람까지 하는 것이라고 생각한다.)

다행스럽게도 많은 분들이 지원해주셨고, 그 중에서 테스터의 역할을 뛰어넘어 좀 더 큰 그림을 그리고 실현하길 원하는 두 명이 합류해서, NBT에는 QA 클래스가 생겨나게 되었다. 그것이 2014년 여름에서 가을로 넘어갈 무렵이었다.

QA의 역할에 대한 고민

하지만, 모든 일이 생각대로 순조롭게 흘러가지는 않았다. QA 클래스가 생겼는데도 제품 품질이 그대로라는 불만이 조직 여기저기에서 나오기 시작했다. 사람들이 QA라는 역할에 기대하는 바와, 우리가 QA 클래스를 만들면서 지향했던 방향이 일치하지 않았으니, 어쩌면 예견된 일이었을지도 모르겠다. 나 뿐만 아니라 QA 클래스를 포함해서, “우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애주기 전반에서 수행하는 역할”을 하려면 구체적으로 매일매일 어떤 일을 해야하는지 아무도 모른다는 것이 가장 큰 문제였다.

QA 클래스에 테스터의 역할을 기대하는 사람들에게, QA가 서비스 기획이나 개발 단계에 함께 참여해야 한다고 설명하기가 쉽지도 않았고, QA 클래스도 역할 범위 문제 때문에 조심스럽게 접근하다보니 적극적인 역할을 펼쳐보이기가 매우 어려웠다. (어느 조직이든지 역할과 책임 문제가 가장 예민한 폭탄이다.) QA 클래스가 제품 개발 생애 주기 전반에 참여하려면, 거기에 걸맞도록 제품 개발 프로세스 전반의 변화가 필요했다.

엔지니어링 컬처(EC) 클래스의 탄생

프로세스에 대해 사람들이 흔히 저지르는 오류 중 한 가지가, 훌륭한 프로세스를 만들면 모든 일이 잘 될 것이라는 가정이다. 원하는 결과를 얻으려면 프로세스를 만들고 가이드를 배포하는 단계에서 멈추면 안된다. 프로세스를 만든 다음, 그 목표에 공감할 수 있도록 사람들을 설득하고, 구성원들이 충분히 자발적으로 실행할 수 있을 때까지 조직에 적용하면서, 거기에서 발생하는 역동을 주의 깊게 관찰하고 문제점을 보완하는 지속적인 조정이 함께 이루어져야 한다. 다시 말해, 프로세스를 바꾼다는 것은, 조직의 문화를 바꾼다는 의미다.

QA 클래스의 역할을 조직 문화 관점에서 고민하다보니, QA란 결국 내가 하고 있던 애자일 코치 역할과 큰 틀에서 다르지 않다는 것을 깨달았고, 두 역할을 동시에 병행하는 하이브리드 조직을 시도해보면 어떨까 하는 아이디어가 떠올랐다. 문제를 이런 방향으로 풀어보려는고 시도했던 이유는, 다행스럽게도 QA 클래스 구성원들이 애자일 코치로서의 역할에도 관심을 보여주고 있었고, 1년 남짓 함께 생활하면서 두 사람 모두 그 역할을 훌륭하게 잘 해낼 수 있다는 믿음이 생겼기 때문이었다.

서로의 비전과 바람을 솔직히 이야기하면서 함께 밑그림을 그렸고, 2015년 7월에 QA 클래스는 엔지니어링 컬처 클래스(이하 EC 클래스)라는 새로운 이름과 역할로 진화했다.

20150708_155927460_iOS

그 때 세 명이 함께 만들었던, 그리고 지금도 유효한 EC 클래스의 비전은 다음과 같다.

“훌륭한 개발 문화가 매일매일 성장할 수 있는 환경을 누구보다 먼저 고민한다.”

EC 클래스의 역할

EC 클래스에서 수행하고 있는 역할은 크게 세 가지다.

  • 첫 번째는 “지속적 프로세스 개선”이다. 일일 스탠드업 미팅이나 주간 회고, 또는 그 외 모든 모임에서 의견을 조율하고 더 나은 결론을 이끌어낼 수 있는 퍼실리테이터의 역할을 담당한다. 그러면서도, 개발 프로세스의 개선 지점을 도출해내고, 정책을 명시화하며, 품질을 비롯한 개발 완료 조건에 대해서도 고민한다. 이 과정에서 다양한 린/애자일 실천 방법들을 도입하고 실행하기 위해 노력하고 있다. 아직 흔하지는 않지만, 다른 회사에서는 스크럼 마스터, 애자일 코치, 또는 프로젝트 관리자들이 주로 수행하는 역할이라고 볼 수 있다.
  • 두 번째는 “개발 지원 환경의 구축 및 운영”이다. 위키, 이슈 추적 시스템, CI, 코드 정적 분석 도구 등 각종 개발 도구를 리서치하여 구축하고 운영한다. 아울러 테스트 자동화를 위한 각종 지원을 위해서도 노력하고 있다. 대부분의 회사에서 이런 부분은 관심 있는 개발자가 자발적으로 담당하거나, 또는 몇몇 사람들에게 부가 업무로 주어진다. 나는 이런 활동들이 누군가의 선의에 의존하거나, 부가 업무가 되어서는 안된다고 생각한다.
  • 세 번째는 “품질 문화 정착 활동”이다. 제품 및 코드 품질을 측정하고 시각화해서 각 파티에서 자발적으로 개선할 수 있도록 대시 보드 및 품질 지표들을 관리한다. 또한 제품에 대한 조직 내부 및 외부의 피드백에 대한 모니터링도 꾸준히 진행하고 있고, 그런 의견들이 제품에 잘 반영될 수 있도록 개발 과정에 꾸준히 참여한다. 어떤 관점에서 보면 우리가 처음에 바라던 QA의 역할이 여기에 제일 가깝지 않을까 생각한다.

20160426_020956705_iOS20160401_083951966_iOS20160429_083920383_iOS20150923_020427173_iOS

사실 EC 클래스의 역할을 한 마디로 규정하기란 어려운 일이다. EC 클래스는 자신의 역할에 대해서도 지속적으로 개선하고 있기 때문에 상황에 따라 그 역할을 조금씩 바꾸어왔다. 프로젝트를 성공적으로 수행하고, 그 과정에서 구성원들이 만족할 수 있도록 모든 노력을 다 한다는 점에서 어찌보면 리더십 포지션에 가깝다고 볼 수 있다. 그러나 팀장이 팀원들 위에서 지시하고 통제하는 리더십을 발휘하는 것이 일반적인 모습이라면, NBT의 EC 클래스는 팀원들의 옆에서 그들의 어려움을 함께 공감하고 소통하는 방식으로 리더십을 발휘한다.

바람직한 EC 클래스 구성원의 조건

내가 생각하기에, 애자일이나 QA에 대한 경험이나 지식은 EC 클래스 구성원이 되는데 반드시 필요한 조건은 아니다. 어떤 경우에는 그런 조건들이 오히려 방해가 될 수도 있다. 가장 중요한 것은 “더 훌륭한 개발 문화를 이루고자 하는 열망”“나 자신과 주변 사람들의 성장에 대한 관심”이 아닐까.

스크럼이나 XP 또는 칸반 같은 방법을 중요하게 여기는 사람, 기존 시스템에 대한 절망이 분노와 냉소의 모습으로 남아있는 사람, 현재에서 탈출해서 새롭고 신선한 분위기를 원하는 사람보다는, 자신만의 비전을 갖고 있고 그 비전을 이루고자 하는 열정이 있는 사람, 함께 일하는 사람들에게 다가가서 먼저 신뢰를 보여줄 수 있는 사람, 지금에 만족하지 않고 서서히 더 나은 방향으로 나아갈 수 있는 사람과 함께 일하고 싶다.

그런 의미에서 지금 두 명의 EC 클래스 구성원들은 배울 점도 많고 건강한 자극이 되기도 하는 훌륭한 동료들이며, NBT 제품 길드가 지금까지 올 수 있었던 중요한 원동력 중 하나였다고 생각한다.

앞으로 어떤 사람이 새롭게 합류해서, EC 클래스와 구성원들이 어떤 방향으로 진화해갈지 매우 궁금하기도 하고 기대도 된다.


P.S. 그렇습니다. 이 글의 주 목적은 채용입니다^^ NBT의 EC 클래스에 관심이 있는 분이 계시다면, 함께 이야기를 나눠보고 싶습니다. cho.seungbin@nbt.com으로 언제든지 연락주세요.

[NBT가 일하는 방식 #3] NBT 제품 개발의 흐름

NBT가 일하는 방식

  1. 제품 개발 조직의 구조
  2. 칸반이 진화해 온 과정
  3. 제품 개발의 흐름

오늘은 현재(2016년 4월 26일)의 칸반 보드 구성을 기준으로 NBT에서 제품을 만들어내는 과정을 정말~ 간단하게 소개하 드리려고 한다.

(1) – 프로젝트 진행을 위한 메인 공간

(2) – 제품 개발 프로세스의 각 단계에 대한 정책 및 완료 기준을 명시화

(3) – 프로젝트 생산성 정량 지표

(4) – 앱 릴리스 정보

(5) – 프로젝트 출시 이후 성과 분석

(6) – 제품 전략

(7) – 수시로 발생하는 각종 운영성 업무 지표 수집

NBT의 제품 개발 프로세스는 매우 단순하다. (1) 부분을 보면 알 수 있는 것처럼 옵션, 분석진행중, 구현대기중구현진행중, 배포진행중, 출시완료의 다섯 단계로 이루어져 있다.

옵션

옵션 단계에 대해 설명하기 전에, 우선 “옵션”이라는 용어에 대한 추가 설명이 필요하다. 다른 회사의 제품 개발 프로세스를 살펴보면 대개 이 위치에 “요구사항”, “할 일”, “아이디어”, “백로그” 등과 같은 이름들을 사용한다. 모두 그 역할은 동일하다. 아직 진행하지 않은 프로젝트를 모아 놓는 곳이다. 그런데, 우리가 여기에 옵션이라는 다소 생소한 이름을 사용하는 데에는 이유가 있다. 요구 사항이라는 용어는 암묵적으로 작업자를 수동적 위치에 놓이도록 만든다. 내가 예민한건지 모르겠지만, 요구 사항이라는 단어를 들을 때마다 요구를 전달하는 외부의 누군가와 그 요청을 처리하는 내가 (또는 우리가) 분리된 별개의 존재가 되어버린다는 느낌을 받는다. 나는 다른 사람의 요구를 수동적으로 처리하는 존재가 되고 싶지 않다. 내가 주체적으로 판단하고 실행하는 존재가 되고 싶다. 그래서 선택한 단어가 옵션이다. 함께 캐시슬라이드를 개발하는 사람들이 제품 백로그를 보면서 해치워야 할 일감으로 받아들이는 것이 아니라, 제품을 어떤 방향으로 진화시켜나갈지 주체적으로 판단할 수 있는 여러 선택지로 받아들이기를 바라는 마음에 옵션이라는 단어를 사용하고 있다.

옵션 단계에서 가장 중요한 활동은 매주 금요일에 있는 리프레시 회의다. (옵션을 새로고침한다는 의미다.) 리프레시 회의에 대해서는 나중에 상세히 다룰 예정이기 때문에, 간략하게만 언급하자면 옵션에 등록되어 있는 프로젝트 중에서 현재 시점에 가장 중요한 상위 몇 가지를 선택하는 자리다. NBT의 거의 모든 부서가 모여 백로그를 살펴보면서 제일 먼저 개발에 착수해야 할 항목을 선정한다. 여기에서는  (6)에 있는 제품 전략을 가장 중요한 판단 기준으로 삼는다.

분석

분석 단계의 최종 산출물은 “분석 리포트”이며 NBT 구성원이라면 누구나 위키를 통해 모두 접근해서 볼 수 있다. 분석 보고서에서 다루는 주요 어젠다는 네 가지다.

  • 해결해야 할 문제는 무엇인가?
  • 문제를 해결하기 위한 최적의 솔루션 후보에는 어떤 것들이 있는가?
  • 예상하는 프로젝트 완료 기준은 무엇인가?
  • 어떤 성과를 기대하는가?

대개는 이매지니어가 분석 단계를 담당하지만, 항상 그런 것은 아니다. 프로젝트 성격에 따라 개발자가 분석을 진행하는 경우도 있다. 상세한 분석 리포트가 필요하지는 않기 때문에 A4 한 장 이내의 분량으로 5일 이내에 완료하기를 권장한다. 분석 단계에서 가장 중요한 것은 옵션의 불분명한 부분을 분명하게 만드는 일인데, 그렇게 하려면 해당 프로젝트를 요청한 사람, 제품 전략을 담당하는 PD, 실제로 개발을 진행하게 될 개발자 등 모든 이해 관계자들과 직접 만나 긴밀하게 소통할 필요가 있다. 그 과정에서 취소하는 방향으로 결론이 내려지는 프로젝트도 많다.

분석과 기획은 다르다. 흔히들 말하는 기획서를 작성하는 일은 구현 단계에서 이루어진다.

구현

기획, 개발, 디자인, 테스트 등 실제로 프로젝트를 진행하는 데 필요한 모든 주요 활동은 구현 단계에서 이루어진다.

구현 단계에서는 제일 먼저 프로젝트에 참여하는 모든 사람들이 모여 “프로젝트 차터”를 만든다.프로젝트에 참여하는 구성원들이 분석 리포트를 기반으로 프로젝트 차터를 작성하면서,  목표를 명확한 형태로 확정짓고, 프로젝트 완료 기준을 세우고, 대략적인 설계를 진행하면서 세부 업무를 분할하여 프로젝트를 곧바로 시작할 수 있는 상태로 만든다. 프로젝트 차터 작성이 끝나면, 그때부터 프로젝트가 본격적으로 진행된다.

개인적으로 구현 단계에서 가장 중요하게 생각하는 것은, 모든 참여자가 프로젝트를 함께 시작해서 함께 끝내는 것이다. 기획자의 최종 목표는 파워포인트로 기획서를 만들어 개발자에게 넘기는 것이 아니고, 디자이너의 최종 목표 역시 이미지 파일과 디자인 가이드를 개발자에게 넘기는 것이 아니다. 소프트웨어 엔지니어도 정해진 기능을 코드로 구현하는 것이 최종 목표가 되어서는 안된다. 팀에서 스스로 결정한 프로젝트 목표를 협업을 통해 달성해서 고객에게 가치를 전달하는 것이 모두의 최종 목표가 되어야 한다. 직군 사이의 갈등이 생기는 근본적 이유는 서로 달성하고자 하는 목표가 다르기 때문이라고 생각한다.

물론 역할에 따라 팀원 각자의 작업량과 업무 주기가 달라서, 모두가 프로젝트를 함께 시작해서 함께 끝내려면 불가피하게 남는 시간들이 생긴다. 아무래도 이매지니어는 프로젝트 초기에, 소프트웨어 엔지니어는 프로젝트 후기에 업무량이 집중되기 때문이다. 모든 작업자가 항상 100%의 효율을 발휘하도록 만드는 것이 당연하다고 생각하는 관리자는 이런 선택을 하기 어렵다. 불안감을 이겨내기 어려워서다. 다행스럽게도 나는 이 문제를 크게 고민하지 않고 살고있다. NBT 제품 길드의 구성원들은 (스스로 개선 프로젝트를 진행하거나, 주변 동료에게 도움을 주거나, 새로운 기술에 대한 학습 등을 통해) 이렇게 남는 시간을 생산적으로 사용할 수 있다는 믿음이 있기 때문이다.

성과 분석

위 사진의 (5) 부분은 성과 분석을 위한 곳이다. 이 공간을 마련하기 전까지는, 프로젝트를 완료해도 그 성과가 좋았는지, 더 개선할 부분은 없는지, 궁극적으로는 우리가 올바른 방향으로 가고 있는지 알기 어려웠다. 출시 이후 성과 분석이 필요한 프로젝트가 있다면, 이매지니어는 출시 완료 단계에 붙어있던 티켓을 성과 분석 부분으로 옮긴 다음, 적절한 시일이 지난 후 분석 리포트에서 미리 정해두었던 성과 지표의 결과를 간단하게 정리해서 모두와 함께 공유한다.

이 성과 분석의 결과가 새로운 옵션으로 이어지기도 한다.

향후 계획

여기까지 오는 데에도 오랜 시간이 걸렸지만, 지금도 고민하고 있고 여전히 해결하지 못한 숙제들도 많다. 대표적인 것들은 아래와 같다.

  • 옵션에 등록되는 항목들의 품질을 더 높이려면 어떻게 해야 할까?
  • 리프레시 회의가 아닌 어둠의 루트를 통해 들어오는 긴급 업무 요청에는 어떻게 대응하는 것이 좋을까?
  • 아직 제품 길드 내부에서 함께 협업하지 않고 있는 UI/UX 기능과 원활하게 협업하려면 장/단기적으로 어떤 방법이 좋을까?
  • 갈수록 레거시와 복잡도가 늘어나고 있는 제품의 품질을 개선하거나 유지하려면 또 무엇이 필요할까?
  • 파티 사이의 협업과 합의가 필요한 프로젝트 진행이나 정책 결정은 어떻게 하는 것이 최선일까?

이전에도 여러 차례 반복해서 강조했지만, 지금까지 했던 이야기는 전부 현재의 스냅샷에 불과하다. NBT 제품 길드는 지속적이고 점진적으로 더 좋은 방법을 찾아 개선하는 문화를 추구하고 있기 때문에, 제품 개발 프로세스는 지금까지도 계속 진화해왔고 앞으로도 그럴 것이다.

“우린 답을 찾을 것이다. 늘 그랬듯이.”

(조금 진부한 표현일 수도 있지만) 우리에게 가장 어울리는 말이라고 생각한다.

[NBT가 일하는 방식 #2] NBT의 칸반이 진화해 온 과정

NBT가 일하는 방식

  1. 제품 개발 조직의 구조
  2. 칸반이 진화해 온 과정

이번에는 NBT의 간판(看板)인 칸반(看板)이 변화해온 모습을 공유하려고 한다. 지난 2년여 동안, NBT의 제품 개발 프로세스는 상황에 맞게 계속 바뀌어왔고, 칸반 보드 역시 거기에 맞추어 함께 진화해왔다.

내가 합류했을 때 캐시슬라이드는 서비스를 출시한지 이미 1년 정도가 지난 상황이었고, 그래서 (물론 신규 기능 개발도 여전히 활발히 일어나고 있긴 하지만) 어느 정도 유지보수 모드에 들어간 상태라고 판단했기 때문에 칸반을 선택했다. 만약 새로운 서비스를 개발하는 팀이고 인원이 더 적었더라면 아마도 스크럼을 선택했을 것이다. 하지만, 지금은 칸반을 기반으로 스크럼으로부터도 다양한 원칙과 실천법을 가져와 적시적소에 활용하고 있다.

20160318_043659845_iOS

 

1세대 (2014년 2월 ~ )

20140217_010505842_iOS

NBT에서 첫 번째로 사용했던 칸반 보드다. 구조가 매우 단순해서 “To-Do”, “Development”, “Done”의 세 단계로 구성했고, WIP 제한은 엄격하게 적용하지 않았다. To-Do 다음에 “Planning” 단계를 그려놓긴 했지만 실제로 사용하지는 않았는데, 당시 개발팀과 별도 조직이던 서비스기획팀 구성원들에게 함께 참여할 수 있음을 간접적으로 알리는 단순한 용도였다.

그리고, Development 하위에 다시 단계를 세분화해서 2-tier 로 구성하였다. 관리자의 관점에서 보았을 때 그다지 중요하지 않지만, 칸반을 처음 사용하는 개발자에게는 이런 구성이 도움이 될 수 있다. 이렇게 하면, 프로젝트를 시작할 때 어떤 세부 작업이 필요한지 미리 고민하는 습관을 키울 수 있고, 포스트잇을 다음 단계로 옮기는 손맛(?)을 더 자주 느낄 수 있다.

가장 중요한 것은, 당시 개발 프로세스를 그대로 보드에 옮겨놓고, 가장 기본적인 몇 가지 운영 규칙만 정했다는 점이다. 칸반을 처음 적용할 때에는 단순하게, 현재 상태 그대로 시작하는 것이 좋다.

2세대 (2014년 3월 ~ )

20140512_025900363_iOS

1세대를 한 달 남짓 사용한 이후 개선한 버전이다. 크게 바뀐 것은 없다. 좀 더 양이 늘어난 백로그를 관리하기 위해 구글 스프레드시트를 사용하기 시작했고, 칸반 보드의 시각화 측면을 강화하기 위해 고무 자석을 활용한 것도 이때부터다.

또한, (전담 테스트 인력이 있었던 것은 아니지만) “Test” 단계와 “Release Ready” 단계를 명시적으로 활용하기 시작했다.

3세대 (2014년 6월 ~ )

20140627_023945838_iOS

서비스기획팀도 칸반 보드를 함께 활용해보기로 하면서 개발 프로세스 이전 단계까지 포함하기 시작했다. 서비스 기획 단계를 명시적으로 표현하기가 쉽진 않았고, 결과적으로 활용도 그렇게 원활하지는 못했지만, 하나의 아이디어가 사용자의 손에 들어가기 전까지 모든 단계를 볼 수 있게 되었다는 점이 3세대 칸반 보드에서 가장 중요한 부분이다.

왼쪽 상단 “서비스 기획 INBOX” 단계에서 출발해서, 왼쪽 하단의 “출시 완료” 단계에서 끝나는 구조로 되어있다. 좁은 공간에 많은 정보를 표현하려다보니 상당히 복잡했다.

4세대 (2014년 7월 ~ )

20140811_005840073_iOS

새로운 사무실로 이전하면서 훨씬 넓은 보드를 벽에 부착하여, 4세대 칸반 보드를 구성해서 활용하였다. 공간이 넓어 3세대를 넓게 펼쳐놓았고 크게 달라진 것은 없다.

4세대 칸반 보드를 상대적으로 가장 오랫동안 사용했었는데, 칸반을 사용하면서 이 때가 가장 어려웠던 시기였다. 뭔가 복잡하고 있어보이지만 제대로 활용되지 못한 부분이 많았고, 인원이 늘어나면서 일일 스탠드업 회의 참여 인원이 한 번에 30명이 넘는 등 개인적으로도 대단히 혼란스러운 상황이었다.

시행착오를 겪으면서 큰 개선 없이 오랫동안 유지했던 4세대 칸반은, 혼자 설계하고 구성하고 관리했던 마지막 세대다.

5세대 (2015년 4월 ~ )

20150430_101455337_iOS

4세대 보드의 가장 큰 단점은 크기가 작은 소규모 유지보수 과제와 굵직한 주요 과제(“핵심 과제”라고 불렀다)가 칸반 보드 상에 뒤섞여 있어, 핵심 과제의 진행 상황만 별도로 보기 어려웠다는 점이다. 핵심 과제는 경영 목표 달성을 위해 그 주목도가 훨씬 더 높을 필요가 있었다. 그래서, 5세대 칸반에서는 각 핵심 과제를 빼내서 별도로 진행 상황을 알아볼 수 있도록 구성하였다. 이 시기에 서비스 기획은 칸반을 거의 활용하지 않는 상태로 다시 돌아갔다.

이때부터 EC(Engineering Cultrue) 클래스 구성원들과 함께 칸반 보드를 설계하고 구성하기 시작했다. 고무 자석을 활용하여 다양한 시각화 장치가 본격적으로 등장하기 시작한 것도 이때부터다.

6세대 (2015년 9월 ~ )

20150925_045729116_iOS

또 다시 사무실이 이전하면서, 새롭게 6세대 칸반을 구성하였다. 크게 두 부분으로 나누었는데, 왼쪽은 캐시슬라이드를 개발하는 두 파티가, 오른쪽은 DevOps, Data, Engineering Cultrure 클래스와 같은 전문가 팀이 활용하는 형태였다.

이 시기에 가장 중요한 것은, 나는 큰 틀만 구성하고 세부적인 사항들은 각 파티와 클래스가 아이디어를 내고 개선하면서 칸반 보드를 직접 바꾸기 시작했다는 점이다.

7세대 (2016년 1월 ~ )

20160304_095603007_iOS

6세대 보드에서 각 클래스의 칸반 보드 활용도가 다소 떨어진다는 피드백이 있었고 파티도 2개에서 3개로 늘었기 때문에, 캐시슬라이드를 직접 개발하는 파티들이 좀 더 넓은 공간을 활용할 수 있도록 단순하게 구성했다. 이 때부터 AD, User, Cash의 세 파티가 칸반 보드를 자발적으로 활용하고 개선하면서 개인적으로는 관리 부담이 많이 줄어들었다.

8세대 (2016년 3월 ~ 현재)

20160411_032259898_iOS

현재의 모습이다. 중요한 변화가 몇 가지 있는데, 윗 부분에 개발 프로세스 정책이나 완료 기준을 (현실적이며 복잡하지 않은 선에서) 명시화 하였고, 아랫 부분에는 각 단계의 사이클 타임의 추세를 참고할 수 있도록 했다. “출시 완료” 단계 이후에 성과를 분석하고 게시할 수 있는 자리도 마련해서, 프로젝트 완료 이후 그 결과가 어땠는지도 모두가 알 수 있도록 했다.

2014년 2월부터 지금까지 약 26개월 동안 NBT의 칸반 보드에는 큼직한 변화가 8번 정도 (대략 세 달에 한 번 꼴) 있었지만, 작은 변화와 실험은 꾸준히 이루어져왔고, 칸반 보드는 지금도 지속적으로 바뀌고 있다.

변화하지 않는 칸반 보드는 죽은 보드다.

앞으로도 NBT 칸반 보드의 모습은 계속 바뀌어갈 것이다. 앞서 이야기했던 바와 같이 조직 구성도 마찬가지지만, 우리를 둘러싼 환경과 해결해야 하는 문제가 계속 달라지기 때문이다. 지금 최선이라고 생각하는 방법이 영원히 최선일 수 없기 때문에, 우리에게 맞는 더 나은 개발 프로세스를 만들기 위해 모든 구성원이 끊임 없이 노력하고 있다.

 

그 밖의 보드들

아래 사례들은 제품 개발 조직 캐시슬라이드를 개발하면서 사용하고 있는 칸반 보드와는 별개로, NBT 곳곳에서 자발적으로 등장한 보드들이다. 엄밀히 따지면 칸반 보드라고 보기 어려운 것들이지만, 별다른 장치나 정책이 없더라도, 업무를 시각화하는 것만으로도 성과를 크게 개선할 수 있다.

20140811_013136823_iOS

운영팀에서 목격한 개인 칸반 보드다. 구성은 무척 단순하지만, 제품 개발 조직에서 활용하고 있는 칸반을 보고 조직 외부에서 자발적으로 업무를 시각화한 첫 번째 사례다.

20151126_104537257_iOS

그 이후 운영팀은 팀 차원에서 칸반을 활용하기 시작했다.

20160201_053359701_iOS

캐시슬라이드와는 별개의 제품을 개발하는 TF에서 업무를 시각화 해놓은 모습이다. 구체적으로 어떻게 활용하고 있는지는 잘 모르지만, 매일 이 앞에 모여 스탠드업 회의를 진행하고 있고, 팀 외부에서도 진행 상황을 알 수 있도록 팀 공간 내부가 아니라 외부를 활용한 모습이 인상적이었다.

20160413_024132948_iOS

디자인팀이 업무를 시각화한 모습이다. 개인 보드를 모아놓은 형태로 되어있는데, 얼마나 성과가 있는지는 아직 물어보지 않아 잘 모르겠다.

20160404_005639273_iOS

각 파티에서 회고 시간에 활용하고 있는 “카이젠보드”다. 칸반 보드는 프로젝트 진행에 대한 내용만으로 이루어져 있기 때문에, 개선해야 할 아이템들은 별도의 보드로 관리하고 있다. 회고를 진행하면서 액션 아이템들을 도출해내고 잘 진행되고 있는지 수시로 확인한다.

20160404_130810895_iOS

서비스 인프라를 운영하고 있는 DevOps 클래스의 칸반 보드다. 업무 요청이 수시로 들어오고 긴급 대응도 많은 특성을 반영하여 업무를 시각화했다.

 

칸반에는 칸반이 없다?!

얼마 전에 트위터에서 우연히 이런 트윗을 보았다.

애자일에서 말하는 칸반 보드는 역전 앞 같은 말이 아닌가… (…

워낙 자주 듣던 이야기이다. 사람들은 소프트웨어 개발 진행 상황을 시각화한 보드를 가리켜 흔히 ‘칸반’이라고 말한다. 나도 급할 때는 무의식 중에 보드를 가리켜 ‘칸반’이라고 이야기하기도 하는데, 그렇게 해도 의사 소통에 별로 문제가 없기 때문이다. “칸반 == 보드”라는 오해는 그 만큼 널리 퍼져있고 뿌리 깊게 자리잡고 있어 벗어나기 쉽지 않다.

곰곰이 생각해보았는데, 그 원인은 크게 두 가지로 볼 수 있을 것 같다.

  • 데이비드 J. 앤더슨이 도요타 생산 시스템TPS, Toyota Production System제약 이론TOC, Theory Of Constraints당김 방식pulling system에서 영감을 얻어 새로운 소프트웨어 개발 방법을 만들면서 거기에 ‘칸반’이라는 이름을 붙였는데, 이는 일종의 메타포로써 사람들에게 쉽게 다가가기 위한 전략이었다고 할 수 있다. 마케팅 측면에서는 성공적이었지만, 그 이름이 지금에 와서는 오히려 사람들에게 혼란을 주고 있다.
  • 칸반에서는 보드가 매우 중요한 역할을 수행한다. 그러나 워낙 시각적인 측면이 강렬하기 때문에 보드 이외의 다른 중요한 요소들을 보기가 쉽지 않다. 낮에는 태양의 밝기 때문에 달과 별이 보이지 않는 것과 마찬가지라고나 할까.

kanban-chinese

많은 사람들이 알고 있는 것처럼 칸반Kanban‘은 看板간판을 일본식으로 발음한 것이다. 간판의 사전적 의미는 ‘기관, 상점, 영업소 따위에서 이름이나 판매 상품, 업종 따위를 써서 사람들의 눈에 잘 뜨이게 걸거나 붙이는 표지’이지만 여기에서는 그런 의미가 아니다. 칸반이라는 단어에는 (연관성은 있으나) 서로 다른 세 가지 정의가 있다.

 

1. 도요타 생산 시스템에서의 칸반

kanbancardfromliker

위는 도요타에서 실제로 사용하던 칸반의 모습인데, 생산 도중 추가로 부품이 필요할 때 이 카드를 작성하여 프로세스의 전 단계로 보내면, 카드를 받은 곳에서는 카드를 보내온 곳에서 필요한 부품을 생산한다. 즉, 도요타 생산 시스템(린 제조 프로세스)에서 프로세스 전 단계로 보내는 물리적 주문서가 칸반의 첫 번째 정의다.

 

2. 당김 방식의 신호로써의 칸반

도요타에서 이런 방식으로 생산 프로세스를 운영했던 가장 큰 목적은 적시 생산JIT, Just-In-Time을 위해서다. 프로세스의 전 단계에서 미리 예측한 양만큼 생산한 부품을 다음 단계로 밀어내는push 것보다, 프로세스 이전 단계에서 필요한 부품을 당겨와pull 생산하면 필요한 때에 필요한 만큼만 제품을 생산해낼 수 있고 그 재고량은 최소화할 수 있다. 여기에서 칸반은 작업 시작을 알려주는 역할을 한다. 즉, 당김 방식에서 사용하는 새로운 작업을 시작할 수 있다는 신호가 칸반의 두 번째 정의다.

그렇다면 소프트웨어 개발의 칸반에서는 무엇이 ‘새로운 작업을 시작할 수 있다는 신호’의 역할을 할까? 바로 진행 중 업무(WIP)의 양을 제한한 값에서 현재 진행 중인 업무 항목 수를 뺀 값이 0보다 크다면 그것이 바로 새로운 작업 시작의 신호가 된다. 이것을 논리적으로 표현하면 다음과 같다.

if ( 0 < ('WIP Limit' - 'WIP') ) {
    pull();
}

도요타 생산 시스템에서의 칸반과 비교해보았을 때 가장 두드러지는 차이점은 바로 물리적 실체가 없다는 점이다. 그래서 소프트웨어 개발에서 이야기하는 칸반을 가상 칸반 시스템virtual kanban system이라고 말한다.

 

3. 소프트웨어 개발 방법으로써의 칸반

칸반의 마지막 정의는 데이비드 J. 앤더슨이 만든 소프트웨어 개발 방법으로써의 칸반이다. 이런 혼란을 막기 위해서인지는 모르겠으나, 요즘 해외 커뮤니티에서는 소프트웨어 개발 방법인 칸반을 Kanban Method라고 부른다. 모두 여섯 가지 핵심 요소가 모두 포함되어 있어야 칸반 메소드라고 할 수 있다. 시각화만이 전부가 아니다.

  • 시각화한다.
  • 진행 중 업무(WIP)를 제한한다.
  • 흐름을 관리한다.
  • 정책을 명시화한다.
  • 피드백 루프를 실행한다.
  • 함께 개선하고 실험을 통해 발전시킨다.

요약하자면, 원래 칸반은 ‘도요타 생산 시스템에서 프로세스 이전 단계에서 새로운 업무를 당겨오는 신호 역할을 하는 카드’라고 할 수 있다. 우리는 이 단어를 소프트웨어 분야의 개발 방법 중 하나인 칸반의 이름으로 사용하고 있는 것이다. 따라서, 따라서 칸반 메소드에서는 보드를 칸반이라고 볼 수 없으며, 포스트잇을 칸반이라고 할 수도 없다. 칸반(소프트웨어 개발에서의 칸반 메소드)에는 칸반(즉, 당김 신호 역할을 하는 카드)이 없다.

물론 보드를 가리켜 칸반이라고 불러도 의사 소통이 안되는 것은 아니며, 무슨 큰 일이 나는 것은 더더욱 아니다. 하지만 칸반을 단순히 업무 시각화 방식으로 인식하는 오해가 여기에서 비롯된 것이라 생각하면 가볍게 생각할만한 것은 아니라고 생각한다.

다시 한 번 더 강조하지만, 칸반에는 칸반이 없다.

 

KANBAN@NBT

어제 있었던 Xper 정모는 NBT에 칸반을 도입한 후 20개월 동안의 이야기를 처음으로 외부에 공개한 자리였다.

다 마친 후 몇몇 분들이 회고하는 자리에도 잠깐 있었는데, 대부분 긍정적인 피드백을 주셔서 다행이다.
발표 자료를 정리하면서 새삼 느꼈던 거지만, 그 동안 함께 여기까지 온 우리 개발실 멤버들 정말 대단하고 자랑스럽다.