业界敏捷浪潮

• ISO 9000（09版）标准将在原来八大原则的基础上新增敏捷原则
• 2000年美国军方软件开发标准（DOD 5000.2）推荐迭代为软件开发优选模式
• 世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一

软件开发顺应时代变化，从重型过程转向轻量型敏捷。

敏捷宣言揭示更好的软件开发方法

• 敏捷宣言（ 2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动；
• 敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作。

敏捷更符合软件开发规律

• 软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长；
• 敏捷开发遵循软件客观规律，不断地进行迭代增量开发，最终交付符合客户价值的产品。

对敏捷的常见误解

• 误解一： 敏捷开发意味着可以不需要文档、设计和计划
• 误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合
• 误解三： 敏捷只适用于小项目开发
• 误解四： 敏捷只会对研发产生改变
• 误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了
• 误解六： 引入敏捷只需要按照既定的步骤去做就可以了
• 误解七： 敏捷是CMM的替代品，是另一种流程
• 误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了

统一认识：敏捷=理念 优秀实践 具体应用

敏捷包括三个层次：

• 理念（敏捷核心思想）
• 敏捷包括3个层次 优秀实践（敏捷的经验积累）
• 具体应用（能够结合自身灵活应用才是真正敏捷）

理念：聚焦客户价值(Value)，消除浪费

产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费。

理念：激发团队(Team)潜能，加强协作

• 团队是价值的真正创造者，应加强团队协作、激发团队潜能
• 软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本

理念：不断调整以适应(Adapting)变化

不断地根据经验调整，最终交付达到业务目标的产品。

具体应用：因地制宜选择适合的敏捷实践

团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化。

深入理解敏捷理念

深入理解“聚焦客户价值”

• 标识和消除软件开发中的浪费
• 交付刚刚好的系统
• 随时构建质量，不容忍缺陷
• 及时消除技术债务，持续保持快速响应

深入理解“激发团队”

• 认清团队的基本事实
• 敏捷方式下管理者的转变
• 敏捷方式下团队成员的转变

深入理解“适应变化”

• 认清“客户是逐步发现真正需求”
• 小批量是快速交付的关键
• 通过迭代计划不断调整以适应需求变化
• 应持续保持良好的软件架构
• 利用多层次反馈不断调整以逼近目标

聚焦客户价值，标识和消除软件开发中的浪费

聚焦客户价值，交付刚刚好的系统

在项目明显超负荷时，管理者简单地期望靠团队work harder来解决，最终导致：

• 质量下降
• 项目延期
• 客户不满意
• 团队疲劳
• 埋下长期隐患

当质量、进度、资源冲突时，能改变的只有项目范围，即选择“交付刚刚好的系统”

• 产品交付前，客户往往期望多而全的功能，产品交付后，客户把稳定的质量放在首位。
• 与其为了满足多而全的功能导致交付延迟，质量不稳定，不如按时交付刚刚好的系统，保证其高质量运行。
• 交付刚刚好的系统，基于对客户需求的深入理解，并花时间了解细节，简化（simplify）需求（降低复杂性）而不是简单地拒绝需求（delete）。
• 做到“交付刚刚好的系统”，同时需要管理者有足够的勇气和果断决策。

聚焦客户价值，随时构建质量，不容忍缺陷

缺陷遗留带来高额成本：

• 对单独质量保证活动（如后端测试）的依赖，容易形成缺陷可以遗留到下个阶段的心理，导致缺陷发现成本升高（系统测试阶段缺陷定位和解决成本是开发阶段的10倍）

从项目一开始就随时构建质量：

• 形成零缺陷文化，不要容忍缺陷：发现缺陷应立即停下来解决，以保证在坚实的质量基础上前行。
• 开发和测试紧密协作：测试人员参与到设计和开发过程中，共同预防缺陷的产生。

聚焦客户价值，及时消除技术债务，持续保持快速响应

常见技术债务:

• 日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静态检查告警等。

为什么会有技术债务：

• 为满足短期商业目标，不影响其外部表现的情况下，会在技术方面进行一定的让步，这种让步虽对当前版本的质量影响甚微，但会严重影响后续版本响应客户需求的能力，从而形成技术债务。

对待技术债务的态度：

• 技术债务是有成本的，如不及时偿还，会随时间积累利息变高，导致开发效率大幅下降，从而降低客户响应能力。因此对待技术债务的态度是加以管理并及时偿还（如及时重构）。

激发团队，认清团队的基本事实

关于团队激励：

• 当团队自管理时效率最高
• 人们对自己做出的承诺比别人要求的承诺更认真
• 人们会尽力做到最好
• 在强大的压力下努力工作，人们会自然而然地降低对质量的要求

关于团队绩效：

• 当团队成员不被打扰时，工作效率最高
• 当团队解决自我问题时，提升最快
• 广泛的、面对面的交流是团队工作最高效的方式

