计划和技术债务

一旦有了一个程序（针对一个业务目标的一系列相互关联的项目）并且拥有技术债务，就会遇到更大的问题。 不仅仅是因为技术债务可能更大。 不只是因为您有更多的人。 但是，因为您也是在地理上分散的团队，所以这些团队几乎总是​​按职能和时区分开。

因此， 在基础架构，技术债务和自动化测试框架中 ， 关于团队并置的很好的例子很少出现在程序中，除非您将跨职能的团队并置在程序中。 如果他们这样做，那就太好了。 你知道该做什么。

但是，假设您没有它们。 假设您有我在咨询实践中看到的东西：一个位置的建筑团队，或一个位置的建筑师和世界各地的建筑师； 在多个时区的开发人员和“他们的”测试人员； 产品所有者与开发人员和测试人员分开。 该程序之所以称为敏捷，是因为该程序在迭代中运行。 而且，由于它是一个程序，因此该软件预先存在组织中的敏捷过渡，因此您在wazoo（技术术语）中承担着传统技术债务。 你是做什么？

让我们看一个例子，看看它如何工作。 这是一个由几个客户组成的故事。 讲这个故事时，没有客户受到伤害。

我们还假设您正在开发自定义电子邮件客户端的5.0版。 版本4是先前的版本。 版本4遇到了麻烦。 迟到了6个月，而且越野车相当多。 有人出售敏捷作为使软件无错误且及时的方式。

您没有针对大多数代码，单元测试或系统测试的自动化测试。 您有一系列缺陷，使开膛手杰克的杀戮清单看起来像是孩子的游戏。 但是敏捷是您的银弹。

项目经理位于伦敦。 整个计划的测试人员都在班加罗尔，因为管理层先前已经解雇了所有测试人员并将测试人员外包。 那是在版本2中恢复的。此后，他们雇用了所有班加罗尔测试人员作为班加罗尔子公司的员工。 该计划的架构师位于旧金山，并且有一个架构师团队，该团队分散在其他四个团队中：丹佛，洛杉矶，慕尼黑和巴黎。 开发人员聚集在“卓越发展中心”：洛杉矶丹佛，剑桥，巴黎，伦敦，慕尼黑和米兰。 那是8个开发团队。

哦，如果您认为我在跟这种情况开玩笑，那不是。 这是我的大多数拥有分布于不同地理位置的团队和计划的客户每天都要面对的问题。 他们应该得到您的同情和同情。 不要告诉他们：“不要敏捷。” 真是的 他们有权行使敏捷性。 您可以告诉他们：“不要去Scrum。” 那是合理的。 Scrum适​​用于跨职能的同一地点团队。 敏捷适合每个人。 Scrum用于特定子集。

你是做什么？

1. 将特定的测试人员分配给特定的开发团队。 没有呼叫人资源； 从而使管理人员可以像对待资源一样对待人员并即插即用。 您需要组建坚如磐石的团队。 一旦团队在一起，就可以命名。
2. 为团队命名，以便团队反映出他们工作的要素组。 电子邮件产品有什么作用？ 它获取电子邮件，对电子邮件进行排序，删除，转发，创建新邮箱，等等。 必须为功能区域命名八个功能团队：通用功能的平台，排序，删除，转发。 有两个团队在Platform上工作。 他们分别称为Platform 1和Platform2。有人建议他们将自己命名为Suuss 博士的书Thing1和Thing2。
3. 确保您有足够的产品负责人，以便他们可以为每个功能区域制定路线图。 有了路线图，团队就知道他们要去哪里。 更重要的是，架构师知道程序的去向。
4. 建筑师会思考并提供足够的指导。 在一个小型项目中，体系结构可能会随项目而发展。 在较大的程序中，该风险太大。 您有太多人在并行开发，因此架构无法在没有指导的情况下自行发展。 但是我的意思并不是说应该有一位全知的大师级架构师。 不不不。
   我希望架构师既是开发团队的工作成员，又是架构实践团队的一部分，他负责架构设计，指导架构的业务价值。 我不想要大体系。 但是在想什么呢？ 当然，这是个好主意。 坚持一个主意吗？ 坏。 愿意提出一个主意吗？ 大。 愿意参加沙盒比赛并辩论几个想法吗？ 大。 我之前在《敏捷架构师的领导方式》中写道。
