나는 평균보다 4-5 배 더 많은 스토리 포인트를 만들고 있지만 절반의 속도로 버그를 생성합니다. 그래프에 따르면 버그가 2 배 더 많다고합니다. 어떻게 처리합니까?

따라서 일반적으로 최상위 계층 프로그래머는 일반 피어보다 훨씬 더 / 더 나은 코드를 생성 할 수 있습니다 .

일반적으로 코드에서 발생하는 오류의 비율은 프로그래머에게 비교적 일정 하다는 것이 인정 됩니다.

대신 코드를 작성할 때와 코드를 작성한 후에 사용되는 프로세스의 영향을받는 경향이 있습니다 . (알다시피) 인간은 상당히 일정한 비율로 실수를 저지르는 경향이 있습니다. 프로그래머가 많을수록 실수를 더 많이 발견하고 수정하는 것이 더 빠릅니다.

• 위의 두 가지 주장은 Steve McConnell의 Code Complete에서 제공 한 것이므로 관점이 다른 것은 아닙니다.

그래서 최근에 내 코드에서 이것을보기 시작했습니다. 필자는 많은 동료들 (팀이 추정 한 스토리 포인트로 측정)의 코드 양을 4-5 배 정도 향상시킬 수 있습니다. 그러나 나는 여전히 실수를한다. 더 나은 단위 테스트, 코드가 수행하는 작업에 대한 이해 및 코드 검토를 수행 할 때 발생하는 문제에 대한 더 나은 눈 사이에서 나는 4-5 배의 버그를 생성하지 않습니다.

하지만 QA가 팀의 다른 개발자 보다 버그를 여전히 두 배나 많이 생성하고 있습니다. 당신이 상상할 수 있듯이, 이것은 비 기술적 인 사람들이 미터법 측정을하는 데 약간의 문제를 일으 킵니다 (읽기 : 내 상사).

필자는 동료의 절반 속도로 버그를 생산하고 있으며 두 배나 많은 버그를 수정하려고 노력했지만 두 배나 많은 버그를 생성한다는 그래프가 있으면 어려운 판매입니다.

그렇다면 생산성 향상이 버그 수 증가로 이어진다는 사실을 어떻게 처리 할 수 ​​있습니까?

나는 당신이 당신의 우려를 섞고 있다고 생각합니다. 그리고 아무것도 없다 당신의 당신이 변화해야한다는 쪽.

생산성은 프로젝트가 얼마나 빨리 완료되는지에 대한 힌트입니다. 프로젝트 관리자와 다른 모든 사람들은 프로젝트가 언제 제공 될지 알고 싶어합니다. 생산성이 높거나 빨라지면 프로젝트가 더 빨리 제공됩니다.

버그 비율은 생산성이 아니라 프로젝트 규모와 관련이 있습니다. 예를 들어 코드 N줄당 버그 가있을 수 있습니다 Y. 해당 메트릭 내에 해당 코드 줄이 얼마나 빨리 작성되는지를 나타내는 것은 없습니다.

이를 합치면 생산성이 높아지면 더 빨리 작성되는 버그를 볼 수 있습니다. 그러나 프로젝트 크기에 묶여 있기 때문에 어쨌든 그 수의 버그가 생길 것입니다.

그렇다면 생산성이 높을수록 프로젝트가 끝날 때 더 많은 시간을 투자하여 버그를 찾아 내거나 개발자가 버그를 더 빨리 찾을 수 있습니다. ¹

질문의 더 개인적인 측면을 다루기 위해.

만약 당신의 상사가 당신이 생산하는 버그의 비율과 반대로 당신이 생산하는 버그의 수를 엄격히보고 있다면, 교육 세션이 순서입니다. 생성 된 버그 수는 백업 속도없이 의미가 없습니다.

그 예를 극단으로 가져 오려면 상사에게 급여의 두 배를 원한다고 말씀하십시오. 왜? 나는 당신의 프로젝트에서 전혀 버그 를 만들지 않았 으므로 당신보다 훨씬 뛰어난 프로그래머입니다. 뭐? 그는 프로젝트에 도움이되는 한 줄의 코드를 생성하지 않았다는 문제가 있습니까? 아 이제 속도가 중요한 이유를 이해했습니다.

