敏捷开发基础概念介绍

《敏捷软件开发 原则 模式与实践》 《重构》 《人月神话》 《编写有效用例》 《人件》 《修改代码的艺术》 《 Scrum 敏捷项目管理》
敏捷项目全流程梳理
敏捷项目流程
迭代1
Story1开发 StoryN开发 迭代n Story1开发 StoryN开发 AT AT ST ST AT AT ST ST
总结




软件是复杂的，由此引发了一致性和可变性的问题。随着软件规模的日益膨胀， 参与的人日益增加，软件的本质问题越来越突出 复杂性： 1、采用分而治之的思想，把一个大的软件划分为多个小特性，降低了每一 轮迭代搜需面临的复杂度 一致性： 1、按照特性组织团队，发挥群体智慧，团队共同拥有代码，共同为需求、 架构、设计、测试负责。 2、通过持续的反馈（迭代、面对面的沟通）消除不一致 可变性 1、变化难以预测，过早的应对变化会导致浪费。Keep it simple。 2、每一个项目都是不同的，每一个人也都是不同的。敏捷团队根据团队成 员和项目需求的特性，自己决定流程、方法和工具



对敏捷常见的误区

敏捷不写文档 敏捷不适合大型软件开发，尤其是高质量要求领域 敏捷和CMM对立


敏捷是银弹！？

敏捷导致对人员的极度依赖 敏捷导致管理者无法看到项目组的进展，从而导致失控


只写项目组认为必须的文档 如果认为项目组新员工比较多，可能就得写比较多的文档 如果需要经常和大量的客户、众多的项目组交流，可能就需要比较多的书 面规格、接口文档。因为人多的时候，面对面的沟通带来N平方问题
AB E D

敏捷强调软件的需求、设计、计划都是复杂的，以至于不可能一次就精确的 完成，所以要通过快速的反馈对需求、设计、计划进行修正
迭代是敏捷建立持续的快速反馈机制的技术手段

敏捷与迭代关系(续)

随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团 队的必选项。但是迭代对整个团队的需求、架构、协同及测试能力都提 出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中， 敏捷可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比 迭代化开发更大一些
彭珂 Date: July 13, 2012

敏捷是一种强调轻量的过程方法论，它强调拥抱变化而不是与之对抗，通过有 效的沟通发挥群体的智慧 敏捷方法论采用迭代/增量开发的过程模型 敏捷门派众多，2001年，成立敏捷联盟，并发布了宣言和原则


敏捷宣言
个体和交互 可以工作的软件 客户合作 响应变化 胜过 胜过 胜过 胜过 过程和工具 面面俱到的文档 合同谈判 遵循计划

常见的文档为： 需求文档，敏捷实际上要求对需求的阐述非常细致，并且可测（部分非功 能性需求可能难以测试），现有产品文档根本无法满足要求。但是迭代开 发中文档是跟随迭代过程不断完善，而且很多公司是在测试完成后才开始 写规格文档。文档是结果记录，而非开发过程中的沟通工具。 代码（代码即设计文档）：最好的代码是自注释代码，应当尽量通过重构 让代码可以直接阅读，尽可能减少需要注释才能看懂的代码。 架构文档（通常是几页纸，参见附录微软对架构的看法）
1、我们的成功经验是什么？ 2、有什么能改进？

针对项目组当前的问题，自主决策改进方案，并在下一个迭代中实施， 即使改进方案无效，也可以在下一个迭代回顾时发现，最多 浪费一个迭代周期

自我决策改进方案，以适应复杂的需求、人员状况，是敏捷团队的最大特点
敏捷实践
敏捷是聪明的工作
敏捷是关于以下三件事情的：

敏捷导致对人员的极度依赖

敏捷强调团体的智慧，团队共同决策，实际上减少了人员的依赖 结对编程保证了任何一行代码都至少有两个人懂 持续集成保证了即使不了解系统也敢于修改系统。同时大量的测试用例是 系统最准确的文档。对系统有疑问，而又没人可以咨询的时候，可以通过修 改代码、测试用例的方式去探索，而看不懂文档就完全没有办法了

我们的版本开发是不是迭代？
1、宏观上讲，我们也是迭代开发，但颗粒度太大，存在问题 2、周期太长，验证反馈太慢，长周期要承担更多的需求变更风险，导致恶性循环 3、没有真正识别主要需求点和主要设计点，无法尽快确认需求和避免设计风险 4、不具备快速验证的能力 5、对于大部分的产品，我们应用迭代的主要诉求在2，3两点
敏捷不适合大型软件开发

胶片前面已经介绍过，众多的电信厂商、微软、IBM、美国军方、神舟飞 船系统，均采用或者部分采用敏捷的思想进行开发 敏捷认为变化不可预测，如果小型项目的变化都不可预测，大型项目显然 更无法预测，所以认为敏捷适用于小型项目，大型项目使用瀑布的说法是 错误的。


