팀은 지속적으로 스프린트 목표를 달성하지 못합니다

우리는 하나의 제품을 가진 작은 소프트웨어 회사입니다.

우리는 scrum을 사용 하며 개발자는 각 스프린트에 포함 할 기능을 선택합니다. 불행히도 지난 18 개월 동안 팀은 단거리 달리기 위해 헌신 한 기능을 한 번 제공하지 않았습니다.

"소프트웨어는 소프트웨어가 완료되면 더 빨리, 더 이상 늦지 않을 때 완료됩니다. 팀에 압력을 가하고 더 많은 사람들을 참여시키는 데 도움이되지 않습니다. ... "스프린트 성공률을 개선 할 수있는 방법에 대한 질문에 개발자 중 한 사람으로부터 비슷한 피드백을 받았습니다. 아, 그리고 우리는 회고를 사용 합니다.

내 질문은 기본적으로 :

개발자의 품질에서 문제를 찾는 것이 언제 공평합니까?

나는 당신이 당신의 자신의 일 / 기능을 선택하고 여전히 각 스프린트에 실패한다면 :-당신은 자신의 코드의 복잡성을 감독 할 수 없다고 생각하기 시작했습니다. 또는 코드가 너무 복잡하여 아무도 복잡성을 감독 할 수 없습니다.

뭔가 빠졌습니까?

먼저 '누가 신경 쓰는지'물어봐야합니까?

스프린트를 완료하면 기분이 좋으며 일부 회사에서는 스크럼 상위에서 쿠키를 생성합니다. 그러나 궁극적 인 테스트는 회사가 목표를 달성하고 있는지 여부입니다.

위의 내용은 대단합니다. 스프린트의 계획된 내용을 완료하지 않고 회사가 성공하면 대신 Kanban을 사용할 수도 있습니다. 백 로그를 정렬하고 가장 중요한 작업을 수행하며 정의 된 반복에 대해 크게 걱정하지 않아도됩니다.

정의 된 반복의 가치 중 하나는 프로세스 개선을 추진하는 것입니다. 당신은 지금 그것을 얻지 못하고 있습니다. 따라서 프로세스를 개선하고 결국 스프린트를 완료하는 나머지 프로세스를 채택하거나 원하는 것을 좋아할 수 있습니다.

뭔가 빠졌습니까?

예!

당신은 18 개월 갔다 -또는 회고와 36 스프린트의 근처 어딘가에 어쨌든 그것을 고칠 수 없습니까? 관리 팀 책임을 보유하지 않은 다음 그 관리는 보유하지 않은 그들 팀의 책임을 유지하지에 대한 책임?

당신은 당신의 회사가 광범위하게 무능하다는 것을 놓치고 있습니다 .

그래서 그것을 고치는 방법. 당신 (개발자)은 많은 일에 헌신하지 않습니다. 스토리가 너무 커서 그렇게 할 수 없으면 스토리를 더 작은 덩어리로 나누어야합니다. 그리고 나서 사람들은 그들이 할 것이라고 말한 것에 대해 책임을 져야합니다. 그것이 각 스프린트마다 수행되는 작은 기능 만 얻을 수있는 것으로 밝혀지면 이유를 알아 내고 더 나아지게하십시오 (개발자를 교체해야 할 수도 있음). 그들이 합리적인 양의 일에 헌신하는 방법을 알아낼 수 없다면, 당신은 그들을 해고합니다 .

그러나 그 전에, 나는 일이 그렇게 오래 갈 수 있도록 관리에보고, 그들이 무엇을하지 않는 이유를 알아내는 것이 자신의 일을.

Scrum 대신 몇 주 동안 약간의 변경을하고 Kanban 을 시도해 보시기 바랍니다 . 팀에 더 효과적 일 수 있습니다.

Scrum은 스프린트에서 사용할 수있는 작업 시간을 제한하여 생산성을 높이는 반면 Kanban은 활성화 된 동시 문제 수를 제한하여 생산성과 속도를 높입니다. 시간 추정은 더 이상 프로세스의 일부가 아닙니다. ( 소스 )

간단히 말해서, 칸반은 무엇입니까?

Kanban은 효율성을 위해 작업을 구성하는 데 사용되는 도구이기도합니다. 스크럼과 마찬가지로 Kanban은 작업을 관리 가능한 덩어리로 세분화하고 Kanban 보드 (Scrum Board와 매우 유사)를 사용하여 작업 흐름을 통해 진행되는 작업을 시각화합니다. 스크럼이 스프린트를 통해 특정 양의 작업을 수행 할 수있는 시간을 제한하는 경우 Kanban은 한 조건에서 허용되는 작업량을 제한합니다 (많은 작업 만 진행할 수 있으며 너무 많은 작업 만 수행 할 수 있음) -목록.)

스크럼과 칸반은 어떻게 같은가요?

스크럼과 칸반 모두 크고 복잡한 작업을 효율적으로 분류하고 완료 할 수 있습니다. 둘 다 지속적인 개선, 작업 최적화 및 프로세스에 높은 가치를 부여합니다. 또한 두 팀 모두 WIP에 대한 모든 팀 구성원과 향후 계획을 계속 유지할 수있는 가시성있는 작업 흐름에 매우 유사한 초점을 공유합니다.

