답변:
TL; DR : 필요할 때마다 해제
릴리스를 수행 할 가치가있을 때마다 릴리스를 수행합니다. 때로는 단일 기능 또는 버그 수정이 완료된 후 릴리스를 수행하는 것을 의미합니다. 때때로 이것은 기능 및 / 또는 버그 수정 모음을 발표하는 것을 의미합니다.
그렇다고해서 빠른 릴리스가 필요한 "긴급 상황"이 자주있는 것은 아닙니다. 출시를 쉽게하기 위해 열심히 노력했음을 의미합니다. 우리의 코드는 모든 빌드와 함께 테스트, 태그 및 패키지로 제공됩니다. 우리는 자동화 된 승인 테스트를 사용하므로 테스트를 통과 한 코드에 대해 많은 신뢰를 얻었습니다. 우리의 패키지는 로컬 yum repo를 통해 즉시 사용 가능하므로 릴리스 배포는 쉽지 않습니다.
절대로 이는 "스프린트"의 기본 전제에 위배됩니다. 당신은 당신이 끝내기로 결심 한 것을 마칠 때까지 달려갑니다. 완료하면 실제로 완료되고 작동합니다. 그런 다음 해제 할 수 있습니다.
출시는 출시를 위해 물건이 포장되는 별도의 스프린트 유형일 수 있습니다.
버그 수정 릴리스는 짧은 스프린트 일 수 있습니다. 같은 길이의 스프린트를 정기적으로 예약하지 않는 것은 많은 사람들에게 나쁜 생각으로 간주됩니다. 따라서 일반적인 규칙은 버그 수정이 다음 스프린트 동안 발생하는 우선 순위가 높은 작업이라는 것입니다 .
비상 사태라면 지원 및 개발이 너무 많아서 더 적은 일이 발생하도록 조직을 변경하는 것이 좋습니다.
팀이 맡고있는 작업이 스프린트 내에서 여러 릴리스를 수행하는 데 도움이되는 경우 원하는 횟수만큼 릴리스하십시오.
결함 수정 릴리스의 경우에도 마찬가지입니다. 릴리스하는 것이 타당하다면 그렇게하십시오.
내가 일했던 마지막 애자일 직업은 모든 스프린트를 릴리스했습니다. 매주 목요일마다 (2 주 스프린트) 코드가 동결 된 후 고객이 작업 할 수 있도록 제품이 패키지되어 UAT 서버에 게시되었습니다. 이것은 제품의 초기 개발 중이었습니다. 웹 응용 프로그램이 아닌 배포 가능한 프로그램, 특히 성숙한 제품의 경우 2 ~ 3 주마다 업그레이드하는 데 부담을주지 않을 것입니다.
거의 모든 릴리스에는 스토리 포인트와 결함 (버그)이 혼합되어 있습니다. 결함은 "이상적이지 않은 시간"으로 계산됩니다. 근무일에 이상적인 5 시간이 있으며 이는 새로운 포인트 작업의 헤드 다운 코딩을 의미합니다. 하루에 다른 3-4 시간은 회의, 토론, 디자인, 때로는 "스파이크"(중심 연구 / 개념 증명 개발) 및 결함 작업입니다. 더 나은 제품에 기여하고 프로세스의 필수 부분이지만 팀 전체의 스프린트를 감당할 수없는 것입니다. 결함 전용 릴리스를 수행 한 유일한 시간은 IPM 기준으로 백 로그에 사용 가능한 스토리 포인트 작업이없는 경우였습니다. 그런 다음 QA 스프린트를 예약하여 "가능한 한 많은 결함을 제거"하라는 지시를 받았습니다. 준비 할 요구 사항이없는 것은 항상 PO의 결함 (및 PO가 클라이언트를 위해 작동 함)이기 때문에, 우리는 단순히 계약 변경 통지를 발행하고 우리가 가진 것과 협력 할 수 있습니다. 물론 실제 이야기 작업이 끝나고 우리가 "보증"개발에 들어간 후에는 결함이 모두있었습니다.
잘 관리되는 Agile 프로젝트에서 요구 사항이 절대로 발생하지 않아야합니다. 백 로그에는 항상 스프린트 작업을 수행 할 준비가되어 있어야합니다. 그러나 때로는 PO가 생산 요구 사항에 휩싸입니다. 경우에 따라 BA / 테스터는 요구 품질 또는 스토리 충돌과 관련된 이유로 스토리를 개발 백 로그에 공개합니다. 때로는 팀이 잘 정의되지 않았거나 예측이 어려운 이야기를 "펀트"해야한다고 결정하고 나머지주기를 쉽게 수행 할 수있는 것이없는 경우가 있습니다. 요컨대, 애자일에서도 똥이 발생합니다.
출시한다는 것은 무엇을 의미합니까? PSP-아마도 선적 가능한 제품을 의미한다면 두 가지 옵션이 있습니다.
레벨 2와 레벨 3의 주요 차이점은 레벨 2에서는 스프린트가 끝날 때 최종 PSP를 만들기 위해 약간의 노력을 기울여야하지만 레벨 3에서는 처음에는 도구와 구성에 약간의 돈과 노력을 기울이고 PSP를 준비했다는 것입니다 항상 자동으로 = 수동 작업이 필요하지 않습니다. 레벨 3을 완전히 달성하는 것은 드 rare니다.
Scrum에는 새로운 기능이 배포 될시기에 관한 규칙이 전혀 없습니다. 모든 팀에는 "완료 정의"가 있어야하며 여기에는 항상 테스트에 대한 몇 가지 기준이 포함되어야합니다. 기능이 "완료"되면 실제 환경에 대한 준비가되어 있으며 배포하기 전에 충족해야 할 다른 종속성이나 조건이없는 경우 Sprint가 종료 될 때까지 기다릴 이유가 없습니다. 배포하십시오.
스프린트 검토 / 계획 회의에서 발표되지 않았다는 의미는 없습니다. 개념은 팀이 완료 한 모든 내용이 PO (및 기타 고객 SME)에게 표시되므로 시스템이 발전함에 따라 점점 더 시스템에 대한 이해도를 높일 수 있습니다.
몇 주 후에 우리는 우리의 요구에 맞는 좋은 솔루션을 찾았습니다. 우리는 언제든지 원할 때 석방하기로 결정합니다. 우리가 그렇게하는 방법 :
그게 다야. 우리는 CI 시스템으로 git과 maven을 사용하며 테스트 범위가 좋습니다. 우리가 이렇게 할 수있는 이유 중 하나입니다.
거의 2 세인 질문에 대답하는 것은 약간 중복 될 수 있지만 희망적 으로이 질문에 오는 사람들에게 가치를 더하기 위해 2 센트 정도를 추가하고 싶습니다. :)
질문에 답하려면 : 스프린트가 끝날 때 스프린트에서 커밋 된 것을 해제해야합니다. 이를 통해 스크럼의 다른 모든 부품 / 프로세스 / 가이드 라인과 연계하여 적시에 최고의 비즈니스 가치를 창출 할 수 있습니다.
그러나 긴급 상황, 버그, 예상치 못한 이벤트 등으로 인해 손을 잡을 수 있습니다. "릴리스 계획"이 유용한 개념입니다. "릴리즈 계획"이란 폭포 형 계획이 아니라 스프린트에서 제품 백 로그 및 스토리 우선 순위를 관리하는 데 도움이 될 수있는 기대 계획을 의미합니다.
그러나 아마도이 질문에 대한 다윗의 의견은 가장 고려해야 할 사항입니다. 스크럼이 항상 정답은 아닙니다.