반복 종료시 다운 타임을 어떻게 줄일 수 있습니까?

내가 일하는 곳에서는 3 주 반복으로 스크럼 중심의 민첩성을 연습합니다. 그렇습니다. 반복이 짧으면 좋을 것입니다. 그러나 변경하는 것은 현재 선택 사항이 아닙니다.

반복이 끝나면 일반적으로 마지막 날이 매우 느리게 진행된다는 것을 알았습니다. 실제 작업은 이미 완료되어 승인되었습니다. 몇 회의 (회고 및 다음 반복 계획)가 있지만 그 외에는 많이 진행되지 않습니다.

우리 팀이 마지막 날까지 추진력을 유지하기 위해 어떤 종류의 기술을 사용할 수 있습니까? 결함을 해결해야합니까? 어쨌든 다음 반복 작업을 조기에 시작 하시겠습니까? 다른 것?

나는 최근에 같은 질문으로 어려움을 겪고있다. 우리는 다음 반복부터 시작하지만 이것이 반복의 만족을 제거한다고 생각합니다.

나는 "회사에 이익을주기위한 의도"라면 개발자에게 맡길 수있는 옵션에 대해 생각하고있다.

예 :

• 무언가를 배우는 하루를 보내십시오
• 혁신 시간 프로젝트에 사용
• 리팩토링을하지 않는 성가신 코드를 정리 해보자
• UX를 ​​볼 수있는 앱을 잘 살펴보십시오 (다른 방법으로는 시간을 찾지 못하는 것 같습니다)

프로그래머에게 동기를 부여하는 것이 무엇이든 적시에 릴리스를 제공하도록 인센티브를 제공합니다.

하루를 쉬십시오. 당신은해야 할 일을했는데 왜 아직도 일하고 ​​있습니까?

프로세스 변경이 가능하면 반복 제거, 지속적 릴리스 및 백 로그에서 스토리 제거를 고려하십시오. 그러나 약간의 가동 중지 시간이 필요하지 않습니까?

나는 같은 문제를 발견했습니다 (때로는 2 주 스프린트를 사용하여 더 악화시킵니다). 그 날 (스프린트 검토 일 및 스프린트 계획 일) 동안 내가하려고하는 것은 내가하고 싶지만 우선 순위가 낮은 버그, 광택, 또는 도구 개선. 때로는 중요하지만 섹시하지 않은 작업을 수행하기에 좋은 시간을 만들어서 그렇지 않으면 시간을 내기가 어려워지기 때문에 실제로 이것은 긍정적으로됩니다.

반복이 끝날 때까지 사용자 스토리가 거의 항상 완료 되더라도 끝에는 버그 목록과 함께 "좋아하는 사람"목록이 항상 많이 있습니다. 따라서 사람들이 이야기를 마치면 할 일이 항상 많습니다.

회고 회의를하는 것이 왕이라고 생각합니다. 주로 동일한 문제가 발생하더라도 반복이 어떻게 진행되었는지, 어떻게 배우는지, 실수를 깨닫지 못하면 약간의 시간을 투자하는 것이 매우 중요합니다 잘 된 것들.

모든 버그가 해결되고 수행해야 할 긴 작업 목록과 작업 지점이 함께 수행 된 경우, 팀을 큰 화면 앞에서 함께 모아서 맥주와 함께 만들어졌습니다. 생산성이 높지는 않지만 구현 된 내용과 실제로 작동하는 방식에 대해 이야기하는 것이 좋습니다.

당신이 며칠이 있다면, 나는 배울 새로운 것을 찾고 그것을 가지고 놀려고 노력할 것입니다. 아마 다음 큰 일 일 것입니다. 그러나 다시 며칠이 있으면 백 로그에 할 사용자 스토리가있을 것입니다.

금요일에 마지막 순간 문제를 해결할 수 있도록 목요일에 반복이 완료됩니다. 그러나 그 금요일 (2 주에 한 번)은 비어 금요일과 일치하므로 매우 침착하게 노력합니다. 몇 가지 사소한 버그를 수정하고 책 (스택, StackExchange, 블로그 등)을 읽는 데 시간을 보내며 마지막 날에는 맥주와 함께 휴식을 취하십시오. 그렇지 않으면, 당신은 완성 또는 폐쇄의 느낌에 도달하지 않고 대신 바퀴에서 멈추지 않는 햄스터 같은 느낌.

항상 제 시간에 정확하게 끝내고 싶을 지는 모르겠습니다 . 작업을 조금 일찍 완료하면 미래의 이야기, 기능 및 기능에 대해 생각할 수 있습니다. 일을 잘 마친 후에는 일찍 시작하거나 더 많은 이야기를하고 항상 일을 계속하는 것보다 더 많은 보상을 줄 수 있습니다.