이 링크 에서 나머지 세부 사항을 참조하십시오

내 질문은 기본적으로 : 개발자의 품질에서 문제를 찾는 것이 언제 공평합니까?

게시물에 해당 질문에 대한 답변이 충분하지 않습니다. 그들이 무능하기 때문에 실패하는지, 또는 합리적 인 것보다 더 많은 일을하겠다고 결심하여 실패하는지 여부를 알 방법이 없습니다.

내가 정말 재능있는 개발자로, 아주 재능있는 개발자로 구성된 팀에서 두 가지 스프린트 (또는 36!)로 X 스토리를 끝내지 못하면 무능합니까? 아니면, 우리는 추정에 빨려 있습니까? 이야기가 "로그인 화면 만들기"인지 "화성에게 안전하게 사람을 보냈는지"에 따라 다릅니다.

문제는 나쁜 이야기 및 / 또는 나쁜 추정으로 시작됩니다.

추정은 어렵다. 정말 열심히. 스크럼은 작업을 하루나 이틀 이상 걸리지 않아야하는 블록으로 분류하고 짧은 시간 안에 완료 할 수 있다고 확신하는 작은 그룹의 블록을 조립합니다. . 블록이 클수록 시간이 길수록 예측 정확도가 떨어집니다.

당신의 상점은 어떻습니까? 좋은 합격 기준으로 잘 작성 되었습니까? 그들은 단지 며칠 안에 할만큼 작습니까? 제품 소유자를 포함한 전체 개발 팀의 결점 인 잘 작성된 이야기가 없으면 팀은 적절한 평가를 수행 할 수 없습니다.

문제는 나쁜 회고에 의해 악화된다

당신이 잘못하고있는 것은 겉보기에는 회고를 ​​이용하지 않는다는 것입니다. 이 문제를 해결하지 않고 18 개월이 지났으므로 팀이 문제를 인식하지 못하거나 회고에서 문제를 해결하지 못하고 있습니다.

다음 스프린트에서 더 나은 결과를 얻기 위해 팀이 수행해야 할 최소한 하나의 액션 아이템으로 각 회고가 끝납니다. 각 회고전에는 이전 스프린트의 액션 아이템에 대해 이야기했는지, 효과가 있는지 확인하는 것이 포함됩니까?

해결책은 비난하는 것이 아니라 배우는 것입니다.

첫 번째 단계는 책임을 찾는 것을 멈추고 대신 팀을 개선하기 위해 노력해야합니다. 당신의 팀은 아마도 무능하지 않고, 추정과 계획에 나쁜 것일 것입니다. 팀이 단거리 스토리를 선택하고 일주일 일찍 완료하더라도 스프린트를 끝내도록 강요하십시오. 그들이 그렇게 할 수 없다면, 그들은 무능하거나 이야기가 너무 복잡합니다. 그 질문에 대한 답은 분명해야합니다.

일단 한 이야기를 마치면 스프린트에서 X만큼의 스토리 포인트를 수행 할 수 있다는 것을 확실하게 알 수 있습니다. 간단한 수학은 더 많은 이야기를 할 수 있는지 없는지에 대한 질문에 답하는 데 도움이됩니다.

지속적인 개선이 해결책입니다

스프린트에서 한 이야기를 마치면 두 가지를 할 수 있는지 살펴볼 차례입니다. 오히려 헹구고 반복하십시오. 그들이 스프린트 목표를 달성하지 못했을 때, 당신은 그들의 추정 능력에 한계를 발견했습니다. 이전 스토리의 스토리 포인트 수로 돌아가 잠시 동안 그 포인트를 고수하십시오.

항상 회고를 진지하게 받아들이십시오. 스프린트를 마치지 못한 경우 이유를 파악하고 행동하십시오. 그들은 너무 많은 미지수를 가지고 있었습니까? 그들은 잘못된 기술 조합을 가지고 있습니까? 그들의 추정치는 얼마나 좋았습니까? 만약 그들이 이야기를 X 점으로 추정한다면, X 점에 해당하는 선험적 인 이야기와 같은 양의 작업이 필요 했습니까? 그렇지 않다면, 그것을 사용하여 앞으로 이야기의 요점을 조정하십시오.

당신은 "회고를 사용하십시오"라고 말합니다. 그러나이 회고에서 팀은 실제로 무엇을 하는가? 프로세스 의이 측면을 한 번 다루지 않고 18 개월을 보냈으므로 대답은 다음과 같습니다. 매우 유용하지 않습니다.

나에게 회고는 과정에서 가장 중요한 부분입니다. 회고하는 동안 팀의 상호 합의를 통해 원하는 모든 스크럼에 대해 다른 것을 버리고 변경하십시오. 그러나 프로세스가 모든 사람에게 어떻게 작동하는지, 효과가 있었던 것과 공유 한 것을 공유하기 위해 정기적으로 시간을 내십시오. 작동하지 않으며 개선 할 아이디어를 제안하십시오. 스프린트마다 조금씩 프로세스를 개선하려고 노력하십시오. 조만간 꽤 잘 작동하는 것을 가질 수 있습니다.

