用看板管理大型项目

用看板管理大型项目读书笔记和知识总结，此书从实践角度展示如何使用看板管理大型项目，干货满满~

用看板管理大型项目

• 1.准备工作
  • 1.1 确定时间线
    • 1.1.1 确定时间线和各个版本发布的时间
    • 1.1.2 确定团队和每个时间段内的团队人数
    • 1.1.3 确定关键里程碑
  • 1.2 确定每个版本和开发工作
    • 1.2.1 原则-每个版本都能给客户产生价值，为团队积累知识
    • 1.2.2 分割整个产品的开发工作
      • 1）确定分割维度
      • 2）按照维度分割工作
  • 1.3 如何让客户参与
    • 1.3.1 客户列出功能清单，即 feature areas-大致等同于epics，用于指定该要的发布时间表和版本规划。现场用户可以与开发团队一起，提供反馈、观看产品演示、回答开发人员问题
    • 1.3.2 每次发布前一周，建议客户组织一个验收测试组，试用最新的待发布版本
    • 1.3.3 每次发布后，紧跟客户使用者，连续不断提供后续反馈
• 2. 组织团队
  • 2.1 最好能让所有团队成员一起办公，如果不行，利用好远程会议等工具
  • 2.2 一种常见的团队
    • 1）还有一些不属于以上团队的人员：开发经理，教练，项目经理，配置管理员，各类专家，其他重要干系人
    • 2）需求分析团队涵盖-商务，售前，架构师等角色
    • 3）每个成员都不能只关注自己的工作，如：需求分析人员给出成果后认为自己的工作完成了，而不是全程跟踪该功能直至上线
• 3.每日鸡尾酒会
  • 3.1 开发团队每日站会
    • 讨论今天要完成什么及需要解决什么问题，一般由master主持
  • 3.2 不同专业角色间的同步站会
    • 开发团队每日站会以后举行，各个专业角色分别碰头，根据实际情况决定今天是否单独和不同专业的人沟通相关问题等事情，项目经理和RTE等可以不主动参加某个会议，需要时按需参加
  • 3.3 项目同步例会
    • 每个专业派一个代表，每个开发团队派一个代表，再加上重要的干系人，如项目经理，RTE等，主要关注从需求分析到投入生产的各个工序是否正常运转：每个团队今天在做什么？现在有什么问题阻塞了我们的流程？瓶颈在哪里？如何消除瓶颈？下一个瓶颈会出现在哪里？我们的发布计划进展是否顺利？有没有人不知道今天要做什么工作？
  • 3.4 每天总共有多个立会，分三拨召开。每个立会的时间严格限定在15分钟内。每个立会都有必须出席会议的核心人员。每个立会又都对外公开，所以任何人想了解项目的信息或希望贡献意见，都可以随时加入任何一个立会。立会截止时间是上午10点15分。如果每日立会上出现了15分钟内解决不了的重要问题，我们就跟相关人员单独召开后续会议来解决问题。有时项目同步立会一结束，相关人等就会围站在一起，讨论立会中提出的问题，有些最有意思、最有价值的讨论就是在这时候进行的。