5. 确定完成对每个功能意味着什么。 您必须对每个功能都有接受标准。 这意味着什么？ 您需要每个团队的产品负责人在场。 您仍然需要与每个团队进行对话以讨论完成的意思。 特别是对于地理上分散的团队，在迭代开始时创建积压订单时就需要进行对话。
6. 由于开发人员与测试人员的时区不同，美国开发团队在计划与测试人员的迭代时遇到了麻烦。 因此，他们询问产品负责人，产品负责人是否会在卡片上写下多个短语，因为这将帮助他们更快地完成迭代计划会议。 有人要早起或熬夜，无论哪种方式，都会有人受苦。 多做些准备比少睡多了才有意义。
7. 决定进行持续集成并坚持下去。 尤其是如果您知道自己有技术上的债务并且不想创建更多产品，则必须立即进行连续集成。 这样可以避免更多的技术债务。
8. 我已向一些团队建议他们进行为期一周的迭代，以使他们停止胡言乱语并使故事变小。 估算的重点是让您对团队的想法有所了解，而不仅仅是致力于。 这个想法是，如果您知道使故事变小所需要的，那么您会。
   取而代之的是，我们围绕着估算和管理万物的速度追踪所有这些疯狂的仪式。 （是的，我已经起草了很长时间了，上周我写了《 为什么管理人员关心速度》？ ）。您知道，速度有点像重量。 只有您和您的医生需要知道您的体重。 如果您健康，那就很好。 如果不是这样，则需要进行一些更改。如果团队速度不健康，则作为一个团队，您需要进行更改。 但是，您的管理层没有业务介入。只有您可以更改它。
9. 当您限制迭代长度时，您倾向于使团队蜂拥而至。 这是一种趋势，不是既定的。 如果我真的是宇宙的女皇，我会下令，但我不是，所以我不会。 如果您想减少技术债务，甚至消除程序中的债务，请说明您的团队一次只能处理一个故事，直到完成该故事为止。 这个故事将变得光彩照人。 快速。 您不必担心会进行哪种测试。 一切都会完成。
10. 明确讨论您将自动进行哪些测试以及何时进行。 在一个程序中，我假设我们将首先进行自动化系统测试。 我认为稍后我们将进行探索性测试。 这是因为，如果在启动程序并继续进行重构时没有开始为自动化测试构建某些东西，那么您将永远无法追上。 我假设每次修复缺陷时，都会对其进行自动化测试。 我还假设我们将这些假设纳入我们的开发方式中：-)

到目前为止，这全都在于防止更多的技术债务，而不是在您输入从未见过的代码或测试时跳过技术债务时会发生什么。

如果您打算走进壁橱，拿出一件衬衫，然后关上壁橱门，那是一回事。 但是现在，您走进了电视中那些因death积而死亡的节目之一，您有义务去做某事。 您可以在遇到问题时记录下来； 您可以让产品负责人知道； 提交缺陷报告； 编写测试以控制债务； 也许您还有更多选择。 无论您做什么，都要确保已做某事。 不要打开门，看到里面的烂摊子，然后关闭烂摊子上的门。 真诱人。 哦，我的，这很诱人。

请参阅，由于程序的大小，所有内容都会被放大。 拥有更多的人和更多的团队，一切都会变得更加艰难。 事情发生得更快。 如果您在同一地点跨职能团队，则没问题。 但是，如果您没有在同一地点的跨职能团队，则必须与已有的人员一起工作。 而且，如果您已经有一个大型的旧产品，则希望以小块的方式解决技术债务，以少量的方式进行重构，并在进行时进行集成。

我的理念是：程序越大，您越需要习惯于小块工作，并随身携带。 充分实施一个小故事，将其集成到主线中。 程序上的每个人都这样做。 如果您需要集成团队的帮助，那就去吧。

但是，如果每个人都只实施小故事，并且每个人都发现了自己的技术债务，那么您就不需要一支整合人员大军。 当您对集成和发布负有技术责任时，您仅需要一支由集成人员组成的队伍。 解决此问题，每个人都可以对自己的集成负责。

而且，如果您不能发布，那就是架构师应该开始的地方。 如果您无法进行持续集成，那么架构师应该从这里开始。 因为那是阻碍您在产品上取得进步的原因。 从发行版本开始进行反向工作，然后架构师可以处理产品的其余部分。 在您可以可靠地发布和构建之前，该产品的其余部分无关紧要。

参考： 管理产品开发博客中来自JCG合作伙伴 Johanna Rothman的程序和技术债务 。

翻译自: https://www.javacodegeeks.com/2012/05/programs-and-technical-debt.html