스크럼 Burndown 문제

Question

우리는 스크럼을 약 9 개월 동안 사용해 왔으며 대부분 성공적으로 수행되었습니다. 그러나 우리의 번 다운 차트는 드물게 '모델'차트처럼 보이지 않습니다. 대신 약간의 구토를 통해 무서운 롤러 코스터 타기와 닮았으며 오르막과 낙하를 유발했습니다.

우리는 스프린트 프로토 타이핑과 디자인을하기 전에 더 많은 시간을 보내고 있지만 우리는 여전히 스프린트 중에 처음 생각했던 것보다 훨씬 더 많은 작업을 발견 한 것으로 보인다. 참고 : 이것은 내가 수주 잔액을 충족시키는 데 필요한 작업이 백 로그에 대한 새 항목을 식별하기보다는 처음 생각보다 복잡하다는 의미입니다.

스크럼과 관련된 일반적인 문제입니까? 누구든지 탑승을 원활하게 할 수있는 팁이 있습니까?

대부분의 개발 작업은 그린 필드가 아니라는 점을 지적해야합니다. 그래서 우리는 기존의 크고 복잡한 응용 프로그램에서 기능을 유지할 것입니다. 기존 코드가 어떤 문제를 일으키는 지 모르기 때문에이 유형의 개발에는 스크럼이 덜 적합합니까?

스프린트가 개발 세부 사항을 만들기 전에 얼마나 많은 시간을 소비해야합니까?

업데이트 : 우리는 더 많은 성공과 더 부드러운 승차감을 갖게되었습니다. 이는 우리가 계획을 세우지 않을 때 상황을 호흡 할 수있는 공간을 더 많이 제공 할 때 더 비관적 인 시각을 취한 덕분입니다. 당신은 우리가 더 민첩해질 수 있다고 말할 수 있습니다. 우리는 또한 화상 감소 차트가 범위 v 자원의 표시 라기보다는 일종의 일정이라는 인식을 바꾸려고 노력하고 있습니다.

Answer 1

부드럽게하는 데 유용한 정보.

1) 다른 사람들이 말한 것처럼 - 작은 덩어리로 작업을 시도해보십시오. 이렇게하는 더 분명한 방법은 기술적 인 작업을 더 자세히 세분화하는 것입니다. 가능한 경우 제품 주인과 이야기하고 범위를 줄이거 나 스토리를 "얇게"할 수 있는지 확인하는 것이 좋습니다. 후자가 더 효과적이라고 생각합니다. 팀과 제품 소유자가 논의되는 내용을 이해하면 저글링 우선 순위와 예상치가 더 쉽습니다. 엄지 손가락의

내 일반적인 규칙은 어떤 추정 더 큰 절반 이상 이상적인 날이 아마 잘못 :-)

2) 짧은 달리기를하고있는 시도입니다. 1 달 스프린트를하는 경우 - 2 주를보십시오. 2 주를하면 1 번 시도하십시오. 당신은 당신의 견적에 대해 더 자주 피드백을받을 정확하게

을 추정하기 쉽게 작은 이야기를 작업 할 제품 소유자와 팀을 격려 - -

• 그것은 이야기의 크기에 제한을 역할을하고 그것을보고 쉽게 결정 사이의 연결 당신은 스프린트의 시작했고 무슨 일이 실제로
• 모든 것은 이유에서 좀 더보고

3) 스탠드 업 및 회고전을 사용 :-) 연습을 더 좋아집니다 발생 기복. 코드 기반의 특정 영역에 시간을 할애합니까? 제품 소유자를 오해 한 사람들이 원인입니까? 팀에서 개발 시간을 단축시키는 임의의 비상 사태? 기복이 어디에서 왔는지 더 많이 이해하면 이러한 문제를 구체적으로 해결할 수 있습니다. 다시 말하면, 짧은 스프린트가 더 명확해질 수 있습니다.

4) 기록을 믿으십시오. 당신은 아마 이것을 알 것입니다 ...하지만 어쨌든 그것을 말할 것입니다 :-) 만약 그 무시 무시한 레거시 푸 (Foo) 패키지를 들먹 거리면 마지막으로 스프린트 할 것이라고 생각했던 것보다 3 배 더 오래 걸린다면 - 생각하면 3 배 더 걸릴 것입니다. 다음 스프린트. 아무리 효과적이라고 생각 하시더라도이 시간이 될 것입니다 ;-) 역사를 신뢰하고 어제의 날씨와 같은 것들을 사용하여 내년 봄에 견적을 안내합니다.

희망이 도움이됩니다.

Answer 2

새로운 작업을 스프린트의 시작일에 통합하여 Burndown 차트를 멋지게 볼 수 있습니다.

