导图社区 敏捷方法
- 80
- 1
- 0
- 举报
敏捷方法
敏捷方法，包括极限编程，特性驱动开发，动态系统开发方法，水晶方法，精益开发，测试驱动开发，验收测试驱动。
编辑于2022-06-30 14:49:38- ACP
- 敏捷管理
- 极限编程
- 相似推荐
- 大纲
敏捷方法
1.SCRUM
概述
Scrum是以经验性过程控制理论(经验主义)为理论基础，主张知识源于经验，以及基于已知的东西做决定。
适应型(敏捷)：Scrum框架
undefined
工作事项名称——产品待开发项
在规划Sprint时，Scrum团队从产品Backlog中挑选最高优先级的需求，在Sprint计划会议上经过讨论、分析和估算得到相应的任务，并分配给具体的成员去实现。
Scrum采用迭代、增量的方法来优化可预见性并控制风险。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个冲刺(Sprint) 。
Scrum的三大支柱
1.高度透明
2.检查
3.适应
三大支柱为Scrum的整体框架提供了这些活动
迭代回顾( Spring Retrospective)
每日立会( Daily Scrum Meeting )
迭代评审会议( Spring Review Meeting )
迭代计划会议( Spring Planning Meeting )
重要特征
1.迭代式开发
开发周期分成多个1-4周的迭代
2.增量交付
无论产品负责人是否决定真正发布它，增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
3.自组织团队
有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
4.高优先级的需求驱动
使用 Product Backlog 来管理需求
需求是渐进明细的、 经过优先级排序的
Scrum 团队从 Backlog 最上层的高优先级的需求开始开发
在 Scrum 中，只要有足够 1-2 个 Sprint 开发的细化了的高优先级需求就可以启动 Sprint 了
在开发期间可以通过 Backlog 的梳理来逐步地细化需求
一些工件概念
1.Sprint--冲刺
它是组成整个开发过程的一个短的迭代周期成为一次冲刺
一个 Sprint 是指一个1~4周、有明确生产计划和产出的迭代周期
组成部分
1.Sprint 计划会议
时间
在新的迭代开始前进行
一般来说， Sprint 时间 4 周， 会议时间为 8 小时； Sprint 时间 2 周， 会议时间为 2 小时。
参会角色
整个Scrum团队
即产品负责人、主管、开发团队
会议目的/内容
Sprint 计划会议回答以下问题:1.接下来的Sprint交付的增量中要包含什么内容?2.要如何完成交付增量所需的工作?
2.每日站会
时间
每天进行
15分钟以内完成
参会角色
开发团队
会议目的/内容
开发团队为接下来的 24 小时的工作制定计划
范例
昨天，我为帮助开发团队达成 Sprint 目标做了什么？
今天，我为帮助开发团队达成 Sprint 目标准备做什么？
是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？
3.开发工作
是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划
是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进， 它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进
4.Sprint 评审会议
时间
在 Sprint 快结束时举行
对于一个月的 Sprint 来说，评审会议时间最长不超过4小时。对于时间较短的Sprint来说，会议时间通常会缩短。
参会角色
Scrum 团队
即产品负责人、主管、开发团队
利益相关者
比如客户或者高层领导
会议目的/内容
用以检视所交付的产品增量并按需调整产品待办列表
根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。
这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
主要内容包括
1.产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
2.开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
3.开发团队演示“完成”的工作并解答关于所交付增量的问题；
4.产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标
5.交付日期（如果有需要的话）；
6.参会的所有人就下一步的工作进行探讨，然后Sprint 评审会议就能够为接下来的Sprint 计划
7.会议提供有价值的输入信息；
8.评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
9.同时，为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
5.Sprint回顾会议
时间
在Sprint 评审会议结束之后，下个 Sprint 计划会议之前
对于长度为一个月的 Sprint 来说， 时长不超过 3 小时
参会角色
Scrum 团队
会议目的/内容
是Scrum团队检视自身并创建下一个 Sprint 改进计划的机会
目的和内容
1.检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
2.找出并加以排序做得好的和潜在需要改进的主要方面；
3.同时，制定改进 Scrum 团队工作方式的计划。
并产出可交付的产品增量
每个Sprint结束即可向需求方提交一次版本更新
未完成的任务须退回到待办事项列表中
2.Backlog--待办事项列表
用来管理用户需求和任务，并通过及时梳理来响应需求变更
Product Backlog
用来管理产品需求和开发任务
按照商业价值(或实现优先级)排序的事项列表
列表条目的体现形式通常为用户故事
记录经过识别、分解和估算的用户需求和任务。
Sprint Backlog
迭代待开发项是由产品待开发项分解而来的一系列的项；
迭代待开发项会伴有一个计划以实现迭代的目标，所以它会作为迭代的一部分为开发团队提供预测功能。
它可以将所承担的工作可视化并且只能由开发团队进行更新。
3.Issue--事项
经过识别解析得到的用户故事、开发任务、测试得到的BUG等等统称为事项(Issue)
事项1：Story--用户故事
事项2：Epic--史诗
事项3：Task--任务
事项4：Improvement--改进
事项5：New feature--新特性
事项6：Bug--缺陷
4.Priority--事项优先级
5.Burn-down Chart--燃尽图
1.冲刺燃尽图
2.交付燃尽图
6.Fist-of-five--举手表决
紧握拳头：不，我完全不同意。1 根手指：我非常担心。2 根手指：我想讨论一些小问题。3 根手指：我不完全同意但我可以接受意见通过而不须进一步讨论。4 根手指：我认为想法不错且愿意为其工作。5 根手指：想法棒极了，执行时我愿意带头。
7.需求空间、开发空间和测试空间
1.需求空间
存放、描述项目所有待实现的需求，表现为Product Backlog，由PO主导并管理，所有团队成员可以参与梳理。
2.开发空间
包含项目正在开发实现的所有事项，表现为Sprint Backlog和 Scrum Board，在Scrum Master指导下由开发团队共同管理。
3. 测试空间
管理项目的测试计划和测试用例，是项目的一系列质量目标和验收标准，由 QA主导管理。
当Sprint 开始后，QA根据User Story编写对应的测试用例，加入QA 空间；当开发人员提交到To QA 后，QA 根据测试用例执行测试，反馈测试结果。此外，还包括其他不同级别的测试计划和用例。
Scrum中的基本角色和职责
Pigs角色
项目的实际参与者，必须直接对Story负责，必须在站立会中发言，说明完成的工作，将要的工作，遇到的困难等，即一般意义上的Scrum 团队。
Chickens角色
项目的外围及外部成员，包括组织内各方面的领导、最终用户以及项目的其他利益相关者，也包括某些参与项目实施但不用对Story 负责任的外围成员。
Scrum团队(Pigs)
概述
Scrum团队是跨职能的自组织团队。跨职能团队拥有完成项目全部工作所需的全部技能，不需要依赖于团队之外的人。自组织团队通过内部的决策机制来自我选择如何以最好的方式完成工作，而不是由团队之外的人来指导。
Scrum团队迭代、增量式地交付已完成的产品，借此最大化地从用户获得需求范围内的反馈，从而进行滚动式的需求细化，并努力避免后期返工。“已完成的产品” 表明每次交付给用户的产品必须是潜在可工作的，可以不完善、不细致但是至少必须是可以让用户上手体验的。
1.Scrum Master (SM, 开发经理/实施经理)
职责
Scrum Master负责保证所有人都能正确地理解并实施Scrum，确保Scrum团队遵循Scrum的理论、实践和规则。
服务对象
服务于产品负责人
1.确保Scrum 团队中的每个人都尽可能地理解目标、范围和产品域;
2.找到有效管理产品待办列表的技巧;
3.帮助Scrum 团队理解为何需要清晰且简明的产品待办列表项; .
4.理解在经验主义的环境中的产品规划;
5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;
6.理解并实践敏捷性;
7. 当被请求或需要时，引导Scrum事件。
服务于开发团队
1. 作为教练在自组织和跨职能方面给予开发团队以指导;
2.帮助开发团队创造高价值的产品;
3.移除开发团队工作进展中的障碍;
4.按被请求或需要时，引导Scrum事件；
5.在Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
服务于组织
1.带领并作为教练指导组织采纳Scrum;
2.在组织范围内规划Scrum的实施;
3.帮助员工和利益攸关者理解并实施Scrum 和经验导向的产品开发;
4.引发能够提升Scrum团队生产率的改变;
5.与其他Scrum Master一起工作，增强组织中Scrum 应用的有效性。
SM一般由组织任命
一名优秀的SM能够同时受到团队内成员（Pigs）的支持和外部利益攸关方（Chickens）的信任。
对内，SM充当团队的服务型领导者和敏捷教练员；对外，SM充当团队与利益攸关者沟通的桥梁，帮助他们了解、理解与支持团队工作，从而为团队屏蔽外部干扰并消除障碍。
2.Product Owner (PO，产品负责人)
PO对代办事项列表的管理包括
1.清晰地表述产品待办列表项;
2. 对产品待办列表项进行排序，使其最好地体现工作优先级、目标和使命;
3.优化开发团队所执行工作的价值;
4.确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum 团队下一步要做的工作;
5.确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以自行完成上述工作、与Scrum Master 一起完成 上述工作，甚或与整个开发团队共同完 成对Product Backlog的梳理，但是PO必须是Product Backlog的最终负责人。任何人想要修改Product Backlog,包括改变需求或优先级，必须经过PO来执行。没有人可以强迫团队按照另一套需求来工作。
3.Scrum Team (团队)
开发团队具有这些特点
1.他们是自组织的。没有人(即使是Scrum Master) 有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量;
2.开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能;
3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作，他们都叫开发人员;
4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析;
5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
开发团队包含完成产品开发所需的各类专业人员， 负责在每个Sprint 结束时交付潜在可发布并且“完成”的产品增量。 开发团队由组织组建并获得授权， 通过内部的敏捷决策机制（各种不同功能的会议） 自己组织和管理开发工作。
产品负责人和 Scrum Master 角色不包含在开发团队人数中，但是Scrum Master 和 Product Owner 本身也可以从事开发工作， 这个时候他们也是开发团队的一员。
需求解析与管理
概述
在Scrum中，用户需求被解析成Epic和Story，置于Product Backlog 中进行管理。Epic和Story并没有统一的划分标准，一般可认为Epic（史诗）是有一系列相互联系的Story（故事） 组成的故事集。 实践中，我们可以把系统模块识别为Epic，再从Epic中解析出足够细致的User Story。 或者说，我们用 Epic来描述需求范围， 用Story来定义需求明细。
例如
Epic模块名称：费用管理
费用管理的场景1Story：公司财务要实现费用科目限制
费用管理的场景2Story：总部要实现不同区域部门的预算下放
费用管理的场景3Story：区域员工要实现业务费用报销
1.需求分析
概述
该过程需要全员参与，这有助于及时发现团队成员对同一个需求理解不一致的问题， 可以在很大程度上避免缺陷的引入，也有助于规避人力风险。
全员参与的需求分析活动需要一个扮演导师角色的人带领大家去进行有效的需求分析，Product Owner需要承担起这个责任，Scrum Master可以为Product Owner如何胜任敏捷开发中的需求指导和 管理工作提供指导和协助。
用户需求由 3 个要素组成
需求描述
需求优先级
故事点(工作量)
1.What or How
需要强调： 需求分析是为了准确地描述问题， 而非寻求如何解决问题。
2.需求描述： 完整、 合理、 一致和兼容
敏捷提倡客户价值导向， 应当从客户价值角度描述， 就是描述客户想要什么， 而不是描述技术层面如何实现
对于不合理的需求应该及时拒绝， 否则不仅浪费了团队资源， 系统上线后还可能给利益相关方带来损失
3.确定需求的优先级
确定优先级通常从 5 个方面考虑
1. 经济价值
2.所需成本
3.学习和获取知识的重要性和数量
4.风险
5.客户需要
一般PO都会选择采用风险-价值矩阵来评估需求优先级。
需要完成的优先级排序
1.相对高价值-高风险的需求
2.高价值-低风险的需求次之
3.低值-低风险的需求再次之
尽可能推迟甚至避免开发低价值-高风险的需求
4.估算Story Point
即对需要做的事情或任务进行工作量的估算
对工作量的估算应当以 User Story 为基础
Epic 的整体工作量体现在分解得到的 Story 的工作量的总和以及集成成本上。
用户故事的工作量以故事点（Story Point）来衡量
对工作量应当估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算。
在项目中，可以预设一个基准故事，例如，把实现用户认证页面的故事点定为1，以后每个用户故事都相对于“用户认证页面”这一故事来衡量工作量
2.需求管理
在敏捷实践中，对需求的管理有两种常见方法：完全解析和滚动解析。需求管理体现于一个重要活动： Product Backlog梳理
1.完全解析
完全解析后，项目的需求变得一目了然
1. 需求优先级十分明确， 能够画出细致的路线图；
2. 项目的工作量和工期能够较精确地估算；
3. 能让团队形成项目一切尽在掌握中的自信。
对于需求简单的小项目而言
完全解析有助于全面、 完整地把握项目， 控制项目进度， 并且也比较容易梳理和保持 Product Backlog 的条理性
对于复杂度规模的项目而言
完全解析可能导致Product Backlog管理混乱。长长的Backlog 列表难以组织和梳理，难以对需求进行解耦和确定优先级。并且由于需求是涌现的，频繁的需求变更往往会加重 Backlog的混乱程度， 增加无效工作
2.滚动解析
滚动解析是将需求分解和增量交付有机结合起来。
滚动解析是为了在保证需求的完整性、 合理性和一致性的前提下， 尽可能缩短需求定义和开发之间的时间间隔， 降低管理难度， 控制风险和成本。
3.Product Backlog梳理
该活动包含但不限于这些内容
1. 保持产品待办事项列表有序；
2. 把看起来不再重要的事项移除或者降级；
3. 增加或提升涌现出来的或变得更重要的事项；
4. 将事项分解成更小的事项；
5. 将事项归并为更大的事项；
6. 对事项进行估算。
排序越靠前， 优先级越高， 描述和解析越细致
2.极限编程(XP)
概述
是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。
XP核心价值
XP更加关注软件开发的良好实践，核心价值是简单、沟通、反馈、勇气、尊重。
1.简单：关注于对当前的需求来进行设计、编码
2.沟通：鼓励经常性的口头交流与反馈
3.反馈：要来自系统、客户和小组的反馈。编程中的乐观主义是危险的，而及时反馈则是解决它的方法。
4.勇气：只为今天的需求设计以及编码，不要考虑明天
5.尊重：每个人保证提交的任何改变不会导致编译无法通过，或者导致现有的测试用例失败，或者以其他方式导致工作延期。
架构探针
“架构探针”是在迭代中用于证明的一种技术方法,“探针”的工作是减少风险。探会在整个发布中使用到。
极限编程(XP)的核心实践
完整的团队
XP 项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他--些显示他们进度的东西。
规划游戏
XP中的需求分析，是通过规划游戏完成的。虽然我们从规划游戏开始，讨论极限项目的具体过程,但实际上，规划游戏中的一些阶段几乎贯穿了项目开发的始终。
分3个阶段规划
探测阶段：客户和开发人员- -起把需求分解成很多小的、可估算的部分。
计划阶段：客户和开发人员一起制订、发布计划。
调整阶段：客户和开发人员一起，在开发过程中，根据实际情况，及时调整原有的计划或者制订新计划。
小型发布
便于控制工作量和风险，也可以及时处理用户的反馈
客户测试
客户会描述一个或多个测试以展示软件是如何工作的
共同所有权
敏捷在很大程度上认为团队成员协作决策的参与性决策模式有助于在团队内建立信任。
虽然团队领导者或者scrum领导需要独自作一些决策，但是大部分决策是团队集体进行。这些敏捷原则也被称为集体所有权，自主管理和自我约束。
在集体所有权中,团队成员集体对项目结果负责，并被授权参与决策和问题解决流程。
编码标准
可持续的速度
隐喻
持续集成
测试先行/测试驱动开发
重构
简单设计
结对编程
3.特性驱动开发(FDD)
概述
是一种简单的便于理解的构建产品或解决方案的强有力的方法。项目团队使用FDD的方法首先可以为产品开发一个整体的模型，构建特性(功能)列表和工作计划。团队然后对开发的特性(功能)进行设计和构建迭代。
如图
undefined
工作事项名称——功能性列表
特征驱动开发(FDD)使用一个规范性的模型，当中计划，管理并从个别软件特征方面跟踪软件开发流程。
FDD使用2周或者更短时长的短迭代，来开发一定的特征
FDD的五个步骤是
1.开发整体模型
2.建立特征清单
3.依特征做规划
4.依特征做设计
5.依特征进行建立
一些良好的实践，包括
1.领域对象建模
2.按照特性(功能)开发
3.类(代码)拥有权
分配确定的开发者
特性的所有者(特性组长)需要协调多个开发人员的工作
4.特性小组
5.审查
6.配置管理
7.定期构建
8.可视性进度报告
4.动态系统开发方法(DSDM)
概述
倡导以业务为核心
DSDM的基本观点是，任何事情都不可能一 次性地圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求(传统方法- -般是需 求固定,时间和资源可变)，交付所需要的系统。
DSDM开发过程
undefined
工作事项名称——基于优先级的需求列表
处理事项优先级方案
MoSCoW优先级方案：Must：必须做的；Should：应该做的；Could：可以做的；Would not：不要做的。
DSDM周期有7个阶段
(1)项目准备阶段。
(2)可行性研究阶段。
(3)业务研究阶段。
初始项目活动
(4)功能建模阶段(迭代式)。
(5)系统设计编程阶段(迭代式)。
(6)实施阶段。
项目周期活动
(7)项目后期。
结束项目活动
项目生命周期有五个阶段：可能性研究、交易研究、功能模型、迭代设计、建立迭代安装启用。
DSDM有三个主要阶段：初始项目活动、项目周期活动、结束项目活动
5.水晶方法(CRYSTAL)
概述
水晶方法体系与XP一样，都有以人为中心的理念，但在实践上有所不同。水晶方法体系考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，水晶方法体系探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。
水晶
undefined
水晶是软件开发灵活轻便的一系列开发方法。是区分成员的颜色代码，例如透明，黄色，红色。颜色的选择取决于成果水平的要求。在光谱一端是完全透明的，不考虑颜色。
undefined
Crystal系列开发方法
Crystal Clear(透明水晶)
Crstal Yllow(黄水晶)
Crstal Orange (橙水晶)
Crystal Red (红水晶)
水晶架构是迭代的，并且有三个基本过程：章程、交付迭代、项目总结。
水晶纲领，包括
建设团队
做探索性的360°
为团队定义实践标准
建立初始项目计划
水晶方法拥抱很多其他的敏捷原则
1.频繁地交付
2.反思改进
3.渗透式沟通
4.个人安全
个人安全指的是当你指出困扰你的问题时，你不用担心受到报复。
5.焦点
所谓“焦点”，就是确定首先要做什么
6.与专家用户建立方便的联系
7.配有自动测试、配置管理和经常集成功能的技术环境
6.精益开发(LEAN)
概述
严格说来，精益开发不是一种敏捷的方法，但是精益和敏捷的价值观是紧密相关的。精益的一系列原则是从精益生产中来的,并应用于软件开发。对于精益来说有7个核心的概念，如图2-12所示。
如图2-12所示。
undefined
7个核心的概念
1.消除浪费
2.构建质量
3.创建知识
4.推迟决策
5.快速交付
6.尊重文化
7.整体优化
精益软件开发的原则
清除浪费
强化学习
尽可能晚决策
尽可能早交付
授权团队
构建完整性
全盘检视
看板方法
看板(Kanban)开发方法是近年来最热门的敏捷和精益开发方法。
看板的开发方法限制了在制品(WIP)的数量，这样可以帮助识别在开发过程中产生的问题和最小化浪费以及与成本相关的变更。它使用一个拉动系统进行工作。如图2-13所示。
undefined
看板的5个核心实践
1.可视化工作(价值)流
产品开发的加工对象一信息是抽象和不可见的，这提高了价值流的管理难度。看板开发方法把可视化工作流作为基础实践,先让价值和价值流动具体可见，然后才是管理和优化。图2-14是看板开发方法中的一个典型可视化案例，被称为看板墙( Kanban wall )。
undefined
价值流程图是敏捷采用的精益生产分析技能,用于对形成客户产品或服务的原料和信息(即价值)的流动进行分析。
流程图用于绘制一个流程来识别瓶颈(即流程会减缓和产生库存的地方)
执行价值流程图大致包括5个步骤
1)确认产品，客户和范围(即流程的始末)。
2)地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。
估算流程步骤的持续时长和前置期持续时长(leadtimedurations)。
前置期是指在发生前一项流程或者事件需等待的时长。
3)分析价值流程图来确认浪费存在的地方(比如前置期)和流程可完善的地方
流程时间通常认为是价值增加时间,但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间
4)通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图。
5)通过流程完善活动(即完善)或者其他方法来达到目标的一些工作。
价值流程图的目的是识别流程中的浪费领域和确认可完善的地方
2.限制在制品(WIP)数量
限制在制品数量是看板开发方法的核心机制。如图2-15所示，列标题右面的数字标识了该阶段允许的在制品的最大数目(进行中和完成的价值项的和)。在制品数目小于这个数字时，才可以从前一阶段拉人新的工作。图2-15中, 分析阶段的在制品限制数目是3，而实际在制品数目是2，可以拉人新的工作。测试阶段的在制品数是3，达到了上限，就不允许拉人新工作。
undefined
3.度量和管理流动
快速、顺畅的价值流动是看板开发方法的目标
看板开发方法没有定义特定的度量方法，累积流量图是实际应用较为普遍的一种。
典型的累积流量图
undefined
左面的斜线是累积已经开始的价值项(如用户需求)数目，右面斜线是累积完成价值项的数目
两条斜线的垂直距离表示某个时刻已经开始但还没有完成的价值项数目，也就是在制品的总计数量。
两条斜线的水平间距表示价值项从开始到完成的周期时间，也就是从概念到交付的响应时间，它是价值流动效率的一个重要衡量。
斜线的斜率反映的是价值交付的速率，也就是每周可以交付的价值项数量。
4.协同改进
应用可视化、限制在制品数量以及价值流度量,能够暴露产品开发中的问题和瓶颈。
但发现问题还不够，重要的是如何去解决它们，对此看板开发方法给出了两个建议：①团队协作；②应用科学方法与模型。
5.显式化流程规则
显式化流程规则，是指明确定义和沟通团队所遵循的流程规则。
价值项的“流转规则”是看板开发方法中最典型的流程规则，它定义了一个价值项从一个阶段进人下一阶段所必须达到的准。
图2-17给出了某团队其中一项流转规则的实例，定义了从分析阶段进人开发阶段所必须达到的条件。
undefined
undefined
7.测试驱动开发 (TDD)
测试驱动开发是先定义验收测试然后围绕这些测试实际模块、等级和功能，软件根据怎样会被接受这一前提而编写。当按此正确完成后，软件肯定能通过测试并被验收。
它是在工作开始前定义测试的一种技术，它采用零缺陷的思维模式使工作进度能持续得到确认。在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码。
TDD测试驱动开发过程具有4个基本步骤
1)编写测试
2)核对和确认测试
3)编写产品代码，接着采用测试
4)重构产品代码
遵循这4个步骤，迭代保证编程人员探讨一项软件程序，首先可能会如何失败，并且建立可全面测试的产品代码。这样有助于编出高质量的代码。
8.验收测试驱动(ATDD)
它是一种协作制定验收测试标准的方法，用于创建交付前的验收测试(以终为始)。
旨在验证预期软件中的特性/行为。
验收测试驱动开发(ATDD)与测试驱动开发(TDD)类似，在于它同样需要编程人员在产品代码前编写出测试。
迭代的4个步骤可简记为4个Ds
1)Discuss讨论：敏捷团队和客户或者商业干系人详细讨论用户故事，包含用户故事应有和不应有的预期行为。
2)Distill提取：开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提取流程中，整个团队应充分认识“完成”对用户故事的意义,这正是验收标准所在。
3)Develop开发：提取后,团队开发测试代码和产品代码以产生产品特性。
4)Demo示范：产品特性开发后,团队向客户或商业干系人展示以获得反馈。