팀마다 스토리 포인트 당 버그를 평가할 수있는 측정 항목이있는 것 같습니다. 다른 것이 없다면, 생성 된 많은 버그로 측정하는 것보다 낫습니다. 최고의 개발자 는 더 많은 코드를 작성하기 때문에 더 많은 버그를 만들어야합니다. 상사에게 그 그래프를 버리거나 최소한 버그 수와 함께 몇 개의 스토리 포인트 (또는 측정 한 비즈니스 가치)를 보여주는 다른 시리즈를 던지도록하십시오. 그 그래프는 더 정확한 이야기를 알려줄 것입니다.

¹ _{이 특정 의견은 의도했던 것보다 훨씬 더 많은 관심을 끌었습니다. 그래서 조금 놀랍도록하고 (놀랍게도)이 질문에 초점을 맞추십시오.}

_{이 질문의 근본은 잘못된 것을보고있는 관리자에 관한 것입니다. 그들은 생성 속도 대 완료된 작업 수를보아야 할 때 원시 버그 총계를보고 있습니다. "코드 라인"이나 스토리 포인트 또는 복잡성 등을 측정하는 데 집착하지 마십시오. 그것은 당면한 질문이 아니며 그 걱정은 더 중요한 질문에서 우리를 산만하게합니다.}

_{OP의 링크에 나와있는 것처럼 프로젝트 크기만으로도 프로젝트의 특정 버그 수를 예측할 수 있습니다. 예, 다양한 개발 및 테스트 기술을 통해이 버그 수를 줄일 수 있습니다. 다시 말하지만, 그것은이 질문의 요점이 아닙니다. 이 질문을 이해하려면 주어진 규모의 프로젝트 및 개발 방법론에 대해 개발이 "완료"되면 주어진 수의 버그를 보게 될 것입니다.}

_{자 이제 완전히 잘못 이해 한이 의견으로 돌아가 봅시다. 비슷한 크기의 작업을 두 개발자에게 할당하면 생산성이 높은 개발자가 다른 작업보다 먼저 작업을 완료합니다. 따라서보다 생산적인 개발자는 개발 기간이 끝날 때 더 많은 시간을 사용할 수있게됩니다. 이 "추가 시간"(다른 개발자와 비교)은 표준 개발 프로세스를 통해 침투 할 결함에 대한 작업과 같은 다른 작업에 사용될 수 있습니다.}

_{우리는 다른 개발자들보다 생산성이 높다는 입장에서 OP를 취해야합니다. 그 주장의 어느 것도 OP 또는 다른보다 생산적인 개발자들이 그들의 작업에 빠져들고 있다는 것을 암시하지 않습니다. 기능에 더 많은 시간을 소비하거나 디버깅이이 개발 시간의 일부가 아니라고 제안하면 버그가 줄어든다는 점을 지적하면서 요청한 내용이 누락되었습니다. 일부 개발자는 다른 개발자보다 빠르며 품질이 비슷한 작업을 생산합니다. 다시 한 번 OP가 질문에 제시하는 링크를 참조하십시오.}

여분의 시간을 코드 청소, 연마 및 테스트에 사용하십시오. 여전히 실수는 있지만 덜있을 것입니다. 시간이 걸립니다. 코드 출력 속도는 떨어지지 만 버그가없는 코드 출력은 증가하여 생산성이 향상됩니다. 버그가 비싸기 때문입니다.

코드를 찾아 버그를 더 많이 잡을 때까지 코드를 지점이나 테스트 환경에 유지할 수 있습니까? 브랜치의 버그는 일반적으로 프로덕션 코드의 버그보다 적은 파도를 유발합니다.

그러나 나는 당신의 질문에 이르는 당신의 주장을 정확하게 파고 있지 않습니다. 그리고 아마도 당신의 상사도 아닙니다.

