스크럼 팀에서 시간이 지남에 따라 멈추거나 피하는 방법?

실제로, 나는 그들의 Scrum 구현에 작은 소프트웨어 상점을 돕고 있습니다. 최근에 스크럼 마스터는 팀이 스코프 (커밋 된 백 로그)를 달성하기 위해 시간 이 지남에 따라 문제를 겪고 있다고보고했습니다 . 그들에게는 Unreal Velocity가 있습니다.

내 공식적인 질문은 다음과 같습니다.

1. 회고 회의에 대해 이야기하는 것 외에도; 시간이 지남에 따라 피하기 위해 하드 블록을 구현하는 것이 좋은 생각이라고 생각하십니까?

2. 그렇다면 어떤 기술 / 도구를 제안 하시겠습니까?

   • 개정 제어 시스템 (SVN, GIT, HG 등), 시간 단위 (8-5)
   • 워크 스테이션이 시간 (8-5) 또는 누적 시간 (최대 8 시간 / 일)으로 차단됩니까?
   • 기타 ...

3. 아니면 이런 종류의 것을 막지 마십시오. 그러나 정당하지 않은 추가 시간에 대한 "벌금 시스템" 을 구현 하는가?

@Baqueta (및 유사한 질문이있는 다른 사람) : 추가 시간에 대해서는 지불되지 않습니다. 그들에게 나의 첫번째 조언은 그들의 견적을 검토하는 것이었다 어쩌면 그들이 과소 평가했다. 이것은 내가 가장 좋아하는 조언이었습니다.

초과 근무에 관심이 있다면 제거하십시오. 개발은 일주일에 60 시간 동안 할 수있는 일이 아니며 생산성을 유지하는 데 도움이되는 많은 연구가 있습니다. 초과 근무 수당이 문제인 경우이를 없애고 기본 급여를 개선하여 그들이 원하는 것을 얻도록하십시오.

또한 (이 팀의) 근본적인 문제는 다음의 조합이라고 생각합니다.

1. 개발자는 스프린트에서 무엇을 달성해야하는지, 너무 많은 일이 있다고 할 때 달성 할 수있는 것 / 무시되는 것에 대해상의하지 않은 것에 대해 이야기하고 있습니다.
2. 개발자는 작업이 얼마나 많은 시간이 소요되는지 / 각 작업에 몇 개의 작업 단위가 관련되는지 지속적으로 과소 평가하고 있습니다.

요약 : 팀에 문의하여 견적을 검토하고 PO 에 대해 언급했듯이 범위에 대해 상담을 받고 있지 않다고 생각하므로 PO와 이야기하겠습니다 .

솔직히, 2 번에서 언급 한 "하드 블록"은 내가 오랫동안 들어 본 최악의 아이디어입니다. 오후 4시 45 분에 최우선 버그가 발견되고 블록을 무시할 수있는 사람이 아프면 어떻게됩니까? # 3에 관해서는- 사람들이 자신의 일을하도록 처벌 하는 것을 제안 하고 있습니다.

팀이 스프린트를 완료하기 위해 지속적으로 초과 근무를하고있는 경우, 초과 근무 수당 (예 : 초과 근무 수당 또는 휴일로 초과 근무 수당)에 관심이 있거나 스프린트에서 너무 많은 작업을 수행하려고합니다.

초과 근무에 관심이 있다면 제거하십시오 . 개발은 일주일에 60 시간 동안 할 수있는 일이 아니며 생산성을 유지하는 데 도움이되는 많은 연구가 있습니다. 초과 근무 수당이 문제인 경우이를 없애고 기본 급여를 개선하여 그들이 원하는 것을 얻도록하십시오.

스프린트로 진행되는 작업이 너무 많으면 일반적으로 다음 세 가지 이유 중 하나입니다.

1. 개발자는 스프린트에서 무엇을 달성해야하는지, 너무 많은 일이 있다고 할 때 달성 할 수있는 것 / 무시되는 것에 대해상의하지 않은 것에 대해 이야기하고 있습니다.
2. 개발자는 작업이 얼마나 많은 시간이 소요되는지 / 각 작업에 몇 개의 작업 단위가 관련되는지 지속적으로 과소 평가하고 있습니다.
3. 개발자는 스크럼의 일부가 아닌 작업을 계속 수행합니다.

# 1이면 잘못하고있는 것 입니다. 그것에 대해 두 가지 방법이 없습니다!

