대규모 프로젝트 관리하기

경험담이나 해볼까요?

전 사용자 인터페이스를 가장 나중에 생각합니다. 중요한 핵심 코드에 집중하죠. 그래야 맘이 편하거든요. 중요한 핵심 코드도 혼자 하는 것 보다는 같이 하는게 좋을 것입니다.

가장 먼저, 귀하가 PM을 해야겠군요. 일단 사장과 가장 잘 통하게 될 것이고, 일을 하려면 발주처의 요구도 많이 고려해야 하니까 사장과 밀착 되기 위해서는 귀하가 적당하겠습니다.

시나리오를 짭니다. 프로그램이 어떤식으로 돌아가야 하는지 문서로 작성하면 좋을 것입니다. 사장이 발주처에서 요구받은 내용을 꼼꼼하게 작성하세요. 만약 사장이 발주처로부터 주문받은 내용이 의미심장하고 부족하다면 사장한테 그 문제에 대한 해결을 부탁하세요. 그건 사장이 책임져야 합니다. 대부분의 머저리같은 사장은 자동차가 바퀴랑 핸들만 있음 굴러가는 줄 압니다. 엔진은 몇마력이고, 문짝은 위에 달지 앞에 달지 옆에 달지 아주 꼼꼼하게 물어보세요. 그냥 알아서 하라고 하면 두들겨 패서라도 대답을 구하십시오. 이렇게 시나리오가 정리되면 전체 프로그래머들한테 검토하라고 합니다. 그리고, 검토가 끝나면 회의하고 모자란거 다시 정리하고 ...

그 다음 가장 핵심적인 즉, 가장 중추적인 코드(게임 프로그램에서는 게임 엔진같은)가 무엇인지 판단하고 그것을 기능별로 산산히 조각을 내서 모두에게 분담을 시킵니다. 이 때 되도록 같은 언어를 사용하세요. 한놈은 C로 하고 한놈은 VB하고 그럼 곤란하죠. 하여튼 툴을 통일하세요.
그다음 계속적인 회의를 하면서 코드를 다듬고 연결하고 다시 고치고 추가합니다. 핵심적인 내용을 벋어나지 마세요. 절대루... 그리고, 꼭 모두가 같이 해야합니다.
이렇게 해서 핵심적인 부분의 코드가 완성되면 제가 장담하죠. 상황이 어떻게 되든 일은 일사천리로 생각외로, 그리고 신기가 든 것처럼 문제 없이 진행됩니다. 왜냐구요? 거의 모든 프로그램들이 그렇듯이 사용자 인터페이스니 모니 하는 것들이 핵심적인 코드 부분을 둘러싼 것이기 때문에 중심핵이 안정되고 더구나 모두가 그 코드를 같이 작성했기 때문에 의사소통이 잘되고 서로가 서로의 하는 일을 예측 가능해 진다는 것입니다.
그 다음은 그 이외의 자질구래한 것들을 만듭니다. 자질구래한 것들이 뭔지는 그때 가봐야 압니다. 왜냐하면 자체 프로젝트도 아니고 외주를 받은 것이기 때문에 그건 귀하도 모르고, 머저리같은 사장도 모릅니다. 오직 변덕에 무식함을 겸비한 사장과 발주처에 다려있기 때문입니다.

도움이 되셨기를...

devide and conquer!!!

많은 사람이 프로젝트를 진행 한다는건 상당히 어렵고 힘든 작업입니다.
저도 현재 5명이 함께 작업중인데 구현된 프로그렘은 상당히 보기에 좋지 않은 모습이 되고 또한 기능을 추가 하거나 변경 하고자 할때는 전체적인 소프트웨어 구조의 이혜가 부족하여 더더욱 보기 힘든 코드가 자꾸 되어 갑니다.

최근 뜨고있는 UML은 단지 프로젝트 진행을 위한 설계 노테이션이지 그 이상 아무것도 할 수 없습니다.

효과적인 프로젝트 진행을 위해서는 설계, 모듈( 클래스 ) 등이 잘 설계 되어야 하고 엔지니어의 적극적인 참여가 없으면 결국 배가 산으로 가게되는 현상이 발생 합니다.

다음과 같이 하면 어떨까요.

1. 코딩룰은 만듭니다

프로젝트을 통합적으로 관리 할 수 있는 방법이 필요하겠네요. 제가 추천하고 싶은 것은 UML이구요.
UML은 이미 업계의 표준이 되어 있으니 많은 인력과 자료를 얻을 수 있을것 같구요.
분석작업이 길어지고, 결과물이 빨이 보이지는 않지만 디자인을 제대로하면 업무 분담, 소프트웨어의 완성도도 높일 수도 있구요.
소프트웨어 공학에 거부감을 가지는 개발자들도 있지만 전 실수를 반복하는 것 보다는 철저한 준비과 분석을 거쳐서 프로젝트를 지행하는 것이 보다 효과적일 수 있다고 봅니다.

