第8章
技术债指有意选择的捷径，又指许多损坏软件系统的不良实践。
导致技术债的原因：
1.不合适的设计
2.缺陷
3.测试覆盖不充分
4.手工测试过多
5.集成和管理版本不善
6.缺乏平台经验
技术债的后果：
1.爆发点不可预期
2.交付实践延长
3.缺陷数量可观
4.开发和支持成本上升
5.产品萎缩
6.可预测性降低
7.表现越来越差
8.挫败感四处弥漫
9.客户满意度降低
技术债的起因：
1、如期完成的压力
2、试图以错误的方式提高速率
3、误区：减少测试可以提高效率
4、债累债：旧债不还很快还会有新债。影响版本的发布速度。
第12章
特性团队：特性团队是一个跨职能，跨组件的团队，能够从产品列表中抽取兵完成最终客户想要的特性。一个特性团队应该拥有完成任务所需要的全部技能。Scrum 更倾向于组件特性团队。
组件团队：是开发组件或子系统，这些组件或子系统只能实现最终用户想要的部分特性,这个团队是由专业相近的人组成。
特性团队与组件团队组合
只有一个特性团队从产品列表中抽取对最终客户有价值的特性，这个特性团队全面负责完成所有任务。但是这种情况下，仍然会有一个组件团队帮助维护各组件的完整性，他们仍然有一个列表（偏技术的工作，也许是偿还技术债的工作）。组件团队成员也可以成为特性团队的成员
执行SOS团队，由各个开发团队的成员组成。每个根据哪个成员比较熟悉团队依赖问题来指派参会人员。会议不会总开，每周开几次。
会议议题：
•上次会议之后，我的团队做了哪些可能影响其他团队的事情？
•在下次会议之前，我的团队将会做哪些可能影响其他团队的事情？
•我的团队存在哪些问题可以在其他的团队的帮助下解决
为了完成一个版本的产品，各个团队要在同一段预定的时间，完成预定的任务
把一个版本的产品比喻成火车，
把每个车厢看成一个团队的task
为了让火车能够准时出站，（就是完成一个版本的发布），这几个团队的预定任务必须，在出站前完成
火车时准时出站的，也就是产品的版本是准时发布的。
如果某个团队没有完成预定的任务
这个版本还是要发布的，没完成的任务就要等下个版本再完成了。
