불완전한 이야기의 추정으로 무엇을해야합니까?

나는 비교적 새로운 개발 팀의 일원이다 Scrum. 스프린트가 끝날 때 PO in progress가 몇 가지 큰 이야기를하고 있거나 아니라고 가정하자 accepted.

먼저, 사용자 스토리는 어떻게됩니까? 다음 스프린트로 넘어가시겠습니까?

그렇다면 다시 추정해야합니까? 내 생각에 이러한 사용자 스토리에 남아있는 작업은 최소한이거나 많을 수 있습니까? 그렇지 않다면 왜 안됩니까?

편집 : 내 특정 경우에, 이야기는 사용자 이야기 과소 평가가 아니라 며칠 동안의 장애로 인해 완성되지 않았습니다. 도움이 될만한 분들을 위해VersionOne

agile scrum

— 식용 코드
소스

저는 XP 프로세스를 다루며 이런 상황을 처리하는 가장 좋은 방법이 무엇인지 궁금했습니다

— chrisbunney

장애를 가능한 위험으로 식별하고 위험 노출을 결정하지 못하면 RE (영향 * 확률)는 추정에 문제가 있음을 나타냅니다. RE가 높은 사용자 스토리에는 문제가 발생할 경우 이러한 위험을 해결하기 위해 더 큰 비용과 시간 버퍼가 필요합니다.

— 토마스 오웬스

C => F와 같이 두 배로 늘리고 32를 추가하십시오.

— Paul

답변:

먼저, 사용자 스토리는 어떻게됩니까? 다음 스프린트로 넘어가시겠습니까?

때에 따라 다르지. 다른 이야기가 우선 순위가 높지 않으면 다음 스프린트로 이동합니다. 다른 스토리의 우선 순위가 높은 경우 스프린트에 충분한 공간이없는 경우 스토리가 제품 백 로그로 다시 이동 될 수 있습니다. 이 모든 것은 제품 소유자가 각 스토리에 할당 한 우선 순위에 따라 스프린트 계획에서 발생합니다. 스크럼과 같은 민첩한 방법의 목적 중 하나는 시간을 줄이면서 전달 된 가치를 극대화하는 것이기 때문에, 그 이야기를 마치면 부가가치가 얼마나되는지에 달려 있습니다.

어떤 일이 발생하든 스프린트 종료시 배송 가능한 제품을 찾기 위해 노력해야합니다. 이는 스프린트 종료 제품이 모든 테스트를 통과하고 사용자가 완성 된 기능을 큰 문제없이 완전히 사용할 수 있도록 롤백을 의미 할 수 있습니다.

그렇다면 다시 추정해야합니까? 내 생각에 이러한 사용자 스토리에 남아있는 작업은 최소한이거나 많을 수 있습니까? 그렇지 않다면 왜 안됩니까?

스크럼에서는 스토리를 받아들이고 작업을 시작할 때 부분적으로 완전한 개념이 없기 때문에 스토리를 추정하기 때문에 재 추정 하지 않을 것 입니다. 스토리는 100 % 완료, 테스트 및 수락 (완료)되었거나 완료되지 않았습니다. 부분적으로 완전하다는 개념이 없다면 스토리에 남아있는 작업량을 결정할 방법이 없습니다. 나도이 생각에 혼자가 아닌 것 같습니다 . 당신은 당신이 할 수 있다고 생각한 일을 추정 했으므로이 데이터 포인트를 남겨두고 스프린트 사후 추정치가 왜 벗어 났는지 논의하고 미래의 스프린트로 그 실수를 피하려고 노력하십시오.

— 토마스 오웬스
소스

우리는 이것을 한 번만 경험했으며, 추정치가 틀린 것과는 관련이 없었습니다.

— ediblecode

