우리 회사에서는 한 개인이 단일 작업을 완료 할 수 없습니다. 각 작업마다 QA 및 코드 검토 담당자가 별도로 있습니다. 이것이 의미하는 바는 각 개인이 작업마다 완료하는 데 걸리는 시간에 대한 견적을 제공한다는 것입니다.

문제는 어떻게 화상을 입어야합니까? 시간을 집계하면 다음 추정치를 가정하십시오.

10 시간-개발 시간

4 시간-품질 관리

4 시간-코드 검토.

작업 견적 = 18 시간

매일 매일 저는 "완료 될 때까지 남은 시간"으로 작업을 업데이트 할 것을 요청합니다. 그러나 각 사람은 일반적으로 자신의 부분에 대해서만 생각합니다. 그들은 노력을 남은 것으로 표시 한 다음 노력 추정치를 추가해야합니까? 어떻게 지내세요?

최신 정보

몇 가지 사항을 명확하게 설명하기 위해 조직 내 스토리 내의 각 작업에는 3 명이 필요합니다.

1. 과제를 개발할 사람. (단위 테스트를 수행하십시오 ...)
2. 작업을 검토하는 QA 전문가 (주로 통합 및 회귀 테스트 수행)
3. Tech는 코드 검토를 수행합니다.

나는 잘못된 길이나 올바른 길은 없다고 생각하지만 이것이 우리의 길입니다 ... 그리고 그것은 변하지 않을 것입니다. 우리는 가능한 한 아무리 작은 이야기라도 완성하기 위해 팀으로 일합니다. 개발이 완료 될 때까지 실제로 작동하는지 테스트 할 수 없으며 코드의 품질도 검토 할 수 없습니다. 따라서 가능한 최소한의 기능을 테스트하여 최소한의 기능 만 테스트 할 수 있도록 최선을 다하는 것이 좋습니다. 가능한 빨리 프로세스 초기에 검토했습니다.

이런 식으로 작동하는 사람들에게 내 질문은 그들이 이런 식으로 설정되었을 때 "작업"을 태워 버리는 방법입니다. 작업에 자체 하위 작업이 없으면 (JIRA에서 허용하지 않는) ... 매일 "남은 항목"을 추적하는 가장 좋은 방법은 확실하지 않습니다.

그것은 하나가 아닌 3 가지 일입니다.

하나의 기능 / 스토리 일 수 있지만 세 가지 작업입니다. 한 사람이 한 번에 한 작업을 완료 할 수 있습니다.

TL; DR

여러 방법으로 번 다운을 잘못 사용하고 있습니다. 작업과 이야기는 수행되거나 수행되지 않습니다. 번 다운 (burn-down)에서 시간 기반 계획 추정치와의 편차를 추적하려고하면 실제로 작업 제품의 남은 시간을 추정하는 것이 아니라 일정을 다시 추정하는 것입니다.

스크럼에서는 스프린트의 시간 상자를 측정하는 대신 스프린트 목표를 향한 진행 상황을 측정해야합니다. 이를 통해 지속적인 일정 조정보다는 팀 용량 및 기능 제공에 중점을 둡니다.

작업 대 이야기

당신은 작업과 이야기를 혼동하고 있습니다. 스토리는 팀의 "완료된 정의"에 따라 스토리를 완료하는 데 필요한 모든 작업으로 구성됩니다. 모든 작업이 완료 되지 않으면 스토리는 100 % 완료되지 않은 것으로 간주 됩니다. 스크럼에서 이야기는 항상 어떤 식 으로든 추정됩니다. 가장 자주 이야기 포인트로 추정됩니다.

작업은 스토리를 완료하는 데 필요한 단계 또는 이정표입니다. 각 작업에는 종속성과 전제 조건이있을 수 있지만 다른 작업과는 별도로 코드 검토가 완료되었는지 여부를 말할 수 있습니다.

타 버리다

스크럼에서 번 다운 차트는 스프린트 또는 프로젝트에 남은 작업량을 보여줍니다. 실제 번 다운 차트에는 종종 고원이 있습니다. 경우에 따라 그래프가 올라갈 수도 있습니다. 예를 들어, 3 및 5 포인트 가치가있는 2 개의 스토리가있는 1 주일 스프린트에서 데이터 포인트는 다음과 같습니다.

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

이 이상적인 시나리오에서는 8 개의 스토리 포인트로 시작합니다. 3 점 이야기는 화요일 오후에 완료되었지만 5 점 이야기는 금요일까지 완료되지 않았습니다. 스토리가 완료의 정의를 충족 할 때까지 스토리 포인트는 번 다운에서 공제되지 않습니다. 스토리 포인트 대신 이상적인 시간을 사용하는 경우 변화하는 것은 스케일뿐입니다.

