摘要：
00.经常进行重规划，是敏捷规划和估计为有效探索新产品开发解决方案控件提供支持的方法之一。在每次迭代开始时，都要建立该迭代的计划。发布计划要么在每次迭代后背更新，或者最差的时候也要在每几次迭代后被更新。计划要保持有用，就需要把这些新知识结合到计划中。敏捷估计和规划过程暴露出我们的知识总是不完整的，要 阅读全文
摘要：
00.我们希望所有的沟通，尤其是有关估计和计划的沟通，是频繁的、诚实的和双向的。 01.在一次发布所占据的更长的时间内，项目的利益相关者和参与者需要深入了解项目相对发布计划的进度，并对计划作为修正。 02.如果缺乏信任，就很难有诚实的沟通，所以必须非常严肃地看待失去信任的行为。如果开发人员知道特定的 阅读全文
摘要：
00.任务板具有双重目的，它给开发小组提供了组织工作的方便机制，也是让他们对还剩多少工作一目了然的途径。重要的是任务板让开发小组在如何管理工作方面具有很大的灵活性。 01.绘制发布耗散图是了解项目是否走入歧途的很好的办法。 02.记住可变性是所有估计的组成部分。无论做了多少工作来改善估计结果，开发小 阅读全文
摘要：
00.规划一个大型的、多小组的项目可能需要： *建立估计的共同基准 *更早给用户故事添加细节 *进行前瞻规划 *在计划中加入馈送缓冲区 01.我从来没有使用过大于一次迭代的馈送缓冲区，也几乎没有使用过长于半次迭代的缓冲区。每当我遇到可能需要这样做的时候，我就会之一自己的假设并回顾整个计划，看看我能够 阅读全文
摘要：
00.她们要么具有很高的额外的不确定性，要么一旦出错就会产生更为严重的后果。 01.帕金斯定律：工作总是要拖到最后一刻才能完成。 学生综合症:是在只在快要不能成功的最后时刻才剋是做一件事。 02.进度缓冲区是在除去局部保险的估计值的和上增加的必要安全边界。 03.关于缓冲区建议： *增加进度缓冲区的 阅读全文
摘要：
00.历史值估计需要回答问题： *使用的技术是否一样? *所针对的领域是否一样？ *开发小组是否一样？ *产品所有者是否一样？ *使用的工具是否一样？ *工作环境是否一样？ *对项目估计是否由相同的人进行？ 01.把用户故事扩展成任务并对任务进行估计，重复这样做直到我们发现已经填满了可用的小时数。不 阅读全文
摘要：
00.选择迭代长度时考虑的因素 *正在处理的发布时间长度 *不确定性的多少 *获得反馈的难易程度 *优先级可以保持多久不变 *不用外部反馈自行工作的意愿的强弱 *迭代的系统开销 *紧迫感的产生有多快 01.在客户或用户到底想要什么、小组的速度是多少等方面，以及项目的技术方面都常常会存在不确定性。不确 阅读全文
摘要：
00.发布计划很重要原因： a.她可以帮助产品所有者和整个开发小组判断他们在获得一个可发布的产品之前，必须花多长时间开发多少东西。产品越早发布，开发公司就可以越早开始获得他在此项目中投资的回报 b.发布计划传递了对于在多长时间内可能开发什么内容的期望。很多公式需要这个信息，因为它可以用于其他的战略规 阅读全文
摘要：
00.学会如何看待分割用户故事的方法并不是一种很难获得的技能，但他确实需要实践和经验。 01.分割大用户故事的最佳方法之一就是按照它将要支持的数据进行分割。按照用户故事所支持数据的边界来分割大型用户故事。 02.CRUD操作——建立（Create）、读取(Read)、更新(Update)和删除（De 阅读全文
摘要：
00.预测主体的经济价值是产品所有者的责任，但是则热是和小组的其他成员——程序员、测试人员、分析员、项目经理，等等所共同承担的。 01.把来自新客户的收入和来自现有客户的额外的、增加的收入区分开，往往是有益的。 a.促进现有客户购买更多的许可 b.包含了可以独立出售的可选、附加模块 c.包含允许提高 阅读全文
摘要：
00.主题的价值很难确定，而且敏捷开发项目的产品所有者得到的建议往往是模糊的、最没有意义的：“要根据业务价值确定优先级”。 01.开发活动优先级时必须考虑的4个因素 a.获得这些功能带来的经济价值 b.开发新功能所需的成本 c.开发新功能所产生的学习和知识的量及重要性 d.开发这些功能所减少的风险 阅读全文
摘要：
00.有利于故事点的考虑因素 a.故事点有助于驱动跨功能的行为 b.故事点估计不会过期 c.故事点是纯粹对规模的度量 d.故事点估计通常更快 e.我的理想日不等于您的理想日 01.敏捷开发小组包含了来自于构建产品所需所有学科的成员，包括程序员、测试人员、产品经理、可用性设计师、分析员、数据库工程师等 阅读全文