단일 민첩한 작업 항목 내에서 "관련"작업 처리


12

나는 4 명의 개발자로 구성된 프로젝트 팀에 소속되어 있습니다. 단일 작업 항목에서 발생하는 추가 작업을 처리하는 방법에 대해 오랫동안 논의 해 왔습니다.

이 추가 작업은 일반적으로 작업과 약간 관련이 있지만 항목의 목표를 달성하는 데 항상 필요한 것은 아닙니다 (의견 일 수 있음). 예를 들면 다음과 같습니다.

  • 작업 항목에 의해 변경된 코드 리팩토링
  • 아이템에 의해 변경된 코드에 인접한 리팩토링 코드
  • 티켓 주변의 더 큰 코드 영역을 재구성합니다. 예를 들어 항목에 단일 기능을 변경 한 경우이 변경 사항을보다 잘 수용하기 위해 전체 클래스를 다시 실행할 수 있습니다.
  • 방금 수정 한 양식에서 UI 개선

이 추가 작업이 작을 때 우리는 상관하지 않습니다. 문제는이 추가 작업으로 인해 원래 기능 포인트 추정치보다 항목이 크게 확장되는 것입니다. 때로는 5 포인트 항목이 실제로 13 포인트가 걸립니다. 하나의 경우에 우리는 소급하여 80 점 이상일 수있는 13 점 항목을 가졌습니다.

이 문제를 다루는 방법에 대해서는 두 가지 옵션이 있습니다.

  1. 동일한 작업 항목에서 추가 작업을 승인하고이를 잘못된 추정치로 작성할 수 있습니다. 이에 대한 주장은 다음과 같습니다.

    • 우리는 이런 종류의 것을 설명하기 위해 스프린트의 끝에 "패딩"을 계획합니다.
    • 코드는 항상 찾은 것보다 나은 모양으로 유지하십시오. 반값 작업을 확인하지 마십시오.
    • 나중에 리팩토링을 그대로두면 예약하기가 어려워 결코 완료되지 않을 수 있습니다.
    • 당신은 이미 코드의 깊이에 허리를 가지고 있기 때문에 당신은 지금이 작업을 처리하기 위해 가장 정신적 "컨텍스트"에 있습니다. 나중에 돌아와서 상황을 잃어 버리는 것보다 효율적으로하는 것이 좋습니다.
  2. 현재 작업 항목에 대한 선을 그리고 추가 작업이 별도의 티켓에 들어간다고 말합니다. 인수는 다음과 같습니다.

    • 별도의 티켓을 소지하면 새로운 견적이 가능해 지므로 실제 포인트 수에 대해 거짓말을하거나 모든 견적이 끔찍하다는 사실을 인정하지 않아도됩니다.
    • 스프린트 "패딩"은 티켓 요구 사항을 완료하는 데 직접적인 장애가되는 예상치 못한 기술적 과제를위한 것입니다. 단지 "좋아하기"좋은 부가 품목을위한 것이 아닙니다.
    • 리팩토링을 예약하려면 백 로그 상단에 배치하십시오.
    • 우리가 추정 할 때 이러한 것들을 올바르게 설명 할 수있는 방법은 없습니다. 코드 검토자는 "이 작업 항목에서 실제로 수정하지 않은 UI 컨트롤은 약간 혼동됩니다.이를 해결할 수 있습니까?" "이 컨트롤이 다른 컨트롤과 동일한 기본 클래스에서 상속된다면이 수백 줄의 코드를 모두 기본으로 옮기고이 모든 것을 다시 연결하지 않겠습니까?" , 계단식 변경 등? " 그리고 일주일이 걸립니다.
    • 티켓에 관련없는 작업을 추가하여 "범죄 현장을 오염시킨다"고 원래의 특징점을 무의미하게 만듭니다.
    • 경우에 따라 추가 작업으로 인해 체크인이 연기되어 개발자간에 차단이 발생합니다.

우리 중 일부는 이제 추가 물건이 2 FP 미만인 경우 같은 티켓에 들어가고 더 많은 경우 새로운 티켓으로 만들 수 있습니다.

우리는 몇 달만에 Agile을 사용하기 때문에이 문제를 처리하는 방법에 대한 모든 노련한 Agile 재향 군인의 의견은 무엇입니까?

답변:


