Schwaber & Beedle's 'scrum' book (그리고 제가 읽은 다른 스크럼 문헌들)은 스프린트가 끝날 때 출시 가능한 제품에 초점을 맞추고있는 것 같다. 확립 된 사이트 (적어도 우리의 경우)를위한 웹 개발은 (다양한 크기의) '향상된 기능'과 많은 '수정'을 개발하는 것으로 구성됩니다. 스프린트가 끝날 때만 웹에 배포하면 큰 기능 향상이 느려지지만 (좋은 기능 일 수도 있지만) 작은 기능 향상 (예 : 버그가 오래 걸림)이 크게 늘어납니다.스프린트와 함께 중간 스프린트를 배치했다. (계속 진행중인 'brownfield'공개 웹 프로젝트)
중간 스프린트 배포는 스크럼에서 이단 적입니까? 우리의 경우에도 스프린트가 적용 가능합니까? 전 스프린트를 완전히 오해 했나요?
스프린트가 끝날 때 완료된 작업은 검토 회의 중에 제품 소유자가 검토해야합니다. 중간에 놓으면이 경우가 아닐 수도 있습니다. 당신이 일을 할 수 스프린트가 끝나기 전에 완전 함을 느끼는 경우
:
작업 환경에 대한 설명이 주어지면 2를 선택합니다.
더 많은 애자일 방법론을 고려할 수도 있습니다 당신의 환경에 맞춰라.
나는 중간 스프린트를 공개하지 않을 것이다.
정말 배포 중간 스프린트 나쁜 생각처럼 들리겠다고 생각합니다. 진짜 초점 - stealer.
스프린트 길이를 줄이면 도움이 될까요?
믿을 수 없을 정도로 나쁨 - 이것이 PM이 실패했다는 것을 아는 지점입니다. – annakata
엄격한 스크럼 기반 개발을 수행하려는 경우 중간 스프린트 배포가 이단입니다. 제 생각에는 엄격한 스크럼 접근법이 시나리오에 사용할 수있는 최상의 도구가 아닙니다. 나는 패키지와 태스크를 임명 한 전개를 정의한보다 고전적인 접근 방식을 사용하고자한다. 단일 트렁크에서 개발하고 주어진 배포 패키지의 모든 작업이 완료되면 배포합니다. 그러나 코드와 프로젝트 내의 제약 사항을 알고 있어야합니다.
Alistair Cockburn Crystal "Orange Web"방법을 살펴볼 수 있습니다. 그는 민첩한 원칙을 공개 웹 사이트 제약 조건에 적용했습니다.
스프린트 끝에 릴리스 할 수있는 콘텐츠를 보유해도 중간 스프린트 릴리스가 배제되지 않습니다. 사실, 팀이 생산 지원 책임을 맡을 때는 반드시 필요합니다.
그래도 난이 중간 스프린트 릴리스에 대한 몇 가지 질문을합니다 :
1) 이전 릴리스의 증분 값은 배포의 비용을 초과 하는가? 2) 미니 배포가 각각 역효과를 일으키지 않고 더 많은 일자리를 창출 할 수 있는지에 대한 위험성을 평가 했습니까? 3) 미니 발매물에 대한 고객 피드백을 통해 원하는대로 출시 할 수 있습니까? 4) 스프린트 단축을 고려 했습니까?
위의 "엄격한 스크럼 구동 개발"은 저에게 모순입니다. 만트라는 조사하고 적응합니다.나는 스크럼이 이해 관계자들에 대한 향상된 대응성에 대한 교리로 쓰이고 있음을 제안했다.
프로그래밍과 관련이 없으므로이 질문을 주제와 관련이 없으므로 닫으려고합니다. –