최근 한 관리자는 버그 수정에 너무 많은 시간을 소비하고 있다고 발표했습니다. 그는 우리가 항상 완벽한 코드를 작성해야한다고 생각한다고 생각합니다 (물론 불가능한 마감일을 지키는 동안!) 새로운 코드를 작성하는 데 버그를 수정하는 데 걸린 평균 시간이 얼마인지 궁금해졌습니다.
그렇다면 새로운 코드 개발에 대한 버그 수정에 소요되는 시간에 대한 통계가 있습니까? 아니면 업계 전체의 버그 수정 시간에 대한 경험적 분석이 있습니까? 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는 이러한 종류의 작업이 적극적으로 권장되는 일부 회사에서 근무했으며, 상위 직원은 하위 직원을 숨기고 그 반대도 마찬가지입니다.