번역: 정서 (슈어소프트테크  SW시험자동화연구소 선임)

원문: http://accelerateddevelopment.blogspot.ca/2013/10/its-not-bug-its.html

작성일 : 2013년 10월 23일

번역일 : 2014년 2월 25일

역주: 시스템 개발 시 요구사항 분석의 중요성에 대해 다시 말하는 글입니다. 요구사항을 잘 정의하지 않고 개발된 시스템에 많은 결점이 발생될 수 있고 이를 처리하는데 많은 자원이 투입되거나 최악의 경우 개발된 시스템의 설계를 바꾸기까지 해야 합니다. 대다수의 조직이 요구사항 분석 단계에 많은 자원을 투자하지 않는데 이를 꼬집고 있습니다.

"버그"가 언제 버그가 될까요? 누가 어떤 결점이 버그인지 결정할까요?

만약 내가 "양의 꼬리"도 "다리"라고 한다면 양의 다리 수는 몇개일까요? 정답은 4개입니다. 제가 양의 꼬리가 다리라고 말한다고 실제 양의 꼬리가 다리가 되는 것은 아니니까요!

버그도 마찬가지여야 하지만 우린 "이건 버그가 아니고 특징이야" 라고 합니다. 왜냐면 때로 이것이 명확하지 않기 때문이죠. Watson Humphrey는 "버그" 라는 용어 대신 "결점(defect)" 이라는 용어를 사용해야 한다고 합니다. 왜냐면 보통 사람들은 버그를 심각하게 생각하지 않거든요. 그러니까 앞으로는 결점이라는 용어를 사용하도록 합시다.

그렇다면 언제 이런 "결점"이 결점이 될까요?

• QA(Quality Assurance)가 이것이 결점이라고 할 때?
• PM(Product Management)이 이것이 결점이라고 할 때?
• 고객이 결점이라고 할 때?

위 중 어느것도 정답이 아닙니다. 위의 경우들은 이제 문제점이 밝혀졌고 해당 코드가 변경되어야 함을 의미합니다. 하지만 결점은 코드가 요구사항 명세와 다르게 동작하는 경우를 말합니다.

이것은 중요합니다. 왜냐하면 대다수의 시스템들이 요구사항 명세를 충족시키기 때문입니다. 어떤 코드가 명세와 다르게 동작할 때만 결점으로 간주될 수 있습니다. 우리는 해당 문제가 어떤한 요구사항도 정의되지 않았기 때문이라는 것을 알기 때문에 이런 결점을 "문서화되지 않은 기능" 이라 부릅니다.

불완전하고 일관성없는 요구사항들

많은 조직들이 개발을 시작하기 전에 충분히 완벽한 요구사항을 만들지 않습니다. 요구사항을 어떻게 추출해야 하는지 모르거나 완벽한 요구사항을 추출할 자원이 부족하기 때문이죠.

불완전한(그리고 일관성 없는) 요구사항과 비현실적인 마감시한은 종종 개발자가 각 기능들을 어떻게 구현해야 할지 결정하게 만듭니다. 이러한 결과로 개발자들이 지속적으로 "너희 코드에 결점이 있어"라는 말을 듣게 됩니다.

만약 이러한 과정들이 일반적이라면 이는 재앙적일것입니다. 완벽히 추출되지 않은 요구사항과 일관성 없는 개발자의 조합은 매우 심각한 재작업을 하게 합니다. 이러한 재작업은 코드의 설계를 뒤흔드는 매우 큰 변화를 필요로 할 수 있습니다.

프로젝트 계획에 다각도에서 생각을 해 볼 수 있는 시간을 책정하는 경우는 매우 드뭅니다. 일을 어렵게 만드는 또 다른 점은 요구사항을 추출하는 시간을 꺼리는 조직은 그들의 프로젝트를 과소평가하는 경향이 있다는 것입니다. 이는 결국 개발 그룹이 제품을 출시하는 데에 엄청난 압력을 행사합니다; 이는 소프트웨어 개발의 5대 악습을 조장하게 됩니다. (Stop It! No… really stop it.)

엉성하게 만들어졌거나 문서화되지 않은 시스템 요구사항들에 명시되지 않은 변화가 생기는 것은 결점이 아닌 "요구사항 변경"이라 합니다.

오직 54%의 이슈들만이 Engineer에 의해 해결됩니다.

이 관점에서 볼 때 모든 결점들이 engineering 부서에서 처리되어야 한다는 생각은 심각하게 잘못되었습니다. Capers Jones이 18,000개가 넘는 프로젝트에 대해 조사한 결과 오직 54%의 이슈들만이 engineer들에 의해 해결되었습니다!(색칠된 부분)

이는 해결할 수 없는 문제들이 개발자에게 할당되어 귀중한 시간이 버려진다는 것을 의미합니다. 이슈를 처리하는데 드는 대부분의 시간이 이러한 이슈를 적절한 담당자에게 돌려주는 데 들게 됩니다.

결점 처리 과정 제어하기

대부분의 조직들에게 결점 처리 과정을 수정하는 것은 결점들을 제대로 이해하고 분류하는 작업을 포함합니다. 결점들이 보고되는 곳을 추적하지 않는 조직은 엄청나게 복잡한 버그 추적기를 가지고 있을 것입니다. 여기에 이 문제를 해결할 수 있는 방법이 있습니다. Bug Tracker Hell and How To Get Out! 

최소한 당신은 필요한 요구사항의 결함들을 구현해야 하고, 완벽하지 못했던 요구사항 명세 때문에 발생된 이슈들을 식별한다면 요구사항을 식별하기 위해 필요한 자원들이 밝혀지게 될 것입니다.

당신의 시스템에 얼마나 많은 요구사항 결점들이 존재하는지 알게 된 후에 당신의 상사에게 요구사항 명세의 문제에 대해 말할 수 있습니다.

이슈 처리(화재 진화) 줄이기

이슈 처리를 줄이는 가장 좋은 방법은 더 좋은 요구사항 명세를 작성하는 것입니다. 그렇게 하기 위해 당신은 아래 중 어떤 것이 고장난 것인지 찾아내는 것이 필요합니다.

1. 요구사항 추출 단계에 할당된 시간이 충분하지 않음
2. 당신의 요구사항을 추출하는 작업을 맡은 사람들의 경력이 부족함

모든 경우에서 이 두 이슈들은 해결되어야 합니다. 만약 요구사항이 불완전하고 일관되지 않다면 당신은 전 사원과 함께 끝없이 이슈 처리(화재 진화) 회의를 하게 될 것입니다.  Root cause of 'Fire-Fighting' in Software Projects

요구사항 명세 문서가 없는 상황에서 어떤 사람이 당신에게 당신이 결점이 있는 코드를 만들었다고 했을 때 당당하십시오!