• 4.项目进度板
  • 4.1 进度板样例
  • 4.2 如果某个综述已被分析过(即已细分成若干功能)，相应的综述卡就会被丢弃，代之以第三栏若干更为详细的功能卡。因此，综述卡绝对不会流出第二栏，功能卡则诞生于第三栏。
  • 4.3 功能开发团队会根据各自的情况，把功能卡从“下十个功能”栏拉入他们自己的“正在开发”栏，完成功能开发和测试工作后，再拉入“等待系统测试”栏。
  • 4.4 测试团队定期清理“等待系统测试”栏，把功能卡拉入“正在进行系统测试”栏(并在版本控制系统中创建一个相应的系统测试分支，详细内容请参见第14章)。一旦系统测试完成，测试团队就会将其放入验收测试环境，把功能卡拉入“等待验收测试”栏，然后返回，对新开发完成的功能开始新一轮的系统测试。这种做法是组织文化上的一大转变，即从“版本发布周期最后阶段才做大型系统测试”转变到“(分批)持续进行系统测试”。
  • 4.5 每隔两个月左右，都会有一批真正的用户过来，花两三天的时间做验收测试(基本上只是试用一下系统并给出反馈意见)，这时候我们就会把功能卡挪入“正在进行验收测试”栏。等到验收测试完成，发现并修复了最后的Bug以后，功能卡就会挪入“等待投入使用”栏。之后不久(产品发布后)，功能卡会被挪入最后的“投入使用”栏。功能卡在这一栏会停留几周(显示我们有些成果正式上线了)，不过之后就会被清理掉，以便给新来的功能卡腾出位置。
  • 4.6 节奏
    • · 每两周回顾总结一次(有些团队每周一次)，寻找改进流程的方法。 · (大约)每两周开一次规划会议，决定接下来要专注于哪些功能。 · 随着功能的开发与测试，演示与系统测试持续进行。 · 大概在每两个月的阶段末期核准上线。
  • 4.7 如何处理紧急问题和障碍
    • 1）需要优化工序流，所以不能把任务板塞满。大家都知道路上塞满了车是什么结果，那时整个交通系统会瘫痪。需要空间或裕度来应变，让工序流动更快。还便于处理紧急情况。我们在任务板上用警车磁贴（特殊标明）标出需要特别快速处理的紧急事项。用粉红色便利贴来标示障碍(“路障”)。
    • 2）如果某个功能进展停滞(例如，缺乏测试该功能必需的第三方工具)，我们就在相应的功能卡上贴张粉红色便利贴，写清问题和停滞开始日期。任务板右边还有一小块区域是“前三个障碍”，显示与具体功能不直接相关的普遍问题(如编译环境出问题了)。在每日立会上着重移除这些障碍。
      • 例子，便利贴上的日期表明问题存在了多久，落款则表明谁在负责解决问题(这样我们就知道这个问题该找谁)。
• 5.扩展任务看板
  • 5.1 保留两个层次的任务板——一块大家共享的项目进度板加多块团队任务板。
    • 项目进度看板和团队任务板
  • 5.2 项目进度板上贴的是功能卡，而功能开发团队的看板上则贴有他们负责开发的具体功能和相关细分任务。
• 6.跟踪总体目标
  • 6.1 项目总体目标通常就贴在项目进度板上。例如，第一季度时，我们的目标是“4月5日交付没有重大缺陷、可以向全国范围发布的版本”。实现这一目标之前，还有一个里程碑，即3月14日向两个新增地区发布。这样就可以让所有人的目标统一。
  • 6.2 实现一个目标后，我们就为下一个发布版本写下新的目标宣言。目标宣言就是指路明灯。有时我们需要作出艰难的取舍，而明确的总体目标有助于项目所有人员保持同步，明白对于下一个发布版本而言什么最重要。
  • 6.3 每周或每两周都会做一次现实检查。
    • 6.3.1 可以采用fist of five 方式： 5=绝对能 4=有可能 3=有点悬 2=不太可能 1=拉倒吧 下面是一些可以采取的典型行动。 消除障碍(“买台新的编译服务器，换掉有故障的那台！”) 帮助解决瓶颈问题(“今天我们所有人都做测试！”) 缩小范围(“如果把功能X从这次的发布版本中去掉，就还有可能实现目标！”) 调整目标(“这个目标已经不现实了。我们来定个能真正实现的新目标！”) 更加努力工作(“周日谁能来加班？”)
    • 6.3.2 也可以用燃尽图 
  • 6.4 无论你参与的是什么样的项目，我都强烈建议你们明确定义目标并定期做现实检查。这种做法成本很低，但收益却非常高！
