출처 : https://subokim.wordpress.com/2011/10/07/project-qualify/
- IT의 중심에서
프로젝트 품질관리
PMP 시험을 준비하다보면 ‘프로젝트 품질관리’라는 것을 접하게 됩니다.
프로젝트 품질관리는 범용적으로 통용될 수 있는 내용이지만, 대부분은 SI 현장에서 많이 응용되고 있습니다.
아래 내용은 SI를 하면서 프로젝트 관리에 대해 느꼈던 경험들을 정리했습니다.
궁금해하시는 분들께 참고가 되었으면 좋겠습니다.
프로젝트는 살아있다.
상처를 받기도 하고, 어둠의 세계로 빠져 돌아오지 못하기도 한다.
서비스의 LifeCycle에 따라 운영이나 후속프로젝트로 잘 이어져야 한다.
사고난 프로젝트를 수습하러 들어가보면, 프로젝트 품질관리가 제대로 되고 있지 않은 경우가 태반이다.
왜 그럴까?
1990년대까지 SW는 HW 납품물의 일부였다. 그래서, 건설공정 관리를 본따서 프로젝트를 관리했었다. 제대로 관리가 될 리가 없다. 2000 년대부터 인터넷 기반의 사업이 급증하면서, SW 는 HW와 분리되어 그 자체로 존재가치를 인정받게 되었다.
그러나, 개발 과정을 관리하고 성과의 품질을 측정하기 위한 “노하우”는 여전히 발전되지 못했다.
어떻게 해야 할까?
- 프로젝트 품질관리란 무엇인가?
- 왜 해야 하나?
- 무엇을 관리해야 하는가?
- 첫째, 종료일(시간)을 관리해야 한다.
- 둘째, 자원을 관리해야 한다.
- 이렇게 시간과 자원을 투입해서 만들어내야 하는 산출물은 무엇일까?
- 프로그램 소스와 ERD 가 결과물이다.
- 설계도를 만들어야 한다.
- 문서보다는 주석이 효과적이다.
- 어떻게 관리해야 하나?
- 품질관리는 누가할까?
- 품질수준 평가는 프로젝트의 최고 결정권자가 내릴 수 있는 권한이다.
- 이해 당사자가 아니라면, 품질은 관리되어 지지 않는다.
- 프로젝트의 품질관리는 End Image 로부터 거꾸로 출발한다.
- 어떻게 반복할 것인가?
- 결언
– 품질관리란 프로젝트가 목표 품질을 획득하기 위한 일체의 과정을 말한다.
참고로 개발방법론은 품질관리가 아니다. 개발방법론은 개발을 위한 도구이며, “본질”은 아니다.
아직까지 “프로젝트 품질관리”는 “시스템”이 아닌 Project Manager 의 사랑과 열정에 의존하고 있다.
예를 들어보자. MMORPG 나 “차세대 은행권” 프로젝트와 같은 “Mega Project”들은 “제대로 된 품질관리” 없이는 끝낼 수 없는 프로젝트 들이다.
여러개의 Framework 상에서 각각의 component 와 module을 분리해서 개발하고, dependency를 감안하여 단위테스트와 통합테스트를 수행하지 않으면, 어디서 어떻게 누수가 되고 어디를 디버깅해야 하는지 알지도 못할 만큼 프로젝트 규모가 크다.
“왜 해야 하냐구? 품질관리를 하지 않으면, 프로젝트는 끝나지 않는다.”
프로젝트는 시간과 자원이 투입되어서 가치를 만들어내는 과정이다.
끝나지 않는 프로젝트는 관리할 수 없다.
프로젝트는 “정반합”의 과정을 거쳐야만 한다.
오랫동안 유지되는 프로젝트 들은 “마디”를 잘라, 종료일을 정해야 한다.
목표 품질에 도달하지 못하면, 종료일을 미루고 품질을 높이기 위해 초점을 잃어버린 시점으로 되돌아야 한다.
기능을 고도화하고, 통합하고, 품질을 높이는 작업은 반복적으로 이루어져야 한다.
종료일이란 곧 “목표 품질 수준”이라고도 할 수 있다.
목표 품질 수준에 이르지 못했다면, 프로젝트는 종료되어서는 안된다.
따라서, 초기에 적정 프로젝트 품질 수준을 잘 정의해야 한다.
“개발자들이 기본자원이다.’는 당연한 이야기는 뛰어넘자.
프로젝트 단계들을 잘 수행하기 위한 모든 input item 들이 투입자원이다.
– 분석이 잘 끝나기 위해서는 ‘목표 이미지(Target Image)’가 매우 중요하고, 설계가 잘 끝나기 위해서는 ‘기술에 대한 insight’가 매우 중요하다.
– 개발이 잘 끝나기 위해서는 ‘개발환경’과 관리툴이 중요하다.
– 그리고 상용화를 잘 끝내기 위해서는 ‘Test’와 ‘Aging’이 중요하다.
– 유지보수를 잘하기 위해서는 손쉬운 운영 architecture와 development document, comment 등이 중요하다.
사람을 투입해서 수행해야 하는 activity resource가 진짜 투입자원이다.
“서비스가 잘 되어야 해요.” 이렇게 이야기하지 말자.
실패로 끝난 프로젝트를 수습하러 들어가면 제일 먼저 확보하는게, “프로그램 소스”와 “ERD”이다.
이 두 가지는 PM과 QAO가 관리해야 할 처음이자 끝이다.
ERD 의 최종본은 “Database”로부터 Reverse Engineering 을 하면 얻어낼 수 있다.
만일 제대로 된 DB가 없는 경우라면, 고객 인터뷰를 통해 요구사항으로부터 테이블을 새로 설계할 수 있다.
하지만, “프로그램 소스”는 그렇지 못한 경우가 대부분이다.
소스를 훌륭하게 관리하는 것은 좋은 개발환경을 갖춰야만 한다.
하지만, 거대한 프로젝트의 경우 이 두가지만 가지고는 되지 않는다.
“설계도”가 없으면 굉장히 많이 헤매야 하고, 시간도 많이 걸린다.
설계도를 그리는 방법은 여러가지이다.
기본적으로 HW 리소스를 파악할 수 있는 1)“시스템구성도”, ip와 접근 권한을 알 수 있는 2)“네트워크 구성도”, 트랜잭션의 흐름을 파악할 수 있는 3)“어플리케이션(소프트웨어) 구성도” 세가지가 있어야 한다.
이 세가지는 Bottleneck 과, Scale Out, Performance에 대해 문제를 진단하거나 대응하기 위한 기초자료이다.
“따라서 이런 것들을 확인할 수 있는 수준까지 자세히 그려야 한다.”
하지만 진정한 설계도는 “component와 business logic을 매칭시키는 지도” 이다.
uml 이나 파워포인트나, 엑셀이든 아무거나 좋다. 적합한 툴이 없다면, 손으로 그려도 좋다.
이 지도가 없다면, 사실상 유지보수는 불가능하다.
예를 들면 Spring framework는 component 방식으로 개발이 되기 때문에 component간 in,out definition 과 call flow가 없다면 복잡한 비즈니스 로직을 유지보수 한다는 것은 사실상 힘들다.
참고로 uml 등을 굳이 100% 현행화할 필요가 없다. 이걸 현행화하기 위해 애쓰지 말자.
uml은 핵심 로직을 이해하기 쉽게 그리고, 개발자간 커뮤니케이션 하기 위한 수단일 뿐이다.
RUP 방법론을 써서 이상적인 package 설계와 class 설계, 구현, 테스트까지 해보았지만, 너무 강한 코드 결합 때문에 오히려 유지보수하기 번거로웠다.
개발자는 개발자가 가장 잘 이해한다.
소스코드에 주석을 잘 달아 두는 것 만큼 유지보수를 쉽게 하는 것은 없다.
다음 사람이 잘 유지보수할 수 있도록 친절하게 써두어라. 필요하면 해당 파일 내에 “장문의 편지”라도 써야 한다.
품질관리는 PM 이 해야 한다.
똑똑한 QAO 가 일의 일부분이라도 덜어준다면 감사한 일이겠지만, 그렇지 않다면 PM이 해야 한다.
QC가 하는 것도 아니다.
타협도 있을 수 있고, 책임 지는 것도 있을 수 있다.
상용화 되었을 때 무슨 문제가 일어나고, 어떻게 될 것인가에서부터 출발해야 한다.
그러다 보면, 소스 버전도 관리해야 하고 배포도 관리해야 하고 개발Guide도 관리해야 한다. 테스트도 해야겠고, 재배포도 해야 한다.
“품질관리방법론”이나 “개발방법론”과 같이 정형화된 틀에서 벗어나야 한다.
스스로 무엇을 잘못하고 있고, 무엇이 필요한지에 대해 자주 회의하고, 모자란 부분을 식별해 내는 것이 올바른 품질관리이다.
– 최근에 XP방법론과 Agile 방법론이 유행이다.
가볍고, 빠른 대처가 가능하고 눈으로 확인을 하면서 대응할 수 있기 때문에 아주 효과적인 개발이 가능하다. 이런 개발방법은 “열정”과 “이해”를 바탕으로 하기 때문에, 소속감이 없는 외주직원을 활용할 수 없다. 따라서, 큰 프로젝트를 하기에는 적합하지 않다.
– Mega project들인 Enterprise project 나 Open source project 에는 “아키텍쳐 개발방법론”을 많이 활용하고 있다.
이 방법은 프로젝트 전반에 걸쳐 “아키텍쳐 그룹”이 개발과 테스트까지 관여한다.
그러나, “아키텍쳐”를 이해하는 사람이 없을 때, 소규모 개편조차도 용이하지 않다는 단점이 있다.
– “좋은 개발방법”은 “좋은 Output”을 낳기 위한 중요한 툴이다.
– “프로젝트는 틀에 한정되어 있지 않다.”
– 원하는 결과물을 얻기 위해서는 다양한 개발방법론과 품질관리 경험을 바탕으로 취사선택 하면서 수행해야 한다.
모든 프로젝트는 사람의 얼굴처럼 똑같지 않다.
하지만, 품질관리 의식의 부족, 개발방법 경험부족, 아키텍쳐링 지식 부족 등은 좋은 결과를 방해한다.
반면, 아직 IT에서 이런 경험과 지식은 책으로 정리되어 있지도 않고 누가 나서서 가르쳐 주지도 않는다.
어렵겠지만, PM이 주변에 묻고 스스로 공부하지 않으면 프로젝트는 산으로 간다.
PM의 열정과 사랑은 실패를 경험으로 변하게 한다.
부지런히 탐구하고 도전,경험하는 것만이 최선의 방법이다.
※ 참고문헌 :
* uml freeware – http://www.devcurry.com/2010/06/free-open-source-uml-tools.html
* http://ko.wikipedia.org/wiki/소프트웨어_개발_방법론
* http://xper.org/wiki/xp/
댓글