- 전통적인 개발방식 과 스크럼의 차이
Waterfall의 해결책. 스크럼. 즉, 2~4주 단위로 끊어서 파일럿 형태로 프로젝트를 반복해서 진행하자
- 워터폴:
기획안은 바뀌는데 그렇다면 설계부터 다시 해야하나??
- 스크럼
2주 단위로 잘라서 진행을 해보자. 2주 단위의 프로토 프로그램을 발전시켜서 최종 결과물을 만들자
- 관련 참고자료:
* http://www.slideshare.net/BrandonK/agile-scrum?related=1
* http://www.slideshare.net/einsub/ss-27765585?next_slideshow=1
- 칸반
스크럼의 문제점은?
- 우리는 추정을 정확하게 하지 못한다. 그런데 아웃풋은 2주만에 나와야 한다!
- 오버헤드. 스프린트 플래닝은 개발자들이 관계 없는 기능의 토론을 끝까지 앉아서 보게 만든다
- 스크럼은 업무 시간에 제한을 둠으로써 생산성을 끌어낸다고 하지만, 중요하다면 크기에 상관없이 완성해야 한다. 이슈들이 예상한것보다 커진다면 스프린트에 과부하가 걸린다
- 비현실적인 예측과 끊임없이 발생하는 틀린 추정
-> 생산성 그래프는 끝이 급격하게 뾰족해진다
-> 막바지에 '최선을 다했다'고 말하기 위해 미친듯이 달리게 됨
-> 그 다음주에 회복할 시간을 가져야 하므로 생산성을 망가트린다.
- 스크럼과의 차이점
한번에 진행되는 일의 수를 제한
우선 순위가 낮은 이슈들을 아래배치
동시에 개발이 진행될수 있는 아이템의 수를 제한
- 관련 참고자료:
* http://pitzcarraldo.github.io/articles/2014/05/08/goodbye-scrum-hello-kanban/
* http://postgame.tistory.com/455
* http://www.jundols.com/wordpress/?p=493 (영어)
- 칸반 관련 무료 툴
* http://www.todo2.co.uk/
* http://kanboard.net/
* https://taiga.io/
- 회고
우리가 사용한다면?
서스테이닝 용의 프로젝트는 아닐지도 모른다. 그러나 신규 프로젝트라면 일부 채용하는것도 좋아보인다
룰을 100% 따르는 게 중요한게 아니라 적절히 자기 형편에 맞게 사용하면 될 것 같다