• 7. 定义“可供”与“完成”
  • 7.1 最重要的两个定义是“可供开发”和“可供系统测试”，因为这两处是我们以前出问题最多的地方。
    • 子主题
  • 7.2 可供开发
    • 7.2.1 “可供开发”栏实质上表示“我们这里有一堆已细分好任务、估算完工作量和澄清了范围的功能，不过我们还没决定要开发哪几个功能，以及按什么顺序开发”。所以，这与Scrum产品需求清单大致对应。一个功能要进入可供开发状态，就必须具备以下特点。与Scrum产品需求清单大致对应。一个功能要进入可供开发状态，就必须具备以下特点。
      • 1）必须有一个ID。如果有与该功能相关联的用例规范或其他文档，就可以通过ID来查询这些相关信息。点击项目wiki文档站点上的相应ID就能够访问这些文档。
      • 2）必须有一个联系人。联系人通常是需求分析师，拥有该功能相关领域的丰富知识。
      • 3）必须对客户有价值。把综述分割成可交付的用户故事时，我们需要确保未丢失客户价值。需求分析师对此有最终发言权。
      • 4）必须经由团队估算。通常由一名测试人员、一名开发人员和一名需求分析人员组成的小组利用规划扑克进行估算。我们用T恤衫尺寸(大、中、小)来表示。这种估算是估算工作量的多少，而不是估算时间长短。不过为了简化估算过程，我们遵循下面这些准则：
        • · 小指的是“在没有任何意外的状况下，大约花不到一周的时间就能够到达‘可供验收测试’阶段。”所谓没有意外状况是指我们找对了人，在没有干扰的情况下，专门负责这项功能。
        • · 中指的是一到两周的时间(同样，在没有任何意外的状况下)。
        • · 大指的是超过两周时间。大一些的功能可供开发前需要进行进一步细分。
        • · 必须将验收测试情景写在功能卡背面，即描述典型测试情景的具体步骤。
  • 7.3 可供系统测试
    • 7.3.1 可供系统测试定义如下：
      • 1）验收测试自动化：端对端功能层次的验收测试或集成测试已自动化。我们以前用Selenium测试工具(该工具直接从Web界面运行测试脚本)，不过后来转用Concordion自动化测试框架了。对于我们谜一般的Ajax Web界面而言，Selenium 工具过于脆弱。随着我们转向实例化需求驱动开发(Specification By Example)， Concordion自动化测试框架更符合我们的需要。
      • 2）通过回归测试：对现有功能运行的所有自动化测试都要通过。有时一个新功能会破坏现有功能，所以我们必须要保证定期运行所有回归测试。
      • 3）已演示过：开发团队已向团队其他成员、现场用户、需求分析人员、系统测试人员和可用性专家等人演示过该功能。演示的目的是尽早发现可用性方面的问题，这样就不会等到系统测试阶段甚至用户验收测试阶段才发现问题。
      • 4）清楚填写签入备注：签入该功能相关代码时，应当用该功能ID来标记签入备注，并填写容易理解的备注，说明都做过什么。这将保证最低限度的可追溯性(大型项目的可追溯性总是糟糕得一塌糊涂)。
      • 5）在开发环境中测试过：每个团队都有专用的测试环境，而且测试过该功能，免得开发人员说“在我机器上运行完全没问题”之类的话。
      • 6）已与代码主干合并：该功能代码应当已经合并到代码主干，而且任何代码合并冲突都已解决。这是我们所使用的稳定主干模型的基础。
  • 7.4 两个定义如何提升团队协作
    • 7.4.1 各个团队基本上都只关注项目进度板上“自己”那一部分内容。需求分析人员只看项目进度板左边那一块，认为写好某个功能的需求文档后自己的工作就做完了。开发人员只看中间那一块，而测试人员只看右边那一块。测试人员不参与需求文档的撰写，所以等到一项功能需要进行测试时，他们甚至都不清楚这项功能该怎么用。于是大家花了很多时间争论需求文档应该详细到什么程度。
    • 7.4.2 只有不同角色的人员一起合作，对功能进行估算，然后细分成很小却又不会失去客户价值的可交付单位，并就验收测试达成一致意见，可供开发的状态才算真正实现。 同样，只有不同角色的人员一起合作，从功能层次进行测试(包括自动化测试和手动探索性测试)，来确定该功能可以放行，可供系统测试的状态才算真正实现。
