- 방법론과 관계없이 모든 요구사항을 관철시키려고 하는 고객을 어떻게 설득할 것인가?
- 이터레이션 마다 결과물을 보여주니, 고객의 feedback 이 강력할 수 있습니다
A. 고객의 요구사항이 개발의 방향을 벗어 나지는 않았는지 우선 확인합니다.
B. 고객의 요구사항에 공감하며 반영의 의지를 보입니다.
C. 하지만, 이때 새로운 요구사항이 얼마의 일정이 소요하게 될 것인지를 확인해서 알려주어야 합니다.
D. 팀 미팅을 통해 일정을 추정해 냅니다.
E. 고객에게 소요기간을 이야기하며, 우선순위를 정하도록 합니다. 이로 인해 일정이 변경되는 부분에 대해서 알려준 다음, 선택하게 합니다
- 팀 맴버 구성 비율을 어떻게 가져갈 것인지?
- 기존의 role base의 인원구성으로 whole team 이 가능할 것인지 고민하셔야 합니다.
A. 분석과 설계가 가능한 개발자, 개발할 수 있는 DBA, 모델링이 가능한 AA가 함께 하면 이상적입니다만, 그건 말 그대로 이상적.
B. 팀원들만으로 개발 전영역을 커버하기에 부족하다면, 외부에서 점검/지원해 줄 수 있는 비상주 인력을 소싱합니다.
C. 특정 역량이 부족해 팀 개발이 삐걱일 때는 팀 마스터가 Rain Maker 역할을 할 수 있어야 합니다.
D. 특정 역량이 뛰어난 팀원이 있을 경우에는 구심에 놓고 적극적으로 활용합니다. (ex. 뛰어난 AA : 공학도구나 연계, 특정 개발분야에서 최대 퍼포먼스를! 훌륭한DBA: Data모델링이나 DB설계등에서 최대 퍼포먼스를! 등등등)
- 기존 방법론에 충분히 익숙한 프로젝트 리더 들의 사고 전환을 어떻게 할 것인가?
- 대시보드와 ToDo 정도로는 불안해 할 수 있습니다.
A. 이번 프로젝트를 성공적으로 만들기 위해서, Agile 방법론이 여타 방법론보다 어떠한 장점을 줄 수 있는지 스스로 비교 판단하게 유도합니다. 만일 장점이 단점보다 크지 못하다는 결과가 나오면 방법론 선택이 잘못된 셈입니다. (이래서는 안되겠죠)
B. 애자일을 불안해 한다면, 정확히 불안해 하는 요인이 무엇인지를 파악해서, open 된 곳에서 해당 내용을 볼 수 있도록 만듭니다. 그리고, 팀 원 들은 해당 사항에 대해 어떻게 생각하는지 의견을 모읍니다.
C. 특별히 작성했으면 좋겠다고 생각하는 문서가 있으면, 팀원과 협의를 합니다. 단, 이때 팀원들에게 부하를 주는지, 개발을 방해하게 되는지 살펴보고 판단합니다.
- 앉아서 '아~ '하고 입만 벌리던 고객을 어떻게 참여시킬 것인가?
- SI 기업에는 업무 전문가들이 고객보다 업무를 잘 알아서 고객은 자신이 하는 업무를 몰라도 알아서 구축해 주는 수준입니다.
- 고객은 자신을 괴롭히는걸 좋아하지 않습니다.
A. '고품질의 제품(서비스)전달'을 원한다면 고객이 적극적으로 참여해 주었을 때 보다 더 가깝게 실현가능하다는 점을 이해시킵니다.
B. OO회사는 알아서 다 해준다던데... 하는 식으로 반응하게 될 경우, 고객을 좀 더 번거롭게 만드는 점에 대해 서는 고객과 적극 공감하며, 대신 고객에게 좀 더 빠른 피드백과 전체 비용이익을 더 향상시켜 줄 수 있다는 점을 부각시킵니다.
C. 프로젝트 성공에 대한 열망이 강한 고객일 수록 반감없이 쉽게 끌어들일 수 있다는 점과 일치합니다.
- 타협하고 싶어진다. (자동화된 Test는 어려우니까 빼고…etc)
A. 타협은 할 수 있지만, 이득을 얻지 못하게 되는 부분이 어떤 점인지는 고객/팀원 모두 인지해야 합니다.
B. 그리고, 최대한 적용할 수 있는 부분까지 적용하기 위해 노력합니다. (ex.특별히 민감한 모듈에 대해서는 자동화 테스트를 구축)
- Agile 에 대한 개발자들의 오해와 마음가짐
- Agile 하면 산출물 안 만드는 거 아냐? 라고 생각하는 사람들이 적지 않습니다.
- 만들어야 한다고 하면 급 실망해하며 결국 비슷하잖아... 라고 돌아서기 쉽습니다.
A. 애자일의 가치가 산출물 미작성에 있는 것이 아님을 인식시킵니다..
B. 경우에 따라서는 사용하는 개발 방법론이 Agile 임을 숨길 수도 있습니다. (단, 이런 경우 일부 개발자에게 줄 수 있는 'Agile 프로젝트로 진행한다'는 자긍감은 주지 못하게 될 수 있습니다.)
C. 필요한 산출물은 팀원이 공의의 개념(Consensus)을 갖기 위해서임을 인지시킵니다.
D. 불 필요한 산출물은 최대한 제어되고 있음을 이해시킵니다.
- 기법 활용 미숙 (User story ? Story point?, 스크럼 미팅? CI?)
- 책 읽고, 교육 한번 받고 진행하면 헤메기 딱 좋습니다. 기존 방법론의 갑갑하지만, 타이트한 틀이 없기 때문입니다.
A. 첫 번째 적용 프로젝트일 경우 피할 수 없음. 단, 보정에 대한 감을 빠른 시일 내에 갖을 수 있도록 노력하며, 현황을 고객과 공유할 수 있는 용기를 가져야 합니다.
B. 프로젝트 성공을 위해 할 수 있는 최선을 다할 예정임을 이야기하고, 지원을 얻어야 하겠습니다.
C. 이 때, 이를 볼모로 하는 고객의 낚시 행위에 대해서 적절히 대응 해야 합니다.
- 외부 감리는 어떻게 설득할 것인가?
- 외부 감리가 당황해 할 수 있습니다.
A. 외부 감리를 받아야 하는 프로젝트의 경우 반복주기(Iteration)을 따로 잡아, 감리용 산출물 작업을 할 수도 있습니다.
B. 외부 감리를 받아야 하는 프로젝트는 우선은 애자일 방법론 도입은 미루고, 애자일 기법(Practice)도입을 선행 하는 식으로 프로젝트를 개선시킬 수 있습니다. (Daily Build, CI, TDD, Pair work etc)
C. 자칫 무모하게 들릴 수 도 있지만, 애자일 도입 조직이 큰 조직일 경우, 외부 감리 조직에 대해 로비를 해서 자사의 Agile 방법론이 감리 방법론중 하나로 새롭게 적극 반영 될 수 있도록 하는 작업을 진행합니다. (아직은 초기단계라 선점 가능함. S모사나 L모사, 또 다른 S모사 같은 경우 충분히 가능하다고 봅니다)
- SI에는 분석 설계가 끝난 다음에 개발자가 투입되는 경우가 많습니다. 하지만, 이는 대부분의 Agile 방법에 상치됩니다.
A. 우선은 프로젝트 규모와 방향에 대해서 후 투입된 개발자들이 이해할 수 있게 하는 것이 중요합니다.
B. 이를 위해 분석/설계자들과 Workshop 을 함께 진행하는 것도 하나의 방법이 될 수 있습니다.
C. 요구사항(혹은 SRS)에 대해 분석/설계자들과 개발자들 각각의 개발 SIZE 에 대한 논의를 진행해 볼 필요가 있습니다.
D. 이 때 필요하다면, 일부에 대해 Planning Poker Game 등을 사용해서 각자 비슷한 수준으로 생각하고 있는지 확인해 봅니다.
E. 크게 다른 부분이 나올 경우는 공의가 이루어지지 않았거나 분석에서 추정을 잘못한 경우입니다. 가급적 빠른 협의가 필요합니다.
- 초급 개발자들이 많은 프로젝트는 어떻게 해야 하나요? 문제를 일으키는 개발자가 있을 경우에는요? 그리고, 인원교체가 쉽지 않은 경우에는요?
개발자 5명 정도의 소규모 팀이라면 1명의 포션이 20%입니다. %가 큽니다.
A. 이론적인 솔류션은 '해당 팀원의 문제가 무엇인지를 파악. 이를 해결해 주고 함께 나아간다' 입니다.
B. 하지만, 상황에 따라 팀원을 교체하는 것이 답일 수 있습니다. (이때, 다른 팀원들도 납득할 만한 상황이어야 합니다)
C. 실제, 0.5 MM 나 그 이하의 Man Power 를 내는 팀원의 경우, 교체가능한 인력 수급문제나, 새로운 인력의 프로젝트 적응기간 필요로 인해 '교체'자체가 난감한 경우가 있습니다. 이럴 때 조차라도 팀원 교체, 내지는 팀원 규모자체를 줄이는 방향으로 MM를 맞추는 것이 비용적인 측면에서 이득이 될 수 있습니다. (여기서의 비용은 프로젝트 비용, 커뮤니케이션 비용 등을 말합니다)
- 혹시, 사내에서 필수로 사용해야 하는 프로젝트 프로세스나 시스템(진척도,공정관리 등등)들은 어떻게 할까요? 예외로 할까요?
A. 팀의 마스터(혹은 PL, PM)가 해결해 주어야 하는 문제중 하나.
B. 경량화된 형태로 팀을 운영하는데에, 해당 프로세스가 주는 부담을 최소화 해야 합니다.
C. 관련팀과 협의하여 사용 예외로 처리하고, 대신에 대체할 산출물을 찾습니다.
D. 혹은, 프로젝트 종료 후 애자일 산출물을 바탕으로 후 기입하는 방식을 따르게 할 수도 있습니다.
F. FP 계산을 요구할 경우, 마찬가지로 대체 추정 가능한 산출물을 준비합니다. (ex.Stroy Point의 workday/MM 변환등)
- '전체비용절감'을 생각하는 Agile에서 봤을 때, 배포전까지의 비용이 오히려 예전보다 높을 수 있습니다. 구축만 하고 빠지는 프로젝트의 경우 그걸 감당하려는 PM이나 팀을 만들 수 있을까요?
A. 애자일 실천방법들(TDD, CI, PAIR Programming(=work) )등을 적극 도입할 경우 개발기간이 일정 부분 늦어질 수 있습니다. (연구에 따르면, 숙련된 개발자들로 TDD만 사용했을 때에도 20%정도 가량 개발진척이 늦어질 수 있다고 합니다)
B. 이 때, 가장 좋은 방법은 고객에게 선택지를 내미는 방식입니다. (Practice 사용하면 결함수정비용을 포함한 전체 개발비용을 어느 정도 감소시킬 수 있는지, 연구자료/조사자료를 제시합니다. 도입/미도입에 따른 효과/비용을 이야기해서 고객이 선택하게 합니다.)
C. 가장 좋은 방법은 이런 내용을 바탕으로 차별화된 방식으로 수주를 하는 것이라 생각합니다.
D. 향 후 분리발주가 정착되면, 이를 응용해서 구축 비용을 분할해서 받는 것도 가능해 질 수 있겠습니다.
E. 동일 팀이'기획 -> Product 개발 -> 출시 -> 유지보수/기능개선'으로 지속적으로 운영되는 애자일 팀과 '개발팀 <> 유지보수팀 분리'의 SI 팀이 확연하게 다른 부분이 바로 이 부분입니다.
개인적인 SI 애자일을 도입하는데에 Plus 가 될 수 있다고 생각하는 방향은, 인력과 리소스를 모아 사내에 Star Team 을 만들어서, 다른 사람들이나 팀이 따라오거나 본을 삼을 수 있도록 만드는 것인 것 같습니다. 그리고 이 때, Star Team 의 작업방식을 투명하게 공개해서, 쉽게 따라할 수 있도록 하면 더 좋을 것 같습니다.
이상, Agile을 SI에 도입하기 위해 고려해야 하는 질문들에 대한 개인적인 의견이었습니다.
'이생각 저생각' 카테고리의 다른 글
| 일을 즐거워 하는 사람이 일을 잘하는 사람이 되지 못하는 이유 (5) | 2009.03.01 |
|---|---|
| Agile Development, Explained (0) | 2009.02.27 |
| 애자일(Agile)과 SI 프로젝트, 해결해야 하는 질문들, 잊어서는 안되는 원칙들 (2) | 2009.02.08 |
| 화난 원숭이 실험 (Angry Monkey Experiment) (1) | 2009.01.20 |
| 해커에서 고객까지, SW 사용자의 분류와 대처방법 (0) | 2009.01.09 |