박싱

일반적으로 허용되는 방법은 작업이 1/2 일에서 2 일 사이에 한 입 크기의 청크로 분해되도록하는 것입니다. 하루 이상의 편차는 일일 순위 또는 스프린트 백 로그에서 자명해야합니다. 공식적인 상태 풀을 수행 할 필요가 없습니다.

번 다운 차트에서 통계 분석을 수행하여 스프린트가 올바르게 추세인지 확인할 수 있습니다. 작은 편차 또는 안정은 정상이지만 매일 스탠드 업에서 차단제를 높이 지 않는 사람이 있지만 번 다운이 멈춘 것처럼 보이는 경우 이는 일반적으로 스프린트 백 로그가 잘못 추정되었거나 "보이지 않는 작업"이라는 표시입니다. 프로세스에서 명시 적으로 작성해야합니다.

QA가 수행하기 전에 개발 작업을 "완료"로 정의 할 수 있습니까? 개발이 완료되기 전에 코드 검토를 "완료"로 정의 할 수 있습니까? 개발자 및 코드 검토가 아닌 경우 품질 관리를 '완료'할 수 있습니까?

세 가지 항목을 하나의 작업으로 집계하고 세 사람이 함께 작업해야한다고 말하고 싶습니다.

스크럼은 어떤 품목도 한 팀원의 책임이라고 말하지 않습니다. 반대의 스프린트 로그 항목은 TEAM의 책임입니다. 작업을 수행하는 데 세 사람이 필요하다면 바로 그 일입니다.

중요하지 않습니다. 스토리간에 비교적 일관성이있는 한 번 다운 차트는 여전히 작동합니다. 팀이보고하는 가장 자연스러운 방법을 사용하십시오.

우리 팀은 공식적인 합의가 아니라 실제로 일종의 하이브리드를 수행합니다. 우리는 한 사람이 이틀이 걸릴 것이라고 생각하면 16 시간을 투자하지만 두 사람이 함께 작업하면 변경하지 않습니다.

초기 추정 후, 비공식적으로 남은 시간보다 팀의 완료율이 더 높습니다. 원래 이틀이 걸릴 것이라고 생각했지만 하루 만에 완료율이 25 %에 불과하다고 생각하면 원래 16 시간 중 4 시간이 걸립니다. 남은 3 일 동안 4 시간을 공제 할 것이므로 기술적으로 24를 추정하는 12 시간이 남습니다.

처음에는 스크럼 마스터로서 화가 났지만, 이상한 것처럼 보였습니다. 개발자가 실제로 견적에 시간을 추가하는 것을 싫어하기 때문에 견적을 내리는 매우 자연스러운 방법입니다. 번 다운을 여전히 유용하게 만드는 것은 평균이며, 그것이 중요합니다.

남은 작업 시간은 중요하지 않습니다. 전체 스토리가 완료 될 때까지 아무것도 전달할 수 없습니다.

사람들이 작업에 남은 시간을 채우도록하여 스토리 (전체)에 남은 시간을 추적하려면 한 사람당 작업을 분할하십시오.

그것은 말했다 :

• 큰 과제는 당신의 이야기가 너무 크다는 표시 일 수 있습니다. 이 경우 가장 좋은 해결책은 스토리의 범위와 크기를 줄이는 것이며,이를 줄이면 작업에서 남은 시간을 더 이상 추적하는 것이 더 이상 중요하지 않습니다 (완료 또는 불완전한 작업에 대한 추정의 합) 세분화됩니다).
• 스크럼은 모든 사람이 필요한 일을하도록 장려합니다. 역할이 아닌 사람에게 작업을 할당하는 경우 QA에 병목 현상이 발생하여 개발자가 아무 것도하지 않아도 스토리를 제공하지 못하게 될 수 있습니다.

작업을 여러 작업으로 나누고 서로 다른 사람이 처리하는 작업으로 입력하십시오.

원래 작업 : 문제 해결

새 작업 : (원래 작업의 부모 자식)

• 개발자 A-문제 해결
• 개발자 B-문제를 해결하는 데 개발자 A 지원 (예 : 페어 프로그래밍, 코드 검토)
• 개발자 A-Dataset X를 사용하여 수정 사항을 테스트하는 개발자
• 개발자 B-데이터 세트 Y를 사용하여 수정 사항을 테스트하는 개발자