프로젝트 관리
MSF for CMMI Process Improvement 지침의 프로젝트 관리 단원에서는 소프트웨어 제품의 개발 및 유지 관리 과정을 관리, 계획 및 조정하는 방법을 보다 잘 이해할 수 있습니다. CMMI에 대한 자세한 내용은 CMMI의 배경을 참조하십시오.
CMMI 프로세스 영역의 프로젝트 관리 그룹에는 프로젝트 계획, 프로젝트 모니터링 및 통제, 공급자 계약 관리, 통합 프로젝트 관리, 위험 관리, 그리고 정량적 프로젝트 관리가 포함되어 있습니다. 정량적 프로젝트 관리를 제외한 모든 프로세스 영역은 모델 수준 2 또는 3에 포함됩니다. 정량적 프로젝트 관리는 모델 수준 4의 활동으로, 완성도가 높은 조직에서 정량적이고 통계적으로 안전하며 객관적인 데이터를 사용하여 관리에 필요한 사항을 결정하고 프로젝트를 성공적이고 예측 가능한 결과로 이끄는 방법을 반영합니다.
프로젝트 관리 활동은 부가 가치적인 엔지니어링 활동에 드는 경제적 비용을 나타냅니다. 이러한 활동은 위험을 관리하고, 성공적인 엔지니어링 결과를 얻을 수 있도록 작업을 조정하고, 고객의 기대를 적절하게 설정하는 데 필요한 중요한 활동입니다. 그러나 이러한 활동을 위한 노력은 최소화해야 합니다. 이때 "조금씩 자주" 노력을 기울이는 것이 좋은 방법입니다. 일괄 작업이 적을수록 복잡성과 조정 비용이 줄어듭니다. 프로세스 정의를 만들고 조정할 때는 프로젝트의 위험 프로필을 충족하면서 프로젝트 관리 활동을 가능한 한 최소화해야 한다는 점을 유의해야 합니다.
반복 개발
Team Foundation과 MSF for CMMI 프로세스 템플릿에서는 반복 작업을 지원합니다. 반복 개발 방법에서는 프로젝트 전체 기간 동안 일정 간격마다 시연 가능하고 테스트 완료된 소프트웨어를 전달함으로써 위험을 관리합니다.
.png "연속 반복")
프로젝트 일정은 대개 4-6주 동안 진행되는 일련의 반복되는 단위로 구성됩니다. 각 반복의 마지막에는 사용 가능하고 테스트 완료된 소프트웨어를 시연합니다. 자세한 내용은 영역 및 반복 만들기 및 수정을 참조하십시오.
프로젝트 계획에는 각 반복에서 개발할 기능 요구 사항을 명시합니다. 프로젝트 계획은 반복 0에서 개발하고 각 반복이 시작될 때마다 검토합니다. 프로젝트 계획은 프로젝트 대시보드를 비롯한 여러 가지 방법으로 볼 수 있습니다. 자세한 내용은 요구 사항(CMMI) 및 프로젝트 대시보드(CMMI)를 참조하십시오.
각 반복 계획에는 해당 반복 동안 수행할 작업을 명시합니다. 대부분의 작업은 해당 반복에 할당된 기능 요구 사항을 충족하는 데 필요한 개발 및 테스트 작업입니다. 반복 계획은 진행률 대시보드를 통해 볼 수 있습니다. 자세한 내용은 작업(CMMI) 및 진행률 대시보드(CMMI)를 참조하십시오.
반복 작업에서는 자동으로 위험을 관리하지 않습니다. 위험을 최소화하려면 증분식으로 프로젝트 계획을 세워야 합니다. 초기 반복에서는 "전체적으로 간략한 그림", 즉 제품에서 가장 중요한 동작을 최소화한 버전을 제공해야 합니다. 후기 반복에서는 더 많은 기능을 추가합니다.
반면, 쇼핑 웹 사이트 프로젝트에서 프로젝트 전체 기간을 3등분하여 각 기간 동안 판매 부분의 모든 기능, 웨어하우스 시스템의 모든 기능, 지불 시스템의 모든 기능을 순차적으로 진행하는 방식은 유용성이 훨씬 떨어집니다. 이러한 식의 일정을 적용한다면 매력적이고 기능이 풍부하긴 하지만 정작 고객으로부터 대금을 받을 수 있는 수단은 없는 판매 웹 사이트를 만들게 될 위험이 있습니다. 증분식 방법을 적용하지 않는다면 이러한 위험이 되풀이됩니다.
증분식 개발 방법에는 다음과 같은 장점이 있습니다.
실제 요구 사항을 충족할 수 있습니다. 관련자가 제품을 사용해 볼 수 있는 기회가 있으므로 관련자가 명시한 요구 사항을 지속적으로 개선할 수 있습니다.
아키텍처를 조정할 수 있습니다. 개발 팀에서는 플랫폼과 관련하여 발생하는 장해 요소나 디자인에 대해 가능한 개선 사항을 찾아 처리할 수 있습니다.
결과를 보장할 수 있습니다. 관련자는 프로젝트 리소스가 도중에 감축되더라도 해당일까지의 비용이 낭비된 것이 아님을 알 수 있습니다. 이는 개발 예상 비용이 낙관적이었던 것으로 판명되어 덜 중요한 기능을 생략해야 하는 경우에도 마찬가지로 적용됩니다.
요구 사항을 증분식 개발에 적절한 형태로 표현하는 방법에 대한 자세한 내용은 개발 요구 사항을 참조하십시오.
장기 및 단기 주기
소프트웨어 개발에서 순환적인 요소는 프로젝트와 반복만이 아닙니다. 예를 들어 반복에서 팀 멤버는 작업을 시작 및 완료하고 코드를 체크 인합니다. 빌드 시스템에서는 연속적으로 또는 야간에 제품을 빌드합니다. 팀에서는 반복 작업의 진행 상태를 매일 간단하게 검토합니다.
.png "체크 인, 매일 빌드, 반복, 프로젝트, 프로그램")
대규모 프로젝트
팀 작업이 일련의 반복을 통해 이루어지는 프로젝트는 보다 큰 프로젝트 또는 프로그램의 일부일 수 있습니다. 대규모 프로젝트에서는 여러 팀이 동시에 작업을 수행하게 됩니다. 각 팀은 일반적으로 4-16명의 멤버로 구성됩니다.
각 팀에 대해 별도의 버전 제어 분기를 열어야 합니다. 각 팀에서는 반복이 종료될 때마다 Main 분기와의 통합을 수행해야 합니다. 자세한 내용은 분기 및 병합을 참조하십시오.
Main 분기는 통합 및 테스트용으로 예약합니다. 빌드 컴퓨터에서는 통합 후 전체 테스트를 수행해야 합니다.
팀의 작업 항목을 다른 팀의 작업 항목과 쉽게 구별할 수 있도록 각 팀에 영역을 할당합니다. 자세한 내용은 영역 및 반복 만들기 및 수정을 참조하십시오.
팀에서는 일련의 통합 내용을 공유할 수 있지만 이 과정이 항상 필요한 것은 아닙니다. 팀에서 통합 내용을 동기화하지 않는 경우 각 팀에서는 반복 이름에 해당 팀의 접두사를 사용해야 합니다.
단원 내용
프로젝트 주기: 프로젝트를 시작하고, 요구 사항을 수집하고, 프로젝트 계획을 만들고, 프로젝트를 반복으로 나누고, 릴리스를 전달합니다. 위험을 관리하고, 계획에 대한 변경 내용을 관리합니다. |
|
반복 주기: 요구 사항을 검토 및 업데이트하고, 요구 사항을 구현할 작업을 계획하고, 문제가 발생할 때 이를 관리합니다. |