우리는 하나의 제품을 가진 작은 소프트웨어 회사입니다.
우리는 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시에 완료 할 것으로 예상합니다”).
- 견적은 실제 (범위) 숫자 대신 모든 사람 (개발자 및 관리)이 단일 숫자로 처리합니다.
- 최상의 사례 추정
- 현실적인 추정
- 최악의 추정
… 목록은 그것보다 훨씬 오래 갈 수 있습니다.
“사실 발견”을 수행하고 추정치가 현실과 지속적으로 분리되는 이유를 정확히 파악해야합니다. 기존 기준 소프트웨어가 불량합니까? 단위 테스트 범위가 부족합니까? 개발자가 관리와의 통신을 피합니까? 경영진이 개발자와의 의사 소통을 피합니까? “정의 정의” 와 관련하여 관리 기대치와 개발자 기대치 사이에 연결이 끊어 졌습니까?
답변
팀을 재부트하는 나의 충고는 팀, 스프린트 당 가능한 가장 작은 이야기를 골라 그 하나의 이야기와 하나의 이야기 만 완성하는 것입니다!
팀이 무능하거나 너무 많은 일을하려는 다른 포스터에 동의합니다.
가장 작은 이야기, 가장 격렬한 이야기로 시작하고 단일 스프린트를 완료하십시오. 스프린트를 마치고 성공을 거두면 팀이 시간과 업무 약속의 우선 순위를 정하는 방법을 알 수 있습니다. 시간이 지남에 따라 팀은 최고의 생산성에 도달 할 때까지 점점 더 많은 작업을 수행 할 수 있습니다.