[ 스크럼과 XP ] 실무에서 적용 가능할까? 그 효율성은?

사이드 프로젝트를 하면서, 그리고 실무에서 프로젝트를 하면서 스크럼과 XP에 대해서 공부할 기회가 있었습니다.

스크럼, XP는 애자일 방법론들입니다. 이 책은 추천 받은 읽었던 책입니다.

스크럼과 XP 카테고리 컴퓨터/IT 지은이 헨릭 크니버그 (인사이트, 2009년) 상세보기

읽으면서, 실무에서도 적용 가능할까? 그리고 효율성은 어떨까? 하는 궁금증이 있었습니다.

실제 실무에서 적용을 해 본 결과는,,,

PM은 어떻게 생각할지 모르겠습니다. 팀원들은, 그저 스케쥴링 툴로만 생각하고 있는 듯 합니다.
어쩌면, PM과 팀원들 모두 스크럼과 XP에 대해서 목표를 두지 않고 있을지도 모릅니다.
스크럼과 XP가 목표인 것은 알지만, 데드라인이 있는 프로젝트에서는 큰 영향을 못 주네요^^

그리고 제품관리자의 의견이 큰 프로젝트에서는 프로젝트를 진행할때마다 다양한 변수가 영향을 주게 됩니다.
Product 와 Service 차이로 볼 수 있을 것 같습니다.^^ Service일 경우에는 제품관리자가 계속 옆에서
검토하고 예왜처리를 확인해줘야합니다. 수많은 User가 사용해야하는 Service 일 경우에는 제품관리자와
충분한 협의가 필요 할 것 같습니다. 하지만 책에서는 제품관리자는 멀리 떨어져 있어야 한다고 합니다^^

제품 관리자가 멀리 떨어져 있다면, 개발쪽에서는 빠르게 프로토타입을 만들어 낼 수 있습니다.
그리고 제품 관리자가 프로토타입을 보고 수정을 요청하게 됩니다. 이때 시관관리 리스크가 발생합니다.

아직은 어떤 방법이 옳은지 혼란스럽습니다^^;; Service 일 경우에도 제품관리자가 떨어져있고,
iteration에 따라 개발 Service를 확인해서 최상의 Service가 나온다면 원츄입니다!!!
But...데드라인은 항상 있습니다.


하지만, 책 내용은 정말 좋습니다.
프로젝트를 진행할때, 애자일한 진행을 할 수 있도록 도와줍니다.
프로젝트의 결과물을  윗선에 보여줘야하는 데드라인이 넉넉하고, 아직 아무도 시도해보지 않은 프로젝트라면
큰 도움을 줄 수 있을 것입니다. 소프트웨어 공학을 배우는 학생이라면 한번 쯤은 필독해야할 책 입니다.
대학 4년때에 UML를 접하고, "오~~" 했었는데, 그 때 애자일을 알았다면,,,ㅋㅋ 더 많은 Product를 만들었을텐데라는
생각이 듭니다.

실무에서는 적용해보려 노력하고 있지만, 아무래도 데드라인에 대한 팀원들의 압박, 그리고
각자의 스케쥴 관리에 대한 귀차니즘등이 가장 큰 방해요소가 아닐까 합니다.

PM이 업무에 대해 전체적으로 이해하고, 각자의 업무를 세분화하는데 가이드 역할을 충분히 해주어야 할 것 같습니다.
아...또 리더의 역할이 정말 중요해지네요^^

모두들 세상을 놀라게 하는 서비스, 소프트웨어 만드시길 바랍니다!!!