Pivotal Tracker 보드에 기술적 부채를 해결하는 몇 가지 사용자 사례를 추가했습니다. 기능 (속도 수준 유지) 또는 집안일 / 버그 (속도 감소)로 고려해야합니까? 나는 하나 또는 다른 하나를 일관되게 수행하면 장기적으로 아무런 차이가 없다는 것을 이해하지만 기술 부채 이야기를 추가 할 때마다 결정을 내려야합니다.

몇 가지 생각 :

• 그들은 실제로 버그가 아니며 아무것도 깨지 않습니다.
• 사용자는 영향을 미치지 않는 저수준 구현이므로 아무것도 요청하지 않았지만 장기 개발이 더 쉬워집니다.
• 당신이 잘 사용자에게 가치를 이야기 등의 기능을 정의하는 경우가)가 사용자가 그들이 직접적인 혜택을하지만, 다음에 b)를 참조하지 않습니다하지 않는 한 그들은 어떤 가능한 미래의 개발 / 유지 보수를하기 때문에 않는 추가 값을, 지금은 안돼

나는 실제로 작업을 수행할지 여부를 결정하지 않고 프로젝트 관리 도구에서 기술 부채라고 부르는 것과 그 이유를 알아야합니다.

기능입니다.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

다른 기능과 마찬가지로 정의 및 예약 및 추적됩니다.

이 기능을 구현하는 것이 예약되기에 (고객 또는 귀하에게) 충분히 가치가 없다면, 그것은 다른 문제입니다.

고객이 이에 대해 결정을 내릴 자격이 없기 때문에 기술 부채는 기능 이 아닙니다 . 가장 중요한 것은 고객이 완료 시점을 결정할 수 없으며, 추가로 고객은 귀하의 이익에 대해 전적으로 의지합니다. 기술 부채가있는 것은 귀하의 판단이며,이를 해결하는 방법과 완료 시점을 결정하는 것은 귀하의 책임입니다. 기술 부채는 고객의 소프트웨어 인식이 아닌 (미래) 속도에 영향을 미칩니다. 부채가 없으면 생산성이 높아집니다. 그리고 코드의 모양을 유지하는 데 더 많은 시간이 걸리기 때문에 지금까지 측정 한 속도가 잘못되었습니다.

나는 당신이 이것을 당신의 고객과 의사 소통해야한다고 생각하지만, 그것은 그들의 통제에있는 것이 아닙니다. 당신은 다음과 같이 말할 수 있습니다 : '우리는 지금까지 몇 가지 지름길을 가졌습니다. 이것은 다음 몇 번의 반복에서 속도가 약간 떨어질 것이라는 것을 의미하지만, 장기적으로 유지 보수 가능한 소프트웨어를 확보하기위한 것입니다. '

고객의 기능에 대한 지속적인 작업은 또한 완벽한 디자인을 찾기위한 일종의 학문적 운동이 아닌 클라이언트를위한 소프트웨어 개선에 계속 집중하는 데 도움이 될 것입니다.

기술적 부채를 제거하는 임무는 분명히 기능이 아닙니다. "버그"부서에 삽입 될 수 있지만, 사용자가 관찰 할 수있는 동작 변경을 초래하지 않기 때문에 용어 정의를 확장 할 수 있습니다.

나는 그것을 유지 보수 작업이라고 부릅니다. 개발 프로젝트에는 개발 / 테스트 환경 설정, 테스트 데이터 어셈블, SCM의 브랜치 병합 등과 같은 많은 작업이 있습니다. 사용자가 직접 확인할 수는 없지만 정기적으로 수행하지 않으면 개발이 증가합니다. 장기적으로 비용과 버그 비율.

비록 그것들이 거대하거나 현재 새로운 기능을 구현할 압력이 없다면, 그것들을 별도의 작업으로 처리 할 필요는 없습니다. 일반적으로 새로운 기능이 리팩토링 / 작성 단위 테스트 등을 필요로하는시기를 식별하고이를 새로운 기능 개발의 일부로 처리하는 것이 좋습니다. 관리 사용자와 최종 사용자 모두에게 설명하기가 더 쉬울 수 있습니다. 업데이트 : 또한 개발자가 리팩토링의 가치에 집중할 수 있도록 도와줍니다. 리팩토링을 위해 리팩토링을 쉽게 수행 할 수 있으므로 특정 리팩토링이 고객의 관점에서 가져 오는 부가 가치에 초점을 맞추는 것이 IMHO 유용합니다.

나는 그것을이라고 부를 것이다 improvement.

아무것도 깨지지 않았기 때문에 버그가 아닙니다.

리팩토링이 클라이언트의 요청이 아니기 때문에 기능도 아닙니다. (작동하기 때문에!).

대부분의 추적 시스템 improvement은 기본적으로 이슈 유형 을 지원 하지만 그렇지 않은 경우 유형을 변경할 수 있습니다.