Agile/SCRUM에서 '스프린트 중간' 수용이 유효한 개념인가요?[닫은]

https://stackoverflow.com//questions/9638514

10-12-2019
|

문제

저는 소프트웨어 제품 릴리스를 작업하는 Agile 스크럼 팀의 일원입니다.스프린트 기간은 2주(~10일)입니다.

여기에는 ''라는 독특한 측정항목이 사용됩니다.스프린트 중간 수락'.본질적으로, 스프린트에서 스크럼 팀이 약속하고 계획한 사용자 스토리 포인트의 절반이 해당 스프린트 중간까지 완료되어야 한다고 기대합니다.이로 인해 스프린트가 잘 진행되고 있다는 강력한 지표인 포인트의 선형 소진이 발생한다고 그들은 말합니다.

팀으로서 스프린트 중간 승인은 일반적으로 좋지 않지만 스프린트가 끝날 때까지 헌신적인 사용자 스토리 포인트를 모두 완료하는 것으로 알려져 있습니다.

다음과 같은 질문이 있습니다.

1) 스프린트 중간 수락이 유효한 Agile/SCRUM 관행입니까?다른 곳에서도 사용되고 있나요?

2) 작업의 절반이 절반의 시간 안에 완료될 것으로 기대하는 것은 이를 '공장 현장' 작업으로 취급하는 것과 유사하며, 여기서는 진행 중인 작업의 성격과 복잡성이 완전히 결정적입니다.소프트웨어 개발은 '창조적인' 프로세스이기 때문에 Agile과 같은 매우 유연한 방법론에서 이러한 엄격한 측정 기준은 부적합합니다.어떻게 생각하나요?

3) 우리 스크럼 팀은 스프린트 시간에 맞춰 모든 약속을 완료했지만 스프린트 중간 수락 지표가 좋지 않다는 질문을 받고 있습니다.다른 곳의 스크럼 팀에서는 스프린트가 끝날 무렵에만 약속을 이행하는 것이 완전히 정상적인가요?

미리 감사드립니다.

해결책

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

나는 이전에 중간 스프린트 승인에 대해 들어 본 적이 없습니다.나는 이것이 유효한 Agile/Scrum 관행이라고 생각하지 않습니다. 이 장소 "팀이 작업에 전념하면 제품 소유자는 더 많은 작업을 추가하거나 스프린트 중간에 코스를 변경할 수 없습니다. 세세하게 관리하다."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

언급한 이유로 엄격한 측정항목은 일반적으로 개발자와 함께 사용하는 것이 좋지 않습니다.또한 개발자는 고품질 제품을 생산하는 것보다는 측정되는 모든 항목에서 합격 점수를 얻는 데 더 관심을 가질 것입니다.이것은 Joel Spolsky의 벌레 곰 중 하나입니다. 여기, 여기 그리고 여기

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

성공적인 스크럼 팀은 스프린트가 끝날 때까지 약속한 모든 작업을 완료해야 합니다.번다운 차트는 이 목표를 향한 진행 상황을 안내하기 위해 표시되어야 하며 확실히 스프린트 후반부에 스프린트가 성공할 가능성이 있는지 여부를 나타낼 것입니다.내가 참여한 성공적인 스프린트에서는 사용자 스토리 완성을 향해 꾸준한 진전을 이루는 것이 정상이지만 이는 절반의 시간 안에 사용자 스토리의 절반을 완료하는 데 반영될 수 없으므로 이런 종류의 측정 기준에 반대하는 것이 좋습니다.

다른 팁

진행 중인 작업의 양을 제한하려고 노력해 보셨나요?모든 팀이 몇 가지 스토리에 집중하고 해당 스토리가 끝날 때까지 진행하지 않으면 번다운이 훨씬 더 선형적으로 나타나는 것을 볼 수 있습니다.

이야기의 크기를 살펴보는 것도 가치가 있을 수 있습니다.저는 개인적으로 처음부터 끝까지 완료하는 데 며칠 이상 걸리는 이야기를 보고 싶지 않습니다.

이는 스크럼 관행이 아닙니다.이는 지표로 해석될 수 있지만 나쁜 지표입니다.당신의 의심에 관해서는 당신이 옳습니다.

스크럼에는 진행 상황을 따라갈 수 있는 완벽한 도구인 번다운 차트가 있습니다.임의의 마일스톤을 추가할 필요가 없습니다.

경영진이 스프린트의 기본 개념을 이해하지 못하는 것 같습니다. 상담을 받거나 기본 교육을 받아야 합니다.일주일 내에 수행되는 작업이 여전히 경영진에게 중요하다면 대신 스프린트 길이를 절반으로 줄이도록 제안해 보세요.

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

예, 그렇습니다.

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

작업을 정말 작은 작업으로 나누면 작업 발전에 대한 좋은 측정 기준을 얻을 수 있습니다.따라서 작업을 하루 만에 완료하도록 설계하면 효과적인 번다운 지표 사용을 달성할 수 있습니다.예측할 수 없는 긴 작업이 있는 경우 말씀하신 대로 번다운 측정항목은 관련이 없습니다.

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

문제는 팀이 아니라 작업 설계입니다.문제는 작업 세분성에 관한 것입니다.귀하의 팀은 스프린트 시간 측정 단위로 작업을 완료할 수 있지만 이제는 스프린트 중간 시간 측정 단위에서 작업의 50%가 완료되도록 작업을 구체화해야 합니다.작업을 더 작은 작업으로 나누면 원하는(선형) 번다운 차트를 얻을 수 있습니다.

비표준적인 용어이지만 관리자가 말하는 내용이 있습니다.

끝이 많은 번다운 차트(즉, 차트의 많은 부분에 대해 높게 유지되었다가 마지막에 갑자기 낮아지는 현상)는 작업이 대략적으로 세분화된 관행을 나타냅니다. 전체 스프린트를 완료하고 개별 개발자가 완료합니다.이 패턴을 사용하면 스프린트가 끝나기 직전까지 모든 작업이 완료되지 않은 상태로 유지됩니다.

그것은 실제로 작동하는 방식이 아닙니다.백로그가 우선순위에 따라 정렬되어 있다면 왜 우선순위가 가장 높지 않은 문제를 작업하고 있습니까?또한 이는 각 작업에 대한 "버스 번호"를 매우 낮게 설정하므로 스프린트가 끝날 때까지 작업이 완료되지 않은 상태로 남아 있을 위험이 크게 높아질 수 있습니다.

이 문제를 해결하려면 작업을 훨씬 더 작은 단위로 나누어야 합니다.플래닝 포커를 하고 있고 작업이 8점 이상으로 추정된다면 작업이 과소 지정되었을 가능성이 높습니다.그것은 분해되어야 합니다.가능하다면 2초와 3초(또는 그 이하!)로 유지하십시오.이러한 방식으로 여러 개발자가 동일한 전체 목표에 대해 독립적으로 작업할 수 있으며 동일한 작업이 완료되는 동안에도 번다운 차트가 더 매끄럽고 덜 위험해 보이기 시작합니다.

Mid Sprint 수용은 민첩한 관행이 아니거나 실제로 작동하지 않습니다.각 사용자 스토리 및 작업(예: Rally)에 대한 정확한 추정이 있는 경우 번다운 차트는 스프린트 작업이 계획과 일치하고 시간 내에 완료될 수 있는지 여부를 명확하게 보여줍니다.수락은 작업이 아닌 사용자 스토리의 개발 및 테스트가 끝날 때만 이루어집니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow