답변.

전통적으로 수용 기준의 공식화(acceptance criteria)는 테스터나 개발 팀의 손에 달려 있었습니다. 그러나 유연한 확장 프로세스(SAFe, LeSS, Scrum-of-Scrums)로 전환하면서 형식화된 테스트 시나리오 없이 진행할 경우 대규모 프로젝트의 다양한 참여자 간에 기대의 차이가 발생할 위험이 있습니다: 비즈니스, 테스트, 개발자 및 지원팀은 과업의 완료를 다르게 해석할 수 있습니다.

다중 팀 또는 분산 프로젝트의 문제점은 책임 영역의 다양성, 서로 다른 프로세스와 도구, 팀 간의 언어적 또는 문화적 차이입니다. 심지어 잘 정리된 요구사항도 갈등이 발생하거나 불완전한 수용 기준으로 바뀔 수 있으며, 이는 버그와 비즈니스 불만으로 이어질 수 있습니다.

해결책은 시스템 분석가를 수용 기준 형성 초기 단계에 참여시키고, 팀 간 요구사항을 조정하며, 시나리오와 엣지 케이스를 명확히 형식화하고 공동으로 논의하는 것입니다. 이를 위해 공통 데모 또는 그룹 워크숍에서 진행해야 합니다.

주요 특징:

• 수용 기준은 명확하고, 측정 가능하며, 재현 가능하고, 검증 가능해야 합니다.
• 기준의 사전 합의(수동 체크리스트 + 예상되는 데이터/행동의 예).
• 상호 추적성: 기준은 항상 요구사항, 케이스 및 사용자 스토리에 의존해야 하며, 이는 각 목표를 추적할 수 있게 합니다.

함정 질문.

수용 기준의 공식화를 테스터에게만 맡길 수 있습니까?

아니요, 분석가는 반드시 참여해야 합니다. 그는 비즈니스 맥락의 전체를 이해하고 요구사항의 모든 세부사항을 알고 있습니다.

수용 기준은 긍정적인 시나리오만 포함해야 합니까?

아니요, 반드시 부정적인 경우와 경계 케이스도 추가해야 하며, 그렇지 않으면 구현 및 테스트에서 공백이 발생할 수 있습니다.

다중 팀 프로젝트에서 수용 기준을 구두로 정의할 수 있습니까?

아니요, 구두 합의는 분산 상호작용의 압박을 견딜 수 없으며 갈등을 유발합니다. 기준은 반드시 형식화된 방식으로 수용해야 합니다(예: Gherkin/BDD 또는 구조화된 체크리스트 형태로).

일반적인 실수 및 안티 패턴

• 요구사항 및 사양에 대한 참조 없이 기본적으로 수용 기준을 공식화함.
• 최종 팀으로부터 피드백이 없음.
• 통합 시 다른 팀 간의 구성 요소 상호작용 시나리오를 무시함.

실생활 사례

부정적인 케이스: 은행 애플리케이션에서 송금 기능의 수용 기준이 한 팀과만 합의되었습니다. 두 번째 팀은 첫 번째 기준 블록을 고려하지 않고 자체 내부 인터페이스를 구현하여 거래 ID 형식이 일치하지 않았습니다.

장점:

• 빠른 구현 시작.

단점:

• API 리팩토링 필요.
• 충돌 조정을 위한 시간 손실.

긍정적인 케이스: 분석가는 모든 참여 팀을 위해 시각적 시나리오와 세부 사항에 대한 일련의 워크숍을 진행하였고, 수용 기준을 Confluence/JIRA에 반드시 서면으로 기록하고 요구사항에 대한 양방향 추적을 수행하였습니다.

장점:

• 애매함 제거.
• 잠재적인 버그를 신속하게 감지하고 피할 수 있음.

단점:

• 사전 프로젝트 합의에 소요되는 시간 증가.