평균 스프린트보다 더 나쁜 50 %를 처리하는 방법?

스크럼을 올바르게 이해하면 다음 스프린트에서 팀이 수행 할 수있는 작업을 결정하는 방법입니다.

1. 지난 몇 번의 스프린트에 대해 완료된 포인트 수를 평균화했습니다.

2. 이 수량은 우리의 평균 속도입니다. 다음 스프린트, 우리는 그 많은 이야기 포인트를 취합니다.

이것은 평균 이므로, 역사가 반복되면,이 스프린트 우리는 너무 적은 스토리 포인트를 차지하고 50 %는 너무 많은 스토리 포인트를 차지하고 있습니다.

50 %의 경우 우리는 너무 많은 이야기 포인트를 취했습니다.

• 스프린트를 완료하지 못했습니다. 이것은 우리가 절반의 시간 동안 스프린트 약속을 충족시키지 못할 것임을 의미 합니다.

• 따라 잡기 위해 여분의 일을하십시오. 문제는 이것이 한 방향으로 만 래칫된다는 것입니다. 우리는 스프린트를 달성 할 것이며, 완성 된 스토리 포인트의 수는이를 반영 할 것입니다. 시간이 지남에 따라 항상 마무리하기 때문에 평균은 항상 많은 이야기 포인트를 달성하고 늦게 머무르는 지점까지 상승합니다.

평균 속도와 스프린트 약속에 대한 나의 이해가 정확합니까?

그렇다면 평균보다 낮은 스프린트의 50 %에 대해 어떻게해야합니까?

그렇지 않은 경우, 내가 잘못한 것은 무엇입니까?

평균 속도와 스프린트 약속에 대한 나의 이해가 정확합니까?

예, 당신은 그것의 요점을 가지고 있습니다.

그렇지 않은 경우, 내가 잘못한 것은 무엇입니까?

당신이 간과 것은 이야기의 포인트는 당신이 얻을 것들이다 다 . 스프린트가 끝날 때까지 모든 사람이 이야기를하는 것은 거의 불가능합니다. 당신이 일을 제대로하고 있다면 대부분의 개발자들은 이야기가 테스트되는 동안 며칠 동안 "유휴"상태가 될 것입니다 (개발이 본격적으로 진행되는 동안 스프린트 중간에있는 테스터).

개발자가 고양이 비디오를 보지 않고 버그를 수정하고 코드 / 단위 테스트를 연마하며 프로세스 주변에 문서를 추가하거나 백 로그 또는 스토리 중 하나에 대한 스토리 디자인을 생각하기 때문에 유휴 상태로 인용합니다. 개발 팀이 얻을 수 있지만 이야기에 잘 맞지 않는 수십 가지 유용한 것들.

따라서 시간의 50 %를 과도하게 추측하고 시간의 50 %를 과소 평가한다고해서 스프린트에 실패하거나 초과 근무를해야한다는 의미는 아닙니다 . 그것은 당신이이 기타 작업을 할 시간이 충분하지 않다는 것을 의미합니다 ( 실제로 견적을 놓치지 않는 한 ). 그러나 기타 작업은 시간에 민감하지 않으며 장기적으로는 문제가 발생하기 때문에 큰 문제는 아닙니다.

평균 속도와 스프린트 약속에 대한 나의 이해가 정확합니까?

불행히도 스크럼의 스프린트 계획과 관련하여 몇 가지 잘못된 정보를 받았습니다. 첫째, 개발팀 (DT)은

조직이 자체 작업을 조직하고 관리 할 수 ​​있도록 구조화되고 권한을 부여합니다. - 스크럼 가이드

이것에 대한 단어는 자체 구성입니다. 여기에는 주어진 스프린트에서 수행 될 작업을 예측하는 작업이 포함됩니다. DT는 각 스프린트에서 어떤 작동을하는지 알려주지 않고 자체 작업을 선택할 수 있습니다. DT는 과거 속도, 잘 정립 된 제품 백 로그 및 예측을 작성하기위한 다음 Sprint의 DT 용량과 같은 정보가 필요할 수 있습니다. 궁극적으로, 스프린트에서 달성 할 수있는 것과 불가능한 것에 대한 DT의 결정은 예측에 우선합니다. 그들은 그들이 얼마나 많은 일을하는지 말해서는 안된다.

