그러한 점에서 SI 등에의 프로젝트의 경우는 어떨지 궁금합니다. 계약 기간의 연장이나 프로젝트 실패는 곧 리스크이고 손해일것인 데, 좀 더 장기적 안목으로 여러 불확실성이 야기시키는 리스크에 대한 보험으로서 리드타임이 짧은 팀, 혹은 애자일 팀을 끌여들이려는 시도는 없을까요?
----
그리고 조금 질문을 바꿔서, '애자일이 가능하다고 한다면, 구체적으로 무엇이 어떤 모습으로 가능하다는 뜻일까요?' 조금 더 각개
격파(?) 할 수 있지 않을까요? 고객회사와의 빠른 피드백? 실질적인 가치를 매일 전달하는 개발? 유닛테스트 & TDD? 지속적인 디자인 개선? 지속적인 통합?
페어 프로그래밍? 프로세스 개선을 위한 매일매일의 노력? 혹은 이를 가능하게 하는, 변화에 대해 포용하는 사람들의 마인드? 10%의 애자일, 30%의 애자일, 60%의 애자일, 80% 이상의 애자일이 있다면, 각 스펙트럼 대비 모양새들이 어떨지가 궁금합니다. :)
The Goal을 연관시킨 면이 매력적인 발상이었습니다. 또한, 밑줄 친 부분은 매우 실용적인 문제 의식입니다. 그리고 '각개
격파'로 논의하자는 것도 실용적인 발상이죠. 토론프로에서 모호한 논의가 이어질때 사회자들이 끌고 가는 방향이기도 하죠. 그 뒤에 어떤 분이 약간은 모호한 글을 달아뒀길래.. 제가 좀 구체적인 이야기로 쓰레드를 이어갔습니다.
저는 실제 SI 프로젝트에서 애자일 선언에 입각한 접근을 행해서 효과를 거둔 바 있습니다. 정확하게는 현재도 거두고 있죠. 그 중에서 하나를 소개하자면 OPPM(One Page Project Management)를 보고 인용한 것인데 프로젝트 계획 시점에서 전체를 다루는 WBS는 고객사 내규가 허용하는한 구체적인 액티비티는 명기하지 않고 목적 중심으로 작성했죠. 그리고, 실행계획은 스프린트라는 반복주기 단위로 처음에는 2주 단위.. 그리고 프로젝트 중반 이후부터는 4주로 했다가 현재는 6 주 단위로 작성합니다.
필연적으로 변할 수 밖에 없는 부분을 조기에 고정하려고 욕심을 부리다가 소모하는 시간이
following a plan 이나 comprehensive documentation에 해당하고 그 시간을 아끼면
working s/w를 만드는데 쓸 수도 있고, 변화할 부분을 고정하지 않았기에 Responding to change에 유리하죠. 계획의 2단 분리는 일정 변경으로 유발할 수 있는 고객사 결제 등을 피할 수 있어서 시간을 벌어주었죠. 비슷한 사례 중의 하나로 요구사항 범위 확정건이 있는데요.
우리는 12주 안에 결과를 만들어 보여줘야 할 일이 있었는데요.
문제는 고객도 잘 모르는 요구사항에 대해서 정의하고 만들어야 한다는 점이었습니다.
그런 상황에서 지나치게 요구사항을 정의하고, 필요한지 어떤지도 잘 모르는 기능을 위해
UI 프로토타이핑이나 다양한 계층의 현업 인터뷰 소집으로 인한 시간 소비가 위험해보였습니다. 하여.. 2주만에 요구사항에 대한 최소한의 검증 기준만 세워두고 모호한 것은 바로 구현에 들어갔습니다. 모호한 것 우선해서 개발을 했죠. 그래서 모호한 것은 대충 구현된 프로토타입(throw-away가 아닌)을 보여주고 컨셉 불일치부터 확인을 했습니다.
그런 후에는 살을 붙이면 되었고, 결국 빠듯해보이던 일정에 무리없이 구현을 할 수 있었습니다.
가장 큰 성공요인 중에 하나가 고객과 다른 생각을 하지 않는다는 점을 주기적으로 확인하는 과정에 있었고
그 매개체는 working s/w 였습니다. 물론, UI나 API요소가 강한 것은 그 부분부터 구현했고, 저장방식이 중요한 녀석은 DB 스키마나 클래스 자료구조부터 구현해서 보여줬죠.
이올린에 북마크하기
이올린에 추천하기