CMM定义的是目标，敏捷的实践可以支撑CMM2、3级的KPA，Scrum的两个 掌门人，以及CMM 1.1的项目经理Paulk均持此种观点，但是也有很多人不认同 此观点。SEI的官方网站2008年11月也发表文章《CMMIorAgile Why Not Embrace Both.pdf》 http: //www.infoq.com/cn/news/2008/11/reportintegrating-cmmi-agile，试图融合。 敏捷除了关注CMM关注的流程，更多的关注团体智慧、发挥个人能力 敏捷和IPD-CMM是截然相反的，一个基于瀑布模型，一个基于迭代模型

相对于传统的瀑布式开发，迭代开发把软件生命周期分成很多个小 周期（一般不大于2个月，建议2周），每一次迭代都可以生成一个 可运行、可验证的版本，并确保软件不断的增加新的价值。

迭代的主要目的
1、验证关键设计方案，避免重大的设计风险（主要设计点） 2、尽快确认和澄清客户需求（主要需求点） 3、缩短验证周期（只有在小粒度迭代上才可能实现），提供灵活的特性交付能力
计划story SDP 项 目 启 动 计 划 阶 段
BugFixed SDV 总结 B B I T 验 收 发 布 总 结
计划story SDP
BugFixed SDV 总结
测 试 思 路
Design
Code/UT
Code Review
私有构建
STC
Thanks!
IPD-CMM号称可以不依赖于人，但是仅仅是目标，从来都没有做到 代码日益腐烂，完全无法看懂，没有人敢改代码。 文档糟糕透顶，绝大多数文档是应付流程的产物


敏捷方法是项目的救星吗？不， 我认为它依然会失败。敏捷开 发可以带给你的一件事情是： 让这些项目失败的更快、损失 的更少，因为你可以将时间和 精力用于开始做下一件事情。 Kent Beck

敏捷的三个要素是迭代开发、坦诚合作和自适应性。坦诚合作其实才是 敏捷的精髓，如Ivar所说，敏捷其实是有关Social Engineering的。敏 捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这 是在软件工程几十年的发展过程中相对被忽略的领域
敏捷宣言遵循的原则-迭代

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞 争优势 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付 的时间间隔越短越好 工作的软件是首要的进度度量标准




在团队内部，最具有效果且富有效率的传递信息的方法，就是面对面的交谈

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
围绕被激励的个体来构建项目。给他们提供所需的环境和支持，并且 信任他们能够完成工作 敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够 保持一个长期的、恒定的开发速度


敏捷导致项目管理失控

敏捷虽然强调团队自组织，但是管理者可以通过持续集成和迭代测试结果知 道项目组的实际进展 特性的完成没有二义性，完成了50%的特性就有很大的把握知道项目组的进 展达到了50%。而文档的完善度、正确性根本无法评价，这也是为什么普遍 存在的现象：TR4前进度总是可以完成的，TR4以后进度总是拖后的。我们见 过TR4以后疯狂的加班，但是有谁见过开发人员加班到12点写详细设计文档？
A2
A A3 B1
Feb Mar
B2
B B3 C1
Apr May
C2
C C3
Jun
Jul
计划
A B
C D Week1 Week2 Week3 Week4
AB CD
传统模式下的延迟方式
Week1 Week2 Week3 Week4 Week5 Week6 Week7 Week8
迭代模式下的延迟方式
AB Week1 Week2 Week3 Week4 Week5 Week6 Week7 Week8
虽然右边的也有价值，但是我们认为左边的具有更大的价值

微软







大规模使用，敏捷列入新员工培训课程 Nokia Simens 超过40个产品使用敏捷流程，最大的项目约500名开发人员，跨地域、时差 IBM 项目经理可以自主选用瀑布或者敏捷流程，将为华为提供敏捷顾问和工 具 Ericsson 从第一代GSM基站开发就采用增量式迭代开发，使用敏捷的部分实践 Google 大部分项目敏捷，部分采用传统方法开发 Wiki Wiki的发明人是敏捷宣言的发起人之一，Wiki的灵感来源于敏捷的“集 体代码所有权”思想 神舟飞船软件系统 在敏捷宣言发表之前即采用敏捷的思想 BT： Huawei to propose how we can meet the agile requirements of BT.

最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是， 如何以一个团队的形式开展工作，如何激励团队成员，如何相互合作等 等 敏捷是轻量级的。敏捷非常依赖隐性知识，敏捷认为，只要有掌握足够 知识的人，才可以开发出优秀的软件 敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分 敏捷的本质是变得“聪明” ，聪明就是做正好合适的事，不是找更广的 解决方案，而是正好 。



不断地关注优秀ຫໍສະໝຸດ Baidu技能和好的设计会增强敏捷能力
简单---使未完成的工作最大化的艺术---是根本的

敏捷宣言遵循的原则-自组织团队

最好的构架、需求和设计出自于自组织的团队

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后 相应地对自己的行为进行调整

每一次迭代结束，项目组坐在一起对迭代进行回顾，回答两个问题：
特性集 A
A1 A2 A3 = B1 B2 B3 = C1 C2 C3 =
A B C B A C A3 B3 C3
May Jun Jul
特性集 B
特性集 C
传统方法: “每件事都很重要！一次就要全部做好！”
A1
Jan
B1
C1
Feb
A2
Mar
B2
C2
Apr
迭代开发: “优先级 & 关注点!”
A1
Jan