关于团队构建：

• 团队生产率大于相同数目的个体生产率之和
• 当不同技能领域的人员组成团队并聚焦于工作时，产品更健壮

激发团队，敏捷方式下管理者的转变

敏捷方式下对管理者最大的挑战是学会放松”控制”(loose control)。

激发团队，敏捷方式下团队成员的转变

从被动到主动的心态转变是团队成员适应敏捷开发的关键。

适应变化，认清“客户是逐步发现真正需求”

适应变化，小批量是快速交付的关键

适应变化，通过迭代计划不断调整以适应需求变化

• 变化无法一次性预测，一开始制作大而全的计划易造成浪费
• 应根据迭代积累的经验和需求变化的情况对计划不断调整和细化

适应变化，应持续保持良好的软件架构

良好软件架构是适应变化的基石

• 电信软件的特点是庞大、复杂、生命周期长，因此需要良好架构来保证长期的演进，避免大规模的返工；
• 优秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷；
• 良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集成计划，使分层分级的持续集成更加容易实施。

软件架构需要尽早验证和持续维护

• 新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定；
• 增量开发需识别影响架构的需求，优先实现，规避架构风险；
• 通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。

适应变化，利用多层次反馈不断调整以逼近目标

利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整自身行为，并逐步逼近靶心。

敏捷软件开发核心——迭代开发

什么是迭代式开发

• 迭代开发将整个软件生命周期分成多个小的迭代（一般2-4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。

迭代式开发的关键要点

• 每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。
• 每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。
• 迭代推荐采用固定的周期（2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期。

迭代式开发的好处

• 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险。
• 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要。
• 通过小批量减少排队，提供更灵活、快速的交付能力。
• 平滑人力资源的使用，避免出现瓶颈。

迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上。

敏捷团队的三个核心角色

敏捷团队包括3个核心角色: PO(Product Owner)、Scrum Master(Scrum教练)和Team(开发产品)。

敏捷团队的角色职责

敏捷团队实践：完整团队

什么是完整团队

• 敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。
• 完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。

完整团队的关键要点

• 成员来自多功能领域：团队拥有完成目标所需的各职能成员；
• 坐在一起办公：团队成员无障碍地沟通；
• 团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。

完整团队的好处

• 有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合；
• 通过面对面沟通提升沟通效率。
• 实现团队成员的高度协同，支撑高密度地、持续地、短周期的交付。

完整团队聚焦客户需求交付，提高协作效率。

敏捷软件开发典型场景

• PO和开发团队对产品业务目标形成共识；
• PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序；
• PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发；
• 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成；
• 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明；
• PO对每轮迭代（2－4周）交付的可工作软件进行现场验收和反馈；
• 回到第3步，开始下一轮迭代。

敏捷工作件：产品Backlog

什么是产品Backlog

• 经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。

产品Backlog关键要点

• 清楚表述列表中每个需求任务对用户带来的价值，做为优先级排序的重要参考；
• 动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代；
• 迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）。

产品Backlog的好处

• 通过需求的动态管理应对变化，避免浪费；
• 易于优先交付对用户价值高的需求。

产品Backlog是需求动态管理的载体。

敏捷工作件：迭代Backlog

什么是迭代Backlog

• 迭代Backlog是团队在一轮迭代中的“任务”（Task）清单，是团队的详细迭代开发计划；
• 当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”；
• 每项任务信息包括当前剩余工作量和责任人。

迭代Backlog关键要点

• “任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；
• 任务要落实到具体的责任人；
• 任务粒度要小，工作量大于两天的任务要进一步分解；
• 用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。

迭代Backlog的好处

• 将需求分解成更细小的任务，利于对迭代内进度进行精确控制；
• 剩余工作量可用来实时跟踪团队当前进展。

迭代Backlog提供精细的迭代开发计划。

敏捷工作件：完成标准（Definition of Done）

什么是完成标准

• 基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识；

完成标准的关键要点

• 团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守；
• 有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准。

完成标准的好处

• 共同协商的完成标准是团队的自我承诺，团队会更认真；
• 用于准确评估团队工作进展；
• 清晰和明确的完成标准保证了每次迭代是高质量的。

完成标准确保团队每一步前进都奠定在坚实的质量基础之上。

敏捷管理实践：迭代计划会议

什么是迭代计划会议

• 每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog；
• 多团队迭代计划会议要分层召开

1. 版本迭代计划会议：将产品Backlog（需求）分配给团队；
2. 团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员；

• 迭代计划会议内容：

1. 澄清需求、对“完成标准”达成一致
2. 工作量估计、根据团队能力确定本轮迭代交付内容；
3. 细化、分配迭代任务和初始工作计划。

迭代计划会议的好处

• 通过充分讨论，使团队成员对任务和完成标准理解一致；
• 团队共同参与，促进团队成员更认真对待自己的承偌。

迭代计划会议的关键要点

