微服务架构 自动化测试框架
而且，这就是我说的部分，“哇，内莉。 技术债务是不是故事的一部分？ 为什么有人会关心您如何照顾代码库？ 还是自动化测试基础架构基础？ 为什么有人会关心您如何管理系统？ 您不是负责环境吗？”
通常会有一个震惊的沉默。 从那时起，我意识到，尽管项目或程序的外部看上去很敏捷，但项目文化却并不敏捷。
敏捷的项目文化拥有一支受过授权的团队，这个团队知道他们必须离开代码库一点，使其比前一天发现的更加干净。 知道他们必须每天改善自动化的团队。 直到整个故事都完成后，才会知道故事的团队，其中包括自动化测试和自动化测试框架。 知道他们必须共同努力才能每天交付业务价值的团队，而不仅仅是在迭代结束时。
此问题与产品负责人的部分特性问题有关，该问题不希望花费迭代时间来安排迭代中除特性以外的任何事情。 如果产品负责人仅看到开发人员可以执行的代码，而不查看测试开发人员可以执行的操作，则该项目就不敏捷。 如果只有代码开发人员来估计待办事项，那将是一个巨大的问题。
以下是一些解决方案：
- 将项目上的每个人称为“开发人员”。 或者，称每个人为“测试人员”。 我将团队称为产品开发团队，并将团队中的每个人称为产品开发人员。 您必须改变这样的观念，即团队的一部分负责代码，一部分负责测试，并且这两个部分不能一起工作。 这两个部分（加上所有其他部分）负责将功能部件移动到一种紧密结合的方式来完成。 您加强一组测试人员和一组开发人员的力量，完成工作的机会就越少。
- 确保您具有完成的团队定义，或者以某种方式知道完成的含义。 它不是开发人员完成的，也不是测试人员完成的，它是演示价值完成的，或者发布能力价值完成的。 我知道有些团队需要一段时间，并且需要进行很多讨论才能达成共识。 讨论一下。 如果您不同意，请不要担心。 继续讨论。 这次讨论对您作为团队的成功至关重要。
- 完全停止估算。 如果您的待办事项中的项目大于整个项目团队在一两天内可以完成的项目，请将其分开-不是分解成任务，而是分解成较小的商业价值故事。 现在，您拥有的故事数量与迭代中的天数一样多，或多或少。 使估算更加容易。 关于故事的讨论更多，而估计的时间更少。
- 在编写代码时，无论您在代码中的任何位置，都比查找代码时干净一些。
- 在进行测试时，请使其比发现时干净一些。
- 制定包括自动化在内的产品路线图。 如果您的产品所有者不希望或不能拥有自动化，那么技术人员必须拥有自动化的目标和计划。 但是自动化是一个项目。 您应该有一个愿景和发布标准。 就像任何其他项目一样，您应该适应该项目中的更改。
- 无论您是谁 ，在编写故事时，无论身在何处，都可以提供帮助。 如果您本质上是代码开发人员，则从代码开始。 这是一个故事来说明我的意思：
您碰巧是Platform Paul，您进行了一些开发，一些重构，也许一些架构，一些单元测试开发，无论是什么使您的代码正常工作并签入。
现在，你们三个人与另外两个完成GUI和中间件的开发人员核对，直到现在，您才可以讲故事。 因为该功能需要一点平台工作，更多的中间件和一点GUI才能完成。
产品负责人，如果您不想为技术债务提供资金，您将创造更多的债务。 您将放慢创建特征的速度。 我在“ 管理您的项目组合”中有示例图：增加您的能力并完成更多项目 。
您不必拥有完美的自动化测试框架，而不必在项目开始时就拥有。 您不知道项目开始时是什么。 您只知道自己需要一个。 但是您可以编写一些代码并对其进行重构。 我写了一篇专栏文章。
而且，当涉及到产生技术债务时，您必须做的一件事就是停止。 无论如何，您都不能创造更多。 而且，如果您徘徊在某些具有技术债务的代码或测试中，那么我看不到如何成为一名专业人士并将其留在那儿。 至少，您可以创建一个缺陷报告，内容为：“我们这里有技术债务。” 您知道它会在最不合时宜的时机咬您。
我不喜欢“重写系统以避免技术债务”。 但是您和我俩都知道，技术问题会减慢系统开发的速度，并且通常会减慢系统性能。 我想避免重写。 我要收拾行李。 如果您清理每一个为期一两天的功能，则永远不必付出巨大的代价。
参考： JCG合作伙伴 Johanna Rothman在管理产品开发博客上对基础设施，技术债务和自动化测试框架的想法 。
翻译自: https://www.javacodegeeks.com/2012/04/infrastructructure-technical-debt-and.html
微服务架构 自动化测试框架