저의 경우 일단 코딩 계획서(개발 계획서)를 상당히 신중하게, 충분한 시간을 들여서
작성했습니다.
총 개발 기간이 2달 좀 넘었던거 같은데,
이중 3주 정도를 개발 계획서 작성하는데 보냈습니다.
이를 테면 개발 메뉴얼(설계도) 작성인데,
프로그램에 필요한 정보들을 먼저 수집하고
(어떤 기술이 필요하고, 어느정도의 시간이 걸리는지, 기술을 사용하는데
있어서 발생가능한 문제가 무엇이 있는지, 프로그램의 작동 방식,
어떤 관련 메뉴얼과 문서가 필요한지 (책, rfc 자료) 등등등),

어떤 방식으로 공동개발을 할것인지, 이때 어떤 도구를 사용할것인지,
함수이름과 변수 이름, 구조체 이름은 어떤 규칙으로 만들것인지
주로 포인터를 사용할것인지, 아니면 배열을 사용할것인지,
등등 매우 세세한 부분까지를 정의 해 나갑니다.

수집한 정보를 토대로, 모듈을 나눕니다.
각각의 나눈 모듈을 팀에 분배합니다. 각각의 개발특성에 맞게 분배하는 일이죠.
다음 각각의 모듈에 대한 쏘스와 함수의 대략적인 설계에 들어갑니다.
이러한 설계를 하면서, 자신의 모듈에 대한 이해가 깊어지고,
이해가 깊어지는 만큼 실질적으로 프로그래밍 작업에 들어갔을때의
혼란?을 최소화 시킬수 있습니다. 그전에 웬만한 정리 작업을 하는셈이죠.
이때 팀장은 이렇게 나누어진 각각의 모듈이 원할하게 연결될수 있도록
조정작업을 하게 됩니다.
이러한 조정작업을 거치면서 나중에 각자 개발한 모듈을 붙이기만 하면
프로그램이 완성될수 있도록 main프로그램의 틀을 짜게 됩니다.
공동개발 프로젝트이므로, 쏘스 관리가 필수 입니다.
대부분의 경우 make 도구와 프로젝트 관리도구(CVS)를 사용하게 됩니다.
저희는 make와 CVS를 사용했고요..
이렇게 개발 계획서가 완성되고 나면.. ..
실질적인 코딩에 들어 갑니다.
물론 위의 개발계획서는 문서로 잘 정리를 하죠.
회의 무지 많이 합니다.

별문제 (소스 코드 걸레되기, 소스 충돌, 의견충돌, 정신적 아픔) 없이,
설계도(dd, dfd .., 함수 설계도) 대로 만들어 나가면 됩니다.
매우 부드럽게 프로젝트를 완성했습니다.

문제는 위의 개발방식이.. 글쎄요.. 우리나라의 벤처? 기업에서는
그리 일반적이지 않은 방식이라는 거죠..

빠른 시간내에 프로그램을 만들어서 빠른시간내에 시장에 진입해야 한다는
조급함 때문일지도 모르지만,
위의 방식으로 진행하는 개발방식에 대해서 일말의 불안감을 가지고 있죠..
일단 일을 벌이고 있는걸 봐야지 마음을 놓는 경영자들이 많습니다.

저도 이 프로젝트를 수행하기 전에는 혼자서 아무 계획없이, 일단 돌아가게 만들자. ..
즉 무대포 정신으로 만들었었죠.. ..
그 프로젝트는 거의 1년이 지났는데도 종료 되지 않았음다 --;
거의 좀비 상태로 일을 했는데도 말입니다.
소스만 갈아 엎어친게 3-4번은 되고,
버젼의 종류만 열 몇가지가 됩니다.
지금은 다른 프로그래머에게 인수인계 했는데,
죄송하게도 그 프로그래머 역시 무지 고생하고 있읍니다 --;

거기에 학을 떼고 나서, 경영자와의 약간의 의견 충돌을 거친뒤에 저위의 방식을
관철? 시켰죠..
2달의 개발기간을 널널하게(날밤 안까고, 적당한 시간에 퇴근하면서, 주말에는
영화도 보러 다니고, 때로는 평일날 술도 마시면서) 종료
시켰습니다.
나중에 쏘스 코드 보니 뿌듯한 생각이 절로 들더군요 --;
개발마친뒤 1달이 지났는데, 고객 크레임 거의 발생안하더군요.. ..

결론 먼저분 말씀대로, 기본에 충실하자 즉 개발계획 기간을 충실히 가지자..
입니다.

A 그룹과 B 그룹에 동일한 일을 시킵니다.
A 그룹은 일단 일을 하게 만들고,
B 그룹은 충분한 토론과, 회의를 거친다음에 일을 하도록 시켰더니..
처음 완료 절반정도 까지는 A 그룹이 빠른것 같았으나,
결국 일을 먼저 완료 시킨 그룹은 B그룹이라는 실험결과도 있으니.
경영자가 좀 주저주저 하더라도. ...
밀고 나가십시요 --;;