오늘은 형상관리 계획 수립에 이어, 지난주에 말씀드린 것과 같이

실제 수행단계에서 해야 할 일들이 어떤 것들이 있는지를 확인해보도록 하겠습니다.

실제 업무에서 해야 할 일이 무엇인지를 정의하는 것이 바로 계획이죠.

보통 일을 잘하는 사람과 못하는 사람을 구별해 보고 싶으면,

그 사람이 세운 계획들을 살펴보면 됩니다.

계획 수립을 많이 해보고, 잘하는 사람들의 공통점은

실제 업무에서 해야 할 일을 잘 정리한다는 것입니다.

품질보증 활동이든 형상관리 활동이든 개발 또는 테스트든 상관없습니다.

실제로 해야 할 일들과 그것을 어떻게 하겠다는 방법,

그 일을 하는데 어느 정도의 시간과 자원이 소요될 것이라는 예측,

각 작업 간의 연관관계, 이런 것들을 모두 포괄하고 있는 것이 좋은 계획이죠.

반면에 잘 못하는 사람들의 공통점은 계획 따로, 실행 따로 논다는 것입니다.

이 말은 실행단계에 해야 할 일들에 대해 잘 모르는 것과 같은 의미인 거죠.

경험이 없거나 막무가내식으로 닥치는 대로 일을 하므로 정리를 잘 못합니다.

이 얘기를 지금 하는 이유에 대해선 다들 아실 겁니다.

오늘 이야기하고자 했던 프로젝트 수행 단계(Do)에서

해야 할 일은 지난 글에서 나열했던 계획 단계에 명시했던 작업입니다.

아울러 계획대로 잘 진행되고 있는지 점검하고 수정하는 업무입니다.

실행 단계에 들어가면 보통 가장 먼저 수행해야 할 일은

프로젝트 팀원들(요구가 있을 때, 고객사 담당자들도 포함됨)에게

형상관리 계획서를 배포하고, 수립한 형상관리 계획에 관한 내용을 교육하는 것입니다.

프로젝트에 따라 고객사 담당자가 프로젝트 룸에서 같이 상주하는 때도 있고,

동떨어져서 수행할 수도 있고, 고객사 담당자와 관련자들이

프로젝트 수행팀과 함께 어우러져서 프로젝트를 진행할 수도 있습니다.

따로 떨어져 있을 경우는 보통 어떤 문서들을 달라고 요청하기 때문에

형상 서버에서 해당 자료들의 최신 버전만 보내주면 되지만,

함께 일하고 있을 경우는 고객사 담당자들도 형상관리 서버를 수시로 살펴보게 됩니다.

이런 경우는 특히나 고객사 담당자들에게도 교육하는 것이 필요합니다.

무엇이 어디에 있는지 찾아달라고 하는 번거로운 과정을

반복하지 않기 위해서라도 교육이 필요한 것이죠.

형상관리 서버 구조 및 관리 방안, 백업정책, 권한설정,

관련 프로세스 등에 대해 설명해주고, 이를 준수하지 않을 때

어떤 방식으로 제제를 취하겠다는 것까지 모두 알려주는 것이 좋습니다.

나중에 별도 시간을 소요해서 형상서버를 정리하느라

귀한 시간을 날려버리기 싫다면 특히나 더 그렇습니다.

 http://www.flickr.com/photos/ballyooo/2073958788/

통상적으로 개발자들은 문서 관리를 귀찮아하거나 짜증을 냅니다.

그래서 이런 업무들에 대해 반항하거나 잘 대응하지 않습니다.

예를 들면, 통합검색 파트의 PL이

형상관리 담당자(일반적으로 사업관리/품질관리 담당자가 맡게 됩니다.)에게 와서 물어봅니다.

통합검색 시스템의 데이터베이스 설계서를 다 작성했는데,

이를 어디에 올려야 하느냐? 사업관리/품질관리 담당자들은 실제로 이런 것에

일일이 대응해주며 보내는 시간이 꽤 됩니다.

계획서만 한번 읽어 봤어도 알 수 있는 일이고,

이에 대해 교육까지 실시했음에도 이런 식입니다.

Naming Rule에 맞지 않게 작성해서 올린 파일명을 수정하는데 보내는 시간도

만만치 않게 소요됩니다. 비효율적이지요.

그런 상황이 발생하지 않게 하기 위해서라도 교육을 해야 하며,

위반 시 제약을 부여하는 것은 꽤 중요한 일입니다.