5

민첩한 계획 및 사용자 사례는 프로젝트 이해 관계자와 소프트웨어 사용자에게 가치와 투명성을 제공하는 데 중점을 둡니다. 이것은 좋은 일이지만 좋은 건축 지침, 디자인 관리, 훌륭한 개발 관행 및 기술적 부채 유지의 중요성을 대체하거나 포함해서는 안됩니다.

애자일은 이러한 기술적 인 문제와 문제에 대한 해답이 아니기 때문에 후자를 잘 수행하지 못합니다.

리팩토링 작업, 기술 부채 처리 및 디자인 작업이 주어진 스프린트에서 별도의 사용자 스토리를 설명해야한다는 것에 매우 동의하지 않습니다. 이는 스프린트에 대한 사용자 스토리를 충족시키기 위해 개발자가 수행 할 수있는 작업 일뿐입니다.

작업은 아키텍처 지침 내에서 주어진 사용자 스토리를 완성으로 옮기고 소프트웨어 전체의 우수한 설계 및 개발 방식을 유지 하는 데 도움이되는 할당 가능한 작업 단위입니다 .

그렇기 때문에 시간 측정은 사용자 스토리가 아닌 작업에 대한 것이어야합니다. 여러 사용자 스토리를 완료하는 데 일부 작업이 중요한 이유이기도합니다.


4

빨강, 녹색, 리 팩터. 이것이 단일 작업 항목의 범위입니다. 변경 범위를 다루는 실패한 테스트 스위트를 작성하고 테스트를 통과하는 데 필요한 최소량을 코딩 한 다음 테스트를 통과하면서 코딩 표준을 충족하도록 리팩토링하십시오. 이 세 단계 모두가 필요합니다. 코드 라인을 작성할 때 리팩토링하면 YAGNI를 항상 위반하게되지만 테스트를 통과 한 후 리팩토링하지 않으면 정의상 기술 부채가 발생합니다. 결국 당신은 상환해야합니다.

이 정의와 그에 따라 13- 포인터로 밝혀진 5- 포인터는 잘못 추정되었습니다. 리팩토링 작업을 고려하는 것은 아마도 구조 조정과 비슷했을 것입니다. 새로운 기능이 이해 가능하고 유지 보수 가능한 방식으로 포함 되려면 코드베이스의 상당히 중요한 영역을 재구성해야했습니다. 이는 일반적으로 팀이 일반적인 미래 개발 경로를 이해하지 못했음을 나타내며 이전 반복에서 매우 SOLID 여야 할 경우 매우 간단하게 구현됩니다. 백 로그에서 더 많은 정보를 알고있는 BA와 PM 사이의 더 나은 의사 소통과 현재 스프린트에 중점을 둔 개발 팀이이를 완화 할 수 있습니다. 또는이 이야기는 과거의 개발에서 발생한 많은 양의 기술적 부채를 노출 시켰습니다. 단순히 팀을 따라 잡았습니다. 더 나은 코드 검토 프로세스는 디자인 패턴과 프로젝트의 일반적인 미래 경로에 대한 더 나은 개념 지식뿐만 아니라 그러한 발생을 줄이는 데 도움이 될 수 있습니다.

리팩토링은 "비 이상적인"작업이라는 점을 명심해야합니다. Agile SCRUM에서 작업은 "이상적인 시간"으로 추정됩니다. 즉, 존재하지 않는 새로운 코드를 작성하고 프로젝트의 기능 기반을 발전시키는 데 소요되는 시간입니다. 8 시간의 개발자 하루는 실제로 5 시간의 이상적인 시간 만 가질 수 있습니다. 때로는 6 명, 특히 팀이 실제로 흥얼 거리는 프로젝트의 "스트레치"에서 의지 할 수 있습니다. 프로젝트의 기능에는 영향을 미치지 않지만 다른 방식으로 코드베이스를 개선하는 리팩토링 또는 되돌아 가서 변경하는 것은 계획, 설계, 커뮤니케이션, 검토, 중단 또는 기술 중단 시간과 같은 비 이상적인 작업입니다. 기술적 인 다운 타임 이외의 비 이상적인 작업이 중요하지만 제품 소유자의 눈에는 진전이 없습니다.

