이상적인 세상에서는 버그를 줄이면서 마감일을 맞추는 것이 좋습니다. 그러나 더 바람직하거나 수용 가능한 경험에서 :

1. 마감일을 지키지 만 개발자가 일에 몰려 들기 때문에 많은 버그가 있습니다.
2. 개발자가 코드를 작성하는 데 매우 엄격하기 때문에 버그가 적지 만 마감일을 준수하지는 않습니다.

이 질문에 대한 답변은 고객뿐만 아니라 비즈니스 목표에도 크게 좌우됩니다.

기업 :

시장에서 잘 확립 된 엔터프라이즈 급 고객과 비즈니스를 수행하는 경우 유연성이 떨어지고 변화에 신속하게 적응할 수 없습니다. 따라서 대부분의 경우 안정성은 필수 요건입니다. 연구 개발과 새로운 업종 입력에는 예외가 있습니다. 경우에 따라 더 빨리 마무리됩니다.

이러한 유형의 클라이언트는 일반적으로 좋은 소프트웨어를 개발하는 데 시간이 걸리고 목표를 달성하기 위해 노력할 것임을 이해합니다.

스타트 업 :

새로 시작하는 경우 규칙이 크게 다릅니다. 신생 기업으로서, 구축하려는 제품이 실제로 마케팅 조사에서 예상 한대로 요구를 충족시킬 수 있는지 즉시 알아야합니다. 스타트 업의 경우 가능한 빨리 시장에 프로토 타입을 출시하면 제품의 방향에 대한 귀중한 피드백을 많이받을 수 있습니다.

또한 시장 리더로서의 입지를 다질 수 있으며, 경쟁이 치열 해지기 전에 새로운 업종에서 가치있는 시장 점유율을 확보 할 수 있습니다.

신생 기업은 규모가 작고 유연하며 변화에 빠르게 적응할 수 있으므로이 모델이 가장 적합합니다.

요약하면, 고려해야 할 다른 요소가 있지만, 주요 아이디어는 모든 프로젝트가 다르고 품질과 시장 출시 시간이 다르다는 것입니다. 한 가지 방법을 다른 방법으로 선택하는 데 따른 기회 비용에 대한 철저한 분석을 포함하는 효과적인 비즈니스 전략을 결정하는 것은 경영진의 책임입니다.

또는 ... 3. 비 필수 기능 잘라 내기

때로는 고객이 요청한 기술적 인 캔디 또는 캔디 기능 때문에 마감일을 맞추기가 어렵고 본질적으로 더 큰 버그가 발생합니다. 그것은이다 KISS 및 YAGNI의 원칙을 적용했다.

이 책 에서 인용 한 "재 작업"에서 소프트웨어의 필수 / 핵심 / 진점 센터는 핫도그 스탠드가 토핑없이 핫도그 스탠드가 될 수있는 것처럼 비즈니스가 작동하는 데 필요한 것입니다. 핫도그.

재협상

배우기 가장 어려운 것 중 하나는 고객을 행복하게하는 방법이며, 내 경험상 작은 제품 반복으로 쉽게 수행 할 수 있습니다.

마감 시한은 소프트웨어가 첫날부터 대량 생산 수준에서 작동하도록 요구합니다. 관리자 / 클라이언트는 소프트웨어에 실제로 필요한 것을 항상 알지 못합니다 (대부분의 경우). 불필요한 기능을 줄이고 품질을 유지하십시오. 결국 프로덕션 환경이 얼마나 중요한지에 달려 있지만 추가 기능을 잘라 내고 품질을 제공하려고합니다. "재 작업"에서 다시 인용 :

나중에하는 것도 더 나은 것을 의미합니다

... 그리고 버그가 적은 마감일을 맞추는 것

글쎄, 당신은 이런 식으로 프레임을 만들 수 있습니다 : 당신은 지금 또는 나중에 품질을 지불 하시겠습니까? 처음부터 잘하기 위해 시간을 내거나 나중에 모든 문제를 해결하는 데 시간을 보내십시오. 이 기능 개발 후 버그 수정 단계는 기존 코드가 이미 준비되어 있고 품질이 충분하지 않기 때문에 위험하고 해키가 발생하기 쉬우므로 비용이 많이들 수 있다고 주장합니다.

마감일을 지키고 알려진 문제 목록을 제시하십시오.

사람들은 벌레를 찾는 것을 싫어하지만, 미리 들었다면 훨씬 관대 해지는 경향이 있습니다.

이것은 전적으로 상황에 달려 있습니다 ....

고려해야 할 많은 요소가 있습니다.

1. 패치를 배포하는 것이 얼마나 쉬운가요?
2. 기본적으로 제거 된 버전을 출시 한 후 시간이 지남에 따라 새로운 기능 (엣지 케이스)을 패치 할 수 있습니까?
3. 그러한 제품에 대한 고객 산업의 일반적인 문화는 무엇입니까? 그들은 일회성 완벽한 출시를 기대합니까, 아니면 처음 출시되었을 때 버그가 발생할 수있는 진화하는 시스템에 대한 아이디어에 익숙합니까?
4. 마감 시한을 맞추는 것과는 대조적으로 버그가있는 초기 버전은 비즈니스에 얼마나 많은 위험을 초래합니까?