• 8. 处理技术故事
  • 8.1 技术故事是一些我们需要完成但客户并不感兴趣的事情，比如升级数据库、清理不用的代码、重构糟糕的设计或对原有功能实现测试自动化等。我们通常称之为内部改进。技术故事诞生于项目进度板的“等待开发”栏，通过“下五个技术故事”栏(就在“下十个功能”栏下方)流入开发阶段。这两栏是平行的，都是开发栏的输入队列。
  • 8.2 当开发团队有空接手新的工作内容时，他们要么从“下十个功能”栏拉一张功能卡过去，要么从“下五个技术故事”栏拉一张技术故事卡过去。如何在这两者之间保持平衡并没有一成不变的规则，需要在每日立会中不断讨论和调整。
  • 8.3 技术故事卡右上角上有一个圆点(一般涂成绿色)，以跟功能卡区分。即使被拉入开发阶段后，我们也能凭这个圆点将两者区分开来，因此项目进度看板就能显示出我们在功能和技术故事上是如何分配时间的。
  • 8.4 通常功能更重要，不过也有一些例外情况，让我们需要在一段时间内花费大部分时间和精力专注于技术故事，比如下面的例子。
    • 8.4.1 系统测试一度成为很突出的大瓶颈，所以当时已经完全没有意义再开发新功能，继续给瓶颈增加负荷。发现这个问题后，开发人员就开始专注于实施可减轻系统测试负荷的技术故事，主要是测试自动化的内容。实际上，测试经理当时的任务是创建测试自动化需求清单并进行排序，然后通过“下五个技术故事”栏提供给开发人员。测试人员于是就变成客户了！后面详细讲解解决方案。
    • 8.4.2 在主要版本发布的前一天，团队都希望先将该版本送出门，然后再开始接手新一轮的新功能。于是他们会专注于最后的Bug修复。如果当时没有任何Bug需要修复，他们就会处理技术故事——通常是些我们一直以来都需要完成但没时间做的工作，比如清理不用的代码、完成重构、学习新工具的使用等等。
• 9. 处理BUG
  • 9.1 持续系统测试
    • 9.1.1 要这样
      • 不要这样
      • 对比
      • 就是自动化测试。我们不可能把所有测试都自动化，不过既然要一次次反复进行系统测试，我们就需要尽可能实现测试自动化！
  • 9.2 立马修复Bug
    • 测试人员发现一个Bug后，并不是直接记录到Bug跟踪系统中，而是写在粉红色便利贴上(像记录其他障碍一样)，然后去找开发人员。多数情况下，他们大致知道该去找谁，因为每个开发团队都有一位专职测试人员。否则，他们会找开发团队主管，问清谁是能够修复Bug的合适人选(通常是写那段代码的开发人员)。 接下来，开发人员和测试人员坐在一起现场修复Bug，或者开发人员自己修复Bug，然后马上再去找测试人员。这样做的特点是，没有移交、没有延迟、不需要通过Bug跟踪系统来沟通。这种做法比较有效率，原因如下： 早发现并修复Bug比晚发现和修复Bug更有效率。
  • 9.3 为何要限定Bug跟踪系统中的Bug数量
    • 9.3.1 限定后的好处：把不重要的那个Bug从前30名列表中拿掉，给新Bug腾出位置。如果不是，那我们就直接忽略这个新Bug。 这样一来，Bug跟踪系统就能让我们始终专注于最重要的Bug，而不会成为管理负担。
    • 9.3.2 流程
  • 9.4 Bug可视化
    • 子主题
  • 9.5 预防Bug重现
