답변:
Scrum의 한 가지 중요한 아이디어는 팀이 "완료된 정의"에 동의해야한다는 것입니다. 이상적으로 이것은 체크리스트를 통해 누구나 확인할 수있는 일련의 객관적인 기준과 같습니다.
하지만 문제가 발생할 가능성을 줄이려면 항목을 구현 한 사람이 아닌 다른 사람 또는 자신과 같은 지정된 QA 담당자가 '완료'를 확인하는 규칙이 가장 적합합니다. 병목 현상).
의심스러운 경우 팀 및 스크럼 마스터와 논의하고 함께 결정하십시오.
나는 그 질문에 암시적인 가정이 있다고 생각합니다. 제품 소유자가 백 로그 항목을 선언하거나 작업이 제품 소유자를 만족시키는 경우 "허용됨"과 "완료"사이에는 차이가 있습니다. "완료"는 백 로그 항목과 관련된 모든 작업이 완료되었음을 의미합니다.
그러나 제품 소유자가 볼 수있는 것보다 정기적으로 더 많은 작업이 있습니다. 일반적으로 (자동 및 수동) 테스트, 문서화 및 검토를 포함하여 반 기술 전문가입니다. 제품 소유자는 완료 여부에 관계없이 기술적 인 측면을 거의 알 수 없습니다.
따라서 "완료"의 의미를 결정하는 것은 궁극적으로 팀의 몫입니다. 조직에는 표준이있을 수 있으며 각기 다른 이해 관계자에게는 고유 한 요구 사항이 있습니다. 스크럼 마스터 또는 관련 관리자는 일반적으로 목록을 수집하고 적용해야합니다.
귀하의 예에서 QA / 테스트 관리자는 테스트 완료 여부를 말하는 사람입니다. 그러나 코드를 검토했는지, 보안 요구 사항을 충족하는지, 제품이 국제화되어 있는지, 문서가 완료되었는지 또는 "완료"로 간주되는지 여부를 말하는 사람은 없을 것입니다.
"완료"의 유일한 개념은 전체 이야기가 완성되었는지 여부입니다. 팀은 이야기가 끝났다고 느낄 때 말하는 완료의 정의를 작성해야합니다. 여기에는 일반적으로 "코드 검토", "야간 테스트 실행", "모든 승인 기준이 충족되었습니다"등과 같은 사항이 포함됩니다. 이러한 사항이 완료되면 팀은 모든 작업을 수행했다고 확신 할 수 있습니다. 그들에게 이야기를 끝내기를 기대했습니다.
스프린트 동안, 완료의 정의에있는 항목 중 하나가 달성되었는지 확인하려는 경우 요청하십시오. 스크럼과 애자일은 모두 열린 커뮤니케이션에 관한 것입니다. 당신이 팀의 일원이라면, 팀원에게 누군가가 테스트를 작성했거나 테스트를 실행하거나 야간 작업 등을 만들 었는지 문의하십시오. 이해 관계자라면 스크럼 마스터에게 문의하십시오.
팀 외부에 앉아 있지만 여전히 테스트를 검토해야하는 경우, 팀에 완료 정의의 일부로 "사용자 user3251930에 의해 테스트를 검토해야합니다"를 추가하도록하십시오. 그것이 이야기를 완성하는 데 필요한 것이라면, 솔직하게 이야기하고 프로세스의 일부로 만드십시오. "완료된 정의"의 요점은 팀이 양질의 소프트웨어를 제공하는 데 필요한 것을 수행했는지 확실하게 알 수 있도록하는 것입니다. 그 중 일부가 외부 검토 인 경우에도 마찬가지입니다.
궁극적으로 특정 스토리에 사인 오프하는 것은 제품 소유자이므로, 마지막 날에 스토리 전체의 완료 여부에 대한 최종 결정을 내립니다.
첫 번째 질문은 스스로에게 물어봐야합니다
스크럼 마스터 입니까? 경우 예.
스크럼 프로세스는 스크럼 마스터에 의해 제어 및 관리됩니다.
어떻게합니까 :
요구 사항 단계에서는 검증해야 할 테스트가있을 때마다 사용자 스토리 를 사용할 수 있습니다 .
각 스프린트에서 작업 항목은 제품 백 로그에서 가져 와서 제품 소유자가 지시합니다. 각 항목에는 확인 기준도 있습니다.
스프린트가 시작된 후에는 스크럼 요구 사항이 변경되지 않습니다.
완료된 경우 제품 소유자의 응답으로 만 찾을 수 있습니다.
애자일 에서는 개발 단계에서 늦게 "변화 를 수용 " 한다는 것을 기억하십시오
이것이 자신의 관행에 따라 개발 / 테스트 팀이 정의해야하는 것에 동의합니다. 일부 프로젝트는 너무 민첩하여 알파 스트림에 버그를 방출 할 위험이 있습니다. 일부는 개발 그룹 외부에있는 버그를 프로세스 실패로 간주합니다.
내가 작업중 인 프로젝트에는 코드 변경 사항에 대한 동료 검토가 필요하며 코드를 작성한 사람은 회귀 테스트를 제공 / 업데이트하거나 왜 그렇게 할 수 없는지 설명해야합니다. (그들과 그들의 검토 자들은 그들이 알려진 나쁜 관행을 확인했다는 것을 증명해야합니다. 우리는 그들이 전체 테스트 스위트를 실행하고 깨끗한 결과 (또는 깨끗한 모듈로 알려진)를 보여줄 수 있다면 일반적으로 훨씬 행복합니다 최소한 공개 된 문제) 코드는 여러 플랫폼에서 집중적 인 자동화 된 장치 및 기능 테스트를 통과 한 후에도 회귀가 발생하지 않음을 입증해야하며 자동화 된 코드 분석 시스템을 통해 일반적인 반 패턴을 추가로 확인해야합니다. 그런 다음 기본 개발 스트림에이를 승인하고 작업 항목을 완료로 표시합니다.
그것은 아무도 새로운 실패의 길을 찾지 못한다고 보장하지는 않지만, 개발 속도를 크게 방해하지 않으면 서 위험을 수용 가능한 수준으로 줄입니다.
Done및Undone