귀하의 경우 해당 프로세스가 작동하지 않는 것 같습니다. 스프린트 목표가 달성되지 않았기 때문에 이것이 왜 그런지에 대한 회고적인 초점이 현명합니다. 분명히 팀은 스프린트를 위해 너무 많은 작업을 수행했습니다. 그러나 그들은 왜 그렇게 했습니까?

• 그들은 작업의 복잡성을 과소 평가 했습니까?
• 경영진이 팀이 생각한 것보다 더 많은 작업을 수행하도록 압력을 가했습니까?
• 계획된 작업을 완료하는 데 자원을 빼앗아 간 중단 / 응급 상황이 너무 많습니까?
• 작업 완료를 지연시키는 병목 현상이 발생 했습니까 (예 : 외부 디자인 팀의 자산 대기)?
• 그리고 심지어 : 한 명 이상의 팀원이 전혀 작업을 수행 할 수 없었습니까?

이것은 지난 18 개월 동안 팀이 스프린트마다 스스로 제기해야했던 질문입니다. 그런 다음 답변으로 무장 한 다음 스프린트를 위해 제안 된 프로세스 개선을 제안 할 수 있습니다. 여기에는 다음이 포함될 수 있습니다.

• 다음 스프린트에서 더 적은 작업을 수행하십시오 (duh!)
• 더 보수적 인 추정
• 우리가 지금 달성 할 수있는 것보다 더 많은 것을 이미 취하고 있기 때문에 더 많은 일을하도록 압력을 가하는 사람에게 말하십시오.
• 피할 수없는 긴급 상황을 수용하기 위해 다음 스프린트에서 중단을보다 잘 관리하고 작업량을 조정하십시오.
• 병목 현상을 해결하거나 피할 수없는 병목 현상을 계획하십시오
• 성과를 달성 할 수없는 팀원에게 스토리를 할당하지 마십시오 (별도 적으로 교육 및 멘토링에서 해고에 이르기까지 성과가 저조한 팀 구성원과의 상황을 해결하기위한 경영진 응답 파악)

이것은 지난 18 개월 동안 한 번의 스프린트마다 발생했던 일종의 대화입니다. 팀에 압력을가하거나 더 많은 리소스를 추가하는 것이 아니라 프로세스를 지속적으로 개선하기 위해 회고를 사용하는 것입니다. 분명히 여기서 일어나지 않습니다.

당신은 목표를 놓친 15 번째 스프린트에 의해, 팀은 이것을 한 번만 달성하기 위해 가능한 한 최소한의 스프린트 목표를 취하기로 결정한 시점까지 회고하면서 이것을 여러 번 논의했을 것이라고 생각할 것입니다. 25 번째 미완료 스프린트까지는 단 하나의 문자열 변경만으로 스프린트를 수행합니다. 스프린트에서 팀이이를 관리 할 수 ​​없다면 문제는 당신이 생각하는 것보다 훨씬 나빠집니다.

분명히 여기에서 여러 사람들이 이미 지적했듯이 스프린트 목표는 철약 약속이 아니라 예측이며 누락 된 목표 자체가 부정확 한 예측 이외의 다른 것을 나타내는 것은 아닙니다. 훌륭한 팀은 나쁜 예측 자이기 때문에 많은 목표를 놓칠 수 있지만, 끔찍한 팀은 모든 목표를 달성하고 실제 가치를 제공 할 수는 없습니다. 그러나 18 개월 동안 같은 방향으로 예측이 잘못되면 프로세스의 해당 부분이 작동하지 않습니다. 회고를 사용하여 프로세스를 수정하면 예측이 팀이 각 스프린트를 제공 할 수있는 실제 현실과 합리적으로 가깝습니다.

"소프트웨어가 완료되면 더 이상, 더 이상 완료되지 않습니다."

이것은 사실이지만 개발자가 작업을 시작하는 각 작업에 대해 조직의 모든 사람 이 각 작업에 대한 완료 정의를 이해 합니까?

가장 큰 문제 중 하나는 추정 이지만 개발자는 명확하고 명확하게 지정된 '완료된 정의'가있는 경우에만 현실적인 추정치를 제공 할 수 있습니다. (회사 문서 문제 (예 : 사용자 문서, 공식 릴리스의 작업 패키지 등)가 포함됨)

대부분의 개발자가 작업을 완료하는 데 필요한 시간을 예측하는 것이 요청하기 가장 어렵다는 것을 알기 때문에 과대 평가가 문제를 일으키는 것은 놀라운 일이 아닙니다.

그러나 대부분의 개발자들은 (이기는하지만 합리적인하는 경향이 낙관적가 )의 양을 처리 할 노력 들이 주어진 시간 기간 동안 넣어 수 있습니다.

문제는 종종 개발자 가 불완전한 정보를 처리 할 때 필요한 작업과 전체 노력 사이의 관계를 만드는 데 어려움을 겪고 있다는 것입니다. .

이것은 자연스럽게 시간 추정치가 현실과 단절되게 만들고 빌드 프로세스 및 사용자 문서와 같은 것을 보지 못합니다.