특정 마커에 추가 작업을 표시하고 스프린트의 끝에서 이전에 이러한 작업을 식별 할 수없는 이유를 평가할 수 있습니다.

Answer 3

이것은 그래야합니다. 번 다운 차트가 모델 차트와 비슷하다면 문제가 생길 수 있습니다. 이 도표는 여러분이 헌신적으로 모든 이야기를 끝낼 수 있는지 알아 보는 데 도움이 될 것입니다.

스프린트 중 이야기를 발견하는 것은 항상 발생합니다. 이상적으로는 작업을 설계하고 알아낼 수는 있지만 작업 한 경우 왜 큰 선행 설계가 작동하지 않을까요? 마지막 질문에 답하기 위해 스프린트 계획은 at most four hours이되어야합니다.

Answer 4

다른 사람들이 말했듯이, 번 다운은 위 아래로 움직일 것으로 예상됩니다. 물건은 일어난다! 회고전에서는 "위아래로"비트를 사료로 사용해야합니다.

"완료"가 무엇을 의미하는지 명확히하고 합동 이해를 사용하여 계획 세션을 추진하십시오. 가용 한 일을 구성하는 목록을 종종 가지고 있으면 (a) 잊어 버릴 수도있는 것을 기억하고 나중에 (b) 나중에 다룰 수있는 작업에 대한 아이디어를 더 많이 발동하게됩니다.

또 다른 한가지 생각해보십시오. 예측할 수없는 코드베이스로 한 달에 한 달 동안 일하고 있다면, 나는 당신의 속도가 합리적으로 안정된 속도로 정상화 될 것으로 기대합니다. 계획 한 작업에 대한 성공을 추적하고 계획 할 때 완료된 항목 만 최대로 사용하십시오. 그런 다음 계획되지 않은 작업에 중점을두고 계획 한 작업에 이러한 작업을 포함시키기 위해 다르게 수행 할 수있는 작업이 있음을 알리는 패턴이 있는지 확인하십시오.

Answer 5

필자의 경험에 비추어 볼 때, 스크럼은 유지 관리보다 새로운 개발 방향으로 나아갔습니다.새로운 개발은 오래되고 큰 코드 기반을 유지하는 것보다 훨씬 더 예측 가능합니다.

그 한 가지 가능한 문제는 작업을 충분히 작은 덩어리로 분해하지 않는다는 것입니다. 사람들이 일반적으로 소프트웨어 계획을 세우는 데 공통적으로 겪는 공통적 인 문제는 그 작업을 수행하는 것에 대해 실제로 생각하지 않고 "오,이 작업은 2 일이 걸릴 것"이라고 생각한다는 것입니다. 종종 앉아서 생각하면 A, B, C, D를하는 것으로 구성되며 작업은 2 일 이상이 걸리는 것을 알 수 있습니다.

Answer 6

비슷한 문제가 있습니다. 이전 팀이 1 년 넘게 커져서 커다란 초기 제품 출시를 위해 매우 커지고 급변하는 코드베이스를 유지했습니다. 우리의 burndowns은 부끄러워 보였지만, 우리가 할 수있는 최선이었습니다.

그래프가 더 좋아 보이도록하는 데 도움이되는 한 가지 방법은 상수에 대한 시간/점수를 지정하는 것입니다. 작업을 과소 평가하고 시간을 두 배로 늘린다면 스프린트에서 무언가를 꺼내십시오. 새로운 과제를 끌어 당기는 경우 팀이 저지른 것보다 우선 순위가 높아 분명히 다른 것을 끌어내는 것입니다.

우리는 계획을 수립하기 전에 작업을 여러 가지 작업으로 나누어 보았습니다. 결코 도움이되지 못했습니다. 실제로, 그것은 단지 우리에게 스프린트 동안 계속 추적 할 더러운 티켓을 줬다. 요구 사항은 티켓으로 이전하기 시작했고 (당연히) 모든 셔플에서 길을 잃었습니다.

새로운 팀에서 상당히 급진적 인 접근 방식을 취해 "ProjectX에서 v1.2 기능 구현"과 같은 큰 티켓 (일주일 넘게 긴 티켓)을 만들기 시작했습니다. ProjectX (버전 1.2 포함)의 요구 사항/기능 목록은 위키에 보관되어 티켓이 매우 깨끗하고 수행 된 작업 만 추적합니다. 이것은 우리에게 많은 도움이되었습니다. 우리는 way을 추적 할 수있는 티켓이 적어서 우리가 다른 팀을 돕거나 불을 끄기 위해 우리의 스프린트 작업을 계속해서 꺼내더라도 모든 스프린트를 끝낼 수있었습니다.

우리는 (사람에 의해) 새로운 항목을 가져올 수 밖에없는 경우에만 스프린트에서 항목을 밀어냅니다.

