»
S
I
D
E
B
A
R
«
Cumulative Flow Chart in Kanban: Real Usage Example
Feb 16th, 2010 by Wegra Lee

Edge of Chaos | Agile Development Blog 에 Kanban 의 Cumulative Flow Chart 활용 예[1]가 실려서 옮겨본다.

(Kanban 에 대한 배경 지식이 전혀 없다면 One day in Kanban land [2] 를 먼저 읽어보고 오자. 흥미가 생긴다면 Lean and Kanban[3]의 글들을 시간을 두고 찬찬히 읽어보길 권한다.)


Cumulative Flow 다이어그램을 잘 활용하면 라인 정지(stop-the-line)[4] 나 애자일 회고(retrospective)를 시작해야할 시점을 쉽게 발견할 수 있다. 여기 TargetProcess[5] 개발 과제로부터 실례가 있다.

차트를 보면 우리가 12월 초에 병목을 겪었음을 볼 수 있다. 꾀 복잡한 유저 스토리 하나가 원인이었다. 이론적으론 유저 스토리 하나가 개발 주기에 심각한 영향을 미치거나 병목을 발생시키면 안되지만, 규칙을 조금 어기면 실제 그런 일이 일어날 수도 있다.

문제의 유저 스토리는 jQuery 자바스크립트 프레임워크를 ExtJS 프레임워크[6] 로 교체하는 것이었다. 이 작업은 개발자 한 명이 별도의 브랜치에서 1개월에 걸쳐 구현하였다. 그 한 달 동안 나머지 멤버들은 몇 차례의 릴리스를 성공적으로 마쳤다. 테스터들은 그 유저 스토리에서 별 문제점을 발견하지 못했고, 인수 테스트(acceptance test) 역시 모두 통과하였다. 이 코드를 메인 코드 브랜치에 반영하는 것은 당연한 수순이었고, 그렇게 했다.

불행히도, 코드 반영 후 스모크 테스트 중 꾀 많은 빌드 에러들이 발생하였다. 버그를 다 잡는데는 1주일 이상이 소요되었고, 그 동안 우리는 아무것도 릴리스하지 못했다. 이미 반영된 코드를 다시 롤백하는 것 역시 만만치 않았기 때문에 뾰족한 수가 없었다.

여기서 얻은 교훈은 근본적으로 보다 복잡한 유저 스토리에는 테스트에 더 많은 노력을 들이라는 것이다. 이런류의 스토리는 어플리케이션에 다방면에 걸쳐 영항을 미치고, 보통의 스모크 테스트만으론 충분치 않다. 그래서 우리는 병합 전에 더 세심한 테스팅과 검증이 필요함을 의미하는 새로운 부류의 서비스를 제공할 것이다. 일단 “기술적으로 복잡한 스토리”라고 불러보자.

일반적으로, Cumulative Flow 차트는 과거 데이터를 분석하는데 훌륭한 툴이긴 하지만, 긴급한 병목을 식별해 내는데는 Kanban Board 가 훨씬 효과적이다. Kanban Board 에서 최대 허용 작업 수(limit)에 도달함은 곧 무엇가 문제가 있음을 뜻한다.


References

  1. Cumulative Flow Chart in Kanban: Real Usage Example (Edge of Chaos | Agile Development Blog)
  2. One day in Kanban land (wegra.org)
  3. Lean and Kanban
  4. Stop-the-line (Thoughts in the Wilderness)
  5. TargetProcess
  6. ExtJS framework (Ext JS)
Bad Team Culture – As Many Tasks As Possible in Parallel
Oct 30th, 2009 by Wegra Lee

Bad Team Culture 시리즈.. 두 번째..

As Many Tasks As Possible in Parallel (AMTAPP) 는 문장 그대로 가능한 많은 태스크들을 동시에 진행시키는 프로젝트 관리 방식을 말한다. 훌륭한 프로젝트 관리 가이드와는 전면으로 배치되는 정책으로, 특히 Kanban [1][2] 에서는 철저히 경계하고 있다.