작업이 설명 될 때 처음에 연결 끊기가 시작되는 경향이 있습니다. 그리고 일반적으로 필요한 노력의 양에 대한 단서없이 요구 사항 목록을 작성하는 비전문가에 의해 복잡해집니다.

때로는 고위 경영진이 업무를 지정하고 회사 프로세스 문제를 완전히 무시하기도합니다. 고위 경영진이 테스트 정의, 공식 빌드 빌드 또는 사용자 문서 업데이트와 같은 작업이 시간이나 노력없이 마술처럼 일어난다 고 생각하는 것은 드문 일이 아닙니다. 필요합니다.

누군가 어딘가에서 작업을 제대로 수행하지 않기 때문에 개발자가 코드를 작성하기 전에 프로젝트가 실패하는 경우가 있습니다.

개발 팀이 요구 사항에 동의하거나 수용 기준을 포착하지 않으면 관리에 실패한 것입니다. 코드와 기술 문제에 대한 이해가 불충분 한 사람이 비즈니스를 불완전한 요구 사항 세트에 맡 겼기 때문입니다. 잘못 해석, 스코프 크리프, 금도금 등 프로젝트를 진행했습니다.

개발 팀이 캡처 요구 사항을 동의에 참여하는 경우, 그것은 세부 사항 (과 허용 기준을 명확히 할 책임이 있습니다 팀의 실패가 될 수 - "? 전달 가능한 모습처럼이되어 무엇을, 즉 일 ?" ). 개발 팀은 또한 다른 차단 문제가 있거나 요구 사항이 비현실적인 경우 아니요 라고 할 책임이 있습니다 .

따라서 개발자가 요구 사항 캡처에 관여하는 경우 :

• 팀은 제품 관리자와 함께 수행하여 요구 사항 / 정의를 명확히 할 수있는 기회가 있습니까?
• 팀은 묵시적 ​​/ 가정 요구 사항을 명확히하기 위해 충분한 질문을합니까? 그 질문들은 얼마나 자주 만족스럽게 대답합니까?
• 팀 은 견적을 제공하기 전에 수락 기준 (정의 정의)을 요구합니까 ?
• 수락 기준은 일반적으로 각 작업에 대해 얼마나 잘 파악됩니까? 희미한 세부 사항이 담긴 모호한 문서입니까, 아니면 유형의 기능 및 개발자가 테스트로 명확하게 번역 할 수 있다는 문구를 설명 합니까?

팀 의 생산성 이 문제가되지 않을 가능성이 있습니다. 귀하의 팀은 아마도 개발과 관련하여 그들이 할 수있는 모든 노력을 기울일 것입니다. 실제 문제는 다음 중 하나 이상일 수 있습니다.

• 불완전하고 모호한 요구 사항.
• 처음에는 너무 큰 요구 사항 / 작업
• 개발팀과 경영진 간의 의사 소통 부족.
• 작업이 팀에 전달되기 전에 명확하게 정의 된 승인 기준이 부족합니다.
• 불완전하거나 모호한 / 모호한 합격 시험 사양. (즉, 완료의 정의)
• 수락 기준 정의 / 동의에 할당 된 시간이 충분하지 않습니다.
• 개발자는 기존 기준 코드를 테스트하거나 기존 버그를 수정하는 시간을 고려하지 않았습니다.
• 개발자는 기존 기준 코드를 테스트했지만 요구 사항에 대한 견적을 제공하기 전에 버그를 차단 문제 로 제기하지 않았습니다.
• 경영진은 문제 / 버그를보고 새 코드를 작성하기 전에 버그를 수정할 필요가 없다고 결정했습니다.
• 아마도 회의, 산만 함, 전자 메일 등으로 인해 20 % (또는 비슷한 숫자)의 시간이 소요될 수 있지만 개발자는 시간의 100 %를 책임 져야합니다.
• 추정값은 액면가에 동의하며 아무도 오류 또는 우발 상황에 대한 여지를 조정하지 않습니다 (예 : "우리는 5 일이 걸리기로 결정하여 8시에 완료 할 것으로 예상합니다").
• 견적은 실제 (범위) 숫자 대신 모든 사람 (개발자 및 관리)이 단일 숫자로 처리합니다.
  • 최상의 사례 추정
  • 현실적인 추정
  • 최악의 추정

... 목록은 그것보다 훨씬 오래 갈 수 있습니다.

"사실 발견"을 수행하고 추정치가 현실과 지속적으로 분리되는 이유를 정확히 파악해야합니다. 기존 기준 소프트웨어가 불량합니까? 단위 테스트 범위가 부족합니까? 개발자가 관리와의 통신을 피합니까? 경영진이 개발자와의 의사 소통을 피합니까? "정의 정의" 와 관련하여 관리 기대치와 개발자 기대치 사이에 연결이 끊어 졌습니까?

팀을 재부트하는 나의 충고는 팀, 스프린트 당 가능한 가장 작은 이야기를 골라 그 하나의 이야기와 하나의 이야기 만 완성하는 것입니다!

팀이 무능하거나 너무 많은 일을하려는 다른 포스터에 동의합니다.