• 10. 持续改进流程
  • 10.1 团队回顾
    • 10.1.1 我们的流程改进研讨会基本上是Scrum式的Sprint回顾。
      • 1）每个团队每一两周都会召开一次回顾会议，时长三十分钟到两小时不等，会议地点比较随机
      • 2）目标：反省哪里做得好，哪里做得不好，以及需要做出什么样的改变。
  • 10.2 流程改进研讨会
    • 10.2.1 流程改进研讨会基本上是Scrum的Scrum类型的回顾会议，每个团队和每个专业角色各一位代表(就是每天上午10点钟在项目进度板前碰头的那个“交叉团队”)。这是触发影响范围较广的改变的最有效场所，比如，做出影响多个团队的改变和跟进先前改变的结果。
    • 10.2.2 建议每两周一次
    • 10.2.3 流程改进研讨会的流程大体如下。 目的要明确，要关注焦点，要每个人都发言。
      • 1)做好准备：会议开场，设定主题与关注焦点。
      • 2)收集数据：回顾上次会议之后发生过什么，包括取得的成果和面临的难点。如果我们有主题，就围绕主题回顾具体数据。
      • 3)产生见解：讨论数据及其意义，专注于最重要的难点问题，并确定解决问题的具体方案。
      • 4)作出决策：决定要实施哪些改变。
      • 5)结束会议：决定谁来做什么，以及下次会议之前需要完成什么。
    • 10.2.4 对于流程改进的方案：
      • 1）对于每个方案，进行头脑风暴，找出优劣势。运用快速大拇指评选 或者FIST OF FIVE进行评选
  • 10.3 掌控改变速率
    • 10.3.1实例
    • 10.3.2 犹豫不决之时，就选择最简单的方案。
• 11. 管理在制品
  • 11.1 缓冲区
    • 11.1.1 实例，缓冲栏与WIP栏区别开来
    • 11.1.2 判断缓冲区是否合理，如无必要，可以上一道工序对接下一道工序，优化工作流
  • 11.2 采用在制品限额
    • 11.2.1 进度看板每一栏的顶部都写有一个数字，这是在制品限额(WIP limit)，如“每个团队最多五个功能”
    • 11.2.2 在制品限额旨在避免同时做太多工作，避免让下游流程负载过重。如果测试人员手头已经有太多工作，我们就不希望开发人员再持续不断地开发新功能，给测试人员增加负担，而是希望他们腾出手来帮助测试人员尽快完成测试。
  • 11.3 为什么在制品限额只适用于功能卡
    • 11.3.1 技术故事和Bug修复不包括在在制品限额内。
    • 11.3.2 不包括Bug，是因为Bug通常都相当紧急，而且都相当小。此外，我们还未摸索出在进度看板上以统一方式处理Bug的好方法。有时Bug会在进度看板上标出，有时却没有，我们现在还不希望就此制定太多的规则。
    • 11.3.3 不包括技术故事是因为以下原因。
      • 设置在制品限额的一个原因是避免让下游流程负载过重。开发新功能就肯定意味着增加测试工作量，所以如果我们开发功能速度太快，就会造成测试负载过重。
      • 而技术故事却恰恰相反，技术故事有助于消除下游瓶颈。我们很多技术故事都与测试自动化和基础设施改进有关，而这两项工作都能提高质量，让测试人员的工作更轻松。
• 12. 捕捉并使用流程度量
  • 12.1 流程度量非常有用，可以找出哪里需要改进，看出我们所作的变更是否带来了积极的效果。对于从宏观上规划版本发布大纲也很有用。
  • 12.2 追踪以下两个流程度量：
    • 12.2.1 速率(每周功能数)
    • 12.2.2 周期时间(每个功能的开发时间)
  • 12.3 速率
    • 每周结束的时候计算有多少张功能卡可以进入“可供验收测试(本周)”栏
    • 燃尽图
  • 12.4 为何不使用故事点
    • 提高精确度并未增加多少价值，所以估算故事点就是在浪费时间。
  • 12.5 周期时间
  • 12.6 累计流量
    • 12.6.1 看板的一大优势在于可以实时显示瓶颈位置，不过显示不了历史趋势。
  • 12.7 流程周期效率
