스크럼 환경에서 속도가 크게 증가합니까?

저의 관리자는 최근 속도를 목표 및 생산성 측정으로 사용하도록 추진하고 있습니다. 우리는 현재 평균 50 스토리 포인트 속도로 작업하고 있습니다. 관리자는 팀원을 늘리지 않고 스토리 포인트를 40 %에서 70 스토리 포인트로 늘리기를 원합니다. 우리가 이러한 증가를 달성하지 못하면 그는 우리가 이유를 설명하는 전체 분석을 제공하기를 원합니다.

속도로 팀 성과를 측정하고 그것을 목표로 사용하는 아이디어는 나에게 잘못된 것 같지만 그 이유를 설명하기가 어렵습니다. 어떤 도움? 이것이 왜 생산성을 측정하고 장려하는 올바른 방법이 아닌가?

글쎄, 속도를 40 % 증가시키는 것은 매우 간단합니다. 모든 추정치에 40 % 더 많은 포인트를 추가하고 동일한 양의 작업을 수행하십시오.

이것이 사실이기 때문에, 목표로 속도를 사용하는 것이 왜 틀린지 분명히 알 수 있습니다.

덜 복잡한 답변은 모든 것을 올바르게 수행하는 동안 추정치가 이미 가능한 한 빨리 가고 있다고 가정한다는 것입니다. 실제로 생산성을 40 % 증가시키는 유일한 방법은 초과 근무 나 모든 것이 올바르게되지 않는 것입니다. 이 두 가지 모두 단기적으로는 속도를 높이지만 장기적으로는 속도를 늦 춥니 다. 이 경우 장기는 그리 오래 걸리지 않습니다. 최적의 장기 전략은 지속 가능한 속도보다 빠르게 진행되지 않는 것입니다.

Peopleware는 프로그래머가 생산성을 높이도록하는 문제에 대해 설득력있게 이야기하며 종종 인용되는 고전입니다. 그러나 일반적으로 자신의 길을 가고있는 관리자의 마음을 바꾸는 것은 쉽지 않습니다. 프로젝트에 문제가있을 수 있습니다. 이것은 확실히 붉은 깃발입니다.

의견이 지적했듯이 요청은 분명히 제기 된 방식이 잘못되었습니다. 그러나 그는 지속적으로 생산성을 향상시키고 자하는 것이 잘못이 아닙니다. 원칙적으로 관리자가 노력하고 평가하는 것입니다.

즉, 관리자는 항상 성능을 향상 시키려고 노력하고 있으며 스크럼 및 애자일은 모두 적응할 수 있어야합니다. 속도는 현재 지속 가능한 페이스의 척도이지만 월계수에 앉아서는 안됩니다. 스크럼은 프로세스에서 작동하고 작동하지 않는 것을 평가하고 변경할 수있는 공간이 있습니다. 이를 활용하여 프로세스를 조정하면 생산성 (및 속도)이 높아집니다.

그래서, 당신은 (후 향적 관점에서) 팀으로서 생산성을 높이는 방법을 찾고 있습니까? 스프린트에 정기적으로 많은 양의 노력을 소비하는 것이 있습니까? 해결할 수 있습니까? 아마 40 % 증가하지는 않지만 5-10 %는 시작입니다. 모든 스프린트는 병목 현상을 찾아서 해결해야합니다. 결국, 당신은 그가 당신을 위해 설정 한 목표에 가까워 질 수 있습니다.

TL; DR

속도는 일정을 예측하거나 계획 값을 생성하는 데 매우 유용하며 프로세스 병목 현상 또는 팀 용량의 변화 를 평가하기 위한 의미있는 탐정 제어 기능이 될 수도 있습니다 . 그러나 올바른 생산성 측정 방법은 아닙니다.

속도가 관리 대상과 혼동되는 경우