모든 코더가 동일한 비율의 오류를 생성한다고 생각하지 않습니다. 두 번째 링크는 다른 코더 기술 수준이 아니라 다른 언어를 비교하기 때문에 실제로 주제와 완전히 다릅니다. Code complete는 코더의 기술보다는 프로세스를보고있는 일부 대규모 샘플 측정에 대해 언급합니다. 그리고 최상위 코더가 더 많은 코드를 생산한다고 말하면 그 중 일부는 버그가 적다는 것을 의미합니다. 응용 프로그램에 따라 다릅니다. 예, 저는 다른 관점의 문제라고 생각합니다.

결국 보스가 더 깨끗한 코드를 원하면 더 깨끗한 코드를 제공하십시오.

나는 사지에 나가서 악마의 옹호자가 될 것입니다. 그것은 내가 당신의 곤경에 동정하지 않는다고 말하는 것은 아니지만, 내 동정은 당신을 도울 수 없습니다. 필립의 관점 에 추가하겠습니다 .

상사는 제품의 품질에 관심을 가지는데, 그 이유 는 제품 의 이름과 명성이 제품 과 관련이 있기 때문입니다. 품질의 일부는 인식 된 버그의 양입니다 . 경쟁하는 드릴보다 4 배 빠른 드릴을 제공하지만 자주 두 배로 고장 나는 멋진 드릴을 판매하면 평판이 나빠질 수 있습니다. 드릴의 성능이 더 좋다고 주장하더라도 사람들은 속도에 익숙해 지지만 고장을 기억할 것입니다.

뒤늦게 보면 대부분의 버그는 분명히 예방할 수 있습니다. 조금만 더주의를 기울이면 상사가 느끼게되므로 이러한 문제와 필요한 청소를 피할 수 있습니다. 그의 관점에서 볼 때, 그것은 사소하고 감각적 인 것입니다. 그리고 당신이 그것에 대해 주장하는 것은 효과가 없으며 당신을 나쁘게 보이게 할 것입니다.

그는 당신의 뛰어난 생산성을 측정 할 수 없습니다. 검증 가능한 지표를 기반으로 생산성을 높이고 있다고 생각하면 동료들은 어떻게 생각합니까? 그들은 아마도 당신이 더 생산적인 프로그래머이거나 당신의 의견에 홀로 있다는 것에 동의 하는가? 다른 사람들이 어설 션을 백업하도록하면 더 강력한 지적을 할 수 있습니다.

그것은 관점입니다. 자, 당신이 처한이 실망스러운 상황을 어떻게 '고정'하는가?

조금 늦추십시오. 버그 비율 (*)을 낮추려고하는 작업을 배급하는 사람을 명시 적으로 언급하면 ​​섭취량이 적더라도 놀라지 않습니다. 무엇이든, 속도를 늦추면 공급 부족으로 인해 할당 된 버그 수가 줄어 듭니다.

_{(*)가이 있음을 인정하고, 한편으로 사이의 차이점 입니다 당신이 가진 것을 인정, 다른 한편으로는, 당신의 이름에 버그가 그리고 당신은 그 양을 줄이기 위해 노력하겠습니다 있고 너무 많은 이름에 버그를하고해야 행동을 취하다.}

상사 가 작동하지 않기 때문에 상사를 설득하려고 시도하지 마십시오 . 다시 말하지만, 당신이 당신의 요점 을 인정 해야 한다는 것을 의미하지는 않습니다 . 그의 염려를 없애지 않으면 서 상대를 제시하고 의견을 가질 수 있습니다. 당신이 요점을 주장하고 우수한 생산성을 만족스럽게 입증 할 수 없다면 (그리고 가능하다면), 동료를 모욕하거나 무시하는 것처럼 보일 수 있기 때문입니다. 당신은 그 사람 이되고 싶지 않아요 .

20 %의 시간 동안 동료와 동일한 "양"의 코드를 생성한다고 가정하면 실제로 코드를 디버깅하고 완벽하게 만드는 데 4 배의 시간을 소비 할 수있어 버그 비율이 훨씬 줄어 듭니다. 그런 다음 자신을 훌륭한 프로그래머라고 부를 수 있습니다.

가장 큰 문제는 품질을 목표로하는 대신 다른 것보다 5 배 많은 코딩을하는 이유입니다. 이것은 당신의 자아가 당신에게 지시하거나 상사가 당신을 강요합니까?

