敏捷书籍总结

看板实战

• 在制品（WIP）
  我们将剖析在制品( Work In Process, WIP)的概念。首先，让我们谈谈WIP这个缩写，以及这个词该如何解释。WIP至少有两个不同的含义:
  1.进行中的工作
  2.流程中的工作
  这两个意义在精益文献中都被广泛使用。我们研究精益和看板的时候，碰巧看到了“流程中”这个词。在本书中，我们使用“流程中”这个表述，但如果您愿意的话，也可以把这个词换成“进行中”。

• 什么是在制品
  在制品是指你手头正在处理的所有事情，包括正在处理的任务、等着被验证或者部署的工作项、还有那些虽然还没开始处理，但已经等在你的收件箱里的事情。也就是，所有那些需要完结，才能交付最终客户价值的半成品。

• 约束在制品
  本章谈到了流程中的工作，特别讨论了通过约束在制品来缩短前置时间。利特尔法则确定无疑地告诉我们，更多的在制品会让每个工作项的周期时间变长。你应该约束在制品，以获得更快的流速和更短的前置时间。

• 在制品形式
  在制品有多种表现形式，我们看看软件开发领域中的几种常见的表现形式:
  1.没有被实现的需求规格说明;
  2.“在我的机器上可以运行”但还没有集成的代码;
  3.未测试的代码，它们可能符合也可能不符合你的标准;等待下一次发布，还没有进入生产环境的代码。大量在制品会带来的问题和负面影响:.
  4.更多的上下文切换;
  5.被拖长的反馈环，进而给你带来额外工作。
  还有我们提到的，有过多的在制品的几个表现形式:
  风险增加;
  消耗变多;
  质量下降;
  动力降低。

W1P太高
工作闲置
WIP太低
人员闲置

用户故事与敏捷实践

• 用户故事
  故事卡包含对用户或者客户有价值的功能的简短描述。
  故事卡是故事的可见部分， 但客户团队和开发人员关于故事的对话更重要。
  故事卡由客户团队编写， 因为他们最了解如何表达需要实现的需求， 也因为他们会在后期与开发人员共同确定故事细节并安排故事的优先级顺序。按照故事对客户的价值来安排故事的优先级顺序。将各个故事放入迭代，进行发布与迭代规划。

速率是开发人员可以在一-轮迭代中完成的工作量。
如果故事太大以至于无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事。
用户故事是很有意义的， 因为它们强调口头交流，你和开发人员都可以理解，可以用于进行迭代计划，在迭代开发过程中能很好地工作，而且因为它们鼓励推迟细节。

优秀的故事应该具备以下特点，INVEST来代表这六个特征：
1.独立的(Independent)
2.可讨论的(Negotiable)
3.对用户或客户有价值的(Valuable to Purchasers or Users)
4.可估计的(Estimatable)
5.小的(Small)
6.可测试的(Testable)
故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事。故事可以注释一- 些细节，但是过多的细节会使故事难以理解，也可能给人一一种开发人员和客户无需交谈的错觉。给故事加上注释的最好方法是给它编写测试用例。 如果故事太大，复合故事和复杂故事可以分成几个小的故事。如果故事太小，几个小故事可以合并成-一个较大的故事。故事应该是可以测试的。

• 验收测试
  验收测试用于验证实现的故事是否开发成符合客户团队的设想。
  验收测试可以用来记录客户和开发人员讨论的很多细节。
  验收测试记录了有关故事的一-些假设,这些假设可能还没有和开发人员讨论过。
  验收测试提供了检查故事是否被完整实现的基本标准。验收测试应由客户来写而不是开发人员。验收测试应在程序员写代码之前就写好。 如果新的测试对阐明故事的细节或意图没有任何帮助， 就不用再写。
  FIT和FitNesse是写验收测试的优秀工具，它们用的是我们熟悉的表格或电子表格格式。
  开发人员职责
  若团队觉得有需要，则负责实现自动化验收测试。
  开始开发一个新的故事时，负责考虑更多的验收测试。
  负责为代码作单元测试，使验收测试就不必顾及故事的每个细节。客户职责
  负责编写验收测试。
  负责执行验收测试。

• 故事点
  一种可以满足所有这些目标的估算方法，即用故事点(story point)估算。故事点有个很好的特性是团队可以定义自己认为合适的故事点。一个团队可能决定定义一个故事点为一个理想日的工作(也就是说，一天中没有任何干扰，没有会议，没有电子邮件，没有电话，等等)。另一个团队可能定义一个故事点为一个理想周的工作。还有一个团队可能把-一个故事点作为故事复杂度的测量。
  要正确使用故事点，请记住下面几点。
  你的团队的故事点和我的团队的故事点是不一-样的
  一个故事(可能是一一个史诗故事)分解成-一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等。
  。这些任务估算的总和不需要与故事的估算相等。

• 用故事点估算故事,
  故事点是故事复杂度、工作量或工期的相对估算。
  应由团队估算故事， 估算属于团队而不是个人。
  通过和其他估算进行比较来进行三角测量。
  团队是否使用结对编程对故事点估算没有影响。
  结对编程影响的是团队的速率,不是他们的估算。
  开发人员职责
  责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
  负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。负责以团队估算。
  负责估算应与其他估算--致。即所有2点的故事都应差不多。
  客户职责
  负责参加估算会议， 但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。

• 用户故事估算
  为了计划一个发布， 客户必须排列故事的优先级。 把故事划分成诸如高优先级、中等优先级和低优先级这三种类型是很有用的，但这会导致乏味冗长的争论，会针对某个故事是高优先级还是中等优先级而争论不休。幸运的是，我们可以借用来自DSDM的方法，它是另--种敏捷过程”。
  DSDM包括一个 排列优先级的方法，称之为莫斯科(MoSCoW)规则。MoSCoW是以下短语的缩写:
  必须有(Must have)
  应该有(Should have)
  可以有(Could have)
  这次不会有(Won't have this time)
  “必须有的功能”是指系统的基本功能。 “应该有的功能”是指很重要但短期内有替代解决方法的功能。如果项目没有时间约束，通常认为应该有的功能是强制性的。“可以有的功能”是指如果没时间就可以在发布中不予考虑的功能。列为“不会有的功能”是客户期望拥有但同时承认需要在后续发布中实现的功能。