• 充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一致；
• 相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周）；
• 确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序 。

迭代计划会议由团队共同确定迭代交付内容和完成标准。

敏捷管理实践：每日站立会议

什么是每日站立会议

• 每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加
• 聚焦在下面的三个主题：

1. 我昨天为本项目做了什么？
2. 我计划今天为本项目做什么？
3. 我需要什么帮助才能更高效的工作？

每日站立会议的关键要点

• 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；
• 高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）；
• 问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决；

每日站立会议的好处

• 增加团队凝聚力，产生积极的工作氛围；
• 及时暴露风险和问题；
• 促进团队内成员的沟通和协调。

每日站立会议促进团队沟通协调，及时暴露问题。

敏捷管理实践：可视化管理

什么是可视化管理

• 将项目状态 (进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息。

可视化管理的关键要点

• 物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到，（存在电脑中的文件不是可视化的）；
• 内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；
• 实时刷新：延迟的信息拖延问题暴露，降低运作效率。

可视化管理的好处

• 简单，一目了然 ，降低管理成本；
• 实时状态显示，及时暴露问题；
• 信息同源使团队理解一致，提升团队凝聚力；
• 激励先进，鞭策后进，增强团队进取心。

可视化管理及时暴露问题，激励团队。

敏捷管理实践：迭代验收

什么是迭代验收

• 每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；
• 由Scrum Master组织， PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示可工作软件。

迭代验收的关键要点

• 展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完成”标准；
• 收集反馈：PO 根据验收情况及客户反馈意见，及时调整产品Backlog。

迭代验收的好处

• 通过演示可工作的软件来确认项目的进度，具有真实性；
• 能尽早地获得用户对产品的反馈，使产品更加贴近客户需求。

迭代验收尽早演示可工作的软件，收集反馈意见。

敏捷管理实践：迭代回顾会议

什么是迭代回顾会议

• 在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；

• 围绕如下三个问题：

1. 本次迭代有哪些做得好
2. 本次迭代我们在哪些方面还能做得更好
3. 我们在下次迭代准备在哪些方面改进？

迭代回顾会议的关键要点

• 会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
• 关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；
• 会议结论要跟踪闭环：可以放入迭代backlog中。

迭代回顾会议的好处

• 激励团队成员；
• 帮助团队挖掘优秀经验并继承；
• 避免团队犯重复的错误；
• 营造团队自主改进的氛围。

迭代回顾会议是促进团队持续改进的最有效手段。

敏捷工程实践：用户故事（user story）

什么是用户故事

• 用户故事是站在用户角度描述需求的一种方式；
• 每个用户故事须有对应的验收测试用例；
• 用户故事是分层分级的，在使用过程中逐步分解细化；
• 典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。

用户故事的关键要点

• I – Independent，可独立交付给客户；
• N – Negotiable，便于与客户交流；
• V – Valuable ，对客户有价值；
• E – Estimable ，能估计出工作量；
• S – Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成；
• T – Testable，可测试。

用户故事的好处

• 用户故事站在用户视角便于和客户交流，准确描述客户需求；
• 用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；
• 用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。

用户故事便于团队站在用户角度分解细化需求并制定验收标准。

敏捷工程实践：结对编程

什么是结对编程

• 两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；
• 操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；
• 领航员检视的同时还必须负责考虑下一步的工作方向 ，比如可能出现的问题以及改进等。

结对编程的关键要点

• 程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；
• 开始一个新Story开发的时候即可变换搭档，以增进知识传播；
• 培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果；
• 实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异。

结对编程的好处

• 有助于提升代码设计质量；
• 研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高；
• 结对编程能够大幅促进团队能力提升和知识传播。

结对编程提高代码质量和工作效率。

敏捷工程实践：持续集成(CI)

什么是持续集成

• 持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。

持续集成的好处

• 大幅缩短反馈周期，实时反映产品真实质量状态；
• 缺陷在引入的当天就被发现并解决，降低缺陷的修改成本；
• 将集成工作分散在平时，通过每天生成可部署的软件；，避免产品最终集成时爆发大量问题。

持续集成的关键要点

• 持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息；
• 自动化测试用例的完备性和有效性是持续集成质量保障；
• 修复失败的构建是团队最高优先级的任务；
• 开发人员须先在本地构建成功，才可提交代码到配置库 ；
• 持续集成的状态必须实时可视化显示给所有人；
• 大系统持续集成需分层分级，建立各层次统一的测试策略。

持续集成提供产品质量的快速反馈，保证随时拥有可工作的软件。

结束语

• 方法和模型不是万能的，但是没有方法和模型是万万不能的。
• 任何一种方法和模型，要深刻理解并身体力行，都是要付出巨大的努力和代价的，甚至会伴随着剧烈的阵痛。
• 停止抱怨，寻找问题解决之道，并坚持不懈地前进，才有可能获得成功。