Ken Schwaber는 자신의 블로그 http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/ 에서 다음과 같이 말합니다.

"하나님은 우리를 도와주십시오. 사람들은 폭포에서 느슨하게 휴식을 취하고 창의력을 발휘할 수있는 방법을 찾았습니다. 린 (Lean)과 칸반 (Kanban)으로 숨어있는 곳은 제거되었습니다.

내 프로젝트에서 반복 계획 중에는 항상 추가 작업을 선택하고 반복의 모든 작업이 완료된 경우 작업 할 "보너스 작업"이라고 레이블을 지정합니다. 실용적으로, 이러한 "보너스 작업"은 일반적으로 어쨌든 다음 반복에서 가장 먼저 수행되는 것이지만, "보너스 작업"이라고하는 용어 학적으로는 훨씬 더 잘 작동합니다.

학습이나 혁신 시간과 같은 다른 것들을 위해, 우리는 각 개발자가 정상적인 일로 그 일에 일주일에 하루를 보내 게합니다. 요일이 될 수 있습니다 (예 : 매주 끝날 필요는 없습니다).

우리 팀의 모든 개발자는 스프린트가 끝날 때까지 자유 시간을 모든 스프린트 작업이 완료된 경우 'Google 시간'으로 사용합니다.

회사에 이익이되는 한 각 개발자는 자신의 아이디어 / 프로젝트를 수행합니다. 이와 같은 시스템을 사용하는 것이 좋습니다. 팀 내 업무 만족도가 실제로 높아졌습니다.

3 일 일찍 꾸준히 마무리한다면 스프린트를위한 충분한 이야기를 계획하고 있지 않다고 제안합니다.

스크럼의 목표 중 하나는 생산성을 높이는 것입니다. 각 스프린트를 촬영할 때는이 작업을 수행하지 않습니다.

이 문제를 해결하려면 이전보다 많은 이야기를 계획하십시오. 이전 속도에만 맡기십시오. 그러나 그 이야기를 마치면 추가 이야기를 시작하십시오. 더 많은 것을 완료하면 다음 스프린트의 속도를 올립니다. 만일을 대비하여, 당신이 약속 한 것보다 조금 더 계획을 세우거나 적어도 몇 개의 이야기를 줄을 서십시오.

이것이 우리가 Kanban으로 전환 한 이유 중 하나입니다. 프로젝트를 중단하지 않고 스크럼의 모든 이점.

나는 하루를 쉬는 Todd의 대답을 좋아하지만, 아침에 스프린트 계획과 회고를 시도하고 점심 시간에 끝내는 데 어려움을 겪고 팀으로 긴 점심을 먹습니다. 점심 시간에는 스프린트에 대한 토론을 장려하여 비공식적 인 회고를 무료로 받으십시오.

그런 다음 aftenoon을 줄 수 없다면 (그리고 오후에 집에 가서 목표를 세우지 않는 것을 의미합니다) 기술 부채는 다른 무엇보다 개발자를 우울하게 만드는 것이므로 : 내 의견) 기술 부채를 해결하고 삶을 더 쉽게 만드는 방법을 알면 기술 부채를 해결해야합니다.

개인적으로 회고는 실제로 시간을 투자 할 가치가 없으며 일반적으로 반복되는 몇 가지 일반적인 주제 (불량한 사용자 사례, 나쁜 평가 등)가 있으며 문제 영역으로 받아 들여서 계속 진행합니다. 또한 회고 (스크럼을 채택하는 초기 단계에서하는 경향이 있음)를 기다리지 않고 문제가 발생할 때 / 문제를 처리하려고합니다.

이제 회고하는 대신 각 개발자 쌍은 기존 회고 백 로그에서 미결 항목을 선택하여 작업합니다.

또한 스프린트에 대한 보너스 항목으로 작용하는 기술 부채 백 로그도 계속 유지합니다 (비즈니스가 사전에 백 로그에서 무언가를 구현할 준비가되지 않은 경우).

이것은 항상 스프린트마다 하루의 주목을받을 수있는 모든 작은 작은 아이템이 있다는 점에서 이미 긍정적으로 입증되었습니다.

다가오는 스프린트에 관한 흥미로운 이야기를위한 화이트 보드 디자인 세션을 갖고 구현 아이디어를 공유하십시오. 스토리를 세부적으로 밝히고 스토리 포인트 또는 티셔츠 크기 추정치로 판단되는 계획 세션과 별도로이 작업을 수행하십시오. 세션을 비공식적으로 유지하고 창의성을 장려하십시오.