우리의 애자일 버전이 작동하지 않습니다. 팁?

저는 4 명의 개발자로 구성된 소규모 팀에서 일하고 있습니다. 우리는 매주 동일한 문제를 지속적으로 제공하는 Agile 버전을 구현하고 있으며 프로세스 개선에 도움이되는 제안을 찾고 있습니다.

배경:

우리는 일반적으로 2 주 스프린트를 수행하며, 각 스프린트는 업무를 과소 평가하는 경향이 있으며, 일정이 미달되어 관리자에게 문제가 있습니다.

우리는 매니저가 우리를 위해 만든 스토리를 작성하여 각 스프린트를 시작합니다. 때때로 그는 과제도 맡기고 우리는이를 추정합니다. 우리는 스토리 포인트를 사용하지 않습니다. 우리는 Urban Turtle 소프트웨어를 사용하여 "스프린트 관리"는 본질적으로 단지 스토리와 작업이며 관련 번 아웃입니다. 스프린트 종료시 릴리스를 계획하지 않습니다.

가장 일반적인 문제는 스프린트 시작시 작업이 범위가 훨씬 크지 만 우선 순위가 높은 것을 발견하기 위해 작업을 계획하므로 추가 작업을 수행해야한다는 것입니다. 두 번째로 가장 일반적인 문제는 우리 중 한 명이 기술적 인 문제에 부딪쳐서 불타는 시간을 늦추어 장애물을 일으킨다는 것입니다.

우리에게 제공된 유일한 제안은 우리가 필요한 시간을 더 조정할 수 있도록 아침에 스탠드 업을하는 동안 견적을 조정하고 업데이트를 제공하는 데보다 적극적으로 대처하는 것입니다.

그러나 우리가하는 일에 근본적으로 문제가있는 것 같습니다. 아마도 프로젝트 수준에 대한 관리자의 기대와 스프린트 수준에 대한 기대 사이에는 연결이 끊어 질 수 있습니다. 우리는 프로젝트 계획에 따라 이러한 스프린트 반복을 만들고 있기 때문에 스프린트를 연장하거나 항목을 연기하는 것이 프로젝트 계획을 망칩니다. 따라서 개발자는 필요할 때 예상치를 확장하여 시간에 맞춰 스프린트를 완료함으로써 애자일을 수행하도록 장려되고 있습니다.

이것은 드문 문제가 될 수 없으므로 매번 스프린트마다 동일한 문제가 발생하는 것을 멈추는 방법에 대한 제안이 나보다 더 현명 해지기를 바랍니다. 실망 스럽습니다.

우리는 일정이 늦었 기 때문에

이런 유형의 사고는 당신의 문제입니다. 일정이 늦지 않았습니다. 일정이 너무 빡빡합니다. 몇 시간이 아닌 추상적 인 점으로 스토리를 추정 한 다음 2-3 회 반복하여 속도를 계산해야합니다. 속도는 관리자가 원하는 포인트가 아니라 반복 할 때마다 일반적으로 수행하는 포인트 수입니다.

그 후에는 일을 지속적으로 과소 평가하더라도 중요하지 않습니다. 속도가 이미이를 설명합니다.

분명히 포인트 대신 시간을 사용하면 불가능합니다.

문제는 팀이 정확한 추정을 할 수없고 불가피한 문제를 예측할 수없는 것처럼 보입니다.

작은 작업은 큰 작업보다 정확하게 추정하기가 훨씬 쉬우므로 작업을 훨씬 작은 청크로 나누십시오.

그들이 어떻게 할 것인지 정확히 알지 않는 한, 어떤 사람도 어떤 작업을 평가할 수 없습니다. 개발자가 무엇을 완료해야하는지 모르는 작업에 대해서는 개발자가 조사 및 설계를 수행 할 수 있도록이 스프린트 일정에 시간을 투자하고 정확한 견적을 제시하십시오. 반나절을 넘지 마십시오. 그러나 작업을 다음 스프린트로 옮기십시오. 그런 다음 다음 스프린트 계획을 세우면 좋은 평가를 받게됩니다. 이 여분의 시간은 개발자가 어떤 경우에도 지출하게되는 시간이기 때문에 낭비되지 않습니다.

또한 프로젝트 관리자에게 돌아가서 작업 목록을 처리하기 위해 더 많은 스프린트가 필요하다고 말하지 마십시오. 불가능한 목표를 달성하는 것보다 그렇게하는 것이 좋습니다.

시간의 100 %를 할당하려고합니까? 그렇다면 중지하십시오. 스프린트 동안 팀이 기여해야하는 모든 시간을 더하여 시작하십시오. 각 근로자가 하루 6 시간 동안 프로젝트를 진행 한다고 가정 하여이를 수행하십시오. 이것은 "이상적인 날"로 간주됩니다. 다른 두 시간? 회의, 휴식, 관리 업무, 전자 메일을 읽고 하루를 계획하고있는 아침 등의 시간에 빠졌습니다. 이것은 "베팅을 헷지"하거나 "샌드백"이 아니기 때문에 현실적입니다.

둘째, 하루에 6 시간에 80 %를 곱하십시오 . 왜? 인간으로서 우리는 작업에 얼마나 많은 시간이 걸리는지 예측하는데 어려움을 겪습니다. 이것은 우리의 판단에서 오류를 설명합니다. 다시 말하지만, 모래 주머니가 아니라 현실적입니다.

이제 작업에 직접 적용 할 현실적인 시간을 나타내는 숫자가 있습니다. 추정 할 때는 다음 이야기로 이어질 때 이야기 추가를 중단하십시오.

