我们有一个项目即将推出，PM 坚持团队应该“吃自己的狗粮”？
在什么时候这样做是现实的？
例如假设我们必须编写一个编辑器。我们不能在一开始就使用这个编辑器来实际编码，因为它不存在。我们必须使用另一个编辑器。
在项目期间的一段时间内，使用有问题的编辑器会减慢项目的速度，并且会适得其反。
那么我们在什么时候切换呢？
更新：经过团队内部的一些讨论，我们在开发过程中会强调的要点是：
- 实施可能的最小子集开始
- 尽快识别关键特征
- 只切换部分开发者使用新产品，将风险降至最低
12 回答
12
你们中的一些人应该尽快使用它。第一个版本应该被精简，只有你需要的最重要的功能才能将它用作（在这种情况下）编辑器。一旦你开始使用它，你会很快发现哪些功能很重要。
于 2008-10-23T02:03:46.713 回答
4
<咆哮>
不生产狗粮，就不用吃狗粮。
无论如何，这个病态和愚蠢的短语的起源是什么？狗不生产自己的食物（有一个粗俗的例外）......
</rant>
问 PM 更重要的是：使用正在开发的产品进行开发，还是按时生产高质量的代码？如果有冲突，哪个更重要？
常识性的答案是：当你正在构建的东西比你拥有的工具更好时，就使用它。
于 2008-10-23T02:12:56.977 回答
3
您不必切换到专门使用开发编辑器。开始使用它，直到它影响你的生产，列出有问题的东西，修复它们，重复直到你能够在大多数/所有时间有效地使用它。
于 2008-10-23T02:04:46.040 回答
2
在项目期间的一段时间内，使用有问题的编辑器会减慢项目的速度，并且会适得其反。
听起来你有你的答案。切换的时间是当您的项目不会妨碍生产力时。
于 2008-10-23T02:07:33.260 回答
1
这是那些“取决于”问题之一。一些指导：
- 在项目完全出炉之前使用该项目有哪些风险？他们可以接受吗？
- 项目进展会更快还是更慢，这是一个问题吗？
- 从商业角度来看，最终产品的质量会提高吗？
- 您最终会得到使程序员更有效率但对客户无用的功能吗？
- 相反，是否会因为开发人员对它们不“感兴趣”而推迟关键功能？
- “狗粮的味道”会激励您的开发人员吗？
也许最有帮助的指南是我称之为“Headrick 规则”的东西，以首先向我解释它的同事之后：
如果您需要某人完成某事，请让他不完成它而痛苦！
当然，另一方面是让尽可能快地完成项目变得愉快。就个人而言，我喜欢构建和使用工具，所以我会在谨慎允许的情况下尽快提供狗粮。但我的同事是一个虐待狂，他会回答：“只要它编译好！”
祝你的项目好运！
于 2008-10-23T02:17:27.717 回答
0
一切都与大小、可扩展性和范围有关。如果该产品能够从“狗粮”方法中获得宝贵的成功，那么 ASAP 将是正确的答案。最终用户体验决定了使用产品的最终结果。
于 2008-10-23T03:08:11.250 回答
0
根据正在完成的开发方式，您可以提前或稍后切换。如果您使用的是 TDD 方法，或者在列表中查找和修复错误的位置较高，那么只要您有足够的功能，您觉得可以帮助您的日常生活，我就会开始。如果您有效地确定了功能的优先级，那么这可能是开发的早期阶段。
否则我会等到你进入一些后期阶段，pre alpha 或 pre beta。这意味着您在发育早期不会感到太多痛苦。
正如其他人所提到的，如果您可以改变您的开发工作以尝试使产品更早可用，那就去做吧！我建议让人们尽早开始认真使用该产品，以帮助评估各种功能并让您的初始用户对产品产生情感上的依恋。关心的开发人员通常会付出额外的努力来使项目变得更好。
于 2008-10-23T02:05:20.580 回答
0
这是关于找到你的“临界质量”特征是什么。如果只是错误而不是功能问题，请立即切换。修复你的错误。如果您需要在工具变得有用之前进行功能开发，请完成这些关键功能，然后切换。
我真诚地希望你不是在写编辑器！;-)
于 2008-10-23T02:05:42.560 回答
0
我想正确的答案是尽快。当然，使用有缺陷的版本一开始会减慢您的速度，但随后您将在开发过程中执行 QA，因此从长远来看，您将节省时间。如果应用程序中存在阻塞，我会建议您的一些团队而不是整个团队切换，以防止大量持有。
于 2008-10-23T02:07:20.653 回答
0
在它达到“Alpha”阶段之前不要开始使用它。它应该具有完整的所有主要功能并且没有已知的严重错误。然后你就可以开始使用它了。
让目标用户试用也很重要，而不仅仅是开发人员（除非它是开发人员工具）。
您想留出足够的开发时间来适应尽可能多的“如果这样做会不会很棒？” 尽可能的特色。
于 2008-10-31T19:33:54.257 回答
0
当应用于开发团队自己不会使用的软件时，这个问题是没有意义的，因此开发人员应该尽快使用它。“可行”意味着它可以很好地工作，并且不会把事情破坏得太严重。
在开发文本编辑器时，开发人员应该尽早使用它，因为错误并不重要。在开发版本控制系统时，开发人员应该只在它被证明是可靠的时候才使用它。当 Subversion 团队离开他们的 CVS 服务器时，这是一件大事。
一个想法是在团队中拥有更早和更晚的采用者，因为后来的采用者可能会发现早期的采用者已经视而不见的东西。
于 2008-10-31T19:44:56.450 回答
0
当狗粮变得开胃时，尽快。我想这是另一种说法，即您应该尽早并经常交付价值。顺便说一句，永远不要提供已知的有缺陷的软件。没有错误的更少功能比有错误的更多功能更好。
于 2008-10-23T02:51:19.397 回答