"Velocity"는 특정 기간 동안 팀의 평균 용량을 나타내는 범위입니다. 과거 성능에 대한 통계 분석으로 향후 워크로드 용량 또는주기 시간에 대한 확률 적 추정치를 예측하는 데 사용할 수 있습니다. 이는 계획 일정을 세우기위한 일정이나 목표를 설정하는 관리 목표 인 "스케줄링 대상"과 완전히 대조적입니다.

숙련 된 민첩한 프로젝트 관리자는 적절한 속도 사용이 팀이 관리 정의 일정 목표를 달성 할 수있는 지속 가능한 역량을 보유하고 있는지 판단하는 것임을 알고 있습니다. 때로는 대답이 그렇습니다. 모두가 행복합니다. 때로는 철분 삼각형 이 범위, ​​비용, 시간 및 품질에 대한 비즈니스 결정을 강요 하는 시점에서 대답이 '아니오' 입니다.

정치 옵션 평가

우리는 평균 속도가 50 스토리 포인트입니다 ... 팀원을 늘리지 않고 40 %에서 70 스토리 포인트까지 증가하라는 요청을 받았습니다.

귀하의 추정 관행이 적절하고 속도가 상당히 안정적이라고 가정하면 관리자는 과거 성과에 근거하지 않고 추정 규모를 조정하거나 관리 목표를 설정하는 데 기쁨을 얻지 못할 것입니다. 올바르게 지적했듯이 이것은 근본적으로 용량 문제입니다.

용량 제한은 팀원 수와 관련이 있거나 조직 프로세스의 제한 일 수 있습니다. 물론 더 많은 사람을 추가한다고해서 실제 프로젝트 용량도 항상 추가되는 것은 아닙니다. 이 일반적인 오해에 대한 자세한 내용은 Brooks 'Law 를 참조하십시오 .

당신이 직면 하는 문제 는 정치적입니다. 게시물의 분위기에서 관리자가 팀의 기본 용량을 실제로 변경하지 않고 생산성을 높이고 자하는 것처럼 들립니다. 솔루션은 그러므로 있습니다 또한 정치적, 자연에서 주로 교육.

Scrum 상점 인 경우 Scrum Master에 적절한 프레임 워크 채널을 통해이 문제를 해결하도록 요청하십시오. 백 로그 정리 및 스프린트 회고는 종종이 특정 문제에 대한 이상적인 검사 및 적응 기회입니다.

스크럼 상점이 아닌 경우 조직 내에서 우려를 해결하는 적절한 방법을 결정해야합니다. 관리자와 계약을 잘 맺었다 면 두 사람이 점심 식사에 대해 논의 할 수 있도록 애자일 견적 및 계획 사본을 빌려줄 수도 있습니다 .

다른 모든 방법이 실패하면 이력서를 닦고 프로젝트가 끝날 때까지 전문가의 최선을 다하여 죽음의 행진 을 준비 하십시오. IT 프로젝트의 68 %가 실패합니다 . 관리 목표가 조직의 역량에 확고히 근거하지 않는 한, 아마도 귀하의 목표가 그 중 하나 일 것입니다.

관리자가 Scrum 팀에서 어떤 역할을하는지 모르겠습니다. 그는 코치입니까? 그는 제품 소유자입니까?

그가 코치와 같은 팀 내부에있는 경우 (개발 작업에서 일하는 경우) 다른 팀 구성원에게는 해당되지 않았기 때문에 자신의 생산성을 과소 평가하는 이유를 물어볼 수 있습니다. 그가 반복 할 때마다 30 스토리 포인트를 더 개인적으로 가정 할 수 있다고 믿는 경우이를 보여주십시오.

더 가능성이 높습니다 : 그는 팀 외부에 있습니까, 아마도 제품 소유자입니까? 그렇다면 그는 그런 어리석은 요청을하는 것을 이해해야합니다.