가장 작은 이야기, 가장 격렬한 이야기로 시작하고 단일 스프린트를 완료하십시오. 스프린트를 마치고 성공을 거두면 팀이 시간과 업무 약속의 우선 순위를 정하는 방법을 알 수 있습니다. 시간이 지남에 따라 팀은 최고의 생산성에 도달 할 때까지 점점 더 많은 작업을 수행 할 수 있습니다.

과거 성과를 기반으로 데이터를 수집하고 신뢰 수준을 구축해야합니다.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

가장 간단한 예는 2 주마다 일정한 시간 간격을 두는 것입니다. 2 주 이내에 팀이 완료 할 스토리 포인트 수를 추정하십시오. 그리고 2 주간의 스프린트가 끝나면 실제로 얼마나 많은 스토리 포인트가 완료되었는지 확인하십시오. 시간이 지남에 따라 15 점을 예상 할 수 있지만 10 점만 끝낼 수 있습니다.이 간단한 경우에는 속도 조정으로 앞으로 나아 가기 시작하여 스프린트 당 10 점만 계획 할 수 있습니다. 또는 예상 작업의 66 %를 완료 할 계획입니다.

표준 편차로 신뢰 수준을 구축함으로써 경영진에게 말할 수 있습니다. 현재 프로젝트 목표에 따르면 3 주 안에 완료 할 수있는 신뢰도는 50 %에 불과하지만 5 주 안에 완료 할 수있는 신뢰도는 95 %입니다.

Agile과 Scrum의 기본 개념은 공정을 측정 할 수 있도록 긴밀한 피드백 루프를 구축하는 것입니다. "어디서 고장 났습니까?"라고 물어봐야합니다. 왜냐하면 완전히 분해 된 것 같습니다.

1. 무엇을할지 계획하고 목록을 작성하십시오.
   • 이것은 완료해야하는 항목의 백 로그에서 항목을 선택하는 것으로 구성되어야합니다. 스프린트의 할 일 목록에 항목을 가져 오기 전에 팀은 스프린트를 완전히 이해하고 완료하는 데 스프린트보다 적은 시간이 소요될 것으로 예상한다는 데 동의해야합니다.
   • 이상적으로 백로 그는 우선 순위 (비즈니스에 따라)로 정렬되며 우선 순위를 끌어 올 수 있습니다.
   • 백 로그의 항목이 너무 큰 경우 작은 조각으로 나눕니다. 그런 다음 청크를 개별 작업으로 나누고 하루 안에 완료 할 수 있습니다.
   • 이 계획이 쉽고 빠를 것으로 기대하지 마십시오.
2. 정의 된 기간 동안 목록의 항목에서 실행 (스프린트)
3. 달성 한 내용 검토
   • 어떤 이야기가 끝났습니까?
   • 스토리가 완성되지 않았다면 스토리를 구성하는 어떤 작업이 완료 되었습니까?
   • 완료된 작업이 없으면 지난 월요일에 모든 사람이 정확히 무엇을 했습니까? 지난 화요일? 등-이 시점에서 심각한 내성에 대한 시간입니다 ...

4. 문제점 해결 (피드백 분석 및 적용)

   • 끝나는 데 얼마나 걸렸습니까?
   • 작업이 완료되지 않은 이유는 무엇입니까?
   • 팀 구성원이 스토리 (기능)를 1 일 이내에 완료 할 수있는 작업으로 분류하고 있습니까? 그렇지 않은 경우이 작업을 수행하여 작업 관리 목록의 일부로 만드십시오.
   • 스프린트 중에 작업 목록 또는 작업 목록의 항목이 어떻게 변경 되었습니까? 이것이 마무리하지 않은 원인입니까? 그렇다면 목록이나 기능을 변경하지 마십시오. 변경된 기능이 안정 될 때까지 백 로그에 버리십시오.
   • 스프린트에서 완성 할 수있는 것으로 일부 품목의 크기와 범위를 어떻게 줄일 수 있습니까? 로깅 개선, 간단한 버그 수정, 오타와 같은 작은 것을 선택하여 팀이 수행 할 수있는 일을 측정 할 수있게하십시오. 이 작업을 수행 할 수없는 경우 달리기 중지하고 다시 계획하십시오 .

5. 1 단계로 돌아가서 놓을 때까지 반복하십시오.

문서화 장애, 종속성 작성 문제, 통신 문제, 요구 사항에 대한 정보가 충분하지 않습니까? ... 무엇입니까? 개발자들이 새로운 기술을 배우기 위해 시간을 보냈습니까? 그들은 디자인에 많은 시간을 보냈습니까? 스프린트 작업 목록에서 학습과 같은 것들이 설명 되었습니까?

당신의 팀은 그들이 회고 할 때마다 문제를 해결했다고 생각 했습니까? 팀은 문제를 해결하기 위해 행동 했습니까? 팀이 응답하지 않았고 경영진이 단순히 솔루션과 조치 과정을 지시 했습니까?

시간이 오래 걸리기 때문에 개발자가 아닌 체계적으로 문제가 있습니다. 어느 시점 (1 년이되기 전에)에 팀원 (스크럼 마스터 포함)이 물어 봤어야했는데, 작지만 달성 할 수있는 것은 무엇입니까?

