제품 개발 프로세스 #4

이번엔 아마 제품개발 프로세스 끝낼 수 있을 듯..

지난번에 설계 단계까지 했었군요.

구현 단계에 대해서는 구현의 방법등과 같은 내용 보다는 관리적인 면을 말씀드리겠습니다.

일전의 글에서 개발자들에게 코드 리뷰 시간을 할당하라고 하였었는데 , 바로 이 단계에서 필요한 것입니다.

코드리뷰 일정은 이미 개발계획서에 반영이 되어 있을 것입니다. 보통 주1회 2시간 정도가 적당합니다.

그리고 구현단계 초기에는 코딩가이드에 대한 교육도 진행이 되어야 합니다.

코드리뷰에 대해서는 Fagan Inspection 과 같은 관리적, 절차적 지침도 있는 것 같고 , 코드리뷰 관리 시스템도

일부 제작이 되어 있는 것 같기도 합니다. ( 이 시스템으로 논문을 진행하시는 분이 있어서 ...^^ )

어떤 방법을 사용하든 코드리뷰의 목적을 정하고 시작하면 그 방법에 대하여는 크게 고민하지 않아도 될 것 같습니다. 다만 너무 무거운 프로세스나 시스템을 사용하게 되면 본래의 목적을 잃게 되는 경우가 있어 되도록이면

큰 제약 사항없이 진행하는 것이 좋을 것 같습니다.

코드리뷰의 목적은 크게 아래의 두가지 일 것입니다.

첫째는 코드의 품질 향상이고 두번째는 개발자간의 기술공유가 될 것입니다.

방법적으로 코드리뷰는 일주일 단위로 주기적으로 진행을 하게 되는데 , 지난 시간에 지적이 나왔거나 논의가 된 부분에 대한 결과를 먼저 공유하고 , 지난 주간에 제작된 코드를 전체 리뷰를 하는 식으로 하면 무리가 없을 듯합니다.

시간은 진행을 해보니 전체 두시간 정도가 적당하고 가능하면 개발자 전원이 모일 수 있도록 해야 효과가 커집니다. 여기서 주의하실 점은 관리자의 입장에서 코드리뷰 도중에 나오는 개발자간 커뮤니케이션을 관여하게 되면 , 구현상의 솔직한 의견들이 나오기 어렵다는 것입니다. 그래서 코드리뷰의 원활한 진행을 위해서는 관리자 참여에 제한을 두는 것도 하나의 방법이 될 것입니다. 이 리뷰의 내용은 인사에 반영하지 말란 것이지요.

코드리뷰 외에도 Pair Programming 등의 진행 기법이 있는데, 전체적으로 적용하기에는 어려운 점이 있습니다. 신규 개발자 라든지 외주 개발자가 섞인 경우 시행 해 볼 수도 있을 것입니다. ( 저는 해본 적 없습니다만 )

구현이 진행되기 전에 도움말 제작 등의 작업은 없어도 되지만 , 스타일 가이드와 그래픽등의 UI 작업은 완료가 되어 있어야 합니다. 프로젝트 관리자는 설계기간 조정과 투입인력의 배분을 통해서 이러한 팀간의 일정 연결이 잘 되도록 특별히 신경을 써야 합니다.

그리고 빌드관리 시스템을 가동하게 됩니다. 빌드관리 시스템은 일일빌드 체계로 운영하는 것이 좋으며 , 개발팀

전체가 항상 최신의 버전으로 개발에 임할 수 있도록 해야 합니다. 되도록이면 오후4시경에 빌드를 하는 것이 무리가 없을 것입니다. 오후 4시에 하는 이유는 당일 빌드는 당일에 완료해야 하기 때문이죠. 실패했더라도 수정에  필요한 시간을 주어야 하기 때문입니다. 만약 빌드가 계속 안되게 되면 그 담당자는 문제가 해결 될 때까지 퇴근 할 수 없다는 원칙은 세워 두시기 바랍니다.

이렇게 일일빌드를 체크하시며 구현을 진행하시면 됩니다. 그래서 구현단계의 마지막에 다다르게 되면 개발자 테스트 단계가 됩니다. 개발자 테스트 단계에서는 아래의 사항을 만족 할 때까지 계속 코드를 고치거나 수정을 해야 합니다.

