어느 것이 더 낫습니다 : 버그가있는 기능을 선적하거나 기능을 전혀 제공하지 않습니까?

Question

이것은 약간의 철학적 질문입니다. 나는 대부분의 사용자가 소프트웨어를 사용하는 시간의 10 % 만 사용한다고 가정하는 소프트웨어에 작은 기능을 추가하고 있습니다. 즉, 소프트웨어없이 3 개월 동안 괜찮 았어,하지만 4 또는 5 사용자가 그것을 요청하고, 거기에 있어야한다는 데 동의합니다.

문제는 내가 작업하고있는 플랫폼 (그리고 아마도 내 뇌의 한계) 때문에 "할 수있는 최선"은 여전히 ​​중요하지 않지만 눈에 띄는 버그가 있다는 것입니다. 코딩 된대로 사용할 수 있지만 경우에 따라 "다소 불안정합니다."

어떻게해야합니까? 90 %의 기능이 실제로 "아무것도없는 것보다 낫다"는 기능입니까? 내가 해결할 수없는 몇 가지 버그 보고서를 얻을 것이라는 것을 안다 : 나는 고객들에게 그것들에 대해 무엇을 말해야 하는가? 답이없는 기능 요청이나 응답이없는 버그 보고서로 살아야합니까?

Answer 1

항상 답이없는 기능 요청 및 버그 보고서가 있습니다. 배송은 가능하지만 가능한 경우 "알려진 문제점"및 해결 방법이 포함 된 readme를 포함하십시오.

Answer 2

정확하게 원고를 문서화하고 배송하십시오.
사용자가 일 가능성이 높은지 확인하십시오. 및 은 워킹 문서를 참조하십시오.

기능을 요청한 사용자와 논의 할 수도 있습니다. 일부 시장 조사를 수행하십시오.

당신이 지금 바로 고칠 수 없기 때문에 당신이 미래에 그것을 할 수 없다는 것을 의미하지는 않습니다. 모든것은 변한다.

Answer 3

'베타 버전'으로 표시된 항목에 라벨을 지정하고 요청한 사람들에게 보내십시오. 얼마나 효과가 있었는지에 대한 피드백을 받고 불만 사항이 무엇이든 해결하면 더 큰 사용자 그룹으로 롤아웃 할 준비를해야합니다.

Answer 4

사람들에게 문제가 있다는 것을 알고 있는지 확인하십시오. 거기에는 버그가 있습니다. 그리고 그들에게 의견을 제안 할 수있는 쉬운 방법을 제공하십시오.

처음에 기능을 제안한 "4 명 또는 5 명의 사용자"와 "폐쇄 베타"를 갖는 것은 어떻습니까?

Answer 5

사용자의 관점에서 생각해 봐야합니다. 그러면 좌절감이 줄어들 것입니까? 버그 코드는 일반적으로 누락 된 기능보다 더 실망 스럽습니다.

Answer 6

다른 어떤 것도 손상시키지 않는다면 배송하지 않으시겠습니까? 당신이 고객과 좋은 관계를 맺고있는 것처럼 들리므로, 그 기능을 원하는 사람들은 그것이 그곳에 있지 않더라도 그것을 얻게되어 기쁠 것이며, 원하지 않는 사람들은 상관하지 않을 것입니다. 또한 다음 릴리스에서 개선하기 위해 많은 피드백을 받으실 수 있습니다!

Answer 7

조기에 배송하십시오. 자주 리 포트됩니다.

내 말은, 배송을 중단시키지 말고 문제를 해결하는 것을 포기하지 마십시오.

위키를 해결할 수 없다는 것은 코드베이스에 문제가 있음을 나타냅니다. 기능을 추가하는 것보다 리팩토링에 더 많은 시간을 투자하십시오.

Answer 8

완벽 주의자는 "하지 마십시오"라고 대답 할 수 있습니다.

사람들이 "할 수 있습니다"라고 대답 할 수도 있습니다.

균형이 어디까지 가능한지 생각해보십시오. 버그가 중요하지 않은 경우 해당 기능을 퍼팅쪽으로 기울일 것입니다. 대부분의 사용자는 귀하가하는 것과 같은 방식으로 귀하의 소프트웨어를 보지 않습니다. 당신은 장인/예술가로서 일반인보다 비판적인 사람을 의미합니다.

기능을 요청한 4-5 명에게 베타 버전을 제공 할 수있는 방법이 있습니까? 그렇다면 일단 의견을 받으면 어떤 결정을 내릴지 명확 할 것입니다.

Answer 9

귀하의 기준에 따라 다릅니다. 나에게 버그 코드는 생산 준비가되지 않았으므로 배송해서는 안됩니다. 사용자가 특정 조건에서 기대할 수있는 사항을 알 수 있도록 알려진 문제점 목록이있는 베타 버전을 제공 할 수 있습니까? 그들은 새로운 기능을 사용하는 이점을 얻게되지만 완벽하지는 않다는 것을 알고 있습니다 (자신의 위험을 사용하십시오). 이렇게하면 잠시 동안 기능을 요청한 4 명 또는 5 명의 고객이 버그를 수정할 수있는 시간을 더 많이 주며 나중에 대량으로 출시 할 수 있습니다.