기본 규칙은 제품 소유자가 목표를 설정하고 팀은 반복에서 수행 할 수있는 작업을 설정하는 것입니다. 그렇게하지 않으면 자원, 속도, 기능 등 고전적이고 잘 알려진 철권으로 연결됩니다. 둘 고르세요! 한 번에 세 개를 선택할 수는 없습니다 (그리고 품질은 조정 변수가 아니므로 품질을 낮춰 모서리를 자르면 상황이 더 나빠질 수 있습니다).

현재 목표를 바꾸고 싶지 않다면 팀원을 더 많이 모집하여 생산성을 40 % 향상시킬 수 있을까요? 팀원을위한 사전 교육에 투자 할 수 있습니까? 팀은 지속적인 개선을 통해 시간이 지남에 따라 속도를 낼 수 있지만, 임의의 결정에 의한 것은 아닙니다.

팀의 속도를 변경하는 것은 방의 크기를 변경하는 것과 같습니다. 할 수 있지만 기본적으로 방을 바꿔야합니다.

스크럼 마스터 나 스크럼에 대한 기본적인 이해를 가진 사람들이 그에게 설명해 줄 수 있습니까?

이 경우 관리자는 팀으로부터 정직하고 충실한 평가를받은 후 잘못된 방향으로 전환했습니다. 관리자는 이해 관계자에게 의뢰하여 요청 된 시간 내에 요구 사항을 완료 할 수 없음을 알려야합니다. 그런 다음 관리자 / 분석가는 반드시 포함해야 할 기능과 대기 할 수있는 기능 (몇 주 정도 인 경우)의 우선 순위를 정해야합니다. 이해 관계자가 불합리한 경우 상급 관리자가 참여해야 할 수 있으며, 이는 일반적으로 도전이 될 수 있으며 다른 모든 토론이 필요할 수 있습니다.

내가 신발에 있었다면 나는이 프로젝트는 이유에 대한 자세한 사례와 함께 올 것이다 IS 한 추정으로 걸릴 것. 또한 낮은 반품 품목을 식별하십시오. 많은 가치를 부여하지 않고 상당한 프로그래밍 노력이 필요한 항목을 찾아 스프린트에서 제거하십시오. 또한 "Y"날짜에 "X"를 제공하는 반복적 인 접근 방식을 제안하고 가능한지 확인한 후 후속 항목 반복을 수행하여 나머지 항목을 가져옵니다.

기본적으로 누군가 마감일까지받을 것으로 예상되는 내용과 이해 관계자의 요구 사항 대부분을 이해 관계자에게 알려야합니다. 다음 릴리스에서는 나머지 항목을 갖게됩니다. 고객이 불합리한 경우 상위 관리자가 참여해야하며, 관리자가이를 수행 할 수 있어야합니다.

그러나 고객이 약속을했는데 지금까지 아무도 말을하지 않았다면 그것은 오르막길이 될 것입니다. 불행히도 이것은 드문 상황이 아닙니다.

두 가지 문제에 직면 한 것 같습니다.

귀찮게하는 속도 측정에 관한 부분은 아마도 측정이 비용 일 것 입니다. 당신이 정말로 개선하고 싶은 것은 가치 입니다. 불행히도 소프트웨어의 가치를 측정하는 것은 매우 어렵고 주관적입니다. 여전히 불완전하고 주관적인 지표조차도 유용 할 수 있습니다. 실제 문제는 팀이 더 많은 코드를 작성해야하는 것이 아니라 이야기가 더 가치가 있어야한다는 것입니다.

다른 문제는 귀하의 계정에 따라 귀하의 관리자가 40 %의 생산성 향상을 기대한다는 것입니다. 귀하의 질문 에이 요청의 맥락이 언급되지 않았습니다. 팀이 개선하기를 원한다면 좋은 성격을 가질 수 있습니다. 또는 관리자가 팀의 성과가 저조하다고 생각하는 미묘한 표시가 아닐 수도 있습니다.