또한 버그 수정 비용도 고려해야합니다. 빨리 찾을 때 코드를 빨리 수정하기에 충분한 "내부"코드 일 수 있습니다. 개발 후 한 달이 지나야 나타나는 경우 이미 프로그래밍 된 코드의 큰 부분을 찾거나 변경하기가 어려울 수 있습니다.

코드를 생성하는 스킬 셋이있는 것 같습니다. 속도 대신 품질에 중점을두면 멋지게 만들 수 있습니다. 잠시만 기다려 봐, 내 생각 엔 네가 좋아 할꺼야.

다음 문제는 더 나은 성과를위한 인정을받는 것입니다. 상사와 이야기하고 진행 방법을 물어보십시오. 결국 회사와 돈이며, 버그를 줄이려면 어떻게 해야하는지 결정해야합니다.

개발자는 GOOD 개발자가 아니더라도 솔로를 이해하고 코딩 할 수있는 능력으로 밝고 천재적 일 수 있습니다. 훌륭한 개발자는 양질의 작업을 만들어 전체 프로젝트를 개선합니다.

나는 이것이 당신이라고 말하지는 않지만, 내가 일했던 가장 실망스러운 프로그래머 중 하나가 팀의 누구보다 많은 코드를 작성했으며 우리는 팀에 좋은 사람들이있었습니다. 우리는 순위 소프트웨어로 커밋을 추적했기 때문에 일부 사람들과 거의 경쟁했습니다. 그는 엉뚱한 코드를 꺼내서 ZERO 문서, 흠 잡을 수없는 숲을 남기고 실제로 내 자신의 코드 중 일부를 이해하기 어렵게 만들었습니다. 결국 그는 한 사람의 쇼가 되었기 때문에 프로젝트를 거의 탈선시켰다. 사람들은 그를 따라갈 수 없었습니다. 우리는 팀으로서 동기화되지 않았습니다. 우리는 실제로 유지 관리 능력을 회복하기 위해 몇 년 후 그의 기능 중 일부를 다시 작성했습니다.

내가 원했던 것은 속도를 늦추고 더 많은 시간을 소비하는 것이 었습니다 .1) 코드베이스의 품질 향상 2) 팀과의 의사 소통 3) 다른 사람들을 돕고 기능 / 이야기를 마무리하는 데 도움이되는 것들에 대한 작업 4) 고정 버그

코드 라인별로 생산성을 측정하는 데 동의하지 않지만 핵심 지표입니다. 코드 카운터에 주석이 포함되어 있습니까? 그렇다면 "버그 비율"을 줄이면서 라인 출력을 유지하는 쉬운 방법이 있습니다. 의견의 질과 양을 늘리기 만하면됩니다. 의견에는 버그가 거의 없으며 (가능한 경우에도) 일반적으로 충분한 의견이 없습니다. 내가 하지 코드 인플레이션을 용서하지만, 주석의 행위 미니 코드 리뷰처럼, 당신이, 리팩터링을 생각하고 개선 강제로.

관리를 계몽하려는 것은 시작이 아닙니다. 낡은 진부한 말이 있습니다. "당신은 저나 당신의 눈을 믿겠습니까?" 상사와 관련된 것은 버그 수입니다. 합리화의 양은 그들에게 허용된다고 말할 수 없습니다. 두 배 이상 위험합니다. 또한 버그 수에 영향을받는 유일한 사람은 아닙니다. QA는 버그를 식별하기 위해 두 배의 작업을 수행하므로 관리 팀에서 버그를 줄이려고합니다.

가장 좋은 해결책은 생성 한 버그 수 를 줄이는 것 입니다. 관리가 더 행복 할뿐만 아니라 당신도 마찬가지입니다. 그렇지 않습니까? 나는 동료를 4 배나 능가한다고 자랑 할만큼 확신 합니다. 여러분은 버그를 똑같이 또는 더 적은 수의 버그로 만드는 것을 좋아 합니다.

당신이 언급 한 바와 같이, "... 코드에서 발생한 오류의 비율은 코드를 작성할 때와 코드가 작성된 후에 사용 된 프로세스에 영향을받는 경향이 있습니다." 버그 생성 속도를 변경하려면 코드 작성에 사용하는 프로세스를 변경해야합니다.