상황에 따라 회고가 너무 늦습니다.
매일 회의를 개최하고 지난 24 시간 동안 수행 한 작업에 대해 사람들로부터 진정으로 지위를 얻고 있습니까?
스크럼 마스터는 이러한 회의를 사용하여 각 개발자의 목표에 대한 진행 상황을 측정합니까?
진행 과정을 모니터링하려면 해당 스크럼 방법론을 사용해야합니다. 사람들이하는 일에 대한 좋은 통찰력을 제공해야합니다.
산만합니까? 커피에 너무 많은 시간을 보내거나 SE / SO에있는 다른 사람들을 돕거나, 뉴스를 읽거나, 설명되지 않은 검사를하는 데 시간이 많이 걸립니까? 아니면 정말 머리를 숙이고 전체를 기발하고 철저하게 과도하게 헌신하고 있습니까? 매일보기는 좋은 아이디어를 제공해야합니다. 또한 개발자가 과제에 계속 집중할 수 있도록 도와 주므로 어제 아무 것도하지 않았다는 것을 인정할 필요가 없습니다.
물론 스프린트를 통해 꾸준한 진행 상황을보고했지만 여전히 결과가 나오지 않으면 거짓말을하고 새로운 개발자를위한 시간 일 수 있습니다.

프로그래밍 코드와 같은 복잡한 작업을 완료하는 데 필요한 노력과 시간을 예측하는 것은 어렵습니다. Joel Spolsky는 다음과 같이 말합니다.

소프트웨어 개발자는 실제로 일정을 세우는 것을 좋아하지 않습니다. 보통 그들은 하나도없이 도망 가려고합니다. "그것이 끝나면 끝날 것입니다!"라고 그들은 이렇게 용감하고 재밌는 징거가 보스를 낄낄 거릴 것으로 예상하고, 그 후의 쾌감을 위해 일정을 잊어 버릴 것이라고 말합니다.

그러나 회사 운영을 위해서는 마감일이 필요합니다. Joel이 제안한 바와 같이 증거 기반 일정 을 사용하여 관련된 확률로 시간을 예측하고 어떤 유형의 위험과 관련이있을 수 있는지 관리합니다.

스크럼은 몇 가지 일을합니다.

첫째, 우선 순위를 권장합니다. 공급 업체는 먼저 무엇을하고 싶은지를 말해야하며 "모든 것이 똑같이 중요하다"고 말하지 않아야합니다.

둘째, 모든 것이 끝나지 않아도 다소 유용한 제품을 생산합니다. 그것이 각 반복의 끝에 "잠재적으로 선적 가능한 제품"을 갖는 시점입니다.

셋째, 피드백 루프가 더 엄격 해집니다. 스프린트 종료시 "완료"를 요구함으로써 "90 % 기능이 완료되었지만 절반 만 완료"문제를 피할 수 있습니다. 마감일을 미룰 때, 마감일을 거의 맞지 않은 것처럼 보이게하거나 따로해야 할 일을 따로 떼어 놓을 수 있습니다. 완료에 대한 정의를 갖고 수행중인 작업을 주장함으로써, 무언가가 나중에 대신 보이는 것보다 어려운지 알 수 있습니다.

넷째, 세부 계획을 작업 수행에 가깝게 이동하여 재고를 피합니다. 계획을 세우는 것은 인벤토리의 한 형태입니다. 즉, 고객이 직접 판매하거나 사용할 수없는 자원에 소비 된 자본입니다. 이러한 재고는 썩을 수 있고 (계획이 변경되고, 새로운 정보가 쓸모 없게 됨), 요구와 일치하지 않을 수 있습니다 (분산 네트워크 whatzit가 필요하지 않습니다. (작년에 절반의 시간이 내년과 그 이후의 계획에 소비 된 경우, 지금 준비 할 물건을 연구했다면 2 배 더 많은 배송을 받았을 수 있습니다). 손실없이 계획을 실행에 더 가깝게 이동할 수 있다면 (빈색!) 재고를 줄일 수 있습니다.

이러한 문제를 해결할 수있는 유일한 방법은 아닙니다. 스크럼을 사용하여 개발자가 각 기간 동안 작업 할 수있는 작업 스트림을 정기적으로 추가하고 수행 할 새 작업을 정기적으로 추가하고 진행 상황을 확인하는 것처럼 보입니다.

이것은 스크럼 패턴을 사용하는 유용한 방법입니다. 작업 흐름을 유지하고 생산에 근접한 계획을 유지하며 피드백 루프 등을 제공합니다. 시스템과 일치하도록 개발 및 테스트를 왜곡하지 않는다는 장점도 있습니다 (작업이 기본적으로 테스트가 완료된 경우) 동일한 스프린트 내에서 작업을 완료하고 테스트하려고하면 스프린트의 백엔드에 새로운 개발이 필요하지 않습니다!)

그들이 할 일을 정확히 스프린트에 넣지 않았다고해서 개발자가 훌륭한 일을하고 있지 않다는 증거는 아닙니다. 즉, 프레임 워크의 일부를 사용하여 SCRUM을 팔로우하지 않습니다.