우리에게 도움이되는 또 다른 간단한 팁 : "총 시간 in 스프린트"를 번 다운에 추가하십시오. 이것은 모든 추정치의 합계 여야합니다. (... 그건 당신이 강등되지 않습니다 가정) 도움이 줄을 평평하게 유지에 협력과 당신의 팀이 직면 할 수있는 문제의 가시성을 증가

-ab

Answer 7

내 번 다운 비슷한 문제가 있었다 게다가. 나는 번다에 포함 된 것을 정제함으로써 그것을 "고정"했다.

SiKeep 댓글 : 또는 이 릴리스로 끝날하지 않을 수 스프린트 선택한 백 로그 , 대한

진행 상황을.

당신이 스프린트에 대한 특정 사항을 선택 했으므로 해당 내용이 번 다운 상태에 있기 때문에 모든 "새로운 작업"이 번다운 상태로 나타나야한다는 것을 모릅니다. 나는 당신의 현재 스프린트로 이동하기에 충분하지 않다면 (벌딩에 영향을 미치지 않는) 백 로그로가는 것을 볼 것이다.

추세선이 기본적으로 예상 속도를 따르는 경우, 즉 부울의 위/아래가 정상입니다. 나는 당신이 언급하는 롤러 코스터 트렌드에 대해 걱정할 것이다.그러나 우선 순위가 높은 항목을 현재 스프린트에 추가하여 번 다운을 분리하는 아이디어는 번 다운의 위아래를 저해하는 데 도움이 될 수 있습니다.

다른 사람들이 말했듯이, 스프린트가 시작되기 전에 계획하는 것이 짧아야합니다 ... (no more than 4 hours).

Answer 8

스크럼이 대다수 성공했다고 들었습니다. 스프린트 번 다운 차트가 이상적이라고 생각하는 것보다 더 중요합니다. 스프린트 번 다운은 팀이 스프린트 목표를 달성 할 수 있는지 알 수 있도록 도와주는 도구 일뿐입니다. 팀이 스프린트 목표를 달성했다면 차트가 롤러 코스터처럼 보일 정도로 걱정하지 않아도됩니다. 추가 작업

추가 작업에서 오는 몇 가지 제안 스프린트 회고에게 팀 중에

• 은 가지고 있지에서 올 수 초 스프린트에
• 추가 작업을 잘 수용 테스트를 가지고 있지에서 올 수 잘 정리 된 백로. 엄지 손가락의 좋은 규칙은 팀의 시간 중 적어도 5 %를 다음 스프린트의 이야기에 대해 미리 생각하는 것이다.
• 진행중인 모니터 - 팀이 너무 많이 병렬로 작업하고 있습니까?
• 스프린트 계획 중 - 팀이 스토리를 구성하는 작업의 붕괴에 대해 어떻게 생각합니까?

스프린트 목표를 달성하지 못했다면 확정 된 팀 속도를 사용하여 다음 스프린트 동안 적게 사용하십시오. 당신은 당신이 달릴 수 있기 전에 걷는 것을 잘해야합니다.

Answer 9

우리는 계획되지 않은 작업에 '시간 제한'작업을 사용하고 있습니다. 우선 순위가 높은 작업이 올 때마다 또는 갑작스러운 버그가 나타날 때마다 시간 상자의 시간을 사용할 수 있습니다 (단, 절대 0이 될 수는 없습니다). 이 방법은 예상치 못한 작업을 쉽게 추적 할 수 있고 다음 스프린트 계획 중에 이러한 것들을 고려할 수 있다는 추가적인 장점이 있습니다.

Answer 10

이제 불에 업 차트를 사용 중입니다. 남은 일의 양을 차트로 그리는 대신 두 가지를 차트로 작성했습니다. 완료된 작업의 양과 총 작업량 (즉, 완료 + 미결 상태)입니다.

이것은 모든 작업이 완료 될 때 충족시켜야 할 그래프의 두 줄을 제공합니다. 또한 더 많은 작업이 추가되어 진행 상황이 느릴 때를 명확하게 보여 주므로 큰 이점이 있습니다.

원하는 경우 PO는 한 줄 (전체 작업)을 소유하고 개발자/테스터는 다른 줄 (작업 완료)을 소유합니다.

PO 라인은 작업을 추가/제거 할 때 위아래로 이동합니다.

dev/tester 행은 작업이 끝나면 올라갈 것입니다.

Answer 11

제 Is it your burn down chart?은 번 다운 차트에서 어떤 상태가되는지 설명합니다. 또한이를 어떻게 할 지 제안합니다. 기사에 설명

몇 가지 예 : 당신이 번 다운에 차트 무엇