개발방법론 유감 2/3

  앞서 얘기 하고자 했던 것은 우리가 개발방법론이라는 것을 여러가지 도입해서 사용하고, 또 각각 방법론을 조합해서 사용하기도 하지만, 실제 얼마나 도움이 되는지는 안따지고 막연히 최면에 빠져 사용하는 게 아닌가 하는 점을 들었다.
과연 생산성이 올라가고, 품질이 높아졌는가 하는 것이다. 

오히려 문서 작성으로 개발자를 괴롭히고는 몰라서 그런다. 능력이 없다라고 하면서 억지 춘향을 부렸다고 나도 양심고백을 하면서, 다른 PM 들도 다르지 않을 것이라고 감히 생각한다.

 

 

  혹 동의 못하시는 분들에게, 한가지 예를 들고 넘어가자. 처음부터 개발하지 않고, 2차 또는 3차 개발 사업에 투입되었을 경우, 그 전 산출물을 얼마나 참조하는가? 그 많은 종류의 산출물 중에 몇가지나 들쳐 보는가? 다른 문제이긴 한데, 그 산출물의 내용과 실제 확인한 내용과는 일치하는가?

솔직히 DB 레이아웃 빼고 없다-쩝 너무 극단적인가.ㅠㅠ 
실제 소스와 맞지 않는 산출물을 하나라도 발견하는 순간 - 반드시 있다 - 무슨 복권 당첨된 것 처럼 호들갑을 뜰면서 그 산출물의 신뢰성은 없다라고 정의하고 더이상 보지 않으며, 고객 앞에서 전 개발팀을 엄청 씹는다.

 

  아직도 공공기관에서 환영받고(?) 있는 CBD 방법론도 잠깐 거론해보자. 잘 알다시피 CBD 방법론의 가장 큰 특징은 컨포넌트화 하여 재사용함으로써 생산성을 높이고 유지보수를 쉽게 하는 데 있다. 하지만 우리나라 대부분 공공기관은 우리나라에 유일한 곳이고, 따라서 업무도 유일해서 재사용은 힘들다. 산출물만 CBD 인 것이다.

 

 

  여기서 "개발방법론은 SW 개발을 성공시키는 필수 방정식이다."에 대해 이렇게 생각한다. 방법론으로 성공한 프로젝트가 없다면 우리 공공 SI에 맞지 않는것이다. 그걸 충실히 이행했건 아니건 간에.
꼭 유행하는 방법론, 외국에서 유명한 사람이 - 우리와 정책, 사고방식, 문화, 사상이 다른 사람들이 만들어낸 방법론을
굳이 적용할려고 하지 말자. 그들은 우리를 위해서 그 방법론들을 만든게 아니라 팔아서 자기들 돈벌려고 만든 것이다.
그렇다고 없이 하자는 것은 아니다. 그것들을 나름 새롭게 조합해서 사용하는 것을 허용해 줘야한다. 산출물도 현실화 하였으면 한다. 이에 감리들도 실제 개발되는데 최소한의 추적성이 보장된다면 인정하였으면 한다.

 

 

  나는 반드시 만들어져야 하는 산출물 재사용이 가능한 유일한 산출물이 있다면, 그것은 업무분석 산출물이다. 개발하고자 하는 업무의 분석만 제대로 되어있다면, 이후 추가 또는 연차 개발에 대한 생산성은 틀림없이 높아진다. 정확한 업무를 분석하였으므로 품질도 높을 것으로 판단된다. 내가 발주처 담당자라면, 이 산출물만은 반드시 챙길 것이다.

 

  그리고, 오해하지 말아야할 사항은 개발방법론이 필요없다는 것이 아니라는 것이다. 우리의 현실은 회사에서 개발방법론 교육에 투자하지 않는다는 것이다. 메이저 SW 회사 빼곤 대부분일 것이다. 사실 회사가 성장하려면 반드시 투자해야하는 부분이다. 해서 개발방법론을 적용했더니 훌륭하게 성공했다는 경험을 할 수 있게 하여야 한다. 하지만 슬프게도 그러기 어려운 환경이니 PM이나 PL 본인들이 스스로 투자해야한다. 욕심부리지 말고 나름 로드맵을 세워 차근차근 기본기를 다져 나가야한다고 본다. 해서 [생각하기 2] "내가 프로그램을 짜기 시작한 후 상당 기간 동안은 나름대로의 방법으로 알아서 개발했다." 가 프로젝트의 성공의 요소가 되게 하면 더할나위 없겠다.

SI 프로젝트를 수행하면서 개발방법론적용하고 - 방법론을 적용한다는 것은 개발단계마다 산출물이 나오는 것을 의미하는데, 이 산출물 작성을 고객이 원해서라든가, 유지보수를 위해서가 아니라 개발의 생산성을 위해서라는 것을 명심해야한다.

 

  따라서 PM은 고객을 적당히 속이는 기술이 필요하다. 고객이나 감리가 설득이 되면 좋겠지만 그렇지 않다면 꼭 필요한 문서는 신뢰성과 품질, 형상관리를 철저히 하는 반면, 그렇지 않는 것은 최소한의 요구만 만족시키는 수준에서 적당히 문서를 작성하여 수행하는 지혜가 필요하다. 

< 다음 편에 계속 >