我看到的以产品为导向 （而不是项目）的主要问题之一是为正在进行的工作做准备。 完成此项目后，您可能无法启动该产品的下一个项目。 您可能需要为各种产品循环项目，因为您没有足够的人同时执行所有项目。 但是，如果要发展产品定位，则需要考虑未来。 我喜欢考虑未来，而不是设计或架构，而是技术上的卓越。 否则，团队将成为技术债务的人质。
我经常听到人们说“我们以后可以解决”之类的事情。 或者，“我们的客户需要我们解决问题，而不是给百合花镀金。” 团队可能正在完善已经存在的工作。 我的经验是，品种经理（和产品负责人）经常敦促团队停止思考未来，而专注于现在。 我们称其为技术债务 。 实际上，这是未完成的工作。
先前版本中的技术卓越性使我们可以在以后的版本中更快地移动。 （无论该版本是迭代还是整个项目。）
在质量驱动项目管理中，我根据您的产品在产品生命周期中所处的位置来描述对质量的需求 。 （我还在“ 管理它”中写了更多有关这些想法的文章！ ）
对质量的需求与客户所看到的有关。 对于产品开发人员（开发人员，测试人员，UI，创建产品的每个人）所看到的内容，您可能需要不同的内部质量定义。
这是内部质量技术卓越的一些方面：
- 构建系统的简便性和速度
- 单元测试自动化的便利性，覆盖范围和速度
- 系统测试自动化的便利性，覆盖范围和速度
- 代码和自动测试的可读性
- 您需要多少手动测试。 这不是探索性测试。 这是手动测试，因为它不是自动化的。
我会停在那里。 您可能对产品还有其他技术上的卓越要求，例如性能或可靠性或占用空间等。
构建系统的简便性和速度以及各种测试自动化是指产品开发人员能够保持最新状态并获得有关其当前工作的反馈。 没有轻松，人们就不想签入并开始构建。 没有速度，人们就不想检查测试以查看是否损坏了任何东西。
您无法轻松地进行构建和测试，就无法进行持续集成（有时甚至是持续交付）。
为什么代码和测试具有可读性？ 因为那是大多数产品开发人员整天要做的事情。 他们阅读已经存在的代码。 他们已经在那里阅读测试。 这就是他们决定如何添加该小功能以及他们需要哪些新测试的方式。 如果代码和测试不容易阅读，人们会重新发明轮子（通常采用康韦定律），并增加代码和测试的复杂性。
您需要的手动测试越多，运行测试的难度就越小，并且产品开发人员在了解他们是否犯错时所获得的支持也就越少。 在我们大部分写作中，我们当然会进行拼写检查。 那是一个自动化测试。 为什么我们不将产品的大多数测试作为自动化测试运行？
如果我们注意这些内部质量指标，则可以更快地创建发布。 这是否意味着我们“放慢脚步”？ 也许。
如果您的团队不配对，不成群，也不暴民，您就会变慢。 那是因为您必须安排代码审查和测试审查。 安排时间很耗时，打乱了人们现在正在做的工作。
如果没有文档，您可能会放慢速度。 我喜欢体系结构描述和体系结构图片，因此人们可以看到其路标。
而且，不要告诉我有关自我记录代码的信息。 自从我还活着以来，这种谬论就一直存在。 那是错的。 还是错 我们需要留下路标，让下一个人触摸此代码。 即使我们是下一个人。
如果您通过每一个小小的变化继续构建卓越的技术，您会发现以后不需要时间来构建它。 （我在“ 创建成功的敏捷项目”中对此进行了介绍。）
卓越的技术可以帮助每个人考虑他们所做的工作对未来产品的影响。 您现在进行的清理工作越多，当您返回阅读此代码或稍后进行测试时，认知负担就越小。
如果您想要/需要产品定位，请牢记卓越的技术。
翻译自: https://www.javacodegeeks.com/2018/09/product-orientation-requires-technical-excellence.html