나는 4 명의 개발자로 구성된 프로젝트 팀에 소속되어 있습니다. 단일 작업 항목에서 발생하는 추가 작업을 처리하는 방법에 대해 오랫동안 논의 해 왔습니다.
이 추가 작업은 일반적으로 작업과 약간 관련이 있지만 항목의 목표를 달성하는 데 항상 필요한 것은 아닙니다 (의견 일 수 있음). 예를 들면 다음과 같습니다.
- 작업 항목에 의해 변경된 코드 리팩토링
- 아이템에 의해 변경된 코드에 인접한 리팩토링 코드
- 티켓 주변의 더 큰 코드 영역을 재구성합니다. 예를 들어 항목에 단일 기능을 변경 한 경우이 변경 사항을보다 잘 수용하기 위해 전체 클래스를 다시 실행할 수 있습니다.
- 방금 수정 한 양식에서 UI 개선
이 추가 작업이 작을 때 우리는 상관하지 않습니다. 문제는이 추가 작업으로 인해 원래 기능 포인트 추정치보다 항목이 크게 확장되는 것입니다. 때로는 5 포인트 항목이 실제로 13 포인트가 걸립니다. 하나의 경우에 우리는 소급하여 80 점 이상일 수있는 13 점 항목을 가졌습니다.
이 문제를 다루는 방법에 대해서는 두 가지 옵션이 있습니다.
동일한 작업 항목에서 추가 작업을 승인하고이를 잘못된 추정치로 작성할 수 있습니다. 이에 대한 주장은 다음과 같습니다.
- 우리는 이런 종류의 것을 설명하기 위해 스프린트의 끝에 "패딩"을 계획합니다.
- 코드는 항상 찾은 것보다 나은 모양으로 유지하십시오. 반값 작업을 확인하지 마십시오.
- 나중에 리팩토링을 그대로두면 예약하기가 어려워 결코 완료되지 않을 수 있습니다.
- 당신은 이미 코드의 깊이에 허리를 가지고 있기 때문에 당신은 지금이 작업을 처리하기 위해 가장 정신적 "컨텍스트"에 있습니다. 나중에 돌아와서 상황을 잃어 버리는 것보다 효율적으로하는 것이 좋습니다.
현재 작업 항목에 대한 선을 그리고 추가 작업이 별도의 티켓에 들어간다고 말합니다. 인수는 다음과 같습니다.
- 별도의 티켓을 소지하면 새로운 견적이 가능해 지므로 실제 포인트 수에 대해 거짓말을하거나 모든 견적이 끔찍하다는 사실을 인정하지 않아도됩니다.
- 스프린트 "패딩"은 티켓 요구 사항을 완료하는 데 직접적인 장애가되는 예상치 못한 기술적 과제를위한 것입니다. 단지 "좋아하기"좋은 부가 품목을위한 것이 아닙니다.
- 리팩토링을 예약하려면 백 로그 상단에 배치하십시오.
- 우리가 추정 할 때 이러한 것들을 올바르게 설명 할 수있는 방법은 없습니다. 코드 검토자는 "이 작업 항목에서 실제로 수정하지 않은 UI 컨트롤은 약간 혼동됩니다.이를 해결할 수 있습니까?" "이 컨트롤이 다른 컨트롤과 동일한 기본 클래스에서 상속된다면이 수백 줄의 코드를 모두 기본으로 옮기고이 모든 것을 다시 연결하지 않겠습니까?" , 계단식 변경 등? " 그리고 일주일이 걸립니다.
- 티켓에 관련없는 작업을 추가하여 "범죄 현장을 오염시킨다"고 원래의 특징점을 무의미하게 만듭니다.
- 경우에 따라 추가 작업으로 인해 체크인이 연기되어 개발자간에 차단이 발생합니다.
우리 중 일부는 이제 추가 물건이 2 FP 미만인 경우 같은 티켓에 들어가고 더 많은 경우 새로운 티켓으로 만들 수 있습니다.
우리는 몇 달만에 Agile을 사용하기 때문에이 문제를 처리하는 방법에 대한 모든 노련한 Agile 재향 군인의 의견은 무엇입니까?