• 13. Sprint与版本发布规划
  • Sprint规划会议的目的是弄清楚下一步做什么。就我们的项目而言，这意味着确定哪些功能要进入“下十个功能”栏。
  • 13.1 需求清单梳理
    • 13.1.1 这项工作是Sprint规划会议前半部分的内容，由需求团队向大家介绍接下来需要开发的功能(对，需求团队相当于Scrum模式下的产品负责人，主要是因为他们与客户和用户的联系最密切)。
    • 13.1.2 然后我们分成几个跨职能小组，通常每个小组各有一位需求分析师、一位开发人员和一位测试人员。每个小组拿几张功能卡，用规划扑克进行估算(参见第19章)，并在功能卡上写下小、中或大。如果某张功能卡是“大”，则做进一步细分，或决定暂时将其排除在“下十个功能”范围之外(我们不允许“大”功能进入开发阶段)。他们还会讨论出适当的验收测试方案，并写在卡片背面。
  • 13.2 挑选前十个功能
    • 13.2.1 原则
      • 商业价值——客户最乐于看到的功能有哪些？
      • 知识——哪些功能会产生知识(因此会降低风险)？
      • 资源利用——我们需要平衡功能领域，这样才能让所有团队都有事做。
      • 依赖关系——哪些功能最好组合在一起开发？
      • 可测试性——哪些功能放在一起测试最合理，因而需要同期开发？
  • 13.3 为何将需求清单梳理工作移出Sprint规划会议
    • 项目梳理需求清单非常耗时，会导致Sprint规划会议总是匆忙结束。所以，我们需要严格控制会议时间，重点讨论主要问题。最好的方法是单独进行需求清单的梳理，然后再开Sprint规划会议。通常在Sprint规划会议之前的几天，需求分析团队的一位分析师会与一位开发人员及一位测试人员就接下来的某项功能进行一次非正式的讨论。然后就会对该项功能进行细分、估算，并制定验收测试方案。尽管如此一般我们还是会在Sprint规划会议上梳理一些需求，不过通常是在Sprint规划会议之前就尽量完成需求清单的梳理工作。
  • 13.4 规划版本发布
    • 13.4.1 对于长期规划而言，我们并不一定知道功能总数是多少。我们有的只是一堆模糊的创意。我们可以暂且将其称为综述(epic)或功能领域(feature area)。其中有些创意的规模可能非常非常大！
    • 13.4.2 单独讨论每个综述并估算应将其划分为多少个功能。这种估算工作(跟其他所有估算工作一样)需要需求分析师、开发人员和测试人员都投入一定的时间和精力。估算过程类似于估算故事点，不过我们讨论的问题是“这一综述有多少个功能”，而不是“有多少个故事点”。一旦估算好每个综述的具体功能数，我们就可以统计功能总数，然后按照过去每周三至五个功能的速率进行划分。这一做法提供了足够多的信息，能够让我们很有信心地说：“我们应该能在六到十二个月内全部完成。”虽然还只是大致的估算，但却是基于真实数据的。
• 14. 如何做版本控制
  • 实施主线模型，多团队下的敏捷版本控制(Agile Version Control with Multiple Teams)中稳定主干模式。
  • 流程
• 15. 为何我们只用真实看板
  • 15.1 一个主要原因就是看板可以演变
    • 看板版面结构变更多次，用了两三个月的时间才稳定下来。版面稳定下来以后，我们才开始用黑色胶带来分栏——之前都是手工画分割线，因为变化太频繁。不过，如果有必要的话，我们现在还是可以移动胶带的。
  • 15.2 第二个原因是需要协作(Collaboration)
    • 如之前的鸡尾酒站会。
    • 如果采用电子看板，我们可以用投影仪将看板投影到墙上。但这样就会缺乏互动，即大家无法从墙上拿下卡片边讲边示意，无法在卡片上写下文字，也不能在立会期间将卡片移来移去。大家可能要坐到自己座位上以后才会更新看板——这样虽然便利，却没有多少协作性。
  • 15.3 各种其他工具-云、多人共享、可分配权限
