스프린트 항목이 완료되는 데 시간이 오래 걸립니다. 우리는 무엇을해야합니까?

스크럼의 항목이 예상보다 오래 걸리면 어떻게해야합니까? 나는 처음에 생각했던 것보다 훨씬 어려워 개발자가 완성하기 위해 고군분투하고있는 항목을 주목했기 때문에 이것을 묻고 있습니다.

그런 상황에서 우리는

• 스프린트 타임 라인을 충족 할 수 있도록 스프린트에서 다시 제품 카탈로그로 항목을 제거 하시겠습니까?
• 더 쉬운 스프린트 항목으로 이동하고 타임 라인이 끝날 때까지 문제가있는 스프린트를 남겨 둡니다.
• 스프린트 리뷰에서 왜 현재 스프린트에서 이해 관계자에게 아이템을 완성 할 수 없는가?

미래에 어떻게 그러한 상황을 피할 수 있습니까? 초기 계획이 부족하거나 스프린트 항목을 더 작은 항목으로 나누려고 노력하지 않았습니까?

"항목"을 사용하면 "작업"을 의미한다고 가정합니다.

소프트웨어 낙관론은 소프트웨어만큼 오래되었습니다. 스크럼에 대한 좋은 점은 곧 직면하고 가시성을 창출한다는 것입니다. 이것이 팀 속도가 미래 추정치가 아닌 과거 데이터를 기반으로하는 이유입니다.

스토리를 완성하려면 예상보다 훨씬 어려운 작업도 완료해야합니다. 연기 할 이유가 없습니다. (이것이 Done의 정의가 중요한 이유입니다). 그것이 팀이 이야기에 실패하고 너무 나쁘다는 것을 의미한다면, 다음 회고에 대해 이야기 할 것이 있습니다. Velocity는 내려 가고 (보다 현실적이 됨) 팀은 더 나은 견적을 내리거나 예기치 않은 작업에 대해 더 많은 안전 여유를 남길 것입니다. 제품 소유자는 자신의 출시 계획을보다 사실적으로 볼 수 있습니다.

스크럼의 항목이 예상보다 오래 걸리면 어떻게해야합니까?

항목별로 스토리를 의미한다고 가정하면 스프린트가 끝나면 일반적으로 제품 백 로그에 다시 넣습니다 (그리고 다음 반복을 위해 계획 할 수도 있음). 팀은 현재 반복에서 0 점을 얻습니다.

이야기가 충분히 큰 경우 다른 대안은 세로 로 슬라이스하는 것 입니다. 예를 들어, "제품 카탈로그 검색"스토리는 "카테고리 별 검색"및 "전체 텍스트 검색"으로 분할 될 수 있지만 "검색 양식"및 "검색 결과"로는 분할되지 않을 수 있습니다.

미래에 어떻게 그러한 상황을 피할 수 있습니까?

이에 대한 직접적인 대답은 없습니다. 스크럼에서는 일반적으로 팀과 이러한 종류의 것들을 논의하는 모든 반복마다 스프린트 회고를 수행합니다. 여러 가지 가능성이 있습니다.

• 팀 또는 일부 팀원의 주가 잘못
• 팀 파이프 라인은 항목을 수평으로 처리합니다 (예 : 백엔드-> 프론트 엔드-> QA)
• 이야기가 실수로 너무 크다
• 팀은 스토리 완료에 꼭 필요한 추가 작업을 추가하여 스토리를 "골드 플레이트"합니다.
• 이야기는 본질적으로 매우 크므로 더 긴 스프린트가 필요합니다.
• 팀은 이야기를 부정확하게 추정합니다 (일관되지 않음).
• 프로젝트에 많은 기술 부채 / 부패 코드 기반이 있으며 속도가 너무 낮습니다
• 스프린트 용량을 정확하게 측정하거나 추정하지 않습니다.

등

당신은 당신이 그것을 끝내지 않을 것이라고 말하지만 그것은 나쁘지 않습니다. 그것은 단지 데이터입니다.

"스프린트 타임 라인을 만나십시오"는 목표가 아닙니다. 목표는 사용자 스토리를 완성하는 것입니다. 타임 라인은 스프린트에서 얼마나 많은 일을 할 수 있는지 측정하고 배우는 데 도움이되는 도구 일뿐입니다.

스프린트에서 작업을 완료 할 수없는 경우 우선 순위 목록의 맨 아래로 이동하고 스프린트에서 다른 스토리에 대해 작업하는 것이 하나의 해결책입니다. 그런 다음 남은 시간으로 작업을 시작할 수 있습니다. 다음 스프린트로 진행되는 작업을 다시 추정하고 완료하십시오.

소급하여 미래에 예상치를 개선 할 수 있도록 무엇이 잘못되었는지 논의하십시오.

작업이 예상보다 오래 걸리는 경우, 소급하여 논의해야합니다. 초기 분석에서 누락 된 부분이 있습니까? 팀에서 이미 수행하지 않은 것이 었습니까? 초기 예상보다 시간이 오래 걸리는 데는 여러 가지 이유가 있습니다.

팀은 가능한 한 최선을 다해 업무를 수행 한 후 회고에서 향후 이에 대한 전략을 논의해야합니다. 팀이 스크럼을 처음 사용하는 경우 팀의 초기 속도를 측정하는 데 도움이 될 수 있습니다. 어떤 팀은 20 점을 낼 수 있다고 생각할 수도 있고 어떤 팀은 60 점을 낼 수도 있다고 생각합니다. 요점은 각 스프린트마다 같은 수의 포인트를 얼마나 일관되게 수행 할 수 있는지입니다.

이는 향후 팀이 수행하지 않은 새로운 작업을 수행 할 때마다 예상치 못한 문제를 해결하는 데 시간이 걸리기 때문에 발생합니다. 이것은 실제로 놀라운 일이되어서는 안되는 학습 과정의 일부입니다.

작업이 예상보다 오래 걸리기 시작할 때 일반적으로 회사에서하는 일은 작업을 작은 작업으로 나누는 것입니다.

그렇게하면 개발자가 너무 느리다는 비난을받지는 않지만 작업이 잘못 설계되었음을 인정합니다.

또 다른 것은 개발자가 늦게 ​​구멍을 파지 않도록 개발 팀의 다른 구성원에게 작업을 할당하는 것입니다. 작업이 매우 중요한 경우 일부 XP가 해결책이 될 수 있습니다.