项目经理竟然说不怕延期，你们停下来修bug吧
如果我们因为第一个sprint质量不好，延期sprint，会引起整个项目的延期怎么办？项目经理不应该担心吗？
这个问题要有几个思考点
一，质量有多重要？软件质量建设是软件工作的成本（来自《持续交付》作者乔梁）质量越好，成本越低，效益越高；软件的质量问题
今天不解决，明天也要解决，即软件质量是无法回避的；
较早解决比较晚解决好，即软件质量会蔓延影响系统其他部分的建设、也会影响上下游系统建设；
所以说即使人为强制第二个批次开始，并不会真的避免延期。只会因为质量隐患似的进度变得更不可控，增加整个建设的成本。
二，在发现质量问题时第一时间喊停和建设质量，可以在较早期发现整个项目的风险，从而通过其他手段对项目风险进行控制。在现在的大多数软件工程中，逐步交付价值是需求方普遍接受的，即交付范围通常是可协商的，而交付时间的不确定和交付质量差往往是不能被接受的，即
没有按照约定时间交付任何东西；
不断延期无法准确预估交付时间；
交付但是bug非常多甚至不可用；
都会导致需求方丧失信心，甚至导致项目的全部失败
基于上的价值取向，我们以质量建设和时间盒为高优先级，减少交付批次（即交付更少的功能）维持稳定持续的质量交付；
三，项目管理应该从“聚焦于按照时间计划完成”变成 “聚焦于按照优先级有节奏交付”。原因在于度量项目成功的不是每个时间节点完成计划要做的事情，而是每个时间节点交付客户（上下游都是客户）需要的业务价值； 换一个角度看，延期 是真的问题本身吗？还是无价值产出、价值产出无节奏才令人头大？
四，最后，软件计划几乎很少生效，因为软件建设不同于普通工程，它非常复杂充满变数，往往在全部完成时复杂度才能被完整认知。与其预先制定计划，更应采用随时调整计划的方式进行管理。
plan is nothing， planing is everything。这个过程，研发管理应该既要有宏观视角，又要避免做大而全的计划，采用JIT（Just in time）的建设。
现在回到问题本身，当软件质量出现问题，需要更多时间解决，只可能说明制定计划过于乐观，没有充分预估到风险。我们需要在风险发生的第一时间，揭示风险并及时处理（比如调整整个项目的预期，干系人沟通），会远远好于我们在项目的最后阶段做响应，所有项目管理者应该都了解，更早的发现问题，会有更充裕的时间/资源去协调；
试想，在第一个批次2周的时候就发现有问题并及时揭示风险，预告给干系人，同时进行介入，调整研发计划，甚至安排加班，是否会比2个月后才去响应好一些？