그리고 위반사항이 많이 발생할수록 이를 주기적으로 점검하고,

위반사항(오류)을 관리대장에 기재하고, 이것을 수정하도록 담당자에게 지시하고,

잘 조치되었는지 확인하는 일련의 작업들의 소요시간이 증가하게 됩니다.

이는 절대 바람직하지 않습니다.

보통 형상관리 도구를 사용할 수 있으면, 생산성이 많이 올라가게 됩니다.

일련의 History 기록 및 조회, 권한관리 등을 쉽게 할 수 있고

무분별한 upload로 인한 자료의 상실이 발생하는 것을 막을 수 있기 때문입니다.

사실 프로젝트 규모가 일정 수준 이상 커지게 되면 형상관리 도구를 사용하지 않고

이를 관리하는 것 자체가 불가능에 가까워집니다.

그래서 가능하면 형상관리 도구를 사용하되, 교육 시 이에 대한 사용방법도

함께 전파하는 것이 좋습니다.

위에서 열거한 것처럼 정기적으로 형상서버를 모니터링하고,

현재 형상서버에서 베이스라인에 해당하는 자료들의 상태를 정리해 놓습니다.

예를 들어 통합검색시스템의 요구사항정의서가 고객의 최초 승인 이후에(통상 1.0버전이겠죠)

2번의 변경관리 프로세스를 수행하여 변경된 경우라면

베이스라인 산출물의 현재 버전은 1.2버전이 최신일 것입니다.

(수립한 버전 규칙에 따라 3.0이 되어 있을 수도 있을 것입니다.)

이 상황이 형상상태 보고서에 기록되어 있어야 합니다.

정기적으로 검토를 수행한 후 형상상태 보고서를 작성하고,

이것 역시 하나의 형상항목이므로 History를 관리할 수 있어야 합니다.

변경관리 프로세스에 대해서는 다들 알고 계실 것입니다.

고객사의 최초 승인을 득한 후, 산출물의 내용을 그냥 변경하면 안 됩니다.

요청자(일반적으로 고객사 담당자 또는 PL)로부터 변경관리 요청서를 받고,

변경관리 대장을 통해 이를 기록 및 상태를 관리하고,

경우에 따라 CCB를 소집하여 해당 변경의 승인 여부를 결정하고,

CCB 회의록을 작성하여 근거자료로 남겨두어야 합니다.

변경에 대한 근거 유지가 안 되거나, 적합한 사유와 기록 없이 변경되는 요구사항은

프로젝트 말기에 큰 리스크로 돌아옵니다.

흔히 고객사의 높으신 분들이 “이거 누가 이렇게 바꿨어?” 라고 나올 때

고객사 담당자는 절대로 책임지지 않습니다.

고객사 담당자의 요청으로 바꿨어도, 막상 뭔가 잘못되어 누군가

“책임”을 져야 할 상황에 몰렸을 때, "제가 변경하라고 했습니다"고 하는

고객사 담당자는 한 명도 없습니다.

고객사 담당자의 확인서명이 포함된 회의록(또는 그에 따르는 효과가 있는 문서,

예를 들면 고객사 담당자가 직접 작성해서 송부한 변경요청서)만이

이런 경우가 발생했을 때, 프로젝트 팀이 다치는 상황을 방지할 수 있습니다.

구두로만 왔다 갔다 하는 이야기일 때 아무 효력이 없다는 것을

프로젝트 경험이 조금이라도 있으신 분들은 다 알고 계실 것입니다.

<변경관리 프로세스 수립 사례>

변경관리 프로세스의 필요성은 프로젝트 초반에는

쉽게 납득이 가지 않을 수도 있습니다.

하지만 준수하지 않았을 때 가장 크게 리스크가 되는 부분이기 때문에,

반드시 준수해야 함을 고객사 담당자와 프로젝트 팀에 확실히 인식시켜야 합니다.

고객사에서 어느 정도의 억지를 부리는 것은 일상다반사이고,

요구사항을 추가한다거나, 이미 완료된 것을 고쳐주는 것은 흔한 일입니다.

단지 업무 담당자들과 프로젝트 관리자들 간의 조율이 끝난 후

어차피 해줘야 할 것이라도 변경관리 절차를 준수해야 들어준다는 것을

프로젝트의 모든 관련자들이 인지하게 하여

프로젝트에서 앞으로 문제가 생기지 않도록 하는 가장 좋은 방법입니다.