따라서 리팩토링이 실제 소요 시간을 두 배로 늘리지 않으면 이상적인 시간을 추정 할 때 일정량의 리팩토링 작업이 예상됩니다. 팀의 포인트 스케일이 어떻게 교정되는지 정확히 알지 못하기 때문에 5 포인터는 이상적인 개발자 주 또는 25 시간 이상에 해당합니다. 13 (동일한 규모로 2 주 이상의 개발자 주)이 된 5는 복잡한 문제를 일으킨 원인에 대한 회고의 원인입니다. 아마도 코드베이스에는 실제로 수행 된 것보다 많은 리팩토링이 필요하지 않았을 것입니다. 아마도 새로운 기능을 작동시키기 위해 해결해야 할 팀에게 알려지지 않은 많은 기술 부채가 쌓였을 것입니다.

대체 우주에서 이상적인 코드로 추정 한 5가 실제 시간을 기준으로 7 (~ 35 시간)이되었다고 상상해 봅시다. 새 코드와 일부 이전 비트를 올바르게 패턴 화하기 위해 10 시간의 추가 리팩토링이 필요했기 때문입니다. 디자인 아키텍처. 이 경우, 추가 내용은 개발자 소요일 동안 이상적인 시간과 총 시간 사이의 "간격"내에 있습니다. 그래서 프로젝트 관리자로서 5를 7로 합리적으로 추정하고 합리적으로 평가했습니다.


좋아, 무언가 기술적 인 것이기 때문에 관련이없는 것처럼 보일지라도, 그것은 별도의 항목이 아니며, 특히 사용자의 눈에는 별도의 기능이 아니기 때문입니다. 기술 부채 만 지불하면됩니다.
Tesserex

스토리가있는 작업 항목을 완료하기 위해 일부 작업을 수행해야하는 경우, 단독으로 수행해도 최종 사용자에게 동작 변경이 발생하지 않으면 해당 작업은 일반적으로 기술 부채를 상환합니다. 때로는 비 기능적 요구 사항이 충족되는 것으로 간주 할 수 있지만, 비 기능적 요구 사항은 항상 주관적 일 수 있으므로 증명하기 어려우므로 애자일에서 항상 끈적 거리는 지점입니다.
KeithS

1

스토리 포인트는 주어진 사용자 스토리의 상대적 복잡성을 추정 한 것입니다. 이야기 포인트를 사용하여 X 사람 일 / 시간이 걸리는 것처럼 들립니다. 대신 두 가지 목표를 위해 노력하십시오

  1. 일관된 범위 (3, 5 또는 8 점)에 도달 할 때까지 스토리를 분류합니다.
  2. 스토리에 필요한 리팩토링이 포함되어 있다고 가정

시간이 지남에 따라 속도의 기준이됩니다. 모든 5 포인트 스토리는 다른 포인트와 동일한 시간이 걸리지 않지만 스프린트 당 평균 속도 (팀이 완료 할 수있는 스토리 포인트 수)는 일정합니다.

특정 이야기에 얼마나 많은 시간이 걸리는지 걱정하는 것은 비생산적입니다. 추정량은 일관된 규모의 스토리에 비해 평균치에 불과합니다 (IE 리팩터링으로 인해 하나의 포인터가 조금 더 오래 걸릴 수 있지만 관련 기사에서 그 노력의 이점을 얻습니다).


0

원래 작업 항목에 얼마가 있고 다른 것이 얼마나 많이 있는지 잘 려야합니다. 사용자 스토리는 토론의 출발점이므로 스토리를 진행하는 동안 스프린트 중에 모든 종류의 스코프 요소를 수정할 수 있습니다.

스프린트 계획에서 사용자가 새 양식을 원할 때 발생할 수있는 "스코프 크리프"를 피하기 위해 스토리에 추가 기준을 추가 할 수있는 경우가있을 수 있습니다. 때때로 2 주 스프린트에서 완료하십시오.

명심해야 할 단점은이 추가 작업에서 얻는 가치가 얼마라는 것입니다. 수행 할 수있는 리팩토링이 많이있을 수 있지만 모든 작업에 대해 어느 정도의 이점이 있습니까? 여기에는 팀이 잘 작동하도록 유지하는 데 도움이되는 몇 가지 지침이 있어야하지만 코드를 완벽하게 만들기 위해 길을 잃지 않아야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.