편집 : 귀하의 의견에 따라 상황이 나빠 보입니다. 귀사와 팀을 해고 할 수있는 토대를 마련하고있는 것 같습니다. 다른 직업을 찾아 보시기 바랍니다.

그를 해고하십시오. 다시 말해서, 그의 머리 위로 가서 그가 팀의 모든 신뢰를 잃었다 고 설명하고 그가 비즈니스에 가치가 없다고 설명하십시오. 이 무능 수준의 관리자는 아래 팀보다 훨씬 쉽게 교체 할 수 있다고 설명합니다.

그러한 관리자와 합당한 이유는 없지만 개발자가 사임해야한다는 것을 자동으로 의미하지는 않습니다. 이 개인에게만 비즈니스에 문제가있는 것은 아닙니다. 그 문제를 해결하십시오.

그리고 고위 경영진의 서두를 막으려면 이것이 용서할 수있는 실수가 아님을 분명히하십시오. 담당 관리자가 자신이 관리하는 팀을 이해 하지 못했음을 나타냅니다. 그것은 현재 노동 시장에서 고치거나 그럴 필요가 없다. 관리자는 스포츠 코치처럼 쉽게 교체 할 수 있습니다. 소유자는 팀을 해고하지 않습니다.

이제 이것은 역효과를 낼 수있는 전략처럼 보일 수 있습니다. 그러나 상사와 상관없이 상위 경영진이 이미 어쨌든 이미 잃어버린 상태라고 생각하십시오. 따라서 이미지는 위치에 있지 않은 상황 만 고려한다면 결과는 훨씬 더 긍정적일 것입니다. 실제 위험은 상위 관리자가 관리자를 포함한 전체 팀을 해고 할 수 있다는 것입니다. 오직 당신 만이 그 위험을 추정 할 수 있습니다. 분명히 당신의 결과물을 원한다면, 더 많은 것을 요구하지는 않지만 어느 가격에?

내 경험은 팀, 문제 영역 또는 기술 스택이 변경되지 않는 한 팀 의 실제 속도 를 높이는 것이 매우 힘들다는 것입니다.

내가 증가를 달성 할 수 있었던 곳의 문제는 다음과 같습니다.

• 기술적 부채 정리; 모든 것이 올바른 버전 일 필요는 없으며 코드가 제대로 구성되어 있으며 시스템에 중복성이 없는지 (중복 된 코드, 사용되지 않은 코드 등)

• 관행 개선; 가능한 경우 페어링 (예, 속도가 증가 함), 적극적으로 리팩토링하는 데 시간이 걸리고 (범위!), 범위와 초점에 대해 무자비합니다.

• 작업에 가장 적합한 도구 찾기 및 / 또는 구매 (예 : ReSharper for .NET은 금, Airbrake 및 Ruby 용 Splunk 등의 가치가 있습니다)

귀하의 관리자가 속도의 임의적 인 증가를 요구하는 것은 다른 사람들과 동의합니다. 우선 순위가 높은 다른 직업을 찾고있을 것입니다.

관리자가 팀에게 추가 근무 시간을 요구하고 있습니다. 병목 현상을 제거하고 효율성을 확보하면 속도가 다소 향상 될 수 있지만, 그 증가율 (40 %)을 얻는 유일한 방법은 더 긴 시간 동안 일하는 것입니다.

시나리오를 봅시다.

2 주간 동안 10 일 동안 대화 할 수 있습니다. 유토피아는 하루 8 시간이 될 것이며, 스토리 포인트는 작업 일로 요약됩니다. 처음부터 속도는 8이 될 것입니다. 그러나, 사람들은 아마도 전자 메일, 회의, 화장실 등으로 하루에 6 시간을 보내고있을 것입니다. 이제 개발자 당 6 명입니다. 따라서 기준은 6입니다. 이제 사람들이 하루 10 시간 씩 초과 근무를한다고 가정 해 봅시다. 따라서 개발자 당 10 개의 속도 포인트가됩니다.