그들이 각각의 스프린트에 얼마나 많은 노력을 쏟았는지 반으로 줄 였지만 다른 모든 것을 동일하게 유지했다면, 그들은 각각의 스프린트에 헌신 한 것보다 더 많이 마쳤을 것입니다! 동일한 양의 코드가 생성됩니다. 분명히 "스프린트 실패"는 중요한 부분이 아닙니다. 이는 내부 프로세스 세부 사항 일뿐입니다. 회사의 목표는 똥을 끝내는 것입니다. 특정 종류의 ISO 프로세스 인증이 아닌 한 특정 프로세스를 따르지 않아야합니다.

프로세스는 수행 된 작업의 목표에 종속적입니다.

반면에, SCRUM 규칙을 따르지 않기 때문에 동일한 종류 의 피드백을 얻지 못합니다 . 생성 된 결함의 종류가 SCRUM이 처리하도록 설계된 결함인지 확인하기 위해 결과물을 조사해야합니다. 좀비처럼 영원히 살면서 늦게까지만 죽이는 이야기가 있습니까? 쉬운 것처럼 보이고, 폭발하며, 총 작업 가치가없는 회고적인 이야기가 있습니까? 실제로 제품을 배송해야하는 시점에 배송 할 수 있습니까?

"완료된"모양을 정의하지 않은 경우 "소프트웨어가 완료되면 더 이상, 더 이상 나중에 완료되지 않습니다"라는 오류의 레시피입니다.

대부분의 엔지니어는 최상의 솔루션을 생산하려고 시도하지만, 특히 경험이 적은 엔지니어의 경우 금도금으로 쉽게 이어질 수 있습니다. 관리 의 유일한 책임은 목표의 정확한 위치를 정의하고 엔지니어가 그 방향을 향하도록하는 것입니다. 엔지니어는 종종 측면 선삭을 시도하여 기능을 향상 시키려고 노력하며, 측면 선삭이 장기적으로 속도를 향상 시킬지 또는 개선을 위해 개선되는지 여부를 결정하는 것은 경영진의 책임입니다.

애자일 개발의 핵심은 전력 질주 충족하기 위해 필요한 작업의 각 새로운 조각이 좋지해야한다는 것입니다 및 더 나은을 !!!!!! 예, 이것이 StackOverflow에 추가 할 수있는 가장 강조점입니다. 여전히 강조하지 않습니다. 사람들 이이 초에 필요하지 않은 것을 추가하고 있다는 것을 알게되면 민첩한 개발을 올바르게 수행하는 방법에 대한 교육 이 필요합니다.

아, 그리고 우리는 회고를 ​​사용합니다.

오, 좋아 왜 팀이 실패 했는지 아십니까 ? 무엇이 효과가 있고 효과가 없는지 이야기 할 수있는 36 개의 기회가 있었으므로 스크럼 마스터는 문제를 해결하는 방법을 완전히 이해해야합니다.

당신의 설명에 따르면, 당신의 회사는 "SCRUM은 우리를 생산적으로 만든다"는 사고 방식에 빠졌다고 생각합니다. 진실은 스크럼이 당신의 생산성을 높이 지 못한다는 것입니다. 오히려, 당신이 할 수 있도록하는 도구입니다 자신이 자주 모두 관리 및 개발자들에 의해 간과 개발의 현실을 식별하는 방법으로 생산은.

스크럼 마스터는 팀의 잠재적 문제로 무엇을 식별 했습니까? 그들은 처리 할 수있는 것보다 두 배나 많은 일을 끊임없이 할당하고 있습니까? 그렇다면 스크럼 마스터가 팀의 속도를 볼 수 있기 때문에 스크럼 마스터가 작업량을 줄 이도록 부드럽게 제안해야합니다.

개발자의 품질에서 문제를 찾는 것이 언제 공평합니까?

개발자의 품질에서 문제를 찾아야하는 시간은 문제라고 확신하는 순간입니다. 이것은 SCRUM이 만든 새로운 문제가 아닙니다. 이것이 사업의 현실입니다. SCRUM은 기존 접근 방식보다 팀 구성원의 기능에 대해 훨씬 더 많은 정보를 제공해야합니다. 기존의 접근 방식으로 이해하는 것보다 문제가 "소프트웨어 개발자가 충분하지 않은지"대 "관리 기대치가 비현실적"인지 여부를 알아야합니다. 지금은 경영진이 최선의 업무를 수행 할 때입니다. 회사에 돈을 벌 수 있도록 적절한 직원을 찾으십시오. 문제가 어디에 있는지 알 수 없다면 모든 회고없이 말하기가 얼마나 어려울 지 상상해보십시오!

사람들이 충분히 좋을 것이라고 생각한다면 (직원이 고용이 실수가 아니라는 것을 암시하는 것), 제 조언은 상자 밖에서 생각하기 시작하는 것입니다. 작업이 완료되지 않은 경우 개발자의 작업 모양을 변경하십시오. 스프린트 완료 마감 시한을 확인하는 가장 쉬운 방법 중 하나는 완료 기준에 따라 결과가 만족 스러울 수 있도록 완료 기준을 조정하는 것입니다. 따라서 완성은 팽팽하게됩니다.