• 16. 经验教训
  • 16.1 了解目标
    • 完善是方向，而不是终点！拥有了明确的方向，再专心评估改进工作就会容易得多。
  • 16.2 不断实验
    • 伟大的流程不是设计出来的，而是逐渐演变出来的。所以，重要的不是流程，而是我们用来改进流程的流程。
  • 16.3 拥抱失败
    • 担心失败则是创新的最大敌人。我们应当反思的是“我们学到了什么？下次应当做出什么尝试？”，而不是“我们怎么会失败？是谁把事情搞砸了？”
  • 16.4 解决真正的问题
    • 无论何时尝试作出变革时，都要不断问自己：“我在解决什么问题？这个问题是真实存在的还是假设的？还有没有其他我应当先解决的更重要的问题？”如果不能确定，就要询问别人！我们一不小心就会去钻研些无关问题或假设问题，尤其是作为来自组织外部的短期教练而言。
  • 16.5 拥有专职变革推动者
    • 至少应拥有一名专职的变革推动者，完全专注于推动、领导和协调变革过程。如果有两位专门的变革推动者则更为理想：一位内部人士，一位外部人士。内部人士(通常是员工)拥有特定领域知识，知道什么工作应该找谁，他了解组织的历史以及以往的成功做法。外部人士(通常是咨询专家)则可以提供全新的视角，他拥有帮助其他公司完成类似变革的成功经验。
  • 16.6 让人们参与进来
    • 更好的做法是，先不要自己作出变革提议！而是将你看到的问题用可视化方式呈现出来，让那些相关的人们参与进来，提出他们自己的解决方案。如果是大家自己提出来的意见，人们就会更容易接受变革！
• 17. 敏捷与精益概述
  • 17.1 精益概述
    • 17.1.1 全局优化： 局部的优化长期来说，会对系统整体优化不利。 专注于整体价值流：从概念到现金。从客户需求到软件部署。 交付完整产品：客户不要软件产品，他们要解决问题。完整的解决方案是由完整的团队构建的。 着眼长期：警惕导致短期思维和优化局部业绩的治理和激励体系。
    • 17.1.2 消灭浪费 浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下。 构建错误的功能：“没有什么比高效完成根本不应做的工作更无用。” 拒绝学习：我们有很多策略都干扰了我们学习，例如，只按计划行事、频繁移交、决策与工作分离等，而学习则是开发的精髓。 辗转现象：那些干扰价值顺利流动的做法，例如，任务切换、请求清单冗长、大堆未完成的工作等等，都只能达到事倍功半的效果。
    • 17.1.3 品质为先 如果在验证过程中总是能发现缺陷，那流程就有问题。 最终验证不应发现缺陷：所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。 采用测试先行的开发模式让流程具有防误机制：测试(包括单元测试、端对端测试和集成测试)必不可少，以此建立信心，保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
    • 17.1.4 不断学习 规划工作非常有用。学习则必不可少。 可预测的性能来自于反馈：可预测的组织不会猜测未来并称之为计划；反之，他们会培养能力对未来做出响应。 保持选择方案：视代码为实验——使其具有容变性。 最后可靠时刻：在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策，也不要事后才做出决定！
    • 17.1.5 尽快交付 从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观，创建稳定、连贯的工作流。 快速交付、高质量和低成本是完全相互兼容的：以速度竞争见长的公司拥有很高的成本优势，他们可以交付优质的产品，而且对客户需求更为敏感。 排队理论同样适用于开发，而不仅仅是服务行业：专注于使用性会造成交通堵塞，反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。 管理工作流比管理进度表要容易得多：建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。
    • 17.1.6 人人参与 聪明、有创造力的人员的时间与精力，是当代经济的稀有资源和竞争优势的基础。 获得公正薪资的人员在自主性、成长性和使命感等方面受到激励(2)。 自主性：最有效的工作小组是半自治团队，有一个内部主管从头到尾负责完整、有意义的任务。 成长性：对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。 使命感：将工作与价值挂钩。只有相信自己工作的意义，团队成员才会全心投入工作，实现这种使命。
    • 17.1.7 不断提高 结果不是重点——重点是培养人、发展体制，使之能够交付结果。 失败是个学习机会：即使是非常小的失败都会被深入调查并纠正的，做到一丝不苟的时候，才可能获得最可靠的性能。 标准存在的目的就是要被质疑和提高的：将现行的、最知名的做法纳入人人都遵循的标准，与此同时鼓励所有人质疑并改变标准。 使用科学方法：教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。
  • 17.2 Scrum概述
    • 详见我写的SCRUM文档
  • 17.3 XP概述
    • 17.3.1 该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的，实际上包含了大多数相同要素。
    • 17.3.2 内容：
      • 持续集成：拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
      • 结对编程：在一台工作站上进行结对编程，从而使学习效果最大化、设计质量最大化、缺陷最小化。
      • 测试驱动开发：采用测试代码驱动系统的设计。编写自动化测试脚本，然后编写刚刚足够的代码以使其通过测试，然后从根本上重构代码，提高其可读性，移除重复代码。清理并重复这一过程。
      • 集体代码所有权：允许(实际上是鼓励)开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识，确保整个系统的设计都一致、易于理解。
      • 增量式设计改进：从最简单的设计开始，然后运用重构等技术持续不断地改进设计，而不是从一开始就做好完整的设计。
  • 17.4 看板概述
    • 看板是敏捷软件开发的精益方法。具体方法看上面
  • 17.5 Scrum专注于结构和沟通，XP增加了工程实践，看板则专注于将工作流可视化，并对瓶颈进行管理。