# 2 인 경우 일반적인 원인은 시간 추정 또는 시스템 개발 중 경험이 부족한 것입니다. 이에 대한 좋은 방법은 시간 추정을 중단하고 '작업 단위'를 추정하는 것입니다. 추상 단위를 사용하십시오. 실시간 시간이 아닌지 확인하십시오 (결국 여전히 시간 간격을 나타내고 있지만 추상화가 중요합니다!). 그런 다음 일주일에 실제로 수행되는 작업 단위 수를 계산 한 다음 해당 데이터를 사용하여 스프린트를 설정할 수 있습니다.

그것이 # 3이라면 어떻게 든 다른 작업에서 팩토링을 시작해야합니다. 일관성이 있으면 쉽게 설명 할 수 있습니다 (위의 2 번 참조). 빈번하지만 예측할 수없는 경우 다루기가 훨씬 까다 롭습니다. 왜 이런 일이 발생하는지 살펴보고 싶을 것입니다 (예 : 'live'code =>의 심각한 버그가 충분히 테스트 되었습니까?).이를 해결할 수 없다면 궁극적으로 scrum이 올바른 접근법이 아닐 수 있습니다. 우리 팀은 최근 이런 이유로 간반으로 전환했습니다.

편집 : 질문에 제시된 아이디어에 대한 나의 비판을 명확히했습니다.

우선, 그들이 스프린트를 끝내기 위해 초과 근무를 해야하는 경우 스프린트에서 너무 많은 일을 한 것처럼 들립니다. 모든 시간이 기록됩니까? 그렇다면 이야기의 실제 작업량을 계산하고 그 숫자를 사용하여 다음 스프린트 작업을 계산할 수 있습니다.

또한 팀이 너무 많은 일을함으로써 자신에게 해를 끼치고 있음을 이해하도록하는 것이 중요합니다. 민첩한 선언서조차도 지속 가능한 페이스에 대해 이야기합니다. "애자일 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 일정한 페이스를 무한정 유지할 수 있어야합니다." 초과 근무는 항상 지속 가능하지 않습니다.

대체로, 나는 힘과 처벌 대신에 의사 소통을 제안합니다. 나는 그것이 팀의 민주화로 이어질 것이라고 생각할 것입니다.

초과 근무하는 개발자는 실제 또는인지 된 인센티브에 반응 할 가능성이 높습니다. 인센티브가 실제 인 경우 인센티브를 제거하거나인지 된 인센티브가 작동하지 않음을 알리는 것입니다.

제안 된 각 하드 한계에는 해결 방법이나 다른 문제가 있습니다. 소스 제어 블록은 개발자가 창이 다시 열릴 때까지 커밋을 보류하게 만듭니다. 지원 문제가 발생하거나 개발자 중 한 명이 어떤 이유로 시간을 변경해야하는 즉시 워크 스테이션 블록을 사용해야합니다. 페널티 시스템은 초과 근무 시간을 숨기거나 묻어 버립니다.

문제가 더 근본적이라고 생각합니다. 팀은 초과 근무에 대한 인센티브가 있습니다 (또는 인센티브가 있다고 생각합니다).

이 문제를 해결해야합니다. 그들의 성과 평가는 그들의 속도 수치에 묶여 있습니까? 관리는 초과 근무합니까? 장시간 근무하는 사람들에게 프로모션과 상이 제공됩니까? 초과 근무 수당을받는 계약자입니까?

단순히 팀에게 초과 근무를하지 말라고 지시하십시오. 기간.

이로 인해 일부 작업을 완료하지 못할 수 있습니다. 그것은 문제가 아니라 데이터 포인트입니다. 그런 다음 해당 스프린트를 사용하여 다음 스프린트를 계획 할 수 있습니다. 다시 말하지만, 그들은 초과 근무를하지 마십시오. 완료 여부에 관계없이 다른 데이터 포인트가 있습니다. 오히려 헹구고 반복하십시오.

트릭이나 한계는 필요하지 않습니다. 초과 근무를하지 마십시오. 얼마나 많은 작업을 수행 할 수 있는지 알아보고 스프린트 계획을 적절히 조정하십시오.

어쩌면 그들이 "많이"작동하지 않고 문제가있을 수 있습니다. 이것은 예정된 근무일이있을 때 문제가 될 수 있지만 대부분의 정상적인 시간은 회의 및 기타 사회적 및 개인적 방해 요소로 구성됩니다. 그들은 단지 생산성을 느끼기 때문에 초과 근무 기간 동안 일하고 있습니까?

스프린트에서 작업량을 줄이고 플렉스 시간 작업을 시작하십시오. 그들이 나중에 올 수 있도록하십시오. 담당자는 사람들에게 집에 가라고 말하면됩니다. 괜찮아 일찍 떠나면 눈살을 찌푸 릴 수있는 환경을 조성하는 기업 문화가 있습니다.

처음 스크럼으로 전환했을 때이 문제로 어려움을 겪었습니다. 마감일 근처에 추가 노력을 기울이는 것은 당연하지만 스크럼에는 2 주마다 마감일이 있으므로 조정됩니다. 반복 할 때마다 커밋 된 스토리 포인트를 줄이기 위해 다른 사람들이 제안한 제안 외에도 스토리를 충분히 분류하여 각 개발자가 최소 2 ~ 3 회 반복 할 수 있도록 제안합니다.

이는 각 개발자가 각 반복마다 무언가를 달성 한 것처럼 느끼게 할뿐만 아니라 범위 내에서 약간의 여유를 제공합니다. 번 다운 쇼에서 스토리를 완료 할 수 없다고 표시되면 스토리를 꺼내서 완료 할 수있는 스토리에 사람들을 재 할당 할 수 있습니다. 사람들이 범위를 조정할 수 있다는 것을 알면 비현실적인 마감일에 대해 스트레스를 덜 줄 것입니다. 진행중인 모든 스토리에서 반복을 시작하면 조정할 여지가 없습니다.

모든 사람이 반복 당 2 개의 스토리를 완료하는 경우 이상적인 누적 순서도는 다음과 같아야합니다.

실제로 모든 사람이 바쁘게 유지하면서 마지막 날에 모든 이야기를 끝내는 것은 매우 어렵 기 때문에 결코 그렇게 보이지는 않지만 좋은 경험입니다. 초과 커밋 된 경우 빨간색 영역이 더 커져 스토리를 제거 할 수 있습니다. 커밋이 부족하면 파란색 영역이 더 커져서 스토리를 추가 할 수 있습니다. 스토리가 너무 크면 녹색 영역이 더 커져 스토리를 분할해야합니다.

초과 근무를 피하려면 프로젝트 범위를 줄여야합니다.

다음 차트는 프로젝트에서 불확실성이있는 위치를 보여줍니다.

제품 정의 및 요구 사항 단계에서 노력을 추정하는 데 큰 차이가 있습니다. 기능을 구현하는 데 한 달 또는 하루가 걸릴지 확신 할 수 없습니다.

나는 단순히 너무 크고 지정되지 않았고 너무 많은 작업이 있기 때문에 어떤 작업도 수행 되지 않는다는 것을 내기하고 있습니다.

팀이 5 일 안에 10 매의 티켓을 처리 할 수 ​​있고 20 매의 티켓이 할당 된 경우 해당 번호를 줄이고 제품 소유자 / 프로젝트 관리자 / 관리자 / 클라이언트에게 전달하여 우선 순위를 정하도록 지시하십시오.

이 시점에서 초과 근무로부터 팀을 구할 수있는 유일한 방법입니다. 모든 것을 전달할 수는 없지만 전달하는 것은 버그가 적습니다.

또한 새로운 직업을 찾고 팀원들이 같은 일을하고 이력서와 전문 포트폴리오를 수정하도록 도와 줄 것을 권합니다. 초과 근무를 기대하는 회사는 누구도 일하지 않아야하며 생산 된 소프트웨어는 대체로 버그가 있습니다.

나는 "하드 블록"에 강력히 권고합니다. 이러한 통제는 미세 관리로 인식되어 근본적인 문제를 해결하지 못할 수 있습니다.

프로그래머가 왜 초과 근무를하는지 알아내는 것이 좋습니다. 대답은 당신을 놀라게 할 수 있습니다. 당신은 "외 주자"(사원이 아닌)처럼 들리며, 개인적으로 (일대일) 만나면 프로그래머가 기꺼이 솔직하게 말할 수 있습니다.

초과 근무를하는 이유는 진정으로 업무량입니까, 아니면 문화 나 기대와 더 관련이 있습니까?

작업 부하 이유는

• 커밋 된 백 로그가 너무 큽니다.
• 프로그래머 또는 제품 소유자가 "골드 도금"(필요한 것보다 기능을 더 복잡하게 함)

기대는

• 초과 근무에 대한 일종의 재정적 또는 인정 보상
• 실패의 두려움. 프로그래머는 마감 시간을 지키지 않으면 자신이 나빠 보이거나 처벌받을 것을 두려워합니다.
• 프로그래머는 초과 근무의 장기적인 영향을 과소 평가하고 있습니다.