요컨대, 이것에 대한 흑백 답은 없습니다. 예를 들어 : 현장에있는 장치로 출시하기가 어렵고 비용이 많이 드는 임베디드 시스템과 같은 경우 가능한 한 기한을 다시 조정하여 버그가없는 상태로 내보내는 것이 가장 좋습니다. 반면에, 수정 사항이 나오면 언제든지 롤업하여 쉽게 업그레이드 할 수있는 대형 웹 포털 시스템 (웹 앱으로 작성)과 같은 경우에는 초기에 닷지 버전을 출시하는 것이 더 합리적 일 수 있습니다. 그런 다음 패치 문제 (및 대소 문자 기능)를 얻습니다.

그러나 하루가 끝날 무렵, 이것은 내 경험상 기술 결정보다 비즈니스 결정에 더 가깝습니다. 버그가있는 초기 버전을 갖지 않는 (또는 그 반대) 마감 기한을 놓치는 것이 매우 어려운 상황에 처한 경우 결정을 내릴 때 이러한 사항을 평가해야합니다.

참고 : 물론 프로그래머로서 제품을 출시하기 전에 가능한 한 제품을 연마하는 아이디어를 선호합니다 (아마도 마감일이 없습니다.). 그러나 현실적으로는 현실에서 불가능합니다. 종종 제거 된 초기 릴리스는 훌륭한 중간 솔루션입니다.

나는 많은 PM이 고객에게 우리가 일정을 충족시킬 수 없다고 말하고 두려워하는 버그를 알려달라고 두려워하는 것을 보았습니다. 나는 그들이 고객에게 말할 때마다 보통 버그가 적고 마감 기한이 지남에 훨씬 더 관심이 있다고 말할 수 있습니다. 마감일이 절대로 움직일 수없는 경우 (예 : 세금 소프트웨어를 수행 할 때 세금 신고 시즌 시작과 같이) 또는 이동 비용이 많이 드는 다른 항목 (IMHO)에 영향을 미치지 않는 한, 누락 된 마감일보다 더 많은 버그를 기억합니다. 모든 마감일의 98 %가이 기준을 충족하지 않습니다.

나는 그것이 버그에 달려 있다고 생각합니다. 컴퓨터에서 앱이 실행되는 순간 앱이 다운되는 버그를 수정하기 위해 릴리스를 지연 하시겠습니까? 물론 이죠 보름달이있는 동안 Windows ME에서만 발생하는 버그를 수정해야합니까? 아마 기다릴 수 있습니다.

치명적인 버그 인 경우, 2 번 핸드 다운을하는 것이 좋습니다. 업데이트에서 해당 수정 프로그램을 푸시해야하는 경우 수정 비용이 기하 급수적으로 증가하기 때문입니다.

덜 중요한 업데이트의 경우 번들 업데이트를 릴리스하여 비용을 어느 정도 줄일 수 있습니다.

의심 스러울 때, 당신은 # 2로 가겠다 고 말하지만, 그 접근 방식으로 경영진으로부터 반발하는 것에 놀라지 않을 것입니다. 필자는 관리자가 불필요하게 중요한 업데이트를 일으키지 않는 것보다 마감일을 얼마나 잘 달성하고 있는지 더 판단하는 경향이 있다고 생각합니다.

둘 다. 코드 품질을 향상시키지 않겠습니까? 품질 코드로 마감일을 맞출 수 있습니까? 더 적은 기능을 사용할 수 있지만 품질이 프로세스에 반영되면 두 가지를 모두 달성 할 수 있습니다.

지금 일어나는 일은 비즈니스를 추진하고 두 가지 일에 대해 대화를 나눌 수있는 역량있는 팀 리더 또는 개발자 관리자가 필요하다는 것입니다.

1. 코드로 구운 품질 = 빌드 당 2 개 적은 기능
2. 이해 관계자의 요구에 따라 가장 필요한 기능의 우선 순위를 정합니다.

그런 다음 최고 가치의 기능에 집중하고 우수성을 제공 할 수 있습니다.

테스트에 관한 한 결코 끝나지 않습니다. 끝났지 만 끝나지 않았습니다.

심각도가 높고 우선 순위가 더 높은 버그가있는 버그로 시작하십시오.

많은 버그로 마감 시간을 맞추면 업계에서 나 빠지고 고객은 다시 오지 않을 것입니다. 고객과 상담하여 2 ~ 3 일 지연 될 수 있습니다.

최종 사용자로부터 이것을 보았을 때 누군가 월요일에 무언가를하기로 약속했다면 사용을 중단했을 때 작동하지 않거나 모두 버그가 있습니다.

그러나 "절차"측면을 살펴보면 응용 프로그램에 더 많은 테스트가 필요하고 소프트웨어의 자연스런 부분이 필요하다는 의미입니다.

내 최선의 방법은 일이 작동하는 방식으로 작동하도록 노력하는 것입니다 (주요 모듈 인 경우 세부 사항에주의를 기울이지 말고 양식에 로그인해야하지만 나중에 알림을 표시하지 않으면 누구나 그림을 볼 수 있습니다).

이것은 당신 만이 대답 할 수있는 질문입니다. 그것은 제품의 유형, 고객, 고객이 요구하는 것에 따라 달라집니다. 우리가 간단한 'a 또는 b'답변을 줄 수있는 방법은 없습니다. 완전히 상황에 따라 다릅니다.

그러나 나는 버그 수정의 비용 당신을 생각 나게합니다 후 릴리스가 고정보다 훨씬 높다 전에 릴리스. 따라서 버그를 수정하기 위해 출시 후까지 기다릴 지 여부를 결정할 때 더 많은 시간 / 노력 / 돈을 소비 할 것임을 고려하십시오.