사안의 역사:
요구 사항 변경 관리는 시스템 분석의 가장 복잡한 측면 중 하나로, 특히 대규모 및 분산 프로젝트에서 더욱 그렇습니다. 역사적으로 무질서한 변경 적용 문제에 직면하여 추가적인 위험, 비용 및 갈등이 발생하곤 했습니다.
문제:
주요 어려움은 변경의 투명성을 보장하고, 다양한 팀의 작업을 동기화하며, 실수를 최소화하면서도 유연성을 잃지 않는 것입니다. 프로세스가 정립되지 않으면 프로젝트는 끝없는 수정 작업에 빠져버리기 마련입니다.
해결책:
변경 관리를 위한 접근 방식은 프로젝트 구조에 따라 다릅니다:
핵심 특징:
민첩한 방법론(agile)을 사용할 때 변경 관리에서 완전히 벗어날 수 있습니까?
아니요, agile에서도 변경 사항을 기록하고 팀과 조율할 필요가 있습니다. 간소화된 절차라고 해서 통제가 없다는 의미는 아닙니다.
30명으로 구성된 팀에서 요구 사항 변경을 추적하기 위해 이메일 알림만 사용하는 것으로 충분합니까?
아니요, 그러한 접근 방식은 정보 손실 및 오류를 초래할 것입니다. 중심화된 이력 저장 기능이 있는 전문 도구가 필요합니다.
고객의 모든 요구 변경을 자동으로 수용해야 합니까?
아니요, 각 변경 사항은 영향 평가 및 우선 순위를 거쳐야 하며, 그렇지 않으면 프로젝트에 대한 통제를 잃을 수 있습니다.
부정적 사례:
대규모 프로젝트에서 변경 요구 사항이 이메일을 통해 중앙 집중 없이 수용되었습니다. 정보는 소실되었고, 중복된 작업이 생기며, 기한이 지켜지지 않았습니다.
장점:
단점:
긍정적 사례:
Jira에서 변경 로그가 도입되고 CCB 회의에서 정기적으로 논의되었습니다. 각 변경 요청은 설명 및 평가를 거치며 투명한 이력을 가졌습니다.
장점:
단점: