방법론은 프로젝트의 위험을 감소시키는 것을 목표로 합니다.
어디에나 적용 가능한 최적의 방법론이란 존재하지 않으며, 프로젝트와 팀에 따라
달라질 수 있습니다.
Agile 방법론이 화두 입니다.
하지만, 도입만 하면 저절로 잘 되는 건 아닙니다.
얼마만큼 방법론에서 제시하고 사전에 팀원과 약속한 활동 등을 잘 실천 했는가가
중요 합니다.
PM은 언제쯤 오픈 에 대하여 스스로 신뢰할 수 있을까요 ? 그리고 어떤 것을 통하여....
보통은 품질목표 또는 타 측정지표 등을 기준으로 고객과 오픈 에 대한 기준을 정하고 프로젝트를 시작 합니다.
PM을 경험해 보신 분들은 오픈 에 대한 확신을 언제 가졌는지 회상해보시면 어떨까요 ?
아마도 통합테스트 기간이 끝나가는데도 확신이 서질 않는 경우를 경험해보셨을 겁니다.
누군가가(Stakeholder) 잘되고 있어 ? 다음달 오픈 가능하지 ? 라는 질문에 우리는 자신 있는 대답을 했던가 ?
프로젝트 초반에는 오픈 에 대한 자신감 기대감은 높으나, 진행하는 과정에 그 기대감은 불안감으로 이어지며 오픈 에 대한 신뢰가 희미해지며 프로젝트 후반부에 힘들었던 경험 몇번쯤은 있었을 거라고 생각합니다.
그럼 이러한 문제를 해결할 수 있는 좋은 방법은 없는 걸까요 ?
Agile의 장점이 무엇인가? 라는 질문에 저는...
Agile 방법론은 타 방법론 보다 예측 가능성을 높여준다 라고 이야기를 합니다.
그리도 덪붙여 Agile 방법론만 적용하면 저절로 이루어지는 것은 아니라고 이야기 하죠..^^
Agile에 대한 가치는 애자일 메니페스토(http://agilemanifesto.org/)와
12개의 적용원칙(Twelve Principles of Agile Software)에 잘 나타나 있습니다.
Agile에서는 프로젝트 팀원과 고객이 함께 Product 에 대하여 완성해가는 Cycle을 개발시작(Sprint#1)부터 지속적으로 공유 및 Feedback을 하자 입니다.(가능하지 않을까요? 꼭 완성도를 높여서 고객에게 보여줘야 할까요?)
이 활동을 통합테스트 전까지 꾸준히 하고(이는 단위테스트 완료를 의미함)
통합테스트 에서는 진정한 시나리오 기반의 통합테스트를 하자 입니다.
위 그래프는 Agile vs Waterfall 프로젝트의 결함 식별과 잔존결함의 추이를 나타내는 그림 입니다.
반드시 이러한 결과가 나온다는것은 아니며, Waterfall 방식은 프로젝트 후반부에, Agile은 초반부터 결함이 식별됨을 강조하기위해 예측한 그래프 입니다. Waterfall의 그래프는 많은 부분 동감하리라 생각 합니다.
위의 Agile 방법론의 추이대로 팀이 움직일 수 있는가가 열쇄 라고 생각합니다.
이렇게 되면 아주 많은 기간동안(상대적으로) 우리 스스로 그리고 고객 또한 Product에 신뢰를 가지게 되며 승인테스트 및 Open에 대하여 아주 유리한 환경이 조성될 수 있습니다.(실제로 믿음이 생김)
Agile을 적용하며 Sprint기간내 단위테스트(3자,고객) 및 Feedback을 제대로 못한다면 Waterfall 방식의 프로젝트와 다를게 없다고 생각 합니다.
실제 Agile 방법론을 적용한 프로젝트를 보면 ①의 시점은 Waterfall 에서의 설계 단계이며 Agile 방법론에서는 Sprint#1 이며 이떄부터 Product backlog의 개발로 부터 테스트(3자,고객)에 의해 결함이 식별되고 Feedback이 관리 되어 ②통합테스트 단계를 단축되는 사례가 나오기도 합니다.
Sprint에 들어가면 개발자에게서 개발완료된 프로그램을 최대한빨리(바로) 테스트(3자, 고객)하자 입니다.(고이 모셔두지 말자)
테스트를 하면 Bug가 나오는데 그 Bug를 통해 팀은 배우게 됩니다. 그 배움은 미 개발 Product에 반영되어 실수를 줄일 수 있습니다. 이러한 활동은 Working S/W 로 Product이 유지됨을 신뢰할떄 예측 가능성을 높임(오픈 등..)
1. 남아있는 Product backlog 개수(진척) : 완료된것 보다는 남아있는 것에 관심을 가짐
(Burn-down chart)
2. 결함은 꾸준히 식별 되고 있는가(테스트:3자, 고객) : 적절한 결함 식별
(ex 요구사항, 설계+개발 : 5개/FP)
3. 미조치 결함(기능개선 등 포함)은 증가되지 않게 관리 : 결함은 빨리 처리할수록 비용이
적게들고 쉽게 고침
매일 Scrum Meeting 을 통해 공유하며 이는 Risk, Issue가 빨리 그리고 투명하게 식별되어 대책 또한 한발 빠르게 대처함 이런과정에서 오픈에 대한 예측 가능성을 아주 높일 수 있다고 생각합니다.
(팀원은 특히 개발자는 힘들어 할 수 있음.. 이런식으로 일을 해보지 않아서.... 나의 실적이 공개되어서... 비교되네...휴~~ 등...)
이런경우 개발자 입장을 고려 기존 방식대로 할것인가 ? -> 리더쉽 및 동기부여 등의 고민 필요합니다.
핵심 실천사항 및 가치로 이야기 하고 있는 부분을 얼마만큼 실천하며 프로젝트를 했는가? 를 함께 봐야 합니다.
위의 과정을 아주 잘 실천 했다면 분명 프로젝트에 긍정적인 요인으로 작용하여 분명 도움이 될것을 아주 긍정적으로 봅니다.
위 들어가며 에서 던진 질문. PM은 언제쯤 오픈에 대하여 스스로 신뢰할 수 있을까요 ?
위 <그림>에서 ⓐ,ⓑ,ⓒ,ⓓ 시점에 프로젝트 Open에 대하여 PM은 신뢰도를 얼마만큼 가질 수 있을까요 ?
Agile 프로젝트 에서는 ⓐ -> ⓑ -> ⓒ -> ⓓ 로 갈수록 오픈에 대한 신뢰(가능성) 계속 높아질것이고 ⓐ 시점만 보더라도 Waterfall 방식보다 훨씬 높을거라 생각해본다.
이런 그래프게 될수 있도록할 수 있는 팀이 진정한 Scrum 팀이 아닐까 생각 합니다.
¶™ Agile is a culture !
댓글 없음:
댓글 쓰기