협력적인 사용자 스토리 작성과 회고

협력적인 사용자 스토리 작성

부실한 명세는 프로젝트 실패의 주요 원인 중 하나이다. 명세 문제는 사용자가 자신의 진정한 요구사항을 명확히 알지 못하거나, 시스템에 대한 전반적인 비전이 부족하거나, 중복되거나 모순된 기능, 기타 의사소통 문제 등에서 발생할 수 있다. 애자일 개발에서는 사용자 스토리를 작성하여 개발자, 테스터, 비즈니스 담당자의 관점에서 요구사항을 캡처한다. 순차적 개발 방식에서는 요구사항 작성 후 공식적인 리뷰를 통해 이러한 기능에 대한 공동 비전을 확보하지만, 애자일 개발에서는 요구사항 작성 중에 비공식적인 빈번한 리뷰를 통해 이러한 비전을 달성한다.

사용자 스토리는 기능적 특성과 비기능적 특성을 모두 다루어야 한다. 각 스토리에는 이러한 특성을 위한 승인 기준이 포함된다. 승인 기준은 비즈니스 담당자, 개발자, 테스터 간의 협업을 통해 정의되어야 하며, 이는 비즈니스 담당자가 검증할 기능에 대한 확장된 비전을 개발자와 테스터에게 제공한다. 애자일 팀은 승인 기준이 충족될 때 작업이 완료된 것으로 간주한다.

사용자 스토리 작성 과정의 예시 사용자 스토리 작성 과정에서 팀은 먼저 특정 기능이나 요구사항을 정의한다. 예를 들어, 전자상거래 웹사이트에서 “사용자가 장바구니에 상품을 추가할 수 있어야 한다”는 기능적 요구사항을 다룬다고 가정하자. 이 기능적 특성 외에도 “상품 추가가 1초 이내에 완료되어야 한다”는 비기능적 요구사항도 정의할 수 있다. 이후, 팀은 해당 스토리를 세분화하고, 브레인스토밍을 통해 필요한 모든 세부 사항을 도출한다.

기능적/비기능적 특성의 예시

기능적 특성의 예로는 사용자 로그인, 상품 검색, 장바구니 추가 등이 있으며, 이는 시스템이 특정 작업을 수행할 수 있는지 여부를 정의한다. 반면, 비기능적 특성은 성능, 보안, 확장성 등을 포함하며, 예를 들어 “로그인 인증이 2초 이내에 완료되어야 한다”는 요구사항이 이에 해당한다.

테스터의 관점에서 스토리 개선 예시

테스터는 사용자 스토리를 검토할 때 누락된 시나리오를 발견하거나 비기능적 요구사항을 제안할 수 있다. 예를 들어, “사용자가 비밀번호를 재설정할 수 있어야 한다”는 스토리를 검토할 때, 테스터는 “재설정 링크가 일정 시간 후 만료되어야 한다”는 보안 요구사항을 추가할 수 있다.

3C 개념과 예시

• 카드 (Card): “사용자가 이메일 인증을 통해 계정을 활성화할 수 있어야 한다”라는 카드에는 예상 개발 시간, 우선순위, 승인 기준이 명시된다.
• 대화 (Conversation): 팀은 “이메일 인증 링크는 24시간 동안 유효해야 한다”는 비즈니스 논리를 논의하며, 이를 통해 세부 사항을 구체화한다.
• 확인 (Confirmation): “24시간 이후에는 인증 링크가 만료되어야 한다”는 기준이 테스트로 검증된다.

회고

애자일 개발에서는 각 반복(iteration)이 끝날 때 회고(retrospective)라는 회의를 열어 성공적인 점, 개선 가능한 점, 개선 방안을 미래 반복에 어떻게 적용할지 논의한다. 회고에서는 프로세스, 사람, 조직, 관계, 도구와 같은 주제를 다룬다. 적절한 후속 조치를 동반한 정기적인 회고는 팀의 자율 조직화와 개발 및 테스트의 지속적 개선에 매우 중요하다.

회고 진행 과정의 예시 회고는 보통 다음 단계로 진행된다:

1. 팀원 의견 공유: 팀원들은 각자 지난 스프린트에서 잘된 점과 개선이 필요한 점을 포스트잇에 적는다.
2. 의견 그룹화: 비슷한 의견을 그룹으로 묶고, 우선순위를 정한다.
3. 개선 계획 수립: 우선순위가 높은 문제에 대해 실행 가능한 개선 방안을 논의한다. 예를 들어, “테스트 자동화 스크립트 작성에 시간이 부족했다”는 의견이 있다면, 다음 스프린트에서 자동화 작업을 분배하는 계획을 수립한다.
4. 후속 조치 설정: 논의된 개선 사항에 대해 책임자를 지정하고, 진행 상황을 추적한다.

테스터의 역할과 예시

테스터는 회고에서 다음과 같은 역할을 수행할 수 있다:

• 테스트 커버리지를 늘릴 방법 제안: 예를 들어, “지난 스프린트에서 비기능적 요구사항에 대한 테스트가 부족했다”는 의견을 제시하고, 다음 스프린트에서 이를 강화하는 방안을 논의할 수 있다.
• 결함 원인 분석 공유: 특정 결함이 왜 발생했는지 원인을 분석하고, 이를 바탕으로 프로세스 개선을 제안할 수 있다.

상호 신뢰 부족 시의 문제점 상호 신뢰가 부족한 환경에서는 팀원들이 솔직한 의견을 내지 못하거나, 자신의 실수를 숨기는 경향이 생길 수 있다. 이러한 경우 회고는 형식적인 절차로만 끝나며, 실질적인 개선으로 이어지지 못한다. 예를 들어, 결함 원인 분석 과정에서 책임 회피가 발생하면, 동일한 문제가 반복될 가능성이 크다.

개인적인 생각

사용자 스토리와 회고는 애자일 개발의 핵심 요소로, 팀의 협업과 지속적 개선에 크게 기여한다. 사용자 스토리는 명확한 요구사항 정의를 통해 개발 방향을 명확히 하고, 회고는 문제를 식별하고 해결하는 과정에서 팀의 성숙도를 높인다. 하지만 이 과정이 성공적으로 이루어지려면 팀원 간의 신뢰와 적극적인 참여가 필수적이다. 앞으로 인공지능 도구와의 결합을 통해 사용자 스토리 작성과 회고 과정이 더욱 자동화되고 효율화될 가능성이 높다고 본다.