@ user1016253 예상치에 문제가 있음을 의미합니다. 추정에는 위험 노출 (영향 * 확률 = 노출, 노출이 비용, 시간 및 품질에 영향을 미치는 경우)이 포함되어야합니다. 발생한 장애가 있었지만 추정치가이를 설명하지 않았거나 충분히 설명하지 않았기 때문에 간과되거나 잘못 평가 된 것 (영향 또는 확률이 너무 낮아 노출이 너무 낮습니다 (문제가 발생했을 때 문제를 식별하고 수정하는 데 할당 된 리소스가 충분하지 않음)

— Thomas Owens

@ user1016253 그리고 위험과 잠재적 장애물을 추정하고 보는 데 어려움을 겪고 있다면, 스토리를 각 백 로그로 들어가는 여러 스토리 또는 개발 팀에서만 이해하기 위해 하위 스토리로 분해하는 것이 좋습니다. 해야 할 일. 소규모 작업 단위에서 위험 분석을 추정하고 수행하는 것이 더 쉬운 경우가 많습니다.

— 토마스 오웬스

@Thomas Owens : 위험을 관리하는 데 유용한 방법이 아닌 것 같습니다. 특히 치명적이지 않은 확률이 낮은 이벤트는 노출이 적기 때문에 관리가 잘되는 프로젝트조차 일정에 따라 일정을 벗어날 수 있습니다. 위험을 감수하지 않으면 거의 달성 할 수 없습니다. 물론 추정 추적은 변명을 받아들이는 피할 필요가 않습니다, 또는 당신은 단지 최근의 모기지 충돌을 주도하는 투자가 유효 같다 견적을 바람과 같은 이유

— 데이빗 쏜리

@DavidThornley 위험을 전혀 관리하는 방법이 아니라, 탐지 및 완화 전략을 포함하는 위험 관리 계획의 출발점입니다. 이 계획은 계획에 충분한 돈과 시간이있어 위험이 문제로 발전 할 수 있도록하는 기술입니다. 그것은 소프트웨어 평가 및 칼 위 거스에서 스티브 맥코넬에 의해 주창 것 이 논문 . 작업 별 버퍼가 아니라 프로젝트 (또는 반복) 버퍼가 다양한 위험을 구체화해야한다는 것을 인식하는 것이 중요합니다.

— Thomas Owens

일반적으로, 나머지 팀과 프로젝트 스폰서 / 제품 소유자와상의 한 후 스프린트를 초과 한 작업이 무엇인지 결정하는 것은 선출 된 스크럼 마스터의 몫입니다. 스프린트가 끝나면 우선 순위가 무엇인지 검토 할 차례입니다. 문제가되는 스토리가 새로운 스토리 나 기존 스토리보다 우선 순위가 낮을 수 있으며 트래커에 '진행 중'또는 트래커가 사용하는 모든 레이블로 되돌려 놓아이 스토리를 다른 시점에서 추적해야 함을 나타냅니다. 제 시간에. 또는 이야기가 완전히 스코프 될 수 있습니다. 어떤 트래커를 사용하고 있는지 언급하지 않았지만, 내가 본 대부분의 트래커는 스토리가 더 이상 프로젝트의 일부가 아닌 경우 스토리를 '데 스코프 드'로 설정할 수 있도록합니다.

둘째, 팀이 Scrum을 처음 사용하기 때문에 학습 과정의 일부입니다. 이제 일부 스토리가 너무 커서 팀이 스토리를 분류하는 데 더 많은 시간이 걸립니다. 이런 일이 발생하도록하는 것은 일반적으로 스크럼 마스터의 책임입니다. 스크럼 마스터는 또한 불완전한 스토리가있는 프로젝트 스폰서 / 제품 소유자에게 문의하여 추가로 분류하거나 완전히 설명에 대한 최종 발언을 얻어야합니다.

우리 팀에서는 새로운 스크럼 마스터가 2 주마다 선출되므로 (스프린트) 모든 사람이 작업 관리, 스크럼 회의 구성 및 모든 사람이 진행 보고서를 제출하도록하는 기회를 얻습니다. 나는 그것이 당신 팀의 경우라고 기대하고 있습니다. 확실히 좋은 경험입니다.

— 황량한 행성
소스

Nitpick : 불완전한 스토리로 무엇을할지 결정하는 것은 우선 순위의 문제입니다. 따라서 저는 제품 소유자가 Scrum 마스터가 아니라 이것을 결정해야한다고 생각합니다.

— sleske

@sleske-동의합니다. 나는 내 대답에서 그것을 분명히해야했습니다. 원래 나는 스크럼 마스터가 팀과 상담하겠다고 말했지만, 내가 수정 한 프로젝트 스폰서 / 소유자를 포함시켜야했다. 그래도 고마워.

— 황량한 행성

스프린트의 끝에서 불완전한 스토리가 여전히 불완전한 경우 완료 시점의 정의를 완전히 훼손 할 가능성이 있기 때문에 해당 시점에서 실제로 스토리를 분류 할 수 없습니다. 그러나 아직 코드를 검토하지 않았습니다! " 이것이 바로 서사시로서의 이야기가 끔찍하고 스프린트에 절대로 허용되어서는 안되는 이유입니다.

— Robin Green

@RobinGreen 나는 당신의 epics에 동의하고 나는 그들 팬이 아닙니다. 중요한 것 중 하나 (내가 간과 한 많은 사람들이 간과 한 것)는 회고의 가치입니다. 우리는 최근에 JIRA의 Agile 보드를 사용하기 시작했으며 팀의 팀 성과 차트를 자주 보여줍니다. 불완전한 이야기는 언제 그리고 언제 발생하는지 논의하고 즉시 백 로그에 넣습니다. 회고에서는 이야기가 불완전한 이유를 살펴 봅니다. 자원 부족? 지식 부족? 또는 아마도 둘의 느슨한 조합입니다.

— 황량한 행성