마지막으로 제품 소유자가 작업을 추가하지 못하게합니다. 스크럼 계획은 팀을 위한 것이며 PO는 작업을 수행하는 팀의 일부가 아닙니다. 물론, 실제 세계에서 PO가 팀의 누구보다 지식이 많으면 그녀의 의견이 매우 유용 할 수 있습니다. 그럼에도 불구하고 팀이 뒤처지기 위해 열을 받고 있다면 팀은 그들이 할 일을 정확히 소유해야합니다. 귀하의 목표는 합격 기준을 충족시키는 것입니다. 작업이 직접 수행되지 않으면 수행하지 마십시오.

Scrum은 생산성 향상에 관한 것이 아닙니다. 더 개방적이고 의사 소통하는 것입니다. 작업에는 필요한 모든 작업이 필요합니다. 스크럼은 이해하기 쉽고 이해 관계자와의 의사 소통이 쉬워지고 팀이보다 쉽게 ​​약속을 이행 할 수 있도록하기위한 것입니다.

스프린트 시작시 허용 기준이 잘못 정의 되었습니까?

스토리 카드는 추정시 수용 기준 (있을 경우)이 좋지 않기 때문에 초기 추정치가 너무 낮습니다. 팀이 카드가 무엇인지 실제로 명확하게 파악할 수 있도록 ADD (Acceptance-Test-Driven Development) 일명 스토리 테스팅 으로 전환 하는 것은 어떻습니까?

이야기가 너무 큽니까?

스프린트 중간에 스토리가 예상보다 오래 걸린다는 또 다른 이유는 스토리가 너무 클 수 있습니다. 플래시 플래시 카드 데크 에서 애자일을 보셨습니까 ? "Shrink XL story to Fit"이라는 플래시 카드가 있습니다. 지연 사례, 부작용, 비 기능적 측면 또는 오류 처리와 같은 스토리를 이후 스토리로 분할하는 전략을 제공합니다.

충분한 정보가 없기 때문에 추정 할 수 없습니까?

@sleske는 스파이크 에 대한 좋은 제안을한다 . 추정 시간에 기술 미지수를 시도하고 식별하십시오. 어떤 것이 있다면, 나중에 스프린트로 스토리를 연기하고 대신 이 스프린트를 시간 상자로 조사 (스파이크)하여 추정 할 수있는 방법을 배우십시오. 원래 이야기를 해결하고 해결하지 마십시오. 이야기를 추정 할만큼 충분히 알고 나면 스파이크가 이루어집니다.

더 빨리 실패

@Patrick Hughes에 동의합니다. 1 주 스프린트로 이동하면 문제를 더 빨리 볼 수 있습니다.

@Kevin과 @Patrick의 좋은 제안 외에도 ...

민첩한 접근 방식은 "하나의 크기에 모두 맞는"것은 아니지만이 의견은 주목을 받았습니다.

우리는 동일한 어려움을 지속적으로 제공하는 것으로 보이는 애자일 버전을 구현하고 있습니다.

당신은 "책에 의해"방법론으로 시작하는 것이 좋습니다. (요즘 스크럼은 지배적입니다.)-다른 성공적인 팀이 한 일을 정확히하십시오 ... 몇 가지 스프린트를 위해 그렇게하십시오 ... 현지 조건을 최적화하는 데 필요한 변경.

숙련 된 Scrum 코치를 임대하는 것은 (몇 번의 반복을 위해) 실제 차이를 만들어 낼 수 있습니다. 민첩성을 얻는 데 미묘한 부분이 있습니다.

먼저 책 scrum-xp-from-the-trenches를 따르는 것이 좋습니다 . 속도 계산에 대한 요점을 26 페이지를보십시오. 아이디어는 초점 요소를 정의하고 다음 스프린트에 대해 말하는 것입니다.

사용 가능한 요일 * 초점 계수 = 추정 속도

추정 속도는 다음 스프린트 동안 구현할 스토리의 추정값의 합계입니다.

그리고 한 스프린트 후에는 마지막 스프린트 포커스 팩터를 다음과 같이 계산합니다 :

포커스 팩터 = 실제 속도 / 사용 가능한 요일

여기서 실제 속도는 스프린트 동안 구현 한 스토리의 추정값의 합계입니다.

그런 다음 다음 스프린트에이 실제 포커스 팩터를 재사용하고, 스프린트 몇 개를 마친 후 스프린트 동안 실제로 달성 할 수있는 양을 더 정확하게 파악할 수 있습니다 ...

스프린트를 1 주일로 단축하기 위해 추정치를 얻을 때까지 초과분을 더 빨리 인식하고 더 작은 단위로 반응 할 수 있습니다.

스코프가 완전히 출혈하는 원인이 될 수있는 부작용을 인식하기 위해 호흡 공간을 확보하기 위해 작업을 설계 할 때 더 많은 시간을 앞당기십시오. 작업 자체가 너무 길어서 적절한 민첩한 추정을하기에는 어려울 수 있습니다. 작업이 더 짧은 단계로 분류되어 삼키기가 더 쉬운 지 확인하십시오.

몇 시간 동안 문제에 얽매이지 않고 걸림돌에 부딪히자 마자 누구나 적기를 보내도록 편하게하십시오. 이 과정에서 자아와 비난을 시도하고 분리하십시오. 다른 사람들보다 쉽습니다. =)

@Kevin이 제기 한 것처럼 회의와 같은 오버 헤드가 항상있어 시간을 먹는 사람으로 인식하지 못할 수 있으므로 작업에 100 % 직접 예약하지 마십시오.

일정이 정해지면 2 주로 되돌아 가면 더 적은 회의에서 다시 약간의 시간을 들일 수 있습니다.