반복하는 동안 많은 버그를 처리해야했기 때문에 속도가 항상 변동합니다. 요구 사항이 누락되었거나 누군가가 며칠 동안 아플 수 있습니다. 작업이 과대 평가되었거나 팀이 추가 시간을 투입하여 높을 수 있습니다.

그러나 안정된 50 세인 경우 실제로 70 세가 되려면 추가 시간이 필요합니다.

속도의 문제점은 속도가 개발 프로세스의 측정 결과 인 종속 변수라는 것입니다. 40 %의 속도 증가를 요구하는 것은 자동차를 더 빨리 향해 소리를 지르면서 더 빨리 일하려고하는 것과 같습니다. 엔진에 더 많은 연료와 공기를 공급하거나 더 빠른 자동차를 타고 속도를 높이고 교통량이 적은 경로를 찾으십시오.

개발자 시간당 기능 포인트와 같이 적절하게 측정하면 더 많은 시간을 작업해도 속도가 증가하지 않습니다. 하루에 포인트를 측정 한 다음 측정 중 "일"이 무엇인지 재정의하는 경우에만 작동합니다. 이것은 단지 속도의 환상만을 제공합니다.

속도를 높이려면 개발 과정에서 독립 변수를 개선해야합니다. 더 빠른 컴퓨터와 컴파일러,보다 효율적인 빌드 시스템, 더 나은 디자인 프로세스, 더 유능한 개발자, 더 나은 작업 공간, 최고 동기 부여. 40 % 개선에는 매우 중요한 변경이 필요합니다.

관리자가 공동 작업실 주변의 폐쇄 된 사무실에 팀을 배치하거나, ​​팀의 완전히 새로운 개발 하드웨어를 구매하거나, 팀을 멘토링하기 위해 정말로 수석 개발자 몇 명을 고용하여 40 %를 얻을 것인지 고려하십시오. 개발 프로세스에 대한 입력을 향상시키는 데 사용할 수있는 리소스가 없다면 개선에 대한 진지한 관심이 거의 없습니다. 이것은 매니저에게 리버스 엔지니어링을하여 실제로 동기 부여가 무엇인지 알아 내도록합니다.

글쎄, 다른 답변이 보스의 요청을 심각하게 받아들이는 것이 조금 놀랐습니다. 40 %의 생산성 향상을 요구하는 사람은 소프트웨어 개발에 대한 첫 번째 사실을 모릅니다.

나는 여전히이 주제에 대한 Phil Factor 를 읽는 것을 즐깁니다 .

IT 관리에는 두 가지 기본 경로가 있습니다. 어려운 기술 노하우와 성공적인 프로젝트를 통해 얻은 신뢰성을 바탕으로 피, 땀 및 눈물을 통해 거래를 배우고 점차적으로 사다리를 올라갈 수 있습니다. 또는 예리한 옷을 입고 넥타이를 타거나 링고를 배우고 정상까지 부드럽게 이야기 할 수 있습니다.

두 경로 모두 똑같이 효과적입니다. 후자의 품종을 다루는 것은 분명히 약간의 실망과 놀라움의 순간을 초래할 수 있습니다 ... 심지어 절망 ... 그리고 그 중 일부는이 이야기들에 기록되어 있습니다.

그러나 권력의 위치에서 기술적 인 무능함을 만날 때 슬프고 당황하기 쉽고 모든 브러시를 같은 브러시로 타르는 것은 쉽습니다. Phil은 그것에 대해 조언합니다. 대부분의 관리자는 열심히 일하고 회사에 잘 기여하며, 몇 가지 간단한 지침을 따르면 빈약 한 관리자조차도 필요한 표준까지 교육받을 수 있습니다. 관리자에게 모든 혜택을 줄 수있는 방식으로 관리자를 돕는 것은 팀 책임의 일부입니다.

궁극적으로, 당신이 그들을 훈련시킬 수 없거나, 승진 시키거나 피할 수 없다면, 직장의 풍부한 코미디에 의도하지 않은 공헌으로 그들을 사랑하는 법을 배울 수 있습니다.

