通读教材第五问
① 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文
② 列出一些事例或资料，支持你的提问 。
③ 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。
【或者】我反对作者的观点（提出作者的观点，自己的观点，二者差别，以及理由）。
第14章中提到，可持续工程与Scrum，我的理解是：
模型：可持续发展工程有很多种方法，我们今天来讲讲两种模型
专用时间模型：
在专用时间模型中，一个Scomm团队负责开发项目的Poduot Backog,同时还负责用专门的时间来处理现有产品或者服务出现的问题。这些团队把维护遗留系统当成他们在新产品开发项目，上的休假或者做其他事情的时间。他们把本来可以用在SprintBacklog条目上的工作时间先抽取一部分出来。 此后，再继续做Sprint 计划与分解及相应的估计工作。如果没有跟踪过历史数据，就很难确定需要从团队的Sprint中抽出多少个小时。如果团队不知道过去花费多少小时用于遗留系统的中断与可持续工程，就要猜测一下。毕竟，你的团队已经有一-些经验，所以这样的猜测在某种程度上还是准确的。然后，随着每个Sprint的进展，收集每次需要团队处理的事件实际花了多少时间。这样的数据可以使今后的猜测更精确。
20个小时之间。现在，产品负责人有足够的数Sprint 完成210个小时的用户故事，而且时的用户故事。产品负责人还知道，在图142中，我们可以看见团队有5个s团队有可能在每个Spinin的数据。花在数据非常自信自州表教事的时间是120、Spint信地认为团队能够在每个那队在每个m花最多完成250个小
在可持续工程上的时间是50~90个小时之间，
工程。 230小时以外的时间很可能专门用于司的会
专用时间具有以下优点。
. 在新系统上工作的人感受到了遭留系统的缺陷所带来的痛苦，这样度有的于保证同样的缺陷不会重复发生。
可能总体成本更小。
对遗留系统的修复可以(几乎)立即加入新系统的开发中。没有人觉得自己被驱逐到专职的可持续工程团队。专用时间也有以下缺点。
职业团队模式：在故事中，Rohit 建议组个专职团队专门维护遗留 系统。我在微软和其他公司工作的时候，多次使用了类似的方法。这个拉动系统借鉴了Scrum和看板精益中的一些元素。
就像Scrum团队，个专职的可持续工程团队也具备完成 工作所需的所有技能。而且，也像Scrum团队一样，团队应该完成项目干系人确定了优先级的ProductBacklog,只是在这种情况下，Product Backlog由问题而不是功能组成。这些问题可以放入Product Backlog,也可以放到白板上由团队提取。还有，就像Scrum团队一样，这个可持续工程团队也应该有产品负责人来保证这些问题已完成预检分类，以便优先级最高的条目总是最优先处理。
Sprint的长度应该比Scrm常规建议的短-些， 以便团队可以更快地响应变化和问题，就像实时的-样。 我提倡而且喜欢做一天的Sprint, 但有些问题可能无法在一天以内解决与发布。此时，需要每天向项目干系人和团队其他成员报告问题的进展情况。
团队做每8发布的时候，团队的活动(计划、会议、发布和承诺)要快速进行。早上，有一个简短的计划会议，讨论过去.天出现的新 问题和正在处理的遗留问题。 团队成员处理和解决问题之后，可以在. 天当中或者在一天结束的时 候打包一起发布，发布的时间选择常常取决于组织的具体情况。在第天开始的时 候，团队简要谈谈前-天取得的进展，然后再讨论当天的计划。但是对于比较复杂的大问题，专职的可持续工程团队应该按周进行目标计划会议、每日站会和每周的项目干系人会议。
目标计划
在每周的第一天，团队一起开会评审 大型工作问题队列并计划周的目标， 比如“从系统中转移5000个订单”或者“把对客户的支持响应时间减少10秒钟”。团队成员评审当前的问题列表，并把它们与每周目标联系起来，依据他们当时所了解的信息来确定当前这一周能够完成的工作。 他们明白，如果有突发的服务中断或者意外事件，这个计划可能会变。
每日站会与每日发布
在目标计划会议结束的时候和每天开始的时候，团队应该召开每日站会，团队成员在会上确定哪些问题他们认为可以在当天处理并对完成这些问题做出承诺。对于当天正在处理的问题，他们还要报告状态并做发布计划。在每天结束的时候，团队还要一起开会分享进展 与障碍，检查是否有新的问题需要加入问题列表，并且如果可能，还要演示与发布工作成果。团队应该努力做到在业务部]能够处理的前提下尽快发布修复。我的团队是每天发布，我们组织里其他团队是每周发布。修复特定问题的紧迫性取决于很多因素，包括客户正在经历的痛苦。如果在一周之内出现新的问题，那么响应这个问题就是专职团队的工作。
项目干系人会议
每周至少次(如果出现紧急问题则需要多次)， 团队应该与项目干系人起开会演示缺陷修复并对新问题确定优先级。项目干系人应该明白，有些在演示的修复可能已经发布了。举行这样正式的评审会议，有助于团队产生成就感并使项目干系人有机会表扬团队的努力并对可能改善流程的方法提供适当的反馈。在这样一个团队中工作是值得的，但也可能困难而繁琐。
为一种管理遗留系统问题的方法。在这样一个专限团队中工作是值得的，
专职团队具有以下优点。
团队。眼，队可以是新员工的培训场，在他们学习老系统后发可以入有
专职团队可以快速响应。
团队成员是(或者将成为遗留系统的专家。
相较于新产品团队，他们常常能够以更快的速度处理问题他们能够更频繁地发布。专职团队具有以下缺点。
工作往往重复、枯燥。
团队成员可能对他们的工作缺乏激情。
如果没有做到快速修复或没有得到承认与认可，士气可能会受挫。
专职团队的开销更大，因为有专门技能的人需要重复分派到专职团队和更大的组织。
其他团队可能并没有认识到还有别的人在帮他们善后。
成功要领
苏瑟兰Der StertanD曾经告诉我，最好的代码就是“没有代码”，因为“没有代码”意味着系统是可持续的、可维护的、运转良好而且不花任何成本。不幸的意，我们必须写一些代码来构建我们的系统。 而且所有的代码，- 且写出来，就会成为遗留代码。有单元测试与自动化验收测试等支持部件、有良好文档的、整洁的遗留代码，维护的成本比较低，但是维护成本与责任是无法根除的。
不管选择什么模型来支持遗留代码，都要像对待团队开发新功能的流程- -样来对待可持续工程流程:随着时间而进化流程，做出改变，使团队更成功。
专职维护团队成员的轮换
如果组织有一个专职的维护团队，那么它的成员可以很可能也应该在开发新功能的团队与维护团队之间进行轮换。这一点很重要，有几个原因。首先有助于防止接门放能是人们反复做同样的重复性任务优其是用同样的技术或能系统的同一
