Agile , Scrum, Kanban

 시작하기 전에

 ---------------------------------------------------------------------------------------------------------------------------------------------

 애자일 소프트웨어 개발 방법론.. 많이 들어보셨겠지만, 실제 업무상에서는 잘 와닿지 않는 것이 대부분이였습니다. 

 뭐를 쓰던지 간에, 장단점이 있고, 그것을 어떻게 받아들이느냐하는 마음 가짐도 중요하다고 생각됩니다.

 혼자 작업하는 것이 아니고, 팀이 작업을 하기에 제가 지금까지 일을 해오면서 가장 중요한 것은 팀웍이였습니다.

 사람간의 관계가 잘 형성이 되려면 서로간의 의심이 없는 것, 내가 하기 싫은것을 남에게 미루는 상황이 없는 팀이 이뤄져야 합니다.

 그렇게 되면, 사실 이런 개발 방법론을 넘어설수 있지 않을까 생각됩니다. ㅎ

 책이나 블로그 글을 읽어오면서, 이런 방법론들을 채택해서 진행하는 경험자체가 도움이 되기에,

 몇년전부터 도입을 해서 개발을 진행 했습니다.

 와우.. 아래 이미지가 잘 정리를 해 놓았네요.

 

 우선, Scrum 부터 보면.

 (1) 가능한 조직을 작게 만들고, 자기 조직적인 팀을 나눈다. 

   - 이건 회사에서 가능한지 여부가 중요, 해당 조직에 Scrum master(이사람의 할일은 이후에 나옴)를 배정해야 함.

 (2) Task를 가능한 작은 단위의 목록으로 만든다.(Backlog)

   - 전체 팀원이 함께 Backlog를 작성하는 것이 좋았습니다. 

 (3) Task에 우선순위를 부여 하고, 단위 마다 상대적인 가중치를 부여 한다.

  - Scrum master가 부여해야 함. 

 (4) 시간은 최대한 짧게 반복적으로 나누고, 해당 반복 구간 종료시에 출시 가능한 코드를 시연 합니다.(Code review)

  - 리뷰는 전체가 다 참석하도록 해야 합니다. 또한 고객과의 협업도 중요... 우선순위 및 진행 일정에 체크 필요

 (5) 해당 반복 구간 결과 리포터,회고 작성합니다.

  - Scrum master가 리포터,회고 취합해야 합니다. 또한 회고를 하는 이유는 진행된 프로세스에 대한 문제를 개선하고, 최적화 하기 위함

 암튼 좋습니다. 위와 같이 할 예정인데,  실무에서는 프로젝트가 있고 그 프로젝트에는 정해진 마감 시간이 있습니다.

 정해진 마감시간내에 목표하는 결과물을 산출해 내야 하는 것인데, 이 결과물을 내기 까지 중간에 일련 과정의 흐름을 확인해야 됩니다.

 그렇지 않으면, 대부분의 프로젝트는 결과물이 나올때 까지 멍.... (엄청난 불안감에 휩싸이겠죠.)

 그리하여, 프로젝트 내에는 시간에 비례하는 Task을 만들게 됩니다.

 이렇게 나눈 Task를 정리한 것이 바로 Backlog 입니다.

 시간의 흐름에 따라 진행해야 할 업무들의 순서가 정해 지기 때문이고,

 가장 힘든건 해당 Task가 얼마만큼의 시간이 소요되는지에 대한 예측이 쉽지 않다는 점이죠.

 그래서 아래와 같이  매일 진행할 사항에 대한 회의를 진행 하게 되었습니다.

 (1) 매일 아침 10~15분 가량 익일과 금일에 대한 각자의 진행 업무에 대한 스탠딩 미팅을 진행 한다.

      - HotFix 나 우선순위 변경, 문제 사항 확인, Bottleneck 확인 , 이것도 Scrum master가 리딩해야 합니다.

      - 요건 기준으로 Backlog를 작성했지만, 요건은 언제나 변경이 가능하다는 기준도 가지고 있어야 합니다. (가장 힘들죠)

  Sprint 하는 범위와 시간을 유연하게 관리하는 방법도 필요하게 되었습니다.

  

  칸반

  Kanban 이라고 들어보셨죠 , 쉽게 말하면 작업의 흐름을 시각화 하는 것입니다.

  예전 도요타 자동차 공장에서의 작업 흐름을 ...blablabla... 이건 나중에 찾아보시길 바랍니다.

  앞의 Backlog를 작성하고 나서, Backlog는 어느 한켠에 저장해 두고, 이제 Sprint 합니다.

 

 저는 그냥 주단위로 나눠서, 그 해당 주에 해야 할 것을 나눠서 Sprint 했습니다.

 나눠서 진행 사항을 관리하는 곳이 바로 Trello 였습니다.  

  이 트렐로를 잘 사용만 한다만, 프로세스 진행 사항을 한눈에 볼수 있어서 굉장히 좋습니다.

  저는 수년째 잘 사용을 하고 있고, 기본적으로 

 

  trello : http://www.trello.com

 

 업무는 주간내에 가능한 양만 관리하는 것이 좋습니다.

 작은 조작으로 나눈뒤에, 카드에 각 항목을 기입 한 후 벽에 붙인다.

 - 일반적인 예

     > To do, Doing, Done

 - 조금 세분화

     > To do > Analysis > Development > Testing > Deploy 

     > Ready(Cool,Warm,Hot) , Doing , Done

 - 보다 세분화 

    > Next -  Analysis(ongoing | Done)   -  Development(ongoing | Done)   - Acceptance(ongoing | Done)  - Prod

- 일을 작은 조각으로 나누고, 카드에 각 항목을 기입한 후 벽에 붙인다.

- 이름이 부여된 열을 사용하여, 각 항목이 작업 흐름에 어디 있는지 표시한다.

- WIP(Work in Process) 개수를 매번 제한한다.

- 각 작업 흐름 상태(단계)별로 작업 중인 항목을 얼마나 허용할 것인지 확실한 수치를 부여한다.

- 리드 타임(한 항목 완료하는 데 소요되는 평균 시간)을 측정하라!!

  그리고 난 뒤에 리드 타임을 가능한 짧고 예측 가능하게 만들수 있도록 프로세스를 최적화 한다. 

  여기에 Gantt charts 가 있었으면 좋겠다라고 생각했는데... 지원이 몇년째 안되고 있네요.

  그러던 와중에 plugin 이 나왔네요. 우왕

   elegantt.com : https://elegantt.com/trello/

시간이 지나면서 새로운 툴들이 많이 나오는 것 같습니다.  

더 나은 개발 방법론이라는 것은 보다 복잡한 것이 아닌 쉽고 단순해 지는 것인것 같습니다.

뽀모도로 같은... 암튼 팀작업을 보다 유연하게 잘 할 수 있는것은 진솔한 대화... 회식 입니다. ㅎㅎㅎㅎ(농담)

참고)

kanban : https://www.crisp.se/gratis-material-och-guider/kanban

So long Scrum, Hello Kanban : https://stormpath.com/blog/so-long-scrum-hello-kanban/

한달에 한번 Backlog 만들기  :   http://pitzcarraldo.github.io/articles/2014/05/08/goodbye-scrum-hello-kanban/