이 방식은 현재 내가 속한 팀뿐 아니라 우리 회사의 전형적인 프로젝트 관리 방식이다. 프로젝트가 이렇게 진행될 수 밖에 없는 원인을 몇 년간의 경험을 토대로 유추해 보았다.

  1. 프로젝트는 거의 완벽히 블랙 박스에 가려진체 진행된다. 외부인이 실시간으로 과제의 정확한 진행 상태를 확인할 길이 없다. 물론 내부 팀원들에게도 마찬가지다. 프로젝트 투명성에 대한 글은 [3] 를 참조하기 바란다.
  2. 프로젝트 생존을 위한 사내 경쟁이 심하다.
    1. 따라서 더 적은 자원으로 더 많은 것을 할 수 있다고 해야지만 프로젝트가 생존할 수 있다. 다른 팀 역시 마찬가지 상황이므로, 서로 자신의 역량 이상으로 최대한 부풀려 홍보한다. 1번 – 프로젝트 투명성 부족 문제로, 과제가 마무리 되거나 팀에서 알아서 중간 결과를 보여주기 전에는 꾸며진 보고 자료만이 프로젝트 평가를 위한 근거의 전부이다. 중간 결과 발표 시에도 잘 되는 시나리오 중심으로만 보여주므로 역시 정확한 상황은 알 수 없다.
    2. ‘나중에 할 것이다’ 보다는 ‘이미 진행 중이다’ 가 더 그럴싸하게 들린다.
  3. Big bang 릴리즈 방식을 취한다. Incremental release (iterative development) 에 대한 경험과 인식이 부족하다. 충분히 안정화된 제품은 릴리즈 이전에는 결코 접해볼 수 없다. 오히려 패치 없이도 쓸만한 릴리즈를 하는 것 자체가 희귀한 경험에 해당한다.
  4. 소프트웨어 프로젝트의 납기 지연은 당연한 것이라 받아들이다. 2-1 역량 이상으로 부풀려 이야기하기의 좋은 방어책이 된다. 납기를 중요시 하지만 납기에 늦었다 해서 프로젝트가 당장 부러지는 일은 드물다. 그간 투자한 것도 있으니 계속해서 가능성을 보여주기만 하면 프로젝트는 생존할 수 있다.
  5. 메니저들은 보통 개발 실무를 하지 않는다. 실제 일할 사람 수가 줄어드는 효과를 내는데.. 우리팀의 경우 약 1/5 정도가 개발 실무를 하지 않고 있는 것으로 보인다.

그 외에도 나열하면 끝이 없겠으나.. 간략히 두 가지로 요약해보면.. 역량 이상의 일을 따냈고, 그래도 다 하고 있음을 강조해야 해야 한다. 결과적으로, 일할 사람 수보다 당장 해야할 태스크 수가 더 많은 상황에 처한다. 하나의 태스크에 둘 이상이 달라붙는 것은 사치스러운 짓이다.

그럼 AMTAPP 방식의 폐단은 무엇일까?

가장 큰 문제로 개발자 간의 의사소통이 단절을 뽑겠다. 내가 하는 일과 옆의 팀원이 하는 일은 관계가 거의 없다. 풀어야할 문제가 다르고 서로 코드를 봐줄 일도 없다. 어려움에 봉착해도 상의할 사람도 없고, 일부러건 몰라서건 대충 만들어 놓아도 당작 동작만 하면 아무도 알지 못한다. 겉으로 잘 드러나지 않는 품질이야 어떻든, 동작만 하면 관리자는 만족해한다. 또한 노하우가 공유되지 않아, 못하는 사람은 계속 못하고, 잘하는 사람의 발전도 더디다.

다음으로는 집중력 저하를 들겠다. 소프트웨어는 순전히 개발자의 사고에 의해 만들어지는지라, 소프트웨어 개발직은 다른 무엇과 비교해서도 고도의 집중력을 가장 요하는  직업 중 하나이다. 불행히도 신은 사람의 두뇌를 멀티 태스킹용으로 설계하지 않았다. 동시에 두 가지 이상을 생각하는 것은 어림도 없고, 심지어 하나 하나 번갈아 처리하는 능력 역시 상당히 떨어진다. 일을 바꿔 집중력 끌어 올리기까지는 수분에서 십수분 이상이 필요하다 – 정확한 수치를 Peopleware [4] 에서 본 듯 하나, 지금은찾아보기  귀찮다 :-)

하이라이트는 다른 사람들의 태스크를 만들어내는 태스크를 할당받은 사람들이다. 이들이 일을 열심히 할 수록 다른 팀원들 수십명의 일거리가 눈더미 처럼 불어나 버린다. 코딩하고 결함 잡기도 벅찬 와중에, 문서 고쳐라, 새로운 툴체인 적용해라, 디렉토리 구조 바꿔라, 여기 새 이디엄이 있으니 적용해라, 방금 나온 따끈따끈한 바이너리 당장 테스트해서 보고해라, 보고용 자료 좀 준비해와라, 이것 보고 커맨트 좀 달라 등등 수많은 요청이 쏟아진다. 프로젝트를 이런 식으로 이끌면서 품질은 개발자의 자존심이니 하는 이야기가 나오면 울컥하지 않을 수 없다.


References

  1. Kanban (wikipedia)
  2. One day in Kanban land
  3. Project Transparency (프로젝트 투명성)
  4. Peopleware by Tom DeMarco and Timothy Lister
One day in Kanban land
Aug 31st, 2009 by Wegra Lee

아름프로님의 블로그 (Click Here) 를 통해 알게되었는데.. 원본 링크는 여기 (Click Here).

Kanban (Click Here) 에 대한 설명이지만, 평소 agile/scrum 등에 관심이 있었던 사람이면 누구나 쉽게 이해할 수 있을 것이다. Kanban 에 의해 추가된 것은 아래 taskboard 의 각 칼럼에 있는 숫자들인데.. 이는 각 칼럼에 동시에 올 수 있는 최대 task 수를 의미한다. 예를 들어, Selected 에는 최대 2개까지 옮겨 놓을 수 있고, 동시 개발이 허용되는 최대 task 수도 역시 2, Deploy 검수는 1개씩만 허용된다. 이 숫자는 경험에 기반해 최적화가 가능하며, 마지막 그림에 보면 Develop 최대 개수를 3으로 늘렸음을 알 수 있다.

»  Substance: WordPress   »  Style: Ahren Ahimsa