예를 들자면 “AA라는 요구사항을 BB로 바꾸려면

변경요청서를 써서 사업관리 담당자에게 제출해야 해”라는 사항을

고객사 담당자들까지도 당연하게 받아들이는 분위기로

초반에 몰아가야 한다는 것입니다.

물론 프로젝트 수행팀원들에게도 “절차를 준수하지 않는 추가 요구사항은 없다”고

확실히 인지시켜야 합니다. 이런 사항이 발견되어 문제화될 때

이에 대한 책임을 당신이 모두 지기 싫다면 프로세스를 준수하라 라는 겁니다.

형상관리 업무에서 해야 할 일 중 가장 중요한 2가지는 위에서 얘기한

¨주기적인 형상항목 관리"와 ¨변경관리 프로세스 관리(모니터링 및 승인을 추적 관리)"입니다.

이 2가지 업무를 프로젝트 기간에 반복적으로 수행하는 것입니다.

이 2가지가 사실상 전부라고 생각하셔도 될 정도입니다.

백업 같은 업무는 초반에 환경 구축하고, 이를 스크립트화 시켜서 백업을 수행하고,

이를 관리대장에 기재하기만 하면 되는 일입니다.

문제가 발생하지 않는 한 크게 이슈화될 업무가 아니죠.

마지막으로 개발 소스 형상관리에 대해 가볍게 얘기해보겠습니다.

사실 SI 프로젝트는 대부분이 신규 시스템을 구축하여 이행하는 경우입니다.

모든 개발과 테스트가 완료된 후 한꺼번에

고객사 시스템에 이행하는 형태로 진행됩니다.

개발 진행 중인 소스의 형상을 관리한다는 것은

사실상 불가능에 가까울 만큼 어렵고(당연한 얘기지만 사용하는 개발언어,

프레임워크 등의 요소에 의해 형상이 결정되어 버리기 때문입니다.)

이를 관리해야 할 필요성도 없습니다.

보통 개발 소스의 형상관리는 개발 PL들이 본인들의 파트의 특성을 고려해서

자체적으로 개발서버를 구축하고 오픈 소스 형상관리 도구(ex. Subversion)를

적용하여 관리하는 경우가 대부분입니다.

따라서 프로젝트 관리팀에서 건드릴 부분도 아니고,

이에 대해서는 감리도 크게 문제화 삼지 않습니다.

기껏해야 아키텍처를 수립하고 이에 따라

개발 작업을 진행하고 있는가 정도가 관심사항이기 때문입니다.

아직 적용도 안 한 프로그램 소스에 대해 문제 삼을 필요가 없죠.

여기에서 예외가 되는 경우가 있는데,

유지보수 프로젝트 또는 고도화 프로젝트의 경우에는 조금 다릅니다.

없는 시스템을 새로 구축해서 이행하는 것이 아니기 때문입니다.

고객사에서 적용하고 있는 형상관리 도구가 있을 때 이를 따라야 하고,

고객사에서 적용하고 있는 프로그램 소스의 Naming Rule이 있을 경우

이것 역시 준수해야 합니다.

이러한 때 형상관리 계획 수립(계획서 작성)이나,

형상관리 활동에서 이를 고려해줄 필요가 어느 정도 발생하게 되죠.

제가 얘기하지 않은 부분이 하나 있는데, 바로 이행 계획입니다.

개발이 모두 완료되고, 테스트가 완료되어, 고객사 담당자들의 승인을 득한 후

프로젝트 거의 마지막에 이루어지는 부분이죠.

사실상 SI 프로젝트는 인프라 영역과 개발 영역이 함께 발주되는 경우가 많고

(법적으로 분리 발주하긴 하지만) 이는 신규 하드웨어 인프라를 도입하면서,

개발한 시스템을 신규 서버에 탑재해서 운영하는 경우가 많습니다.

이는 프로젝트 초반에 이행 계획을 수립하기 매우 어렵다는 의미도 됩니다.

따라서 이행 계획 같은 경우는 보통 프로젝트 막판에

별도 계획을 수립해서 고객사의 승인을 득하고 진행하는 경우가 대부분입니다.

형상관리 계획에 포함시키지 않는다는 얘기입니다.

그래서 크게 논하지는 않았습니다.

지금까지 프로젝트에서의 형상관리 업무에 대해

경험한 것을 토대로 이야기해보았습니다.

다음 주에는 프로젝트 품질관리에 관해 이야기해보도록 하겠습니다.