저는 4 명의 개발자로 구성된 작은 팀의 스크럼 마스터입니다. 우리가 진행하고있는 프로젝트에는 이전에 해보지 못했던 많은 작업이 있으며 스프린트 계획 회의에서 쉽게 예측할 수 없습니다. 이 불확실성으로 스프린트를 돌리는 가장 좋은 방법은 무엇입니까? 나는 잠재적으로 탈착 가능한 제품으로 스프린트를 끝내기가 매우 어렵다. 또한 알려지지 않은 길이의 작업이 많은 경우 스프린트를 계획하는 것이 어렵다는 것을 알고 있습니다.스크램블 스프린트로 예측할 수없는 작업을 수행하는 방법은 무엇입니까?
나는 용어가 스크럼에 무엇인지 모르지만 사용자 스토리 용어에서는 기본적으로 주제에 대한 매우 짧은 기간 인 "스파이크"를 수행하여 팀에서 추정 할 수 있습니다 스파이크가 끝날 때의 과제.
예 :
이야기 :
애널리스트는 파이 차트에 재무 데이터를 검토 할 수 싶어.
팀에서는 차트 도구를 사용하지 않으므로 팀에서 이와 같은 것을 작성하는 데 걸리는 시간을 알아야합니다. 아니면 대신 타사 툴링에 투자하고 툴링 세트를 응용 프로그램과 통합 할 수 있습니다.
이러한 장소를 조사하고 예상치를 산출 한 다음 취할 경로를 결정할 때는 급증 할 것입니다.
작업을 예측할 수없는 것처럼 보일 경우, 최선의 방법은 이러한 작업을 예상 할 수있는 더 작은 작업으로 나누는 것입니다. 몇 번의 반복이 필요할 수도 있지만, 의사가있는 동안 의사 디자인을 제안 할 것입니다. Joel은 그의 articles 중 하나에서 이것을 언급합니다.
견적하기 어려운 복잡한 작업은 모두 괜찮습니다. 그러나 진정으로 알려지지 않은 작업을 위해, 당신은 단순히 당신이 무엇을 만들고 싶은지 또는 그것이 어떻게 작동 하는지를 모를 수 있습니다. 문제가 해결되거나 질문에 답을 얻을 때까지 필요한 시간을 알 수없는 다양한 R & D 프로젝트에 작업이 있습니다. – Mnebuerquo
작업이 정말로 알려지지 않았다면, 그것을 (적어도 어떤 종류의 정확도로도) 추정하는 것은 불가능합니다. 내가 제안한 것은 당신이 이미 알고있는 것을 생각하고,해야 할 일을 생각하고, 계획을 세우고,해야 할 일에 대한 느낌을 얻고, 예상을 시작하기위한 것입니다. 그걸 바탕으로 – ARKBAN
불투명도를 제거하는 작업으로 예측할 수없는 작업을 분할하고 "나머지 작업". Proof-of-concept 테스트 또는 스파이크 솔루션으로 불확실성을 제거하십시오. 이 스프린트의 스프린트와 다음 스프린트의 일정을 계획하거나 스프린트의 시작을 스프린트 일주일 연기하십시오.
전 세계 사람이 이전에 해왔 던 작업 또는 팀원에게 새로운 작업 인 "작업"입니다. 나는 나중에 추측 할 것이다. 그렇다면 문제를 해결하기 위해 팀에 필요한 경험이 없다는 것입니다. 따라서 당신은 그 경험을 발전시킬 것입니다. 이 모든 것이 의미하는 바는 이야기의 복잡성이 더 높다는 것입니다. 스프린트의 첫 번째 커플에서는 이야기의 일부에 13 점을 넣을 수 있고 나중에 8 점이되면 나중에 필요한 지식을 얻을 수 있기 때문에 8 점이됩니다.
이야기를 추정하는 방법을 알 필요가 없습니다. 경험 격차로 인해 그 중 적은 부분 만 차지하면됩니다.
알려진 솔루션이없는 비즈니스 도메인 문제를 해결하기 위해 "스파이크"(예 : 스크럼에 사용되는 용어)를 예약하려고합니다. 팀이 훈련을받는 것이 아닙니다.
우리는 종종 이야기를 작업으로 분해하기에 충분하지 않습니다. 우리는 업무가 무엇인지 알기도 전에 발견의 기간이 있습니다. "스파이크"는 관리하기 까다로운 것처럼 보입니다. 하나는 발견 기간에 시간을 정할 수 없을 수도 있습니다. 둘째, 이야기가 얼마나 오래 걸릴지 몰라도 스프린트를 효과적으로 계획 할 수 없습니다.
다른 옵션처럼 Sprint 1과 Sprint 2의 작업을 수행하는 것 같습니다. 단점은 프로세스가 부 자연스러운 작업의 중단을 초래하는 것 같습니다. 왜 이번 주에 발견하고 일을 시작하기 전에 잠시 기다려야합니까?
실제 견적을 얻기 위해 조사를해야하는 경우 스프린트 계획 전에 연구를 자체적으로 수행하거나 옆에두고 다른 사람이 수행하도록 할 수 있습니다.
일반적으로 좋은 예상치를 얻을 수 없다면 나쁜 예상치 (예 : 야생 추측)로 이동해야하거나 작업 시간을 정해야하므로 고정 된 양의 스프린트에서 그것을위한 시간. 그 다음에는 완료된 솔루션을 갖게 될 것입니다. 그렇지 않은 경우에는 다음 스프린트 (또는 이후 스프린트)의 하위 작업으로 나누거나 추정 할 수 있도록 더 잘 이해하게 될 것입니다.
정말 작업을 의미합니까, 아니면 제품 백 로그 항목 (PBIs)에 대해 이야기하고 있습니까? 사실, 나는 일을 예측할 수 없다는 것을 믿기 어렵다. 그들이 정말로 그렇지 않다면, 너무 큰 것 같습니다 (작업은 이미 거대한 16 시간을 초과해서는 안됩니다).
PBI에 대해 이야기하는 경우 설명하는 상황이 상당히 놀랍고 이론적으로는 발생하지 않아야합니다. 최악의 경우, 스토리 포인트를 높은 점수로 지정하면, 이는 엄밀히 말해서 많은 불확실성이 있음을 의미합니다. 하지만 스프린트 준비가 된 PBI는 속도의 절반을 초과해서는 안되며 (또는 스프린트에 너무 많은 위험을 감수해야 함),이 상황을 해결할 수있는 확실한 방법은 이러한 항목을 작은 조각으로 나누는 것입니다. 탐사가 포함됩니다. 그러나 중요한 부분은 시간 제한을 유지하는 것입니다 (심지어 특히 R & D). 스크럼을 사용하면 모든 것이 타임 박스에 저장됩니다.
즉, 불확실성을 줄이려면, 물건을 작은 물건으로 분해하십시오 (항목 또는 작업이 될 수 있음)!
우리는 그러한 일에 "우연"또는 특정 백 로그를 사용합니다. Scrum Tool Agilo은 이러한 작업 방식을 지원하며 이러한 문제도 계산합니다. Burndown에서. 이 방법으로 "계획되지 않은"항목에 대한 적절한 제어 권한을 얻을 수 있습니다.
정밀도와 정확도가 혼동 스럽습니까?
애자일 추정의 아이디어는 정확하지 않은 숫자를 제시하는 것입니다. 그래서 백 로그 항목 추정에 스토리 포인트를 사용하는 것이 가장 좋습니다. 그것은 지속 기간 대신에 노력/복잡성을 강조합니다.
스프린트에서 백 로그 항목을 구현하는 데 필요한 각 작업에 소요되는 시간을 알 필요가 없습니다. 이전에이 스프린트에서 맡은 작업을 감안할 때이 백 로그 항목에 커밋 할 수 있는지 알아야합니다. 각 백 로그 항목이 얼마나 많은 시간을 소비하는지 정확히 알 수 없다는 것을 알기 때문에 우리는 교묘 한 추측을해야합니다.
더 중요한 것은, 스크럼에서 실패한다는 것이 무엇을 의미합니까? 모든 스프린트 백 로그 항목에 오류가 발생하지 않았습니까? 5 개 항목 중 4 개가 완료되고 5 번째 항목이 대부분 완료되면 4 개의 완료된 항목 (스프린트의 속도 측면에서)에 대한 크레딧을 얻을 수 있으며 나머지 작업을 완료하면 미래 스프린트의 다섯 번째 항목은 해당 항목에 대한 전체 크레딧을 얻을 것입니다. 그러나 스크럼을 사용하지 않았다면 더 이상 일을하지 않았습니까? 스크럼에서 유일하게 실패한 것은 실수로 배우지 못하고 동일한 결과를 기대하면서 반복해서 같은 역기능을 반복하는 것입니다.
스프린트 계획 수립 회의에서 알 수없는 내용에 대해 많은 시간을 낭비하지 마십시오. 팀이 작업에 대해 생각하게하고, 스프린트 중에 완성 할 수있는 작업량에 가입하게하십시오. 그들이 과소 평가한다면 당신은 언제나 무언가를 백 로그에 끌어다 놓거나 스프린트를 일찍 끝낼 수있다.그들이 과도한 커밋을하면, 우선 순위 순서대로 할 수있는 백 로그 항목을 마무리하고 향후 스프린트에서 미완성 품목을 방지하는 방법과 함께 스프린트 회고전에서 미완성 항목을 완료 할 수없는 이유를 논의합니다.
그건 그렇고, 이것은 아마도 당신이 말한 단어가 좋지 않다는 것을 알고 있지만 효과적인 스크럼 마스터는 스프린트를 실행하지 않습니다. 팀은 스프린트를 실행하고 스크럼 마스터는 생산성을 낮추고 자신의 약속을 지키는 능력에 간섭하는 장애물을 적극적으로 찾습니다. 스크럼 마스터는 관리자가 아니며 심판, 코치 및 스코어 키퍼의 조합입니다. 그들은 프로세스의 골키퍼이며, 팀이 프로세스를 따르도록 돕고, 프로세스를 돌아 다니려고하는 외부 요원으로부터 팀을 보호하며, 스프린트 백 로그가 업데이트되고 스프린트 번 다운 차트가 업데이트 됨으로써 스프린트 진행 상황을 추적합니다. 현실을 반영합니다. 당신이 기술 한 상황에서, 팀이 얼마나 많은 일을해야하는지 확실하지 않은 곳에서, 스크럼 마스터는 팀이 약속의 팀 소유에 대한 존경심을 반영하도록 결정해야합니다. 결정이 무엇이든 그것이 잘못되지 않을 것입니다.
스파이크는 시간 제한이 있어야합니다. 범위를 제한하고 연구가 수반하는 비용 편익에 대해 더 나은 아이디어를 갖도록 팀에 압력을가합니다. 즉, 몇 달러의 비용이 소요되는 업무에 3 일간의 연구를 수행하는 것은 쓸모가 없습니다.
이것은 또한이 문제를 특별히 다루는 목표 설정 이론에 대한 Latham의 연구에 의해 뒷받침됩니다.
스파이크는 스파이크에서 발견 된 작업과 동일한 스프린트로 계획되어 있습니까? 아니면 스파이크에서 발견 된 작업이 다음 스프린트를 위해 계획 되었습니까? –
@Dave 일반적으로 없습니다. 보통 한 스프린트에서 스파이크를하고 다음 스프린트에서 작업을 수행합니다. 그렇기 때문에 릴리스 관리 중에 스파이크가 발생했는지 확인하는 것이 중요합니다. – Joseph
+1 @Joseph, 당신이 스파트가 타임 박스에 저장된다는 (즉, 특정 고정 된 시간이 할당 되었음) 암시 적으로 말하면서, 당신이 주어진 스프린트에 스파이크한다고 말함으로써. 나는 스파이크가 타임 박스되어야한다고 명시 적으로 말할 가치가 있다고 생각합니다. – JeffH