주의 사항은, 예상 하지 약속을. c-word는 개발 팀을 남용하는 데 사용 되었기 때문에 Scrum Guide에서 제거되었습니다. 예측이 선호되는 용어입니다.

저가형 또는 고급형에서 스프린트 예측이 누락 될 가능성에 대해서는 중요한 것으로 보지 않습니다. 어떤 시점에서 더 많은 분석은 더 나은 정확도를 얻지 못하며 지금은 그 시점을 넘어서는 것 같습니다.

또한 스프린트는 "취소"만 가능합니다. 결코 실패 할 수 없습니다. 스프린트는 스프린트의 목표가 완전히 쓸모없고 관련이없는 경우에만 취소됩니다. 이 경우는 매우 드 rare니다. 예측이 정확하지 않으면 침착하고 스크럼을 유지하십시오. 회고 해 다음 스프린트, 당신의 예측은 더 나을 것입니다 :).

첫째, 속도는 이전 스프린트 또는 때로는 최근 몇 개의 스프린트 (어제 날씨)의 평균이며, 과거의 모든 스프린트의 평균은 아닙니다. 물론 팀이나 회사의 기록 데이터가없는 경우 첫 스프린트에 대한 합리적인 가치를 생각해 내야합니다. 두 번째 스프린트에서는 완성 된 스토리 포인트를 스프린트로 가져옵니다. 그래프를 작성하면 처음 몇 개의 스프린트 (예 : 첫 번째 스프린트의 17, 두 번째의 22, 세 번째의 26, 네 번째의 24)에 대한 변형이 표시 될 수 있습니다. 팀워크와 평가 프로세스를 정상화 할 때 프로젝트 (기술, 도메인)에 대한 이해도를 높일 수 있습니다.

그것은 당신이 조정하지 않는다고 말하는 것이 아닙니다. 예를 들어, 휴일 주인 주가있는 경우, 휴무일이있는 휴일을 고려해야합니다. 팀원이 휴가를 보내고 있다는 것을 알고 있다면 더 적은 수의 사람들이 일하도록 계획하십시오. 물론 계획되지 않은 이벤트도 발생하지만 스프린트 회고의 이벤트를 설명 할 수 있으며 다음 스프린트로 가져 오는 스토리 포인트 수에 어떤 영향을 미치는지 결정할 수 있습니다.

무엇을해야하는지에 대해서는 "스프린트 완료 실패"는 "모든 스토리를 완료하지 못했습니다"와 다릅니다. 나에게 스프린트의 실패는 당신이 마지막에 선적 가능한 제품을 생산하지 않았다는 것을 의미합니다-당신의 이야기가 완전하지 않고, 빌드가 없으며, 고객에게 부가 가치를 보여줄 수 없습니다. 사용자.

무엇을하든 시간이 지남에 따라 늦거나 과도하게 일해서는 안됩니다. 이를 지속 가능한 속도 ( Agile Alliance , Scrum Alliance )라고합니다.

문제가있을 수있는 지표는 다음과 같습니다.

• 팀이 지속 가능한 속도로 일하고 있지 않습니다. 스프린트를 위해 계획된 스토리 포인트를 완료하려면 초과 근무를해야합니다. 압력을 가하지 않고 제 시간에 완료하려면 스프린트를 더 작게 만드십시오.
• 시간이지나면서 속도가 정상화되지 않습니다. 속도가 변하지 않을 것으로 예상되는 사람은 없지만 스파이크 나 스윙이 감지되면 스프린트 회고전의 속도를 조정하십시오. 원인을 파악하고 근본 원인을 해결하십시오.

민첩한 방법론은 회사마다 다르며, 한 구현에서 다른 구현과는 크게 다를 수 있습니다. 저는 애자일에서 두 회사와 함께 일했습니다. 첫 번째 회사에서 그들은 실제로 두 번째 회사에서 통계를 상당히 진지하게 받아 들였습니다. 따라서 아무도 귀하의 측정 항목에주의를 기울이지 않습니다.