상황에 따라 약간의 생각이 있습니다.

Answer 10

에 따라 다릅니다. 버그, 그 심각도, 그리고 그것을 고치기 위해 얼마나 많은 노력이 필요하다고 생각하십니까? 마감 시간과 얼마나 스트레칭을 할 수 있을지 생각해보십시오. 나머지 코드와 클라이언트가이 코드로 얼마만큼 처리 할 수 ​​있는지.

Answer 11

코더가 알려진 문제점을 테스트에 제공하여 고객에게 릴리스하지 않을 것으로 기대합니다.

나는 너에게 버그가 전혀 없다고 생각합니다. 흥미롭게도 일반적으로 모든 버그를 제거하는 것이 가장 힘든 개발자/테스터 인 것으로 나타났습니다. 버그를 기꺼이 받아들이는 프로젝트 관리자 및/또는 고객이 종종 있습니다.

코드를 릴리스해야하는 경우 알고있는 모든 기능/버그를 문서화하고 각 기능을 수정해야합니다.

작업중인 플랫폼의 제한 사항에 대해 더 많은 정보를 게시하지 마십시오. 여기에있는 영리한 사람들 중 일부가 버그 목록을 다운시키는 데 도움이 될 수 있습니다.

Answer 12

대답해야 할 중요한 질문은 당신이 제시 한 디자인에 따라 실제 비즈니스 요구를 해결할 수 있는지 여부입니다. 그런 다음 구현이 설계와 일치하도록하는 것만으로 "버그"가 피쳐의 의도 된 동작 (디자인에서 다루어야 함)의 일부가 아닌 것으로 정의하여 비 버그가되게합니다.

이것은 매우 실제 경로 선택으로 이어집니다. 버그가 의도 한 동작 및 디자인의 일부가 아닌 제대로 작동하지 않는 버그입니까? 또는 if가 의도 된 동작에 따라 작동하지 않는 경우에만 버그입니까?

저는 후자에 대한 확고한 신념입니다. 버그는 그들이 의도 한대로 작동하지 않는 것들입니다. 구현은 비즈니스 요구를 포착해야하는 디자인을 포착해야합니다. 구현이 설계에서 다루지 않은 다른 비즈니스 요구 사항을 처리하는 데 사용되는 경우 구현이 아니라 잘못된 설계입니다. 따라서 버그가 아닙니다.

내 태도는 프로그래머들 사이에서 가장 일반적입니다. 또한 사용자가 소프트웨어 문제를 보는 방식이기도합니다. 그러나 소프트웨어 개발 관점에서 볼 때이 뷰를 채택하는 것은 좋지 않습니다. 솔루션을 비즈니스 요구에 맞게 재 설계하는 대신 버그가 아닌 버그를 수정하도록 유도하기 때문입니다.

Answer 13

기능이 작동하는 기능이 아니라 지금 기능에 대한 수요가있는 경우. 출하해야 할 수도 있습니다.

• 하면 (사용자 다른 개발자 모두) 버그 (들) 과 결과를 문서화해야합니다 :하지만이 상황에서
  .
• 버그 추적 데이터베이스에 버그를 추가하십시오.
• 단위 테스트를 작성하는 경우 (희망) 전에 테스트가 버그를 강조 표시하는 으로 작성되었는지 확인하십시오. 이것은 나중에 버그를 수정하려고 할 때 어디서 무엇인지 알고 기억할 필요없이 을 의미합니다.
• 최대한 빨리 버그 수정 작업을 예약하십시오. 새 코드를 작성하기 전에 버그를 수정합니까?

Answer 14

버그로 인해 사망 또는 사용자 파일이 손실 될 수있는 경우에는 발송하지 마십시오.

버그로 인해 응용 프로그램이 손상 될 수있는 경우 경고 (readme 또는 기타)와 함께 제공하십시오. 크래시로 인해 응용 프로그램이이 정확한 응용 프로그램으로 편집하는 중일 때 사용자 파일을 손상시킬 수있는 경우 응용 프로그램을 시작할 때마다 경고를 표시하고 파일을 먼저 백업하라는 메시지를 표시합니다.

버그로 인해 BSOD가 발생할 수있는 경우에는 누구에게 발송할지 매우주의해야합니다.

Answer 15

사용자를 위해 버그가있는 소프트웨어를 설치해야하는 사람이 나와 있습니다. 해당 기능을 사용하도록 배송하지 마십시오.

문서화해도 최종 사용자는 처음으로 해당 버그를 잊어 버리며 버그는 업무를 수행 할 수 없게되는 중요한 요소가됩니다.