• WIP
  • 交付周期 = WIP/ 交付速率
    • 交付周期：指需求从进入开发团队到完成交付的时长
    • WIP数：指整个系统中并行需求的数目，是处于各个阶段的需求数之和
    • 交付速率：指单位时间交付的需求数
  • 敏捷团队使用WIP限制的4个目标
    • 与任何新活动一样，WIP限制最初使用起来比较尴尬。而WIP限制的目标是在中期使团队达到最优状态，所以短期的尴尬实际上是好事。它会迫使团队触碰到他们流程中的一些痛点。
    • 团队在使用WIP 限制几周后，就可以根据需要进行调整。正因为团队一直在受挫，因此可以抵制调高WIP限制的诱惑。而且还能抓住机会，提高团队整体能力-理论上，可以通过教育团队让每个成员获得新技能或在某些方面提高开发过程的效率。
    • 目标1：不断调整单个任务的大小。
      • 在分解需求和用户故事时，保证单个任务的工作量不超过16个小时是非常重要的。这么不仅可以提高团队确切预估的能力，还能有避免瓶颈。没有什么能比大工作项阻塞通道更能降低团队速度加剧WIP限制了。
      • 当WIP限制有效时，一个事件的循环时间就会降低。循环时间就是完成一个事件需要的时间。
    • 目标2：将WIP限制规划为团队的技能。
      • 上面的例子是假设团队成员的技术能力相似。如果你的团队有技术专家，那么当专家牵涉其中时WIP限制应该有所不同。这个时候需要创建特定于专家工作的状态。如果在该状态下出现瓶颈，正好可以趁机让团队其他成员学习一些额外的专家具备的技能，以此来增强整个团队的流。
    • 目标3：减少闲置。
      • 当一个团队成员出现停工期的时候，鼓励他们去帮助上游或下游团队成员。他们不仅能为团队的整体生产力做出贡献，还可以在此过程中学到一些东西。
    • 目标4：保护一种可持续的工程文化。
      • WIP限制并不意味着开发人员需要急于工作以避免某些情况下工作过载。它旨在保护以保证产品质量和代码库健康为前提的扎实的敏捷工作实践。