'최종형상'에 해당되는 글 1건

  1. 2015/02/15 글뻥 Agile / Waterfall 보다 더 중요한것 (2)
2007년정도부터 마음속 깊은 빡침을 느낀것이 있다면,
고객이 요구사항을 바꾼다는 것.

"인간 마음이 가지고 있는 메커니즘중 하나인 "식상함"이 가장 큰 원인이라 할 수 있는데..."
(물론 오류가 인지하지 못할 만큼 아주 작게 있다는 전제로... 오류가 있다면 이미 망한거임...)
라고 생각하고 "Agile"을 도입하기 시작하였다.

하지만, 점차적으로 발생하는 문제가 있었으니... 

첫째, CMMI Lv. 4 정도 되는 회사에서 어느 정도 트레이닝이 된 동료들과의 Agile은 그리 어렵지 않은 수준이었지만, 그럼에도 튕겨져 나가는 팀원들이 있었는데, 막상 CMMI Lv. 1정도 되는 조직에서는 Agile이 불가했다. 이는 직무 전문성이 현저히 낮음에 문제가 기인한다.
한명의 개발자를 개발자 다운 개발자로 트레이닝 하기 위한 비용을 무시했던 것이다.

둘째, Agile의 본질은 작지만 수 많은 Try / Fail을 겪으면서 체험적 학습을 기반으로 하고 있는데, 한가지 간과하고 있는 것이 있다면 "직관"이다.
직관이라는 것은 경헙과 학습에서 나온다.

셋째, Agile은 최종형상을 찍고 일하지는 않는다. 잘못하면 목적없이 표류해버리기 쉽다.
교육과 경험의 수준이 다른 사람들을 모아서 공통된 관심사를 끌어내는 것은 궁극적으로 비용이 매우 많이 드는 일이다.

Agile하게 일한다는 것은 커뮤니케이션 비용을 줄이려는 노력이고, 이러한 노력을 하려면 최종형상에 대한 상호이해가 필요하다.
팀으로 일한다는 것에 깊은 회의감이 드는 차에 최근에 모 크레이 애니메이션 회사의 일하는 방법을 보며 조금은 영감을 얻었다.

그 회사의 방침은 어떠한 일이든 "무엇을 만들지 최종형상"을 만들고 일을 시작한다.
이때 사용되는 방법이 Academy 즉, 워크샾이다.

이 회사에서는 약 2주간 어떤 일을 하게될지 모든 구성원들이 모여 워크샾을 진행한다.
구체적으로 형상이 나오면 그것을 다듬는 작업은 구성원들과 함께 모여서 모의 시뮬레이션을 2주간 빡시게 진행한다.
그리고나서 일정을 만든다.

이렇게 써놓고 보니, SK C&C 다니면서 Agile이 잘됐던 이유가 설명되기도 하는데...
그곳에서는 제안서 작업이 떨어지면 통상 1달전부터 작은 방에 모여서 PM과 PL들이 제안작업을 하는데,
이때 플랫폼을 쪼게고 쪼게서 아키텍쳐를 그려놓고 외부도입기술과 자체개발기술을 나열하고 어느 영역을 누가 맡을지 일정과 비용에 대한 견적까지 뽑아낸다.

이처럼 최종형상이 나온뒤에서야 업무에 투입되고 투입된 PL들을 중심으로 프로젝트는 돌아간다.

이때는 Waterfall이든 Agile이든 방법론이 중요해지지 않는다.
다시말해 프로세스자체가 스스로 진화하거나 체화되기 시작하기 때문에 CMMI Lv 4. 정도의 수준으로 일을 할 수 있었다.

중요한건 최종형상에 명확한 Big Picture이다.
그리고나서 어떻게 이걸 맞춰갈지에 대한 상호 협의다.
그 협의 방법이 방법론이라 일켰는 것일 뿐이다.
2015/02/15 15:19 2015/02/15 15:19