在成⻓型的团队中解决技术债是⼀项挑战，⾸要做的是投⼊时间去执⾏ 。
不管你的研发团队有多么丰富的经验，还是拥有何等体量的代码，或者是新技术的运用，总会产生一定程度的技术债，简单来说，其实是还有很⼤的改善空间并且可以把它做的更好。技术债的影响范围很难被描述，在于新需求总是在不断的变化，新功能交付的时间不够快速，或者是对研发⼈员的效率满意度不是很⾼。
然⽽，技术债是⼀个被⼴泛应⽤的概括性语⾔，我想把它归纳为“代码库中本来就存在的问题”。
当你发现很多成⻓型团队⼈员在这些症状中苦苦挣扎时，是时候要想到⼀个解决技术债的具体策略，具体⽅法，具体分析，但是有⼀点需要肯定的是，你需要投⼊时间去迈出第⼀步。
在⼀个重视商业价值环境的体系中，想要抽出时间来从事纯技术问题是⾮常困难的；单单向团队中不同分工或技术领域的成员解释重构或切换功能库所带来的潜在的好处都不那么容易，更不⽤说来⾃其他业务线上的同事们了。解决技术债很容易成为管理者们的问题，⽽不是⼀个技术问题——这可能是许多团队难以解决的核⼼问题。为组织选择⼀套因地制宜的⽅法，可以避免⼀些问题。
All together now
⼀种⽅式是安排重复周期（例如每六周一次），组织所有⼯程师⼀起完成技术任务，并不是团队中积压的工作。我在两家创业公司中都⽤过这个⽅法，我们称呼为“Engineering Weeks ”。
我不确定这种做法在其他公司是否有所涉及，在⽹上搜索也没有这个话题的任何信息，如果你的团队这样做，我很愿意了解一下。
如果你在⼀个⾃主研发型团队中⼯作，那么“Engineering Weeks ”的想法确实有吸引⼒，因为它有⼀些得天独厚的优势：
赋予工程师的一些决定权，让工程师们决定那些是最优先解决的问题。
并允许来⾃同⼀技术领域但是担任不同功能团队的开发⼈员⼀起⼯作。
通过来⾃不同团队的⼯程师可以分享他们的经验，并使得整个代码仓库更容易更全⾯的得到解决 。
Engineering Weeks并不仅仅对于树立以及影响小组内部的工作风格发挥作用，也将会给整个团队带来影响。
在实践中，这种⽅法的特性也有所不同，但最终两家公司都放弃了这种想法，我们⾯临的⼀些挑战主要包括：
难以向组织内的其他成员“推销”把⼿头⼯作停⽌⼀周的想法。⽆论我们在解释⾼效率的产出并将技术术语翻译成相关术语付出了多少精⼒（相信我，这是⼀个巨⼤的⼯程），we never managed to get rid of the “engineering taking a break” optics expressed behind the scenes.
事实证明，⼀周甚⾄两周的时间根本不⾜以应对我们设想的重⼤技术变⾰，尤其是那些使跨团队协作受益最多的技术变革。尤其是那些让跨团队协作受益最多的技术变革。 当然你可以在Engineering Week内分出⼀个更⼤问题的⼀部分来做，但在下个⼯程周到来之前，你会失去所有动⼒和意愿。
固定的时间表打乱了功能团队的交付节奏，只需要⼀个sprint就能发布⼀个新功能不⾹？不好意思，我们需要等待⼀周？版本发布后还要扫描bugs。运⽓不好的话，⼯程师下周有可能会翘班。尽管⽇程提前已经规划好了，但是团队还是会感觉⼯程周很奇怪。
我认为这些挑战和经验是可⾏的，如果拥有经验丰富，⾃我驱动的团队，拥有资深pm的技能，并且有⼀些灵活性的协调技巧，那么它对你来说可能是⼀种有效的实现⽅法。它可以保证您有时间解决技术债的问题，同时获得⼀些独特的优势。我的直觉告诉我，它适合⼀些⼩型团队，维护系统仍然可以通过 grassroots-driven initiatives得到改善。
Power to the teams
另⼀种⽅法是让每个功能团队分配时间来解决技术债。如果我们的团队做出正确的决策，那这种组织⽅式可以运⽤⾃如，但如果运⾏起来也会带来挑战。 如果没有代码库的所有权限他们不能能把代码库维护好。
由于当前团队优先级的不匹配，需要跨团队部⻔的协作很难推进。
如果多个部⻔在内部花费时间解决相同的问题，没有沟通以及协调过，导致的效率会极低，这种组织⽅式不利于跨团队的有效沟通。
也有⼀种可能是，如果部⻔内缺少⼀位资深的管理⼈员，他们可能是花更多的时间围绕在技术债中。
这些挑战虽然不简单，但是可以减少⼀部分麻烦。另⼀篇博⽂的思想主题是如何处理所有权的问题，以及如何推动跨部⻔协作及知识共享，稍后可以继续关注。
功能型团队会使⽤排期的⽅式来确定优先级，以便确定下⼀步要做什么。通常情况下，解决 技术债的优先级最⾼，需要优先处理。但是在实践中，这种情况经常会被推翻，因为我们要快速上线新功能，快速迭代解决线上问题，或者存在“如果我们⻓期坚持下去的话，那我们可以笑到最后”的侥幸⼼理。如果这种⼼态已经影响到了团队和客户的话，他们才会发现解决技术债的重要性，但是这个时候已经晚了。
为了避免这种情况，我们需要在团队中明确解决技术债问题，诸多⽅法可以避免这个问题，⽐如：
X% Engineer Time This is the approach I’ve encountered the most. ⿎励每个开发⼈员在他
们有限的时间内花⼀⼩部分时间优先考虑在技术⽅案的实现上。这给个⼈带来很⼤的压⼒，但是也是开发⼈员们最容易忽略的事情。Tech Fridays 在每周五有个专⻔的时间段，只需要半天的时间，星期五的⼯作时间变得不那么紧张，每周安排专⻔时间段让⼤家持续思考并养成技术债的习惯。缺点是这个时间段很短，除了简单的重构和升级之外，能做的事情也很有限。
Cooldown Weeks-这是Engineering Weeks 的⼀个转折点,在交付团队中针对每个sprint进⾏优化，我认为这个词起源于 Basecamp 的 Shape Up，尽管这个观点很⽼套。在完成每个sprint 之后，我们并没有对新的sprint进⾏开展，⽽是花费⼀周的时间在处理上⼀个sprint的残局，这不仅仅只是Tech debt，为下⼀个sprint做准备，做调研，修复bug等等，这些都是在
Cooldown Weeks内值得参考的事情。每个团队成员应该规划⾃⼰要负责的⼯作，⽽不是像在 sprint团队中那样规划⼯作。
对于跨部⻔的Engineering Weeks的优势体现在，在每个迭代周期内，团队成员都可以找到最适合他们⼯作的⽅法。然⽽，这需要跨部⻔扮演多个⻆⾊，有⼀些基础设施和发挥积极主动性来⽀撑协调更⼤的技术项⽬达到资源共享—这种也更适⽤于更⼤的研发团队。
选择的方法并不一定是非此即彼，你也可以尝试将Engineering Weeks和团队工作时间并行，但是它可能会压缩你的⼯作时间。
Keeping up
不管你选择⽤那种⽅法，最终结果需要团队的每个成员积极参与和配合进来。 我们需要对⼀个健康的团队实⾏责任制，以便可以推进和花费时间在技术债上，他们不需要为某⼀个错误承担相应的责任，⽽是对于⾃⼰所做的事情进⾏有有条理和积极开放的⼼态进⾏沟通。
领导需要对此推动和实施，团队成员都必须清楚知道代码库中存在多少tech debt并且需要多久来解决。
靠谱，理智和⼤范围的做到这⼀点会是⼀个巨⼤的挑战。
处理技术债对于这个庞然⼤物来说只是冰⼭⼀⻆，从技术和专业知识⻆度来看这个是很有吸引⼒的话题，这对于公司研发产品和运作有很深的影响⼒，我期待和⼤家⼀起更深层次的探讨这个问题。
最后，感谢阅读。
{测试窝原创译文，译者李媛媛。}
