프로젝트 관리 어떻게 시작할까요?

프로젝트를 진행할 때, 현업에서 사용하는 방법론은 여러가지가 있습니다.
방법론!! 몇몇 사람들 특히 개발자들은 방법론은 쓸데없는 것이고 개발에 전혀 도움이 되지 않는다고 이야기 합니다.
저 역시도 RUP, 마르미, 이노베이터 등의 방법론을 토대로 프로젝트를 진행해 본 경험이 있습니다만,
솔직히 방법론이 무용지물이라는 생각을 해본 적이 꽤 있습니다.

이유는 바로 방법론에 맞추어 개발하고 산출물을 만드는 것이 아니라, 프로젝트 완료 시점에 방법론의 산출물을 한꺼번에 작성하거나 초기에 대충 작성해 놓고 나중에 한꺼번에 변경하는 것이 문제가 되는 것이었습니다.
그러다보니 오히려 방법론이 개발팀에 있어서는 짐이 되는 것이죠..

또, 방법론은 모든 프로젝트를 염두에 두고 만들어 놓은 것이므로.. 프로젝트의 특성에 따라 다시 재구성해서 진행할 필요가 있는데도 불구하고... 그냥 지난번에도 이런이런 것을 적용했으니 이번 산출물에도 이것들은 넣어야 해.. 하는 식으로 사용하므로 문제가 되는 것 같습니다.

일단, 제가 현재 사용하고 있는 제 나름대로의 방법론이 아닌 프로젝트 관리를 나열해 보고자 합니다.
물론 SI 프로젝트로서 고객에게 산출물을 제출해야 하는 경우에는 어쩔 수 없이 협의를 통해 방법론에 따른 산출물을 정의하지만.. 이것은 회사 내부 개발이나 저 혼자 개발할 경우.. 주로 사용하는 것입니다.

첫째, CVS와 같은 소스코드 관리는 필수입니다. 이게 없으면.. 소스에 대한 백업이나 통합등 여러가지를 수동으로 처리해야 하는 문제가 발생합니다. 먼저 CVS를 세팅하고 개발팀 전체가 사용할 수 있어야 합니다.
매일 CVS에 업데이터를 해야 하구요.. 프로젝트 관리자의 입장에서 수시로 들어가서 현재 진행상태를 눈으로 확인해 보는 겁니다.
소스코드의 버전관리는 이전 글(http://xmlmanager.tistory.com/6)을 참고하시기 바랍니다.
또한, CVS와 ANT를 이용해 서버에 배치하는 스크립트를 짜서 활용하기도 합니다.

둘째, 간트차트를 이용한 프로젝트 일정관리를 초기부터 합니다. 툴로는 MS Project를 사용하는데요.
여기서 중요한 점은 간트차트를 통한 일정관리를 1주일 단위로 초기에 전체적으로 잡아 놓습니다.
그리고 매주 업데이트 한다는 것입니다.
일정이라는 것이 늦어지는 경우가 많기 때문에 초기 계획시 늦어질 경우에 대한 버퍼도 마련해 두고요..
하지만, 개발팀에 절대 일정을 다그쳐서는 안됩니다. 매일 야근에 날새면서 개발한 것 치고 제대로 된 것이 없거든요.. 다만, 긴장이 풀어졌다는 느낌이 들지 않도록 유지하는게 중요하다고 봅니다. (이게 정말 어려워요.. -.-)

셋째, DB 설계입니다. DB 설계에서는 ER-Win으로 ER 다이어그램을 만들고요.. (logical, physical 두개 다 만듭니다.) CVS에 함께 공유합니다. 개발중에 DB 필드가 변경되는 경우가 종종 있는데요.. 그때는 공유된 다이어그램도 함께 변경하도록 해서.. 다이어그램과 실제 DB와 똑같이 유지시킵니다.
그리고 DB에서 사용하는 상태값들이 있습니다. 이건 메모형태로 ERD에 포함시켜 둡니다.
ER 다이어그램을 그려 놓으면 나중에 DB 관련 문서들을 만들기 편리합니다.

넷째, MiniSpecification이라는 문서를 하나 만듭니다.(MS-Word를 사용하고, 스타일을 적용함다) 초기에는 여기에 구성도, 전체 흐름, 기본 요구사항등을 자유형식으로 정리합니다. 프로젝트 진행 중에는 각 부분에서 비즈니스 로직이 들어갈 경우.. 해당 로직을 여기에도 정리해 놓습니다.
저는 이 스펙 문서를 꽤 중요하게 생각합니다. 추후 유지보수나 여러 측면에서 활용하려고 하는데요..
만약 이것이 없다면 소스코드를 추적해야 하니.. 시간이 더 걸리겠죠..
하지만, 개발자들은 이걸 그리 최신으로 유지하려고 하지 않습니다. 아무래도 소스코드 바꾸고 잊어버리는 경우가 많은 것 같습니다. 그래서 저는 소스를 확인할 때, 제가 직접 이부분을 정리하는 방향으로 하고 있습니다.
어차피 코딩을 안할 경우, 간트챠트 보고.. DB 확인하고.. 스펙 문서 다듬는 것이 기본 작업이 되니까요..

다섯째, 마지막으로 버그나 기능개선을 위한 엑셀 문서를 하나 만듭니다. 개발완료후, 사용할 것인데요..
Debug와 Enhancement 탭으로 나누고요..
우선순위, 수정여부, 수정일, 기록일, 버그재현단계, 예상수행결과, 실제수행결과, 수정처리자, 비고
의 형식으로 정리합니다.
이것 또한 CVS에 올려놓고 누구나 추가, 수정할 수 있도록 하지만.. 역시 제가 주기적으로 내용을 점검합니다.
(버그질라와 같은 것도 생각해 봤는데, 아직 적용하지는 않고 있슴다.)

이상이 프로젝트 관리만 할 때, 제가 하는 방법입니다. 문서는 MS-Project 파일, ERD 파일, Word 파일, Excel 파일 1개가 만들어집니다.
이렇게만 해도 프로젝트 진행을 관리하는데 바쁩니다. ㅋㅋ 그리고 산출물도 운영하는데 전혀 지장이 없을 만큼 충분히 나오지요..

앞으로 해보고 싶은 것은 개발자들에거 본인이 만든 로직에 대한 테스트코드를 생성하라는 주문을 하고 싶습니다. 어떤 프로젝트에서 개발자 부담을 덜어주려고 제가 직접 JUnit을 이용해 해봤는데요.. 거기까지는 힘들더라구요.. 시간이 너무 많이 걸리고.. 해당 개발자가 인터페이스나 메소드를 변경하면.. 따라서 고쳐줘야 하는데.. 관리자가 할 몫은 아니더군요..

아~ 그리고 최근에는 칠판을 하나 추가했습니다.
프로젝트별 "계획", "완료", "이번주"의 내용을 박스안에 간단하게 기록하는데요..
위 문서들을 CVS에 접속해서 직접확인하지 않는 윗사람들을 위해서.. 한눈에 볼 수 있도록 항목만 정리해 놓은 겁니다. XP 책에 있길래 해봤는데.. 나름 괜찮은 것 같더라구요..  *^^*