그러나 스프린트 목표를 달성하지 못하는 것에 대해 염려하는 것, 또는 부정확 한 추정치가있을 때 발생하는 것 같습니다. 이러한 유형의 우려와 전망은 일반적이라고 생각하지만 특별히 중요하지는 않습니다. 애자일은 무엇보다도 몇 가지 작업을 수행하는 소프트웨어 개발 시스템입니다.

1. 개발자의 이동을 유지
2. 투명도 증가
3. 반영 및 점진적 프로세스 개선 가능

하루가 끝나면 스프린트를 잘못 추정하거나 스프린트에 실패하면 실제로 그렇게 큰 문제는 아닙니다. 회사에서 귀하의 팀 위에있는 사람들은 귀하의 팀이 지속적으로 움직이고 프로젝트가 논리적으로 완성되는 것에 더 관심이있을 것입니다.

애자일 하의 개인으로서 당신은 다른 팀과 관련하여 효과적으로 수행하고있는 작업량에 가장 관심을 가져야합니다. 새로 온 사람이라면 생산성이 높을 것으로 기대할 수는 없지만 고용 기간 중 어느 시점에서 최소한 일부 팀과 동등한 수준에 있어야합니다. 작업을 출력하지 않으면 실제로 작업을 수행하지 않은 것입니다.

평균 속도와 스프린트 약속에 대한 나의 이해가 정확합니까?

평균 속도가 정점에 있습니다. 내 경험상 이것은 백 로그가 크다고 가정 할 때 장기 완료 예상에 매우 유용합니다. 스프린트 계획에 유용하지는 않습니다.

스프린트 계획을 위해 내가 본 과정은 백 로그 상단에서 스토리를 가져 와서 팀이이를 달성 할 수 있는지 결정하도록하는 것입니다. 팀은 직감, 1/2 일 작업으로 분류, 제품 소유자의 압력, 스프린트 목표와의 일치, 최고의 추측 (속도 기반) 또는 이들 모두의 조합을 기반으로 결정했습니다.

때때로 제품 소유자는 더 많은 항목을 추가 할 수 있도록 몇 가지 항목을 건너 뛸 수있었습니다.

때로는 팀과 제품 소유자가 항목을 확장하기 위해 사전 동의 스트레치 항목을 동의합니다.

이것은 훌륭한 질문이며 팀이 개선하는 데 매우 중요합니다. 주제는기만적이고 널리 이해되고 있습니다. 스토리 포인팅의 원래 목적은 스토리에 정의 된 기능을 완성하는 데 필요한 노력 수준 (LOE)을 빠르고 정확하게 추정하는 방법을 찾는 것이 었습니다. 전반적인 목표 : 팀에게 예측 (예 : 프로젝트)을 완료하는 데 걸리는 시간을 예측하거나 예측하는 방법을 제공합니다. 속도에 대한 이해는 맞습니다 : 스프린트 당 평균 평균 점수입니다 (완전히 완료). 따라서 제공 할 프로젝트가 있고 250 포인트이고 팀이 스프린트 당 평균 25 포인트 인 경우 프로젝트에는 대략 10 개의 스프린트가 필요하며 버퍼 시간은 플러스 또는 마이너스가됩니다.

Ken Schwaber와 같은 일부 조명은 속도와 점이 중장기 예측에만 사용된다고 제안합니다. 스프린트에서 실제로 수행 할 수있는 작업에 대한 작업 시간을 두 번째 "위생 확인"으로 사용할 것을 제안합니다. 따라서 각 스프린트의 점수는 용량에 따라 달라질 수 있습니다. 다른 사람들 (나 자신도 포함)은 성숙한 팀이 용량을 정확하게 예측할 수있는 매우 일관된 크기 조정 패턴으로 정착하고 결국 작업 시간이 쓸모없는 추가 부담이 될 것이라고 믿습니다. (팀의 포인트 및 스토리 사이징에 대한 이해가 정확할 때까지 최소 6-12 개의 스프린트 (IMHO)를 위해 새로운 팀을 수행하는 것이 중요합니다.)