첫째 요구사항에 나온 모든 기능이 구현 완료된 상태가 되어야 하고 ,

둘째 시스템이 죽는 Crash 레벨 버그가 없어야 하며

셋째 프로세스 진행이 중단되는 Block 상황이 발생하면 안됩니다

그리고 마지막으로 도움말 등의 텍스트 작업까지 모두 완료되어 있어야 합니다.

이 모든 조건을 만족하게 되면 개발자 테스트의 다음 단계인 QA - 알파테스트 과정으로 진입을 선언하게 됩니다. 알파테스트 단계가 되면 형상관리를 본격적으로 진행하게 되는데 , 프로젝트 관리자는 개발자에게 알파테스트의 각 단계마다 알파1, 알파2, 등과 같이 반드시 Tagging 을 하도록 지시해야 하고 이 Tagging 버전을 기준으로 테스트를 진행 하도록 합니다.

테스트 도중에 발견되는 버그는 버그트래킹 시스템을 이용하여 테스터가 등록하고 관리자가 판단하여 개발자 할당을 하고 수정이 이루어진 버그들의 숫자가 일정 수준에 이르게 되면 다시 Tagging을 하여 다음 단계 알파테스트를 진행 합니다. 이렇게 계속적인 테스트를 거치면서 구현 제품의 완성도를 높여 가는데 특정 조건이 만족되면 베타 테스트 선언을 하게 됩니다.

사업적인 면에서 보면 , 이 알파테스트 단계로 진입을 하게되면 개발팀 외에도 바빠지는 팀들이 많습니다.

기획,마케팅 부서는 런칭 준비를 해야 하고 , 영업팀은 필드테스트 대상 물색? 에 들어갑니다. 그리고 홍보팀은

언론 대응 준비에 들어가겠지요.

이 알파테스트 단계에서는 프로젝트의 일정이 오로지 개발팀의 책임이 되는데 , 이 알파테스트 또한 다음 단계인 베타테스트 진행을 위한 조건을 만족하지 못하게 되면 계속 반복을 해야 하기 때문에 개발자들이 특히 어려운 기간임에는 분명합니다.

이러한 과정을 거치게 되면 베타 테스트를 진입하게 되는데 , 베타테스트 진입에 필요한 조건은 제품마다 회사마다 다를 것 입니다. 여하튼 이 단계에서는 베타 테스트의 대상을 최종사용자까지 할 것인가 또는 QA ,테스트로만 할 것인가를 정해야 합니다. 대개의 경우 B2C 제품인 경우는 오픈베타, 또는 크로즈베타 등으로 진행을 하고 B2B 제품인 경우는 필드테스트를 진행하게 됩니다. 이 모든게 여의치 않으면 QA 테스트로 대체하기도 합니다.

마찬가지로 베타테스트에도 Tagging 이 적용됩니다. 베타1, 베타2 와 같이 말이지요.

다음으로 베타테스트가 완료되면 RC를 정하게 됩니다.

RC1 , RC2 이렇게 말이죠. ( RC : Release Candidate )

원칙적으로는 RC는 여러개가 존재할 수 있으며 , 대체로 그 중에 제일 안정된 버전을 출시합니다.

프로젝트 관리자는 최종적으로 RTM ( Release To Manufacture , Market ) 회의를 소집하게 되는데 , 이 회의에는 프로젝트 관련 모든 사람들이 모이게 됩니다. ( CEO가 참석하기도 합니다. )

RTM 회의에서는 RC에서 처리가 안 된 잔여 버그들에 대한 보고를 하고 , 프로젝트 경과 보고등을 하게되고 출시 결정이 나게되면 프로젝트를 종료하게 됩니다. 이렇게 되면 이날이 회식하는 날입니다. ^^;

출시되기 전에 제품은 정식 버전을 정하게 되는데 1.0 과 같이 두자리 부터 1.0.3.1 과 같이 네자리 또는 기타 빌드 버전을 붙여서 길게 정하는 경우도 있습니다.

이상으로 제품 개발 프로세스에 대한 소개를 모두 마칩니다.

*쓰고 나서 보니까 뒷 부분으로 가면서 속도 조절이 안되어 빠진 부분이 많이 눈에 띄이는 데 이는 틈틈히 수정해 보도록 하겠습니다.