반복 활동
MSF for CMMI Process Improvement v5.0에서는 프로젝트를 일련의 반복되는 단위로 계획합니다. 각 반복의 기간은 일반적으로 4주에서 6주 정도이며, 이 기간 동안 개발 팀에서는 지정된 요구 사항 집합을 구현합니다.
반복 시작 시 활동
반복 계획은 각 반복이 시작될 때 또는 그 이전에 이루어집니다. 반복 계획에는 다음 작업이 포함됩니다.
반복에 할당된 요구 사항을 검토하고 해당 요구 사항을 보다 세부적으로 정의합니다.
각 요구 사항을 구현하고 테스트하기 위해 수행해야 하는 작업을 나타내는 작업(task) 작업 항목을 만듭니다. 그런 다음 부모 링크 형식을 사용하여 이 작업을 요구 사항 작업 항목에 연결합니다.
각 작업의 원래 예상 값 필드를 설정합니다. 예상 기간이 며칠 이상인 작업은 둘 이상의 작업으로 나눕니다.
예상 기간을 반복에 사용할 수 있는 시간과 비교합니다. 총 예상 기간이 너무 길면 일부 요구 사항을 단순화하거나 이후 반복으로 연기합니다.
자세한 내용은 반복 계획(CMMI)을 참조하십시오.
반복 도중 활동
작업 실행
팀 멤버가 작업을 시작하고 완료하며 이러한 이벤트를 작업 항목에 기록합니다. 작업 완료에는 프로그램 코드 및 기타 아티팩트의 체크 인이 포함될 수 있습니다. 각 작업은 며칠 내로 진행되어야 하며 이보다 큰 작업은 반복 계획 단계에서 분할합니다. 자세한 내용은 작업 항목 만들기, 복사 및 업데이트 및 개발 작업 완료을 참조하십시오.
팀 멤버는 작업에 방해가 되며 즉시 해결할 수 없는 문제가 발생할 경우 문제 작업 항목을 기록해야 합니다. 자세한 내용은 문제(CMMI)를 참조하십시오.
테스트
수동 또는 자동 테스트를 개발하고 제품 요구 사항에 테스트 사례를 연결해야 합니다. 제품 요구 사항이 정상적으로 작동함을 보여 주는 테스트 사례에 통과하고 이 테스트 사례에 작업 항목을 연결하기 전까지는 제품 요구 사항을 완료된 것으로 간주하면 안 됩니다.
테스트에 대한 개발 작업은 제품 요구 사항과 연결된 작업에 포함되어야 합니다.
롤링 및 야간 빌드
빌드 시스템에서는 최근에 체크 인된 업데이트로 제품을 빌드하고 자동화된 테스트를 실행합니다. 연속적으로 실행할 기본 테스트와 매일 밤에 실행할 전체 테스트를 설정할 수 있습니다. 이 방법을 사용하면 여러 번의 증분 빌드로 인해 버그가 누적되지 않도록 할 수 있습니다. 자세한 내용은 Team Foundation Build 관리를 참조하십시오.
일간 회의
팀 전체는 반복의 작업 진행 상태를 매일 간단하게 검토합니다. 팀 멤버는 영사기를 사용하여 진행률 대시보드를 보거나, Office Live Meeting을 사용하여 이를 공유하거나, 둘 모두를 수행할 수 있습니다. 자세한 내용은 진행률 대시보드(CMMI)를 참조하십시오.
각 팀 멤버는 최근 진행률, 그날 맡은 작업 및 장애 문제를 간략하게 보고합니다.
프로젝트 관리자나 팀 리더는 문제 해결을 위한 진행 상황을 보고합니다. 자세한 내용은 문제 관리(CMMI)를 참조하십시오.
버그 수를 검토합니다. 버그에는 새로운 개발보다 높은 우선 순위가 지정되어야 합니다. 프로젝트 전체 기간 동안의 버그 수를 낮게 유지하는 데 목표를 두어야 합니다. 버그 수가 늘어나면 그 원인과 개발 작업에 미칠 수 있는 영향에 대해 논의합니다.
번다운(Burndown) 속도를 검토합니다.
범위 조정
번다운(Burndown) 차트에 반복 종료 시까지 작업이 완료되지 않을 것으로 표시되는 경우가 있습니다. 이 경우 프로젝트 관리자나 팀 리더는 작업을 줄일 수 있도록 요구 사항을 단순화하는 방법에 대한 토론을 시작합니다. 자세한 내용은 번다운(Burndown) 및 진행 속도 보고서(CMMI)를 참조하십시오.
요구 사항과 해당 테스트를 조정합니다. 누락된 기능을 위해 새로운 요구 사항 기능을 프로젝트 계획에 포함합니다. 반복이 끝날 무렵 열리는 프로젝트 계획 검토 회의에서 이 기능을 이후의 반복에 할당하거나 생략할 수 있습니다.
반복 중에는 변경 요청과 위험을 고려하지 않습니다.
심사
일반적으로 팀 전체가 아니라 일부 팀 멤버만이 정기적으로 모여 버그를 검토합니다. 모든 팀 멤버는 오류를 발견할 때 버그를 기록해야 합니다. 기록된 버그는 제안됨 상태로 시작하며, 심사 회의는 이 버그를 수정할지, 이후 반복으로 연기할지, 아니면 거부할지를 결정하는 데 목적이 있습니다.
자세한 내용은 버그 작업을 참조하십시오.
반복 종료 시 활동
확인
요구 사항은 관련 테스트가 통과하는 경우에만 완료된 것으로 간주됩니다. 자세한 내용은 요구 사항 확인을 참조하십시오.
회고
프로세스 개선은 CMMI의 중요한 목표입니다.
반복 회고 단계에서는 해당 반복에서 올바르게 수행되거나 잘못 수행된 작업을 되짚어 보고 팀이 사용한 프로세스 및 도구에서 개선할 사항을 조사합니다. 웹에서 회고에 대한 상당한 양의 자료를 볼 수 있습니다.
팀 멤버는 책임 소재를 밝히기보다는 개별 멤버의 실수로 인해 프로젝트 전체에 영향이 미치게 될 가능성을 줄일 수 있도록 프로세스를 개선하는 데 노력해야 합니다.
프로세스를 변경할 때 팀은 다음과 같은 사항에 동의해야 합니다.
변경 내용으로 인해 프로세스가 개선되었는지 여부를 파악할 방법
변경 내용의 평가 시기
변경 결과로 수행할 작업
통합
현재 프로젝트가 보다 큰 프로그램의 일부인 경우 각 팀은 버전 제어 시스템의 분기에서 작업을 수행합니다. Main 분기는 팀 작업을 통합하기 위한 용도로 예약되어 있습니다. 반복이 종료되면 팀은 Main 분기와의 통합을 수행할 수 있습니다. 자세한 내용은 분기 및 병합을 참조하십시오.
통합은 다음과 같은 두 단계로 이루어집니다.
정방향 통합 - Main 분기의 최신 코드를 로컬 프로젝트 분기에 병합합니다. 병합을 수행한 후에는 자동 및 수동 테스트가 실행됩니다. 이때 몇 가지 문제가 발생하며, 발생한 문제는 높은 우선 순위로 수정됩니다.
역방향 통합 - 로컬 분기 코드가 Main 분기에 병합되고, Main 분기에 대한 빌드 및 전체 테스트 도구 모음이 실행됩니다. 오류가 발생하면 변경 내용이 되돌려집니다. Main 분기에 오류가 발생하는 것은 바람직하지 않습니다. 오류가 발생하지 않으면 해당 반복은 완료된 것으로 선언됩니다.
각 반복이 종료될 때마다 통합을 수행하는 것이 좋습니다. 통합 시기가 그보다 늦어지면 정방향 통합 후 수정할 버그가 너무 많아집니다. 버그를 수정하는 데 오랜 시간이 걸리면 그 동안 Main 분기에 새로운 자료가 쌓이게 되므로 정방향 통합을 한 번 더 수행해야 합니다.
다음 반복 준비
반복이 종료되어 가거나 종료될 때는 몇 가지 프로젝트 관리 활동을 수행합니다. 여기에는 위험 검토뿐 아니라 변경 요청 및 변경된 개발 예측 값과 관련한 계획 검토가 포함됩니다.
자세한 내용은 프로젝트 활동을 참조하십시오.