프로그래머는 생산 라인을 사용하여 코드를 생성합니다. 조립 라인은 대량 생산 된 객체를 생성하는 방법을 사용합니다. 자, 소프트웨어 산업의 관행은 숲에서 발견되는 나뭇 가지에서 휘젓는 요령과 비슷합니다. 그러나 우리는 기계를 생산하기 때문에 고속 대량 생산 기계에 사용되는 것과 동일한 엄격하고 규율을 채택해야합니다.

여기에는 결함 발생률을 줄이기 위해 대량 생산에 사용 된 것과 동일한 기술이 포함됩니다. 버그 원인을 파악하기위한 근본 원인 분석 및 그렇지 않은 프로세스 변경. 또는 적어도 품질 보증 전에 확인해야합니다.

1. 버그 목록을 작성하십시오. QA 담당자에게 이미 감사의 말을 전했을 것입니다. 아마도 분류 될 수도 있습니다. 버그 유형, 심각도, 버그가 코드에 삽입 된 지점 등

2. 가장 큰 버그 범주를 선택하십시오. 볼륨이 너무 높으므로 먼저 해당 카테고리를 타겟팅해야합니다. 다른 범주에는 가장 쉽게 찾을 수있는 범주와 가장 쉽게 만드는 범주가 포함됩니다.

3. 해당 버그가 코드에 도입 된 위치를 파악하고 해당 단계 (및 이전)에서 해당 버그가 발생하지 않도록 변경하고 해당 단계에서 버그를 쉽게 잡을 수있는 방법을 살펴보십시오.

4. 비 프로그래밍 관련 부수적 인 문제를 검토하고 작업 품질에 차이를 줄 수 있습니다. 배경 음악, 중단, 식사 시간, 휴식, 굶주림 등이없이 너무 오래 일하는 것

찾은 것이 느려질 수 있습니다. 반면에, 이미 뒤에 놓인 물건을 재 작업 할 필요성이 줄어들 기 때문에 더 빠르게 생산하는 데 도움이 될 수 있습니다. 실제로, 코드보다 4 배나 많은 코드가 동료보다 훨씬 우수하지 않기 때문에 프로세스를 변경하는 것이 가장 확실한 방법입니다.

코드를 가장 많이 생산하는 것에서 회사가 가장 발전 할 수 있도록 목표를 변경하십시오.

동료가 많고 시간이 더 남는 것 같습니다. 기능 및 버그 수정을보다 빠르게 제공 할 수있는 가장 큰 영향은 동료를 돕는 것입니다.

동료들을 도와주십시오

• 코드 검토를 사용하여 코드 품질 및 교육 향상
• 프로세스 자동화를 통해 작업 속도를 높이고 삶을 편하게 만듭니다.
• 그들과 함께 더 나은 테스트를 작성
• 코드 기반 개선을위한 기술 코드 공격
• 항상 다른 사람들을 도울 수있는 방문하는 사람입니다.
• 개발자 생산성에 도움이되는 도구 작성 / 개선
• 더 영향력이있는 경우 동료를위한 더 나은 도구 / 장비 / 작업 조건에 대한 관리로 사례를 만듭니다.
• 더 나은 코드 작성에 대한 교육 세션 준비 및 진행
• 겸손을 실천하다

그렇다면 생산성 향상이 버그 수 증가로 이어진다는 사실을 어떻게 처리 할 수 ​​있습니까?

당신의 상사는 당신의 경우에 이것에 대답 할 수있는 유일한 사람입니다. 그와 이야기하고 더 나은 비율을 지적하고 결정하게하십시오. 그의 결정이 의미가 없다면, 당신의 사고 방식을 가진 회사를 찾을 때입니다.

전문가는 주어진 고객 조건에 대해 작업 할 수 있어야하며 그 결과를 이해해야합니다. 멋진 버그 / 스토리 차트를 사용하면 버그를 줄이는 데 시간이 걸리면 상사가 생산성이 얼마나 많이 떨어질지를 이해하는 데 도움이됩니다.

또한 다음 사항을 고려해야합니다.