이로 인해 관리, 특히 SCRUM 마스터에 대한 책임이 있습니다. 비결은 완료된 경우 매우 가치있는 작업을 작성하는 것이지만, 불완전한 상태로 남아 있으면 회사에 급여를받을만한 가치가있는 충분한 가치를 제공합니다. 18 개월 후, 나는 당신의 회고전이 당신에게 무언가를 가르쳐 줄 것으로 기대합니다. 그렇지 않은 경우, 회사에서 잘못된 것을 발굴하여 밝게하는 실패한 이야기의 명확한 의도로 이야기를 작성해야합니다. 그것은 회사가 개발 팀과 얼마나 많은 좌절감을 가지고 있는지를 감안할 때 회사에 엄청난 귀중한 데이터를 제공 할 것입니다. 당신이 묻는대로 문제는 실제로 개발자 일 수 있습니다. 또는 문제는 지금까지 전혀 몰랐던 회사의 사고 방식의 병리 일 수 있습니다!

실제로 문제가 개발자가 아닌 회사와 관련이 있다면 불완전한 이야기에서 얻은 정보가 실제로 성공적인 정보에서 수집하는 것보다 더 가치가 있습니다! 회사 전체를 구하는 정보 일 수 있습니다! 그것은 정말 귀중한 정보 인 것 같습니다. SCRUM을 도구로 사용하여 정보를 수집 할 수 있습니다.

"언제 개발자의 품질을 보는 것이 공정합니까?"

항상. 분명히 어떤 사람들은 다른 사람들보다 생산적이기 때문에, 고용주로서 그들의 성과를 측정하기위한 변명은 필요하지 않습니다.

까다로운 것은 당신이 그것을하는 방법입니다. 저의 조언은 숙련 된 계약자를 고용하여 파마 직원이 추정 한 것과 동일한 일련의 작업을 수행하고 파마 직원과 함께 작업하여 속도가 더 높은지 확인하는 것입니다.

이를 통해 장기 고용에 구속되지 않고 현재 시장과 비교할 수 있습니다.

그것은 또한 파마들에게 arse를 약간 걷어차 게 할 수도 있습니다.

또한 계약자가 속도 등을 얻기 위해 품질 등을 건너 뛰고 있다고 불평하면 비즈니스 가치가 어디에 있는지에 대한 대화를 유도합니다. 장기 유지 보수 가능성 또는 단기 제품 배송.

그것이 장기적인 물건이라면 그것을 수량화하고 스프린트에 요구 사항으로 내려 놓아야합니다!

이미 몇 가지 훌륭한 답변이 있습니다. 특히, 잘못된 추정, 과도한 약속 및 / 또는 예정되지 않은 작업은 자주 미끄러짐의 원인입니다.

그러나 "[개발자]가 각 스프린트에 포함 할 기능을 선택하는 이유"에 대해 궁금합니다. 개발자는 일반적으로 우선 순위가 가장 높은 기능에 대해 작업해야하며 우선 순위는 비즈니스 결정입니다. 즉, 비즈니스 이해 관계자의 프록시 역할을하는 제품 소유자가 제공해야합니다.
(이에는 예외가 있습니다. 특히 고위험 기능은 일반적으로 이전에 작동합니다. 경우에 따라 사용자가 직면 한 기능은 다른 기능 (예 : "X를 구현하기 전에 실제로 데이터베이스를 추가해야 함")에 따라 달라질 수 있습니다. )

반면, 견적은 기술적 인 결정이므로 비즈니스맨이 판단해서는 안됩니다 . 당신은 이것에 대해 아무 말도하지 않습니다-필자의 경험에 따르면 개발자가 작업 할 것을 선택할 때 비즈니스 사람들이 소요되는 시간을 지시하는 것이 일반적이기 때문에 요점을 제기합니다.

상당히 기능 장애가있는 것 같습니다. 나는 적어도 한동안 개발자 컨설턴트를 데려 오는 것을 권장하지 않을 것이다. 왜냐하면 그것은 사기에 부정적인 영향을 미칠 것이기 때문이다. 그러나 조직이 프로젝트 관리 측면에서 도움을 줄 수있는 것처럼 들립니다. 경험이 풍부한 민첩한 코치를 데려 가서 시작합니다. 중장기 참여가 아니라면 최소한 평가 또는 "건강 검진"입니다. 훌륭한 코치는 개발자의 성과가 저조한 지 알려줄 것입니다. 그러나 최소한 이런 식으로 면밀히 조사하고있는 것은 전체 팀 (개발자 만이 아니라)입니다.

또 다른 관찰 : 내 경험상 스크 램이 좋은 개발 프로세스를 따르지 않으면 프로젝트 관리 방법론으로 성공하기가 매우 어렵습니다. 자동화 된 단위 테스트를하고 있습니까? 또는 더 나은 자동 수락 테스트? 개발자가 페어링 중이거나 최소한 코드 검토 및 / 또는 연습을 자주 수행합니까? 어떤 형태의 지속적인 통합을 연습하고 있습니까?