"슬프고 집착"하지 말라고 충고하는 것이 최선입니다. 기술적 인 문제에 대해 기술적으로 무능한 상사와 싸우지 마십시오. 그는 단지 그것을 개인의 공격으로 볼 것입니다.

관리자가 속도 사용을 오해했습니다. 메트릭이 아니며 대상이 아닙니다. 스프린트 당 팀 작업량을 교정하는 것이 목적입니다.
당신이 그것에 대해 생각하면, 당신의 속도는 최선의 추측에서 나온다, 당신은 각 스프린트 후 재 측정. 보통 시간이 지남에 따라 다소 안정되어야합니다. 그러나 이것이 팀이 실제로하고있는 것의 부산물이라는 사실을 바꾸지는 않습니다 : 고객을위한 가치 창출.

대상 및 / 또는 측정 항목으로 사용하는 것이 잘못된 이유는 이것이 고유 측정 항목이되기 때문입니다. 그것은 종이에는 좋을 것이지만, 제품이 고객의 요구를 가득 채우지 않았는지 전혀 반영하지 않을 것입니다. 그리고 그것이 가장 중요한 것입니다.

내 경험과 관련하여 요점으로 직진합니다.

첫째, 추정치를 부 풀릴 수 있지만 더 많은 일을하고있는 것은 아닙니다.

두 번째 (전제 : 팽창하지 않고 팀 속도에만 집중),

팀 내에서 기술을 찾아보십시오. 그들은 최선을 다하고 있습니까? 응용 프로그램 구성 및 복잡한 작업에 관한 어려운 결정을 내리려면 시스템 설계자가 필요합니까? 팀은 어떻게 노력하고 있습니까? 그들은 문제에 대한 해결책을 연구하고, 리팩토링을하거나, 비즈니스 결정을 내리거나 또는 무엇을하는 데 시간을 보내고 있습니까?

그들은 편안하고 집중적이며 자극적입니까? 그들에게 다음은 무엇입니까?

이것은 "한계를 강요당하는"것이 아니라 전체 팀을위한 질문과 같다. "우리는 한계에 있습니까?" "어떻게 한계를 뛰어 넘을 수 있을까?"

나는 고성능 팀 (첫 건설 및 / 또는 이주를 위해)을 이끌었습니다. 팀의 동기는 성공의 열쇠입니다 ... 그리고 응용 프로그램의 기반이 어떻게 될 것인지 계획하는 것이 중요합니다. 때때로 나 또는 팀원은 시스템 아키텍트의 역할을 수행하여 어떻게 "어떻게"갈 것인지 결정합니다.

때때로 팀원들이 효율성을 잃고 있음을 알게되면 나는 그들이 맥주를 마시거나 좋아하는 음료를 마시도록 초대하려고합니다. 이것은 모든 갈등을 해결하고 다음날 다시 집중합니다.

판매...

속도를 높일 수없는 이유를 설명하기 어려운 경우 ROI를 사용하십시오.

스크럼은 고객에게 가장 중요한 것에 중점을 둡니다. 이론적으로 가장 수익성 높은 작업.

문제가 개발 노력을 판매하는 것과 관련이 있다면, 개발 노력의 ROI를 판매하는 대신 스토리 포인트를 "가격"으로 직접 변환한다고 생각하십시오. 팀이 ROI가 높음을 증명할 수 있다면 누가 의문을 제기할까요? 또한 팀이 "편안함 크기"를 찾은 경우 모든 팀에 한계가 있습니다. 모든 작업을 완료 할 수없는 경우 한 달에 한해 약간 씩 증가시켜보십시오 (아마도) 한계입니다.

작업 내역, 이윤 수익 (사용 가능한 경우), 사용한 스토리 포인트를 보여주고 생산성이 팀 효과가 아님을 보여줌 끝난