프로젝트를 수행을 한다고 할 때, 내 기준으로 볼 때, 각 개발자들의 개발 속도를 측정하는 일은 매우 중요하다. 각 개발자, 아니 자신에게 일이 맡겨졌을 때, 이 일을 해결하기 위해서는 어느정도의 시간이 필요한지를 알아야 계획을 잡고 업무를 수행할 수 있기 때문이다.종료일을 잡고 그 종료일에 맞게 수행하기 위해서 이다.
물론 S/W 관련 연구자들이나, 개발자 중심의 판단 보다, 영업적 판단, 경영적 판단을 중심으로 생각하는 경우 위와 같은 일정 수립에서는 선 설계를 통한 명확한 구분을 가져가는 것이 좋다고 판단하는 경우가 있다. 미리 설계를 하며, 각 설계의 내용을 명확히 하면 각 등급별 표준 등위에 따라 나누더라도 완벽하지는 않지만, 매우 높은 정확도를 갖는 개발 기간 산정이 가능하다고 믿고 있다.
하지만, 여기에는 설계의 함정이라고 생각하는 부분이 있다. 사실 S/W를 설계하는 작업 자체가 난이도가 매우 높은 작업이다. 그래서 무슨 H/W 의 도면이나, 건설 도면 같이 생각하고 각 내용들을 구분지어 할 수 있다고 믿는데, 실제 S/W 개발 중에 나오는 설계는 위에 언급한 도면과 같은 상세 설계가 아니라, 무엇을 개발할지에 대한 대략적인 개발 방향을 잡는 용도라고 본다.
만약 위에서 언급한 블루프린트 설계도 같이 작성을 하려면, 최소한 현재 업무에 대한 전체 공정에 5~60% 이상의 기여를 하고 이와 같은 공정 자체를 3번 이상 수행을 해야 설계가 나올 것 같다. (천재적이거나 광범위한 경험을 갖는 사람이면 위의 한계점이 무의미할 수 도 있겠지만;;;; )
예를 들어 금융 관련 시스템 개발을 3년 정도하고, 엘리베이터 제어 소프트웨어 개발을 1년 정도 한 개발자가, 어느날 국가 세금 관리 시스템을 만든다고 생각해보자. 대략적인 설계는 가능하다. S/W 공학에서 이야기하는 UML이나, 패키지라고 통칭되는 각종 개발 방법론에 의거한 관련 산출물은 만들 수 있다. 그런데 그 설계안 대로 개발을 할 수 있을까? 아니 그 설계도를 보면서 개발 관련된 종료시점을 예측할 수 있을까?
사람 머릿속에서 만들어지는 각종 아이디어를 아예 표준화하여 생각하는 것 자체를 통일시키거나(모든 사람의 머릿속 생각이 동기화되어 동일한 생각을 하게해주는?) 오롯히 혼자 개발하며 동시에 머릿속 생각이 바뀜이 전혀 없다면 가능하겠지만, 실제 현장에서는 중구난방이다. 벽돌이나 전자부품 처럼 표준이라는게 매우 불분명 하다. 그것을 맞춰보려 개발 표준안을 만들지만 어디까지나 권고 사항이고 생각하는 방식이나 표현 방식은 제각각이다.
결국 표준화되지 않는 개개인의 머릿속에서 탄생하기 때문에, 모든 산술적 데이터는 개개인에 맞추어 나와야 하며, 그래서 개개인의 개발 속도가 매우 중요하다고 본다. 즉 이 개발속도 라는 것을 통해 단위 단위를 개개인에게 맡기고 산정하여 합산 처리하면 분명한 완료 일자가 잡히게 된다.
완료 일정이 잡히면 분명한 단위 단위가 예측되며 이후 개발 계획이 설 수 있다.
물론 개발 속도는 개발 외적인 부분에서 사용되지 않도록 장치를 잘 갖추어야 한다. 만약 개발 속도를 개개인을 평가하는 기준이되거나 급여, 기여도 등에 미치지 않도록 해야 한다. 팀을 구성해 팀 단위의 평가 형태로 가져갈 수 있게 하는 등의 안전장치를 확보하고 개개인의 개발 속도에 대한 평가가 필요하다.
2020. 1. 16. 오전 12:08