1、敏捷软件开发介绍,Davin,2009年06月 N.001,目录,敏捷理念 敏捷优秀实践 敏捷应用建议,2018/10/11,Page 3,软件作坊,软件过程控制,重型过程,2001今 敏捷正在流行,软件规模小，以作坊式开发为主；硬件飞速发展，软件规模和复杂度激增，引发软件危机；引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢；随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流
2、行。,软件危机,20世纪60年代,80年代,90年代,软件开发顺应时代变化，从重型过程转向轻量型敏捷,70年代,敏捷诞生的历史背景,Page 4,Hw敏捷的发展： 2006年之前：IPD （集成产品开发） 20062008年：从咨询公司ThoughtWorks引入敏捷软件开发，开展软件项目试点 2008后：产品试点，全部软件项目使用，硬件项目使用优秀实践腾讯敏捷的发展： 2006年之前：IPD （集成产品开发） 2006年之后：从咨询公司ThoughtWorks引入敏捷软件开发，正式命名为 TAPD（Tencent Agile Product Development）,HW敏捷和腾讯敏捷的发展
3、,Page 5,敏捷宣言揭示更好的软件开发方法,敏捷宣言（ 2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动 敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作,敏捷宣言,Page 6,软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品,传统开发,敏捷开发,敏捷更符合软件开发规律,Page 7,对敏捷的常见误解,误解一： 敏捷开发意味着可以不需要文档、设计和计划 误解二： 敏捷只是一些优秀实践，或者是优秀实践的
4、结合 误解三： 敏捷只适用于小项目开发 误解四： 敏捷只会对研发产生改变 误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了 误解六： 引入敏捷只需要按照既定的步骤去做就可以了 误解七： 敏捷是CMM的替代品，是另一种流程 误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了,Page 8,统一认识：敏捷=理念+优秀实践+具体应用,理念（敏捷核心思想） 敏捷包括3个层次 优秀实践（敏捷的经验积累）具体应用（能够结合自身灵活应用才是真正敏捷）,理念,优秀实践,具体应用,Page 9,敏捷理念,不断调整以适应(Adapting)变化,激发团队(Team)潜能，加强协作,聚焦客户价值(
5、Value)，消除浪费,Page 10,优秀实践: 业界敏捷优秀实践概览,结对编程,测试驱动开发,客户参与验收,计划游戏,代码集体所有,每日站立会议,产品backlog （带优先级的需求清单）,燃烧图,迭代计划会议,回顾会议,Scrum Master,Product Owner,Anatomy（系统解剖）,One Track,Systemakut（缺陷管理和决策）,重构,完整团队,稳定开发节奏,Lagomising（需求决策）,隐喻,电信业偏重大规模产品实践、Scrum偏重项目管理，XP偏重编程实践,电信业,Scrum,XP,持续集成,迭代交付,敏捷软件开发典型场景,Page 11,PO和开发
6、团队对产品业务目标形成共识 PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序 PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明 PO对每轮迭代（24周）交付的可工作软件进行现场验收和反馈 回到第3步，开始下一轮迭代,Page 12,什么是完整团队 敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。 完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、
7、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。,完整团队的好处 有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合； 通过面对面沟通提升沟通效率。 实现团队成员的高度协同，支撑高密度地、持续地、短周期的交付。,完整团队的关键要点 成员来自多功能领域：团队拥有完成目标所需的各职能成员； 坐在一起办公：团队成员无障碍地沟通； 团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。,完整团队聚焦客户需求交付，提高协作效率,敏捷团队实践：完整团队,Page 13,产品Backlog关键要点 清楚表述列表中每个需求任务对用户带来的价值
8、，做为优先级排序的重要参考； 动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代； 迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）。,敏捷工作件：产品Backlog,什么是产品Backlog 经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。,产品Backlog的好处 通过需求的动态管理应对变化，避免浪费； 易于优先交付对用户价值高的需求。,产品Backlog是需求动态管理的载体,Page 14,什么是迭代Backlog 迭代Backlog是团队在一
9、轮迭代中的“任务”（Task）清单，是团队的详细迭代开发计划； 当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”； 每项任务信息包括当前剩余工作量和责任人。,敏捷工作件：迭代Backlog,迭代Backlog的好处 将需求分解成更细小的任务，利于对迭代内进度进行精确控制； 剩余工作量可用来实时跟踪团队当前进展。,迭代Backlog关键要点 “任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务； 任务要落实到具体的责任人； 任务粒度要小，工作量大于两天的任务要进一步分解； 用小时做为任务剩余工作量的估
10、计单位，并每日重估计和刷新。,迭代Backlog提供精细的迭代开发计划,任务,责任人,状态,剩余工时,日期,Page 15,敏捷工作件：完成标准（Definition of Done）,什么是完成标准 基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识；,完成标准的好处 共同协商的完成标准是团队的自我承诺，团队会更认真； 用于准确评估团队工作进展； 清晰和明确的完成标准保证了每次迭代是高质量的。,完成标准的关键要点 团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守； 有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准
11、。,Story完成标准样例,迭代完成标准样例,发布完成标准样例,代码合入主干,代码符合规范,代码100%检视,通过验收测试,通过迭代验收,系统测试用例100%通过,通过性能测试,所有Story完成,通过回归测试,所有缺陷解决,更新配套资料,完成标准的样例,代码100%通过单元测试,持续集成无错误,完成标准确保团队每一步前进都奠定在坚实的质量基础之上,Page 16,敏捷管理实践：迭代计划会议,什么是迭代计划会议 每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog； 多团队迭代计划会议要分层召开 版本迭代计划会议：将产品Backlog（
12、需求）分配给团队； 团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员； 迭代计划会议内容： 澄清需求、对“完成标准”达成一致 工作量估计、根据团队能力确定本轮迭代交付内容； 细化、分配迭代任务和初始工作计划。,迭代计划会议的好处 通过充分讨论，使团队成员对任务和完成标准理解一致； 团队共同参与，促进团队成员更认真对待自己的承偌。,迭代计划会议的关键要点 充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一致； 相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周
13、）； 确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序 。,迭代计划会议由团队共同确定迭代交付内容和完成标准,Page 17,敏捷管理实践：每日站立会议,什么是每日站立会议 每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加 聚焦在下面的三个主题： 我昨天为本项目做了什么？ 我计划今天为本项目做什么？ 我需要什么帮助以更高效的工作？,每日站立会议的关键要点 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯； 高效会议：会议限时15分钟，每个人都保持站立，依次发言，
14、不讨论与会议三个主题无关的事情（如技术解决方案等）； 问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决；,每日站立会议的好处 增加团队凝聚力，产生积极的工作氛围 及时暴露风险和问题； 促进团队内成员的沟通和协调。,每日站立会议促进团队沟通协调，及时暴露问题,Page 18,敏捷管理实践：可视化管理,可视化管理的好处 简单，一目了然 ，降低管理成本； 实时状态显示，及时暴露问题； 信息同源使团队理解一致，提升团队凝聚力； 激励先进，鞭策后进，增强团队进取心。,什么是可视化管理 将项目状态 (进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展
15、信息。,可视化管理的关键要点 物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到，（存在电脑中的文件不是可视化的）； 内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨； 实时刷新：延迟的信息拖延问题暴露，降低运作效率。,可视化管理及时暴露问题，激励团队,Story墙（展示Story进度）,缺陷走势图（展示缺陷解决进展）,Anatomy视图（展示系统集成进展）,Page 19,敏捷管理实践：迭代验收,什么是迭代验收 每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求； 由Scrum Master组织， PO和用户代表（外部或内部
16、利益相关人）负责验收、Team负责演示可工作软件。,迭代验收的好处 通过演示可工作的软件来确认项目的进度，具有真实性； 能尽早的获得用户对产品的反馈，使产品更加贴近客户需求。,迭代验收的关键要点 展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完成”标准； 收集反馈：PO 根据验收情况及客户反馈意见，及时调整产品Backlog。,迭代验收尽早演示可工作的软件，收集反馈意见,Page 20,敏捷管理实践：迭代回顾会议,迭代回顾会议的好处 激励团队成员； 帮助团队挖掘优秀经验并继承； 避免团队犯重复的错误； 营造团队自主改进的氛围。,什么是迭代回顾会议 在每轮迭代结束后
17、举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步； 围绕如下三个问题： 本次迭代有哪些做得好 本次迭代我们在哪些方面还能做得更好 我们在下次迭代准备在哪些方面改进？,迭代回顾会议的关键要点 会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因； 关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）； 会议结论要跟踪闭环：可以放入迭代backlog中。,迭代回顾会议是促进团队持续改进的最有效手段,好的,能做得更好的,将来改进的,Page 21,敏捷工程实践：用户故事（user story）,什么是用户故事 用户故事是站在用户角度
18、描述需求的一种方式； 每个用户故事须有对应的验收测试用例； 用户故事是分层分级的，在使用过程中逐步分解细化； 典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。,用户故事的好处 用户故事站在用户视角便于和客户交流，准确描述客户需求； 用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈； 用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。,用户故事的关键要点 I Independent，可独立交付给客户 N Negotiable，便于与客户交流 V - Valuable ，对客户有价值 E - Estima
19、ble ，能估计出工作量 S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成 T - Testable，可测试,初始需求：1.作为网络规划人员，我想要配置一个媒体网关，因为想要增加网络容量和服务 初次分解：1.1作为网络规划人员，我想把媒体网关参数上传到管理系统1.2作为网络规划人员，我想从管理系统下载媒体网关参数 再次分解：1.2.1作为网络规划人员，我想用文件方式从管理系统下载媒体网关参数用例：用户在管理系统上选择以文件方式下载媒体网关参数，执行成功后，检查文件是否正确下载到本地且内容正确1.2.2作为网络规划人员，我想用MML结构方式从管理系统下载媒体网关的参
20、数用例:,故事样例,用户故事便于团队站在用户角度分解细化需求并制定验收标准,敏捷工程实践：结对编程,Page 22,什么是结对编程 两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码； 操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”； 领航员检视的同时还必须负责考虑下一步的工作方向 ，比如可能出现的问题以及改进等。,结对编程的好处 有助于提升代码设计质量； 研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高（source: The Economis
21、t）； 结对编程能够大幅促进团队能力提升和知识传播。,结对编程的关键要点 程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象； 开始一个新Story开发的时候即可变换搭档，以增进知识传播； 培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果； 实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异。,结对编程提高代码质量和工作效率,Page 23,敏捷工程实践：持续集成(CI),什么是持续集成 持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。,
22、持续集成的好处 大幅缩短反馈周期，实时反映产品真实质量状态； 缺陷在引入的当天就被发现并解决,降低缺陷修改成本； 将集成工作分散在平时，通过每天生成可部署的软件；，避免产品最终集成时爆发大量问题。,持续集成的关键要点 持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息； 自动化测试用例的完备性和有效性是持续集成质量保障； 修复失败的构建是团队最高优先级的任务； 开发人员须先在本地构建成功，才可提交代码到配置库 ； 持续集成的状态必须实时可视化显示给所有人； 大系统持续集成需分层分级，建立各层次统一的测试策略。,持续集成提供产品质量的快速反馈，保证随时
23、拥有可工作的软件,参见附件：持续集成解读.ppt,Page 24,敏捷工程实践：Anatomy系统解剖,Page 24,什么是Anatomy Anatomy（解剖）来源于电信行业，从用户视角全面展示复杂产品系统的功能依赖关系，让整个系统的功能按自底向上逐步有序地开发和集成。,Anatomy的关键要点 Anatomy不是系统架构视图，图中的Block是表示系统提供给用户使用的一个功能（capability），是站在纯用户视角，不包含设计信息； Anatomy中的依赖关系是用户使用系统功能的依赖关系，而不是设计或架构上的依赖关系； Anatomy是系统全视图，由最了解系统的工程师绘制出基线，在增量
24、开发时需不断刷新。,Anatomy帮助团队理解系统全局，制定合理的迭代计划,Anatomy的好处 Anatomy是迭代计划制定的重要依据，保证系统按照类似生物自然生长的顺序自底向上有序地开发和集成（Organic integration）； Anatomy也可作为可视化工具，通过标识图中每一个功能的状态，使项目整体进展一目了然，并能极大增强团队的信心； 有助于团队从增量交付向交付全系统的思维转变； 是很好的培训教材，帮助工程师了解全系统。,Anatomy样例,2018/10/11,敏捷辅助参考资料,敏捷软件开发：原则、模式与实践 硝烟中的Scrum和XP Scrum敏捷项目管理,Page 26,谢谢！,2018/10/11,