• 간단한 게터 / 세터 래퍼 vs 통계 계산 또는 실시간 프로그래밍 또는 실시간 통계와 같은 스토리의 복잡성 ...
• 버그 심각도, 텍스트 필드에 작은 오타 나 잘못된 계산 결과, 프로그램 충돌
• 버그를 수정하는 데 소요되는 비용은 지금 당장 또는 나중에 또는 다른 사람이 귀하의 코드를 이해해야하는 경우

상황은 일반 프로그래머보다 4 배 빠르게 일하지만 주어진 시간에 두 배나 많은 실수를 저지르는 것입니다. 작업량과 관련하여 실제로 "평균"만큼 많은 실수를 HALF로 만듭니다.

낮은 실수 대 작업 비율 또는 심지어 완성 된 제품에 대한 실수 (정상 시간의 1/4에서 완료 할 수 있음)를 지적하려고 할 수 있습니다. 대부분의 보스는 그것을 받아 들일 것입니다.

시간당 "허용"마인드로 작동하기 때문에 사장하지 않는 보스가 몇 명 있습니다. 그런 다음 주어진 시간 내에 평균적으로 두 배나 많은 작업을 수행하고 작업 속도를 늦출 수 있으며 작업을 확인할 시간이 더 많기 때문에 동일하거나 적은 실수를 저지를 수 있습니다.

상사가 업무의 질을 향상 시키길 원한다면 업무의 질을 향상 시키십시오.

다음 최고의 프로그래머보다 두 배만 생산하는 것이 아니라 버그 제로를 목표로해야합니다.

당신이 상사에게 그가 사용하고있는 통계에 결함이 있다고 말해야한다. NBA에서 경비원의 회전율을 살펴보면 포워드보다 숫자가 높은 경향이 있습니다. 그러나 공을 더 많이 다루기 때문입니다. 비스타 트 가드가 스타트 가드의 1/5만큼 플레이하고 평균 .vs보다 3 번 이상 공을 돌리는 경우 게임마다 7 번 이상 공을 돌리는 시작 가드-언뜻 보면 시작 가드가 더 나빠 보일 수 있습니다. 그러나 회전 수를 분 수로 나누면 시작 가드가 분 수를 기준으로 훨씬 더 나은 수를 가지게됩니다.

마찬가지로 버그 수를 완료된 스토리 포인트 수로 나눈 경우 훨씬 더 나은 숫자를 갖습니다. 이것이 바로 매니저에게 제안하는 것입니다. 버그 수를 완료된 스토리 포인트로 나눈 값으로 변경하거나, 개발자 당 총 버그 수가 필요한 경우 최소한 새 메트릭을 추가하십시오. 그러나 일부 스토리 포인트는 다른 스토리 포인트보다 훨씬 더 어렵고 복잡하기 때문에 약간의 차이가있을 수 있으며, 관리자도이를 고려해야합니다.

내가 당신이해야한다고 생각하지 않는 것은 속도를 늦추는 것입니다.

측정 값 추가

실제로 계산하는 것은 추가하는 가치라고 주장하십시오. 그런 다음 대략적인 수동 측정을 도입하십시오.

• 생산하는 기능의 가치를 추정하십시오
• 급여를 뺍니다
• 버그의 예상 비용을 뺍니다 (적어도 수정 비용).
• 당신이 생산하는 다른 모든 기술 부채의 추정 비용을 빼십시오

나머지는 귀하의 부가 가치입니다. 다른 사람들도 마찬가지입니다.

이러한 추정은 어렵지만 거친 것조차도 지적 할 수 있습니다. 이러한 추정치를 논의하는 단순한 프로세스는 팀과 프로젝트에 유용합니다.

최고의 프로그래머는 디버깅하고 이해하기 쉬운 매우 일반적인 코드를 작성하는 경향이 있으며 사용 가능한 도구 (정적 분석, 컴파일러 오류, 디버그 코드)를 최대한 활용합니다. 또한 최고의 프로그래머는 이미 자체 경험을 통해 단위 테스트의 가치를 배웠습니다.

따라서 라인 당 초기 문제의 양은 동일하지만 문제는 더 빨리 제거됩니다.