버그는 기술 부채의 일부입니까?

Scrum Master는 버그를 기술 부채라고 부릅니다. 그가 맞습니까? 버그는 Agile 세계에서 기술적 부채로 간주됩니까?

여기에 대한 대답은 매우 간단하다고 생각합니다. 기술적 부채의 주요 특징은 우리가 선택함으로써 발생하는 것입니다.

우리는 특정 목표를 더 빨리 달성하기 위해 나중에 문제를 일으킬 것으로 예상되는 건축, 설계 또는 구현 결정을 내리기로 선택합니다.

버그는 코드에서 우리가 선택한 것이 아니기 때문에 사실상 기술적 부채가 아닙니다.

물론 발견 후 발견에 대한 선택에 관한 모든 종류의 흥미로운 (그리고 아마도 유효한) 주장을 할 수는 있지만 근본적으로 (특히 문제의 맥락에서) 아닙니다. 버그는 기술적 부채가 아닙니다. 버즈 워드 빙고를 남용하는 것처럼 들립니다.

포스트 스크립트로서-나는 기술 부채가 주어진 선택의 본질에 대해 많은 가정을 할 정도로 버그로 이어질 것이라는 주장에 동의하지 않습니다. 예를 들어, 조기 제공을 위해 구조적 손상을 야기하는 잘 작성되고 체계적으로 테스트 된 코드 적용 코드를 가질 수 있습니다. 마찬가지로 배포 프로세스를 자동화하지 않고 버그를 유발하지는 않지만 많은 스트레스와 고통을 초래할 수 있습니다. 물론 부채가 당신이 SOLID (또는 무엇이든)가 아닌 코드를 작성했다는 것이라면 그렇습니다 ... 그러나 항상 그런 것은 아닙니다.

예.

기술 부채 (디자인 부채 또는 코드 부채라고도 함)는 코드베이스 내에서 열악한 소프트웨어 아키텍처 및 소프트웨어 개발의 결과에 대한 신학 적 은유입니다.

출처 : Wikipedia

더 나은 작업 흐름 (예 : 코딩으로 이동하기 전에 아키텍처를 올바르게 수행, TDD 등), 더 나은 코딩 방법 등을 통해 기술 부채를 피할 수있는 것으로 읽습니다.

추가 검토 또는보다 공식적인 방법을 사용하면 대부분의 버그를 피할 수있었습니다. 처음에는 버그를 갖지 않기 위해 할 수있는 모든 것을하지 않음으로써 프로젝트의 즉각적 / 단기 비용을 낮추고 기술 부채를 증가시킵니다.

BЈовић의 답변을 읽은 후에 생각보다 쉽지 않을 수 있습니다.

• 예를 들어 버그는 기술 부채의 일부입니까? 기사는 당신이 알고 있지만 수정하지 않기로 결정한 버그는 기술 부채의 일부라고 주장합니다.

• 또 다른 예로, 기술 부채에 대한 Christopher의 생각은 버그가 아닌 기술 부채 의 결과 로 버그를 검증 합니다. "새 기능 구현 비용"과 같은 나열된 결과 중 많은 수는 버그 수의 영향을받습니다.

• 마지막으로 ABCDE-T 기술 부채 모델을 만들 때 버그를 6 가지 요소 중 하나로 포함 시켰지만 다르게 고려됩니다. 버그 자체가 아니라 버그의 수집, 우선 순위 결정 및 해결 방법에 중점을 둡니다. 버그 자체는 기술 부채의 결과로 표시되지만 (이전 예와 같이) 기술적 부채의 요소로 표시되지는 않습니다.

이 말은 여전히 버그 (모든 버그)가 기술적 부채의 일부라고 대답하고있다.

첫 번째 주장 :

Jeff Atwood의 인용문을 읽으면 대부분의 버그는 다음과 같습니다.

빠르고 더러운 설계 선택으로 인해 향후 개발에서해야 할 추가 노력

비즈니스 응용 프로그램에서 거의 모든 버그는 빠르고 더러운 설계 선택 또는 나쁜 관행 (테스트 부족, 개발자가 알지 못하는 기술 사용, 통신 부족, 도메인 이해 부족, 이는 "빠르고 더러운 디자인을 더 나은 디자인으로 리팩토링하고" 더 나은 사례를 적용함으로써 대부분의 버그를 해결할 수 있음을 의미합니다.

두 번째 주장 :

회사를 다른 회사에 매각 할 때 고려해야하는 회사의 일반 부채와 프로젝트를 다른 회사에 매각하거나 부여 할 때 고려해야하는 기술 부채 사이에서 유사성을 만드는 경우 다른 팀에게는 버그가 기술 부채의 일부라는 것을 쉽게 알 수 있습니다.

• 새로운 기능을 만들기 전에 이러한 버그를 해결해야합니다 (Joel Test의 포인트 5 : 새 코드를 작성하기 전에 버그를 수정 하시겠습니까?)

• 또는 버그를 유지하면서 기술 부채를 유지 / 증가시킵니다.

Jeff Atwood는 자신 의 기술 부채 지불 에 대한 기술 부채가 무엇인지에 대한 훌륭한 답변을 제공합니다.

기술 부채는이자 지불을 초래하는데, 이는 빠르고 더러운 설계 선택으로 인해 향후 개발에서해야 할 추가 노력의 형태로 발생합니다. 우리는 계속해서이자를 지불하도록 선택할 수도 있고, 빠르고 더러운 디자인을 더 나은 디자인으로 리팩토링하여 교장을 지불 할 수도 있습니다. 교장을 상환하는 데는 비용이 들지만, 향후이자 지급을 줄이면 얻을 수 있습니다.

엄밀히 말하면, 버그는 추가 소프트웨어 개발 속도를 늦추지 않으면 (기술 변경, 새로운 기능 추가 등) 기술적 부채의 일부가 아닙니다. 소프트웨어 결함입니다.

그러나 버그를 수정하기에는 비용이 너무 비싸거나 문제를 해결해야하고 (기술적 부채가 더 많이 발생할 경우) 기술적 부채의 일부가됩니다.

버그는 기술 부채가 아닙니다. 기술 부채는 품질의 부재가 아니라 품질에있어 크게 위축되고 있습니다. 소프트웨어에 버그가있는 상태로 제공해서는 안됩니다. 알다시피, 전체적인 소프트웨어가 포괄적 인 문서화에 관한 것입니다.

기술 부채의 가장 큰 범죄자는 "임시 버그 수정"입니다. 테스트를 통과하고 이야기를 받아 들일 수있는 것들을 알고 있습니다. 이러한 임시 수정, 패치 및 기타 사항이 누적됨에 따라 코드가 불필요하게 복잡해지고 업데이트 및 테스트하기가 어려워지며 일반적으로 악몽이지만 여전히 작동합니다.

이 의견을 뒷받침하기 위해 나는 출처 Cwardham으로 바로 갔다. 이것에 관해서, Ward는 Capers Jones와 잠시 동안 좋은 인터뷰를했습니다. 시계 가치가 있습니다.

Ward Cunningham & Capers Jones와의 기술 부채 토론

읽을 가치가있는 또 다른 기사는 Martin Fowler의 글입니다.

기술 부채에 대한 마틴 파울러

Martin의 기사에서 OOPSLA92에서 Ward Cunningham의 기술 부채에 대한 원래 언급에 대한 링크를 찾으십시오.

WyCash 포트폴리오 관리 시스템

위 기사에서 인용 한 내용 :

미성숙 한 코드는 잘 작동하고 고객이 완전히 수용 할 수 있지만 초과 수량은 프로그램을 마스터 할 수 없게하여 프로그래머를 극도로 전문화하고 결국에는 유연성이없는 제품을 만듭니다. 최초 코드 선적은 빚을지는 것과 같습니다.

결국 기술 부채는 일부 사람들에게 버그를 포함하게되었을 수도 있습니다. 나는 그것이 원래 의도라고 생각하지 않습니다.

엄밀히 말하면, 귀하의 질문에 대한 대답은 아니오입니다.

기술 부채 (그리고 아마도 것) 버그로 이어질하지만, 어떤 버그가 기술 부채의 결과가 두 가지 사실 사이의 해석을 가하고 있다고 판단 할 수 있습니다 버그가있다 및 기술 채무있다 (사실로 결론 지을 수있는 가정이).

스크럼 마스터가 버그가 기술 부채의 결과라는 이론으로 '이론적'이라고 말하면 모서리를 깎고 있습니다. 그가 계속 다시 나타나는 특정 버그에 대해이 말을한다면 그는 옳을지도 모릅니다. 여기서 코드 품질을 볼 수는 없습니다 ;-)

그는 또한 기술 부채에 대해 사람들이 자신의 말을 듣지 않아서 모든 버그를 기술 부채라고 표시하는 것에 대해 지속적으로 불만을 제기 할 수 있지만 지금은 추측하고 있습니다.

제 생각에는 버그가 기술 부채의 일부인지 아닌지는 중요하지 않습니다.

일반 사실은 기존의 버그가 추가 작업을 나타낼 것입니다 수 있습니다 그들을하거나 해결하려면를 수정하거나, 미래에 수행해야합니다.

(라벨은 일반적으로 사용되는) 기술 부채는 추가 작업 나타낸다 수 있습니다 미래 ... 하나의 방식 으로든 수행해야합니다.

따라서 알려진 버그 (또는 알려지지 않은) 버그가 기술 부채라고하는지 여부는 실제로 정의의 문제입니다. "기술 부채"에 대한 권위있는 정의 ¹ 이 없기 때문에 전체 토론은 무의미합니다.

Lewis Carroll이 쓴 것처럼 :

험티 덤프 티 (Humpty Dumpty)는 끔찍한 말로 '단어를 사용할 때 내가 선택한 단어를 의미하는 것, 즉 더 많거나 적지 않다'고 말했다. .

실제로 자연어가 작동하는 방식입니다. 단어는 사람들이 생각하는 것을 의미합니다. 사전 정의 등 은 단어가 사용되는 방식을 문서화 할 뿐 정확한 문서 일 필요는 없습니다. 만약 당신의 스크럼 마스터가 알려진 버그를 기술 부채라고 언급하고 싶다면, 누가 자신이 "잘못되었다"고 말해야합니까?

^{1-Ward Cummingham 및 Caper Jones와 같은 인용문도 도움이되지 않습니다. 기껏해야이 구절을 사용 (사용) 할 때의 의미 (또는 의미)를 알려줍니다. 그들은 문구를 "소유"하지 않습니다. 의심 할 여지없이 이러한 문제에 대한 권위자이지만, 이것은 여전히 ​​그들의 의견 일뿐입니다.}