스크럼 번다운 문제 [닫기]
https://stackoverflow.com/questions/91257
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
우리는 스크럼을 약 9개월 동안 사용해 왔으며 대체로 성공적이었습니다.그러나 우리의 번다운 차트는 '모델' 차트와 거의 닮지 않았으며, 대신 오르막과 내리막을 유발하는 약간의 토사물이 있는 무서운 롤러코스터 타기와 더 유사합니다.
이 문제를 해결하기 위해 우리는 스프린트 프로토타이핑 및 디자인 전에 더 많은 시간을 소비하고 있지만 여전히 처음 생각했던 것보다 스프린트 동안 훨씬 더 많은 작업을 발견하는 것 같습니다.메모:이는 백로그에 대한 새 항목을 식별한 것보다 백로그를 충족하는 데 필요한 작업이 처음 생각했던 것보다 더 복잡하다는 것을 의미합니다.
이것이 스크럼의 일반적인 문제인가요? 원활하게 진행하는 데 도움이 되는 팁이 있는 사람이 있나요?
우리 개발 작업의 대부분은 신규 개발 작업이 아니기 때문에 기존의 크고 복잡한 애플리케이션의 기능을 유지하고 있다는 점을 지적하고 싶습니다.기존 코드가 어떤 문제를 일으킬지 모르기 때문에 스크럼이 이러한 유형의 개발에 덜 적합합니까?
스프린트가 개발의 세부 사항을 해결하기 시작하기 전에 얼마나 많은 시간을 소비해야 합니까?
업데이트:우리는 이제 더 많은 성공을 거두고 있으며 더 부드러운 승차감을 누리고 있습니다.이는 주로 우리가 계획대로 진행되지 않는 일을 처리할 수 있는 더 많은 호흡 공간을 제공하는 예측 시 더 비관적인 관점을 취했기 때문입니다.이를 통해 우리는 더욱 '민첩'해질 수 있다고 말할 수 있습니다.또한 번다운 차트가 범위와 리소스를 표시하는 것이 아니라 일종의 일정이라는 인식을 바꾸려고 노력하고 있습니다.
해결책
일을 원활하게 하는 몇 가지 팁.
1) 다른 사람들이 말했듯이 작업을 더 작은 덩어리로 나누어 보십시오.이를 수행하는 보다 확실한 방법은 기술적인 작업을 더 자세히 분석하고 분석하는 것입니다.가능하다면 제품 소유자와 대화하여 범위를 줄이거나 이야기를 "얇게" 할 수 있는지 알아보는 것이 좋습니다.나는 후자가 더 효과적이라고 생각합니다.팀과 제품 소유자가 논의 내용을 이해하면 우선순위와 추정치를 조정하는 것이 더 쉽습니다.
내 일반적인 경험 법칙은 이상적인 하루의 절반보다 큰 추정치는 아마도 틀릴 수 있다는 것입니다 :-)
2) 더 짧은 단거리 달리기를 시도해 보세요.한 달 동안 스프린트를 한다면 2주 동안 시도해 보세요.2주 동안 한다면 한 번 시도해 보세요.
- 이는 스토리 크기를 제한하는 역할을 하며 제품 소유자와 팀이 정확하게 추정하기 더 쉬운 작은 스토리를 작업하도록 장려합니다.
- 추정치에 대한 피드백을 더 자주 받게 되며, 스프린트 시작 시 내린 결정과 실제로 발생한 일 사이의 연관성을 더 쉽게 확인할 수 있습니다.
- 연습하면 모든 것이 좋아집니다 :-)
3) 스탠드 업과 회고를 사용하여 상승과 하락의 이유를 좀 더 살펴보십시오.코드 베이스의 특정 영역에 시간을 할애할 때인가요?제품 소유자에 대한 대중의 오해로 인해 발생합니까?팀의 개발 시간을 빼앗는 무작위 긴급 상황이 있습니까?기복이 어디에서 발생하는지 더 잘 이해하면 해당 문제를 구체적으로 해결할 수 있는 경우가 많습니다.다시 말하지만, 더 짧은 스프린트는 이를 더욱 분명하게 만드는 데 도움이 될 수 있습니다.
4) 당신의 역사를 믿으십시오.당신은 아마 이것을 알고있을 것입니다 ...하지만 어쨌든 말하겠습니다 :-) 그 무시무시한 레거시 Foo 패키지를 조작하는 데 스프린트 지속 시간이 생각했던 것보다 3배 더 오래 걸렸다면 다음 스프린트에서 생각하는 것보다 3배 더 오래 걸릴 것입니다.이번에는 얼마나 더 효과적일 것이라고 생각하더라도 ;-) 기록을 신뢰하고 어제의 날씨와 같은 정보를 사용하여 다음 봄에 추정치를 안내하세요.
도움이 되었기를 바랍니다!
다른 팁
스크럼이 큰 성공을 거두었다는 소식을 들으니 기쁩니다. 이는 스프린트 번다운 차트를 이상적으로 보이게 만드는 것보다 더 중요합니다.스프린트 번다운은 팀이 스프린트 목표를 달성하고 있는지 확인하는 데 도움이 되는 도구일 뿐입니다.팀이 스프린트 목표를 달성했다면 차트가 롤러코스터처럼 보일까 봐 크게 걱정하지 않을 것입니다.몇 가지 제안
- 스프린트 회고 중에 팀에게 추가 작업이 어디서 오는지 물어보세요.
- 스프린트 초기에 좋은 승인 테스트를 거치지 않으면 추가 작업이 발생할 수 있습니다.
- 백로그를 잘 정리하지 않으면 추가 작업이 발생할 수 있습니다.경험상 좋은 법칙은 팀 시간의 최소 5%를 다음 스프린트의 스토리를 미리 생각하는 데 사용하는 것입니다.
- 진행 중인 작업 모니터링 - 팀이 너무 많은 작업을 동시에 수행하고 있나요?
- 스프린트 계획 중에 팀은 스토리를 구성하는 작업 분류에 대해 어떻게 생각합니까?
스프린트 목표를 달성하지 못했다면 설정된 팀 속도를 사용하여 다음 스프린트 동안 더 적은 양을 수행하십시오.달리기를 하기 전에 걷기를 잘해야 합니다.
내 경험에 따르면 스크럼은 확실히 유지 관리보다는 새로운 개발에 더 중점을 두고 있습니다.새로운 개발은 오래된 대규모 코드 기반을 유지하는 것보다 훨씬 더 예측 가능합니다.
그렇다면 가능한 문제 중 하나는 작업을 충분히 작은 덩어리로 나누지 않는다는 것입니다.일반적으로 사람들이 소프트웨어 계획에 대해 겪는 일반적인 문제는 해당 작업을 수행하는 데 필요한 사항에 대해 실제로 생각하지 않고 "아, 이 작업에는 이틀이 걸릴 것"이라고 생각한다는 것입니다.앉아서 생각해 보면 그 작업이 A, B, C, D로 구성되어 있고 결국 2일 이상의 작업이 된다는 것을 알게 될 것입니다.
다른 사람들이 말했듯이, 나는 번다운이 위아래로 일어날 것으로 예상합니다.일이 일어납니다!회고를 위한 자료로 "위 및 아래" 비트를 사용해야 합니다.
모든 사람이 "완료"가 무엇을 의미하는지 명확히 이해하고 공동 이해를 활용하여 계획 세션을 진행하도록 하세요.수행할 작업 목록을 사용하면 (a) 잊어버릴 수 있는 사항을 기억하는 데 도움이 되고 (b) 나중에 떠오를 작업에 대한 더 많은 아이디어가 촉발될 가능성이 높습니다.
고려해야 할 또 다른 점 - 예측할 수 없는 코드베이스로 매달 작업하는 경우 속도가 합리적으로 안정적인 속도로 정규화될 것으로 기대합니다.계획한 작업과 비교하여 성공 여부를 추적하고 계획할 때 완료된 항목만 최대한 활용하세요.그런 다음 계획되지 않은 작업에 집중하고 이러한 작업을 계획된 작업에 포함하기 위해 다르게 수행할 수 있는 작업이 있음을 나타내는 패턴이 있는지 확인하세요.
비슷한 문제가 발생했습니다.나의 이전 팀(1년 넘게 참여)은 규모가 크고 일련의 초기 제품 출시를 위해 매우 크고 빠르게 변화하는 코드베이스를 유지했습니다.우리의 번다운은 부끄러워 보였으나 우리가 할 수 있는 최선이었습니다.
그래프를 더 좋게 만드는 데 도움이 될 수 있는 한 가지는 일정하게 헌신하는 시간/포인트 수를 고수하는 것입니다.작업을 과소평가하여 두 배의 시간을 해야 한다면 스프린트에서 뭔가를 빼내십시오.새로운 작업을 시작하는 경우 팀에서 수행하는 작업보다 우선순위가 더 높으므로 다른 작업을 수행하세요.
우리는 계획을 세우는 도중과 그 전에 작업을 여러 작업으로 나누려고 시도했지만 전혀 도움이 되지 않는 것 같았습니다.사실, 스프린트 동안 추적해야 할 티켓이 더 많이 생겼습니다.요구 사항이 티켓으로 마이그레이션되기 시작했고 (놀랍지도 않게) 모든 셔플에서 길을 잃었습니다.
새로운 팀에서 우리는 꽤 급진적 인 접근 방식을 취하고 "ProjectX에서 v1.2 기능을 구현하는 것"과 같은 큰 티켓 (일주일 이상)을 만들기 시작했습니다. ProjectX (버전 1.2 포함)의 요구 사항/기능 목록은 위키에 보관되어있어 티켓이 매우 깨끗하고 수행 된 작업 만 추적합니다.이것은 우리에게 많은 도움이 되었습니다. 방법 추적해야 할 티켓이 줄어들고 다른 팀을 돕거나 화재를 진압하기 위해 스프린트 작업을 계속 중단하더라도 모든 스프린트를 완료할 수 있었습니다.
(사람에 의해) 새 항목을 가져오도록 강요받는 경우에만 우리는 계속해서 스프린트에서 항목을 밀어냅니다.
우리에게 도움이 된 또 다른 간단한 팁:번다운에 "총 스프린트 시간"을 추가하세요.이는 모든 추정치의 합이어야 합니다.이 선을 평평하게 유지하는 것은 도움이 될 수 있으며 팀이 직면할 수 있는 문제에 대한 가시성을 높일 수 있습니다(강등되지 않는다고 가정할 때...).
-ab
내 번다운에도 비슷한 문제가 있었습니다.번다운에 포함된 내용을 개선하여 이를 "수정"했습니다.
SiKeep은 다음과 같이 댓글을 달았습니다.
그 스프린트를 위해 선택된 백 로그에 대한 진보는 릴리스로 끝나지 않을 수도 있습니다.
스프린트를 위해 특정 항목을 선택했고 그것이 번다운에 포함되어 있으므로 모든 "새 작업"이 번다운에 나타나야 하는지는 알 수 없습니다.현재 스프린트로 이동할 만큼 중요하지 않은 한(번다운에 영향을 주지 않음) 백로그로 이동하는 것을 볼 수 있습니다(번다운에서 상승 추세로 표시됨).
즉, 사소한 상승과 하락은 정상입니다, 추세선이 기본적으로 예상 속도를 따르는 경우.나는 당신이 언급한 롤러코스터 추세에 대해 우려하고 있습니다.그러나 현재 스프린트에 우선순위가 높은 항목만 추가하여 번다운을 격리한다는 아이디어는 이러한 번다운의 증가 및 감소를 완화하는 데 도움이 될 수 있습니다.
다른 사람들이 말했듯이, 스프린트 시작 전 계획은 짧아야 합니다...(4시간 이내).
우리는 계획되지 않은 작업에 대해 '시간 제한' 작업을 사용하고 있습니다.우선순위가 높은 작업이 다가오거나 갑작스러운 버그가 발생할 때마다 타임박스의 시간을 사용할 수 있습니다(그러나 절대 0 아래로 내려갈 수는 없습니다).이 방법에는 예상치 못한 작업이 무엇인지 쉽게 추적하고 다음 스프린트 계획 중에 이러한 사항을 고려할 수 있다는 추가적인 이점이 있습니다.
스프린트 시작일에 새 작업을 통합하여 멋진 번다운 차트를 만들 수 있습니다.
추가 작업에 특정 마커를 사용하여 태그를 지정하고 스프린트가 끝날 때 이전에 해당 작업을 식별할 수 없었던 이유를 평가할 수 있습니다.
이제 Burn UP 차트를 사용하고 있습니다.단지 남은 작업량을 차트로 표시하는 대신 다음 두 가지를 차트로 표시합니다.완료된 작업량과 총 작업량(예:완료 + 미결제).
그러면 모든 작업이 완료되었을 때 만나야 하는 두 개의 선이 그래프에 표시됩니다.또한, 추가된 작업으로 인해 진행이 느린 경우를 명확하게 보여준다는 점에서도 큰 장점이 있습니다.
원하는 경우 PO는 한 라인(전체 작업)을 '소유'하고 개발자/테스터는 다른 라인(작업 완료)을 '소유'합니다.
PO의 라인은 작업을 추가/제거함에 따라 위아래로 이동합니다.
개발/테스터 라인은 작업이 완료될 때만 올라갑니다.
이것은 그래야만합니다.번다운 차트가 모델 차트와 유사하다면 문제가 있는 것입니다.차트는 당신이 헌신하고 모든 이야기를 끝낼 수 있는지 확인하는 데 도움이 될 것입니다.
스프린트 중에 스토리를 발견하는 것은 항상 발생합니다.이상적으로는 작업을 미리 설계하고 알아낼 수 있지만 제대로 작동했다면 대규모 선행 설계가 왜 작동하지 않겠습니까?마지막 질문에 답하려면 스프린트 계획에 다음이 필요합니다. 최대 4시간.