첫 번째 작은 오류는 팀이 속도를 알고 많은 이야기 포인트를 가져와야한다는 것입니다. 실제로 코치는 팀이 10 %에서 20 %를 공제하고 대신 그 수준으로 커밋하도록 장려합니다. 따라서 팀이 스프린트 당 25 포인트를 완료하는 경향이 있다면 스프린트를 25 포인트로 채우지 말고 20-22 포인트에서 멈추십시오. 기억하십시오 : 다른 일이 끝났을 때 이야기를 가져 오는 것은 완벽합니다. 따라서 22 점까지 "커밋"하고 28 점을 완수 할 수 있습니다. 팀이 "샌드백"하고 꾸준히 노력하도록 장려하지 않도록 조심하십시오. 우리가 더 많은 것을 할 수 있는지 확인하기 위해 스트레칭하는 데 아무런 문제가 없습니다.

이제 스프린트 간 차이에 대해 설명하겠습니다. 스프린트 20 점, 50 점, 22 점, 45 점, 15 점, 60 점을 모두 달성 한 팀을 보는 것은 매우 일반적인 (그러나 최적이 아님) 패턴입니다. 편차를 계산하면 50 %의 스윙이 표시 될 수 있습니다 스프린트 후 100 % 스프린트. 한 스프린트에서 팀이 15 점을 완료 한 후 다음 스프린트에서 60 점을 완료하는 이유는 무엇입니까?

팀이 실제로 무엇을 할 수 있는지 알지 못할 수도 있습니다. (스프린트 마지막 스프린트 50 점을 완료했습니다.이 스프린트에서 다시 할 수 있습니다).

또는, 제품 소유자가 팀이 과도하게 커밋하거나 스프린트 시작 후 작업을 추가하고 있음을 나타낼 수 있습니다. 이들은 완결 된 포인트에서 이러한 거친 스윙을 유발할 수있는 일부 안티 패턴입니다.

이 예측 성 측정은 스크럼 마스터가 팀의 관심을 끌고 관찰하는 데 중요한 측정입니다. 종종 한 스프린트에서 몇 개의 포인트를 완성한 후 다음 스프린트에서 많은 포인트가 "불완전한 작업의 롤링 웨이브"라고 부릅니다. 다음은 매우 일반적인 패턴입니다.

제품 소유자는 날짜를 충족시켜야합니다. 따라서 팀은 많은 작업을 수행해야 할 필요성을 느낍니다. 그들은 새로운 팀으로 시작하여 실제로 무엇을 할 수 있는지 잘 모릅니다.

따라서 스프린트 1은 스프린트를 계획하며 성형 단계에 있으므로 모든 작업을 완료 할 수 없습니다. 실제로, 그들은 일을하는 것보다 더 불완전한 일을합니다. 불완전한 작업이 시작되었지만 불완전합니다. 그것은 다음 스프린트로 옮겨졌으며 이번에는 불완전한 것보다 더 많은 일을했습니다. 다음 스프린트에 따르면, 불완전한 작업으로 인한 많은 양의 작업이 완료되고 팀의 신뢰가 높아집니다.

제품 소유자가 흥분하여 다시로드를 늘립니다. 이 스프린트가 끝나면 엄청난 양의 불완전한 작업과 실망스러운 양의 DONE 작업이 있습니다.

여기에서 스프린트 후 완료의 파도 대 불완전한 교류 스프린트를 볼 수 있습니다. 팀이 무슨 일이 일어나고 있는지 알지 못하면이 패턴은 몇 달 동안 계속 될 수 있습니다. 그러나 평균적으로 스프린트 당 약 24 포인트를 완료합니다. 초과 커밋을 종료하면 어떻게됩니까?

당신은 여전히 ​​24 ~ 26 포인트를 완료하지만 이월 작업이 줄어 듭니다. 이제 불가능한 양의 작업을 완료하려는 노력에 압도 당하지 않고 팀 사기를 파괴하는 대신 팀은 프로세스 개선을 시작할 수 있습니다.

시간이 지남에 따라 완료 대 불완전한 작업이 크게 흔들리지 않으면 서 속도가 증가하기 시작합니다.

팀에 "느슨한 시간"을 허용하지 않으면 팀이 더 얇고 빠르며 더 나은 작업을 수행 할 시간이 없습니다. 예를 들어 Dev-Ops는 발생할 수 없습니다. 테스트 자동화-누가 그럴 시간이 있습니까? 그러나 이들은 정확하게 팀이 속도를 높이기 위해 노력해야하는 것들입니다.