JIRA/Agile : Sprint의 잘못된 이름 지정? 아니면 잘못된 방법론? 아니면 ...?

Question

나는 백엔드 프로세싱에 관한 3 번째 스프린트에서 프로젝트를 진행하고있다. Sprint 이름이 "3. 데이터 병합 및 양식 생성"이라고합시다. 그 스프린트에서 4 ~ 5 가지 기능이 그 작업과 직접적으로 관련되어 있으며, 일부는 완료되었거나 완료되었거나 완료되지 않았거나 진행 중이다.

이 스프린트에서 클라이언트에게 어떤 일이 일어 났는지를 보여 주었는데, 나는 신속하게 (예기치 못하게) 갑자기 UI에 대한 몇 페이지의 피드백을주었습니다. 매우 프론트 엔드 물건, 내 현재 스프린트와는 아무 상관 없지만 여전히 관련성이 높고 좋은 물건.

그 당시에는 현재의 백 엔드 작업을 중단하고 피드백을 처리하는 것이 적절할 것으로 보입니다. 그 이유는 UI 문제를 해결함으로써 애플리케이션의 나머지 부분에 '잘못된 정보'가 전파되는 것을 막을 수 있기 때문입니다 (Lotus Domino : 이것이 작동하는 방식입니다).

JIRA에는 Sprint를 보류하고 새로운 것을 시작하기위한 기능이 없습니다. 너는 단거리 경주를 닫아야한다.

현재 스프린트에 기능을 추가해도 좋지만 백엔드 처리와 관련하여 명시 적으로 스프린트 이름에 UI 문제로드가 포함될 수 있습니다.

마치 정사각형 둥근 구멍처럼 느껴졌습니다. 이것이 어떻게 애자일 (JIRA)과 함께 움직일 지 확신 할 수 없습니다.

그래서 제 질문은이 : 스프린트의

1. 명명 그래서 백 엔드 처리를위한 스프린트와 UI 작업을 포함하여 자신의 성격에 너무 많은 노력을 포함하지 않아야 .. 문제인가 물건을 화나게하지 마라.
2. 스프린트가 이와 같이 "인터럽트 된"것이라면 내 스프린트를 보류하고 다른 스프린트로 사이드 트래킹하는 것은 애자일이 작동하는 방식이 아니기 때문에 (따라서 JIRA는 사용자를 허용하지 않을 것이다).
3. JIRA는 민첩한 요구보다 유연성이 떨어집니다 (매우 드물 것 같습니다!)
4. 내가 생각하지 못한 몇 가지 다른 점은 무엇입니까? 변화가 상대적으로 작은하고 팀과 제품 소유자 모두가 당신이 그것을 만들 가서 다음에 동의

   경우 :

Answer 1

범위에 대한 일반적인 접근 방식은 다음과 같이 중간 질주가 변경됩니다. 전형적으로 팀은 모든 변경 사항을 보상합니다. 예를 들어 새로운 스토리를 가져올 때 비슷한 크기의 스토리를 꺼내서 스프린트의 최종 효과가 0에 가까워지는 경우입니다.

변경 사항이 큰 경우 the Product Owner may terminate the sprint입니다. 팀은 평소와 같은 방식으로 새로운 스프린트 계획을 즉시 시작합니다.

스프린트에 포함 된 세부 정보와 함께 스프린트의 이름을 지정하는 것이 일반적인 것은 아닙니다. 간단한 숫자 스프린트 이름 (예 : 스프린트 1, 스프린트 2)을 사용하면 스크럼 팀이 변경 될 수 있음을 분명히 알 수 있습니다.

JIRA에서 스프린트가 일찍 종료 된 경우이를 완료로 표시 한 다음 새 스프린트를 작성합니다. 이것은 속도 계산을 약간 엉망으로 만들지 만, 보상하기에 충분히 쉬워야합니다.