유지 보수에 소요되는 시간에 대한 업계 평균

최근 한 관리자는 버그 수정에 너무 많은 시간을 소비하고 있다고 발표했습니다. 그는 우리가 항상 완벽한 코드를 작성해야한다고 생각한다고 생각합니다 (물론 불가능한 마감일을 지키는 동안!) 새로운 코드를 작성하는 데 버그를 수정하는 데 걸린 평균 시간이 얼마인지 궁금해졌습니다.

그렇다면 새로운 코드 개발에 대한 버그 수정에 소요되는 시간에 대한 통계가 있습니까? 아니면 업계 전체의 버그 수정 시간에 대한 경험적 분석이 있습니까? 50 %가 버그 수정에 너무 많은 비용이 듭니까? 20 % 또는 33 %는 어떻습니까?

개인 경험에서 비롯된 일화적인 증거를 받아들이게되어 기쁩니다. 여기서 우리의 성과를 비교할 수있는 일부 통계의 일부가 될 것입니다.

최근 한 관리자는 버그 수정에 너무 많은 시간을 소비하고 있다고 발표했습니다.

위의 소리는 매우 무지합니다. 그런 경우에 대한 제안 읽기 : 소프트웨어 공학의 사실과 착오 로버트 L. 유리, 특히에 의해 ". 사실 43. 유지 보수 솔루션이 아니라이 문제"

Wikipedia 기사 에는 소프트웨어 유지 관리에 80 %의 노력이 들었다고 언급되어 있습니다.

내 관리자는 Dilbert의 PHB를 천재처럼 보이게 만듭니다. :)

Hm 위에서 주어진 모든 요청이 실제로 버그 인지 분석하는 데 약간의 노력을 기울입니다 .

내 경험상 개선 또는 새로운 기능에 대한 요청이 버그로 제출 된 것은 너무 흔했습니다. 훌륭한 관리자는 프로그래머가 나쁜 관리자를 찾는 데 관여합니다 . 버그를 수정 하는 데 너무 많은 시간을 계속해서 불평 합니다 .

"버그 수정"이 실제로 코딩 버그 나 다른 것을 수정하고 있는지 물어보아야합니다. 실제 코드 버그의 수정은 코드 기반이 좋은 한 대부분의 경우 비교적 작아야합니다. 열악한 코드 기반으로 작업하는 경우 광범위한 버그 수정이 불가피합니다.

그러나 프로그램을 프로덕션 환경에 넣는 과정에서 문서화되지 않은 요구 사항, 예기치 않은 사용자 활동, 데이터 이상, 하드웨어 비 호환성, 설치 문제 및 엄격하게 코드 버그가 아닌 기타 문제가 발견됩니다. 종종 관리자와 사용자는 이러한 프로덕션 지원 / 유지 보수 문제를 일반적으로 코드 변경이 필요하기 때문에 버그로 생각합니다.

또한 사소한 개선 요청이라고하는 것을 버그로 그룹화하는 관리자를 만났습니다. 이들은 종종 버그 추적 또는 문제보고 시스템에 입력되어 "버그"통계를 실제보다 높게 만들 수 있습니다.

그것은 얼마나 많은 코드가 있는지, 얼마나 오래 있었는지 등에 달려 있습니다.

소프트웨어에서 버그를 수정하는 데 소요 된 시간은 출시 첫 6-12 개월로 전면로드되어야하지만 시간이 무한대에 가까워 질수록 유지 관리에 소요되는 시간과 초기 개발에 소요되는 시간이 100 %를 초과합니다. 작업.

어려운 통계는 없지만 (Code Complete는하지만 어떤 페이지 / 섹션을 정확하게 말할 수는 없지만) 내 경험상 개발의 약 40 % (때로는 60 %)가 유지 보수에 소비됩니다. 더 많은 코드를 릴리스할수록 유지 보수 시간이 길어질 것입니다. 버그는 항상 작동하는 것은 아니며 프로그래밍 방식의 결함만큼이나 불확실성의 결과입니다.

좋은 티켓 추적기를 사용하고 (Atlasian의 Jira와 같은) 모든 다른 카테고리, 사용자 스토리, 긴급 성 수준을 정확하게 입력하고 팀 동료의 동의에 따라 시간을 보냈다면 실제로 이러한 메트릭을 계산하는 등 놀랍도록 쉽습니다.

이전 프로젝트에서는 Jira를 사용하여 버그 / 태스크 / 할 일 목록을 관리했으며, 결국 지연과 문제의 가장 큰 원인이 비효율적 인 관리 방식 인 것으로 나타났습니다.

이상하게도, 그 정보가 나오자 우리는 더 이상 Jira를 더 이상 사용하지 않을 것이며 새로운 제품을 가져 와서 교체 할 것이라고 갑자기 말했습니다.

그 동안 Jira를 통해 전달되는 모든 데이터 요청은 관리 팀으로 보내 져야했으며 직접 액세스 권한이 제거되었습니다.

통계 계산의 일부로 개발자 팀은 Jira가 웹 후크에 데이터를 파킹했으며이 웹 후크는 일부 내부 서버의 데이터를 엔드 포인트로 전달하는 데 사용되었습니다. 이러한 보고서는 자동으로보고됩니다.

우리는 웹 후크를 모니터링하기 시작했고, Jira가 더 이상 사용되지 않는다고 말했지만, 더 오래 (정확한 6 개월 이상) 더 오랜 시간 동안 살아남 았으며 고위 경영진의 도매 남용은 잘못 사용하는 평범한 만연.

물론 Jira처럼 복잡한 것은 아닙니다.

수율이 낮은 솔루션을 원한다면 google-docs 스프레드 시트와 GDocs 알림 API를 사용하여 작업 / 티켓 / 버그 / 기능 요청 등을 추적 할 수 있습니다.

GDocs 자체는 이제 웹 후크 및 모든 종류의 것을 발행 할 수 있습니다.

코드를 저장소에 커밋 할 때 트리거되는 Git 및 / 또는 Github 및 일부 후크와 결합하면 놀라운 양의 데이터를 기록 할 수있는 합리적으로 효율적인 홈 브루 시스템이 있습니다.

그러나 일반적으로 제품의 자연 수명 100 % 중 그린 필드 개발과 유지 보수 간 분할은 일반적으로 20/80이며, ALM (Application Lifetime Management)주기의 대부분 비용은 유지 보수 및 지원 비용으로 사용됩니다.

버그를 수정하는 데 너무 많은 시간을 소비하는 것은 없습니다. 버그가없는 코드를 작성하는 것은 불가능하기 때문입니다.

좋은 테스트와 지속적인 통합 정책으로 적자를 줄일 수는 있지만이를 완전히 제거 할 수는 없습니다.

그렇지 않다고 믿는 사람 (IMHO)은 정확한 판단을 내릴 충분한 지식이 없거나 소프트웨어를 실제로 작성하는 것이 얼마나 어려운지에 대한 맹목적입니다 (보다 일반적인 경우).

당신의 관리자가 그것을 위해 있고 그들 중 일부가 있다면, 당신은 그가 하루 동안 그림자를 드리울 것을 제안하고 싶을 것이므로, 당신이하는 일과 어떻게하는지 정확히 볼 수 있습니다.

Iv는 이러한 종류의 작업이 적극적으로 권장되는 일부 회사에서 근무했으며, 상위 직원은 하위 직원을 숨기고 그 반대도 마찬가지입니다.