• 1. 软件过程RUP、XP、实际开发中的Process
  • 2. 回顾软件过程指对软件开发整个过程中各个步骤的划分、定义以及如何来组织各个步骤 这次培训的主题是‘以过程为中心的现代软件开发’,但前三天都没有谈过程,这是因为只有在了解了UML和面向对象的基本理论后,才能够对现代的软件过程进行有效的学习安华明锐科技公司 www.inquiry-tech.com
  • 3. RUP - 概述RUP汇集了主流的业界理论和经验,是目前主流软件过程的代表产品 以架构为中心,用例驱动,迭代式开发 九个核心工作流:设商业建模、需求、分析和设计、实现、测试、分发和项目管理六个核心‘工程工作流’,配置、变更控制、环境三个核心‘支持工作流’安华明锐科技公司 www.inquiry-tech.com
  • 4. RUP - 概述分为初始、细化、构造、交付四个阶段,每个阶段以严格的里程碑为结束标准 每个阶段由一到多个迭代组成,每次迭代都可能执行所有工作流安华明锐科技公司 www.inquiry-tech.com
  • 5. RUP - 概述过程非常严格细致,投入非常多人力,产生非常多文档 可靠程度高,成本高,适合大型项目 也容易陷入文山会海,产生官僚主义安华明锐科技公司 www.inquiry-tech.com
  • 6. RUP - 三大特点以架构为中心 用例驱动开发 迭代式开发安华明锐科技公司 www.inquiry-tech.com
  • 7. RUP - 三大特点用例驱动 一个用例就是系统中向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求。所有用例结合起来就构成了“用例模型”,该模型描述系统的全部功能。 用例并不仅仅是定义一个系统的需求的一个工具。它们还驱动系统的设计、实现和测试。也就是说,它们驱动整个开发过程。基于用例模型,软件开发人员创建一系列的设计和实现模型来实现各种用例。测试人员将测试软件系统的实现,以确保实现模型中的组件正确实现了用例。安华明锐科技公司 www.inquiry-tech.com
  • 8. RUP - 三大特点用例驱动 用例不仅启动了开发过程,而且与开发过程结合在一起。“用例驱动”意指开发过程将遵循一个流程:它将按照一系列由用例驱动的工作流程来进行。首先是定义用例,然后是设计实现用例,最后, 用例是测试人员构建测试案例的来源。 尽管确实是用例在驱动整个开发过程,但是我们并不能孤立地选择用例。它们必须与系统架构协同开发。也就是说,用例驱动系统架构而系统架构反过来又影响用例的选择。因此,随着生命期的继续,系统架构和用例都逐渐成熟。安华明锐科技公司 www.inquiry-tech.com
  • 9. RUP - 三大特点以基本架构为中心 软件架构的作用在本质上与基本架构在建筑物结构中所起的作用是一样的。我们从不同的角度来观察建筑物:结构、服务、供热装置、水管装置、电力等。这样,在开始建设之前,建设人员就可以对建筑物有一个完整的把握。同样,软件系统的基本架构也被描述成要创建的系统的各种不同视图 基本架构是一个关于整体设计的视图,在这个视图中,省略了一些细节,以使软件的更为重要的特征体现得更为明显 一方面,我们实现的用例必须与基本架构相适应。而另一方面,基本架构必须留有实现现在和未来需要的所有用例的空间。在实践中,基本架构和用例必须平行开发安华明锐科技公司 www.inquiry-tech.com
  • 10. RUP - 三大特点以基本架构为中心 架构设计师必须对系统的关键功能也就是系统的关键用例有一个总体性把握。这些关键用例只占用例总数的5-10%,但是它们却是最重要的,因为它们将构成整个系统的核心功能。下面是这个过程的简单描述: ω 架构设计师首先从不与特定的用例相关的部分(比如平台)着手来创建基本架构的大致轮廓。尽管基本架构的这部分是用例无关的,但是,在建立基本架构的轮廓之前,架构设计师必须对用例有一个总体把握。 ω 其次,设计人员应当从已经确认的用例子集着手开始工作,这些用例是指那些代表待开发系统的关键功能的用例。每个选定的用例都应当被详细描述,并在子系统、类和组件层次上实现。 ω 随着核心用例已经被定义并且逐渐成熟,基本架构就越来越成形了。而这种状况,反过来又导致更多用例的成熟。 这个过程会不断持续下去,直至基本架构被认定为稳定了为止安华明锐科技公司 www.inquiry-tech.com
  • 11. RUP - 三大特点以基本架构为中心 四加一视图 作用安华明锐科技公司 www.inquiry-tech.com
  • 12. RUP - 三大特点迭代式开发 开发一个商业软件产品可能持续很长时间。因此,将工作分解成若干更小的部分或若干小项目是切合实际的。每个小项目是指能导致一个增量的一次迭代。迭代指的是工作流中的步骤,而增量指的是产品的成长 为了更加高效,迭代必须受到控制;也就是说,必须对它们进行选择并有计划地实现它们。这就是为什么它们是小项目的原因 开发人员根据两个因素来选择在一次迭代中要实现什么。首先,迭代与一组用例相关,这些用例共同扩展了到目前为止所开发的产品的可用性。其次,迭代涉及最为重要的风险。后续迭代是建立在先前的迭代完成后的开发成果之上的。它是一个小项目,因此,从用例开始,它还是必须经过下列开发工作:分析、设计、实现和测试,这样,就以可执行代码的形式在迭代中实现了用例。当然,一项增量并不一定就是添加性的。特别是在生命期的早期阶段,开发人员可能会用一个更为详尽或者复杂的设计来取代那种较为简单的设计。在后期,增量通常都是添加性的 安华明锐科技公司 www.inquiry-tech.com
  • 13. RUP - 三大特点迭代式开发 一个受控制的迭代过程的好处有很多 : ω 受控制的迭代降低了在一个增量上的开支风险。如果开发人员需要重复该迭代,整个开发团队损失的只是一个开发有误的迭代的花费而已,而不是整个产品的价值。 ω 受控制的迭代降低了产品无法按照既定进度表进入市场的风险。通过在开发早期就确定风险,人们就会在开发早期花时间来解决它们,而在这时,人们通常都不会像他们在开发后期那样匆匆忙忙。在“传统”方法中,困难的问题往往是在系统测试阶段才发现的,而解决这些问题所需求的时间通常又比开发进度中剩下的时间要多,因此,产品的延迟发布几乎是必然的 。 ω 受控制的迭代加快了整个开发工作的进度,这是因为开发人员很清楚焦点所在,而不是在一个漫长而不断变化的进度安排下工作,因此, 他们的工作会更有效率。 ω 受控制的迭代承认了通常都被忽略的一个事实:用户的需要和相应的需求并不能在一开始就作出完全的界定。它们通常都是在后续迭代中不断被细化的。此种作业模式使得适应需求的变化更为容易。安华明锐科技公司 www.inquiry-tech.com
  • 14. RUP - 三大特点这些概念即用例驱动的、以基本架构中心的、迭代式和增量性的开发是同等重要的。基本架构提供了指导迭代中的工作的结构,而用例则确定了开发目标并推动每次迭代工作 缺乏这三个概念中的任何一个,都将严重降低RUP的价值。这就好像一个三脚凳一样,一旦缺了任何一条腿,凳子都会翻倒安华明锐科技公司 www.inquiry-tech.com
  • 15. RUP - 核心工作流六个‘核心工程工作流’:商业建模工作流、需求工作流、分析和设计工作流、实现工作流、测试工作流、分发和项目管理工作流 三个‘核心支持工作流’:配置工作流、变更控制工作流、环境工作流安华明锐科技公司 www.inquiry-tech.com
  • 16. RUP - 四个阶段每个系统可能有多个生命周期,每个生命周期分为四个阶段 初始、细化、构造、交付 每个阶段由一到多个迭代组成,每次迭代都可能执行所有工作流 安华明锐科技公司 www.inquiry-tech.com
  • 17. RUP - 初始阶段初始阶段的目标是为系统建立商业案例和确定项目的边界 目的 明确软件系统的范围和边界条件,包括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定 明确区分系统的关键用例和主要的功能场景 展现或者演示至少一种符合主要场景要求的候选软件体系结构 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出) 估计出潜在的风险,主要指各种不确定因素造成的潜在风险 准备好项目的支持环境 成果 蓝图文档:核心项目需求、关键特色、主要约束的总体蓝图 原始用例模型(完成百分之十到二十) 原始项目术语表(可能部分表达为业务模型) 原始商业案例,包括业务的上下文、验收规范(年度映射、市场认可等等),成本预计 原始的风险评估 一个或多个原型 里程碑 -生命周期目标里程碑 - 就范围定义、成本/日程估计等达成共识安华明锐科技公司 www.inquiry-tech.com
  • 18. RUP - 细化阶段细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素 目的 确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度 针对项目的软件结构上的主要风险已经解决或处理完成 通过完成软件结构上的主要场景建立软件体系结构的基线 建立一个包含高质量组件的可演化的产品原型 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内 建立好产品的支持环境 成果 用例模型(完成至少百分之八十),所有用例均被识别,大多数用例描述被开发 补充捕获非功能性要求和非关联于特定用例要求的需求 软件体系结构描述 可执行的软件原型 经修订过的风险清单和商业案例 总体项目的开发计划,包括纹理较粗糙的项目计划,显示迭代过程和对应的审核标准 指明被使用过程的更新过的开发用例 用户手册的初始版本 里程碑 - 结构稳定安华明锐科技公司 www.inquiry-tech.com
  • 19. RUP - 构造阶段在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试 目的 通过优化资源和避免不必要的返工达到开发成本的最小化 根据实际需要达到适当的质量目标 据实际需要形成各个版本 - alpha, beta等 对所有必须的功能完成分析、设计、开发和测试工作 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品 确定软件、站点、用户都为产品的最终部署做好了相关准备 达成一定程度上的并行开发机制 成果 Beta版产品 测试计划、测试方案和测试报告文档 最终设计文档 里程碑 - 交付Beta版 安华明锐科技公司 www.inquiry-tech.com
  • 20. RUP - 交付阶段交付阶段的目的是将软件产品交付给用户群体 目的 进行Beta测试以期达到最终用户的需要 进行Beta测试和旧系统的并轨 转换功能数据库 对最终用户和产品支持人员的培训 达到用户要求的满意度 ... 成果 最终产品 安装包 用户手册等 里程碑 - 产品发布 安华明锐科技公司 www.inquiry-tech.com
  • 21. RUP - 静态结构开发流程定义了‘谁’‘何时’‘如何’做‘某事’。四种主要的概念被用来表达RUP 角色 - 谁 活动 - 如何 产物 -某事 工作流 - 何时安华明锐科技公司 www.inquiry-tech.com
  • 22. RUP - 核心工作流需要一种方法来描述能产生若干有价值的有意义结果的活动序列,显示角色之间的交互作用,这就是工作流。工作流是产生具有可观察结果的活动序列,可以用UML中的序列图、协同图或活动图来描述工作流。 RUP将开发过程中最基本的工作流称之为核心工作流 RUP中有九个核心工作流代表了所有角色和活动的逻辑分组情况 尽管九个核心工程工作流能使人想起传统瀑布流程中的几个阶段但应注意迭代过程中的阶段是不同的这些工作流在整个生命期中一次又一次被访问九个核心工作流在项目中的实际完整的工作流中轮流被使用在每一次迭代中以不同的重点和强度重复 安华明锐科技公司 www.inquiry-tech.com
  • 23. RUP - 核心工作流业务建模 绝大多数商业工程化的主要问题是软件工程人员和商业工程人员之间不能正确地交流这导致了商业工程的产出没有作为软件开发输入而正确地被使用反之亦然 针对该情况为两个群体提供了相同的语言和过程同时显示了如何在业务和软件模型中创建和保持直接的可跟踪性 在业务建模中使用业务用例来文档化业务过程从而确保了组织中所有支持业务过程人员达到共识。业务用 例被分析以理解业务过程如何被业务系统支持而这些在业务对象模型中被核实 安华明锐科技公司 www.inquiry-tech.com
  • 24. RUP - 核心工作流需求 需求工作流的目标是描述系统应做什么并允许开发人员和用户就该描述达成共识为了达到该目标进行提取 组织文档化需要的功能和约束跟踪为折衷方案及决定形成文档安华明锐科技公司 www.inquiry-tech.com
  • 25. RUP - 核心工作流分析和设计 分析设计工作流的目标是显示系统如何在实现阶段被实现的你需要一个如下系统: 在特定的实现环境中完成用例描述中指定的任务和功能 满足了所有的需求 健壮的被建造如果功能需求发生变化易于更改 分析设计结果是一个设计模型和可选的分析模型设计模型是源代码的抽象即设计模型充当源代码如何被组建和编制的蓝图。设计模型由设计类和一些描述组成设计类被组织成具有良好接口的设计包和设计子系统而描述则体现了类的对象如何协同工作实现用例的功能 安华明锐科技公司 www.inquiry-tech.com
  • 26. RUP - 核心工作流实现 实现阶段的目的 定义代码的组织结构以层次化的实施子系统的形式 实现类和对象以构件的形式源文件二进制文件可执行文件等 将开发出的构件作为单元进行测试 对由单个实现者或小组产生的结构集成为可执行的系统 系统通过完成构件而实现。RUP描绘了如何重用现有的组件或实现经过良好责任定义的新构件使系统更易于使用提高了系统的可重用性。构件被构造成实施子系统子系统被表现为带有附加结构或管理信息的目录形式。安华明锐科技公司 www.inquiry-tech.com
  • 27. RUP - 核心工作流测试 测试的目的是: 验证对象间的交互作用 验证软件构件的正确集成 验证所有需求被正确的实现 识别并确保载软件发布之前缺陷被处理 RUP提出了迭代的方法,意味着在整个项目中进行测试从而允许尽可能早的发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性应用和系统性能来进行。流程从每个维度描述了如何经历测试生命周期的几个阶段,计划、设计、实现、执行和审核 安华明锐科技公司 www.inquiry-tech.com
  • 28. RUP - 核心工作流发布 发布工作流的目标是成功地生成版本,将软件分发给最终用户,它包括了范围广泛的活动 生成软件本身外的产品 软件打包 安装软件 给用户提供帮助 许多情况下还包括如下的活动: 计划和进行Beta测试版 移植现有的软件或数据 正式验收 尽管发布工作流主要被集中在交付阶段,但早期阶段需要加入为创建阶段后期的发布做准备的许多活动 安华明锐科技公司 www.inquiry-tech.com
  • 29. RUP - 核心工作流项目管理 软件项目管理是一门艺术。它平衡了互相冲突的目标,管理风险,克服各种限制来成功地发布满足投资用 户和使用者需要地软件。如此少的无争议的成功项目无疑是该项任务难度的证明。 管理项目的框架 计划、配备、执行、监控项目的实践准则 管理风险的框架 安华明锐科技公司 www.inquiry-tech.com
  • 30. RUP - 核心工作流配置和变更管理 本工作流中描绘了如何在多个成员组成的项目中控制大量的产出物。控制有助于避免混乱,确保不会由以下的问题而造成产品的冲突: 同步更新 - 当两个或两个以上的角色各自工作在同一产物上时,最后一个修改者会破坏前者的工作 通知不达 - 当被若干开发者共享的产品中的问题被解决时,修改未被通知到一些开发者 多个版本 - 许多大型项目以演化的方式开发。一个版本可能供顾客使用,另一个版本用于测试,而第三个版本处于开发阶段。如果问题在其中任何一个版本中被发现则修改需要在所有版本中繁衍,从而可能产生混乱,导致昂贵的修改和重复劳动,除非变更被很好地控制和监控 安华明锐科技公司 www.inquiry-tech.com
  • 31. RUP - 核心工作流环境 环境工作流的目的是给软件开发组织提供软件开发环境-过程和工具软件-开发队伍需要它们的支持 工作流集中在项目环境中配置过程的活动,同样着重支持项目的开发规范的活动。提供了逐步指导手册,介绍了如何在组织中实现过程 环境工作流还包含了提供了定制流程所必须的准则、模板、工具的开发工具箱。 安华明锐科技公司 www.inquiry-tech.com
  • 32. RUP - 产品组成RUP是Rational公司的一个商业产品,它包括: 一套可裁减的过程(文档) 一个丰富的知识库 一套工具模版 一个定制开发工具安华明锐科技公司 www.inquiry-tech.com
  • 33. RUP - 总结RUP汇集了业界最佳经验,博大精深,我们这里只能做一些初步的介绍 要深入学习RUP,请阅读《统一软件开发过程》、《RUP引论》,及向Rational公司购买RUP产品安华明锐科技公司 www.inquiry-tech.com
  • 34. RUP的必要补充 - PSPPSP即个体软件开发过程,由卡内基梅隆大学的软件工程研究所研究员Humphrey创建 Humphrey是具有丰富软件开发经验的学者,他曾长期在IBM公司担任高级软件开发经理安华明锐科技公司 www.inquiry-tech.com
  • 35. RUP的必要补充 - PSPPSP是软件工程师个人的软件开发过程 PSP帮助软件工程师个人进行有效的时间管理、计划和进度管理以及质量管理。软件开发组织中的个体是否具备上述基本素质是同RUP本身同等重要的因素安华明锐科技公司 www.inquiry-tech.com
  • 36. RUP的必要补充 - PSPPSP应用统计过程控制理论,通过提出目标、搜集数据、反馈调整来帮助软件工程师达到按进度、不超预算(不加班)开发出优质软件的目标 实施PSP的方法:阅读《个体软件过程》(Introduction to PSP),长期坚持在软件开发工作中按照PSP方法搜集数据,进行调整 还可以阅读《软件工程规范》,里面完整地讲解了PSP安华明锐科技公司 www.inquiry-tech.com
  • 37. XPExtreme Programming 由Kent Beck等人创建和提倡 同CRC一样,具有非常实际的哲学思想安华明锐科技公司 www.inquiry-tech.com
  • 38. XP声明 本节内容由 提供,请访问http://www.chinaxp.org 获得更多资料安华明锐科技公司 www.inquiry-tech.com
  • 39. 我们为什么需要XP软件工程的应用现状:“特色”问题还是难以解决:国内因为资源限制,软件工程的实施流于形式; 国内软件工程的研究及推广工作,和实践脱钩; 旧的软件工程方法一直不能有效地支持变化。 在北美,虽然软件工程提高了项目成功率,但耗费巨大资源;需求难以量化; 软件从开发到维护及扩展,需求都有可能发生大变化; 编程对设计的反馈非常重要; 项目中的设计可能会经常变化; 代码的可读性和可维护性; ……安华明锐科技公司 www.inquiry-tech.com
  • 40. Fortune 500 公司中成功应用XP的公司包括Ford,Daimler-Chrysler,First Union National Bank,IBM,HP等等。 2-10人的小规模开发队伍(小规模开发队伍 小规模项目)。 越来越多的公司开始使用敏捷开发过程,或者将其与RUP等过程结合使用。谁在用XP安华明锐科技公司 www.inquiry-tech.com
  • 41. 什么是XP Kent Beck 1996XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. -- Kent Beck. XP是勇气,交流,反馈和简单。 XP是软件开发过程中的纪律,它规定你:必须在编程前些测试,必须两个人一起编程,必须遵守编程规范……。 XP是把最好的实践经验提取出来,形成了一个崭新的开发方法。Extreme Programming安华明锐科技公司 www.inquiry-tech.com
  • 42. 软工革命 — Agile Process程序员进行的是有创造性的脑力活动 — 以人为本 Open Source的启示 — 更好的Code Review和测试 对设计过程的重新思考 — 传统设计的缺陷 — 编程中的设计和编程外的设计 开发过程应该更多地面向代码而不是文档 — 轻量级 增量开发的趋势 — 迭代越来越频繁 新方法有Crystal,Scrum,XP等 — XP结合“纪律性”和“适配性”,发展得最好安华明锐科技公司 www.inquiry-tech.com
  • 43. Principles of Agile Processes最高目标是能持续地、及早地向客户交付软件; 拥抱变化; 频繁地发布可运行的软件; 客户和开发人员在一起工作; 以人为本; 最重要的衡量开发过程的手段,是可工作的软件; 稳定的开发速度; 敏捷高效的设计; 简单有效; 重视Teamwork; 积极的调整。 http://www.agilemanifesto.org/principles.html安华明锐科技公司 www.inquiry-tech.com
  • 44. XP的增量过程简单 设计迭代 计划测试驱动 Pair开发持续 集成重构1..N个 Iteration发布 计划1..N个 Release小发布发布1..N个 Task安华明锐科技公司 www.inquiry-tech.com
  • 45. XP中的重要概念 哲学观 管理 需求 设计
  • 46. 哲学观(Philosophy)交流(Communication)勇气(Courage)简单(Simplicity)反馈(Feedback)安华明锐科技公司 www.inquiry-tech.com
  • 47. 管理发布(Release):每一期开发结束时提交给用户的一个可运行的系统。 迭代(Iteration):一期开发过程中的一个开发周期。它有明确的目标,计划和实现方式,它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中,所有迭代的长度是相同的,比如都是3周。 小发布(Small Release):处于开发中的系统,每集成一个新功能,都可以称为一个小发布。 理想开发时间:估计完成一项工作所需的持续工作时间,不考虑意外因素。安华明锐科技公司 www.inquiry-tech.com
  • 48. 需求SPIKE:对不确定的需求和设计等,通过写一些程序、进行详细设计或者演算等等方式做探测和尝试,以确定可行性。这些探测过程称为SPIKE。 User Story:是对用户的一个需求的一段简洁清晰的描述,该段描述有三个属性,即商业优先级、开发时间和风险。从某个角度看,XP过程是面向User Story的。 故事卡:用户把User Story的内容和属性写在一张卡片上,该卡片即故事卡。 例,MSDN中的例子Island Hopper News: (1) 客户浏览分类广告;(2) 客户发布分类广告;……客户浏览分类广告1周价值:高风险:低客户发布分类广告2周价值:高风险:低安华明锐科技公司 www.inquiry-tech.com
  • 49. 发布分类广告浏览分类广告Use Case 说明: 名称 简短描述 事件流程 初始状态 结束状态 异常 ……术语表: 客户: …… 分类广告:…… ……补充说明: 可用性: …… 可靠性: …… 可维护性:…… ……User Story 和 Use Case 的区别Presentation Requirement Mock-up Window ……安华明锐科技公司 www.inquiry-tech.com
  • 50. User Story 和 Use Case 的区别User StoryUse Case Modeling从用户角度看从开发人员角度看由用户写由开发人员写给开发人员看给用户看一张卡片上的一段描述图每张卡必须有商业价值、开发风险和开发时间三个评估值每个图通常常有正规的说明、术语表等等不包含细节流程包含细节流程1周〈 粒度〈 3周无一张卡片只有一个User Story一个图通常有多个Use Case开发计划以User Story为单位无开发速度根据User Story计算无安华明锐科技公司 www.inquiry-tech.com
  • 51. 设计1. CRC: Class – Responsibility – Collaboration。1989年, Kent Beck和Ward Cunningham提出的OO分析和设计方法,现在得到了广泛应用。 Responsibility:Class的行为。 Collaboration: Class之间的相互联系和作用;Collaborator指和某行为(Responsibility)相关的Class。 可以在卡正面加上父类名,子类名;可以在卡背后加上属性。安华明锐科技公司 www.inquiry-tech.com
  • 52. 设计2. Engineering Task:Team一起分析设计一个User Story,把该Story要完成的事情分解,就形成了一些任务(Engineering Tasks)。这些任务要足够小,以至于每个程序员都非常清楚要做什么,并能估计出完成该任务所需要的理想开发天。 每个程序员挑选了一个Task后,就成为该Task的Owner,并估计完成该Task所需的理想开发天数。 Task的粒度由理想开发天限制,大于1天且小于3天。 从某个角度看,程序员的工作安排是面向Task的。 3. Task卡:Task的内容、Owner和理想开发天都记录在一张Task卡上。 例: 上个例子中每个CRC卡可以做为一个单独的任务被承担和估计。安华明锐科技公司 www.inquiry-tech.com
  • 53. XP的惯例和规则
  • 54. 十二条惯例和规则On-Site Customer (现场客户) 计划项目 (Planning Game) 频繁地小规模发布软件 (Small Releases) 简单设计 (Simple Design) 测试驱动开发 (Test Driven Development) 持续集成 (Continuous Integration)集体拥有代码 (Collective Code Ownership) 编程规范 (Coding Standards) 重构 (Refactoring) System Metaphor (系统隐喻) Pair Programming (结对编程) 平稳的工作效率 (Sustainable Pace)安华明锐科技公司 www.inquiry-tech.com
  • 55. On-Site Customer 客户是Team成员,在开发现场和开发人员一起工作。 传统的客户任务一般是讲解需求,运行验收测试,接收发布的系统。XP新增加的任务: (1) 写User Story (2) 评估User Story的商业优先级 (3) 为每个User Story定义验收测试 (4) 计划开发内容 (5) 调控开发过程 Any More?安华明锐科技公司 www.inquiry-tech.com
  • 56. On-Site Customer建立商业模型,把隐藏在客户需求下的原则传授给开发人员: 程序员理解的是表象,而不是本质; 程序员分担任务的过程支解了对他们商业模型的理解; 某些开发外包或分阶段开发(例如增量、迭代等)导致“知识泄露”。 参加设计过程: 和程序员一起找出Metaphor,导引设计方向: 在Metaphor的帮助下,定义更有效更实际的功能测试,给程序员的设计制定了规范; CRC卡鼓励客户更多地参加设计过程。安华明锐科技公司 www.inquiry-tech.com
  • 57. System Metaphor “The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works.” — Kent Beck Team将Domain/Sub-Domain Model,Design/Sub-Design Model以及一些关键概念等等抽象化为比喻。通过这些比喻,加强客户和程序员之间的相互理解,消化积累知识,指导设计开发的方向。 例: Market —发布/浏览,价格洽谈,生成和履行合同; String,Tree,Package,Chartroom,Spider,Robot ……; 电影后期制作 —> 邮递 —> 电影院播放电影。安华明锐科技公司 www.inquiry-tech.com
  • 58. System MetaphorMetaphor的形成过程,是客户建立并抽象商业模型和商业概念的过程,是程序员建立并抽象设计模型和设计概念的过程。 Metaphor使客户和程序员用共通的模型和语言进行交流 — “One Team, one language”。 Metaphor可以帮助减少“知识泄露”和“支解知识”。 Metaphor是设计过程的航标 —— 真正灵活有效的设计是针对商业原则的设计,而不是针对商业原则表现形式的设计,更不是脱离商业需求目的的学术设计。 随着开发的继续,Team会找到更好的Metaphor。这是知识细化、深化的结果,是“持续学习”(Continuous learning)的过程;是对商业模型和设计模型的持续重构。安华明锐科技公司 www.inquiry-tech.com
  • 59. 计划项目增加/改变 需求产生和评估 User Story发布计划迭代计划1迭代计划2迭代计划n…………实施迭代1实施迭代2实施迭代n…………1..N个发布探索阶段计划阶段调整阶段调整开发 速度 / 内容安华明锐科技公司 www.inquiry-tech.com
  • 60. 测试驱动开发失败通过时间单元测试 100% 通过设计先写 单元测试重构运行 单元测试编程发现BUG集成先写 功能测试User Story运行 功能测试安华明锐科技公司 www.inquiry-tech.com
  • 61. 重构减少重复设计,优化设计结构,提高技术上的重用性和可扩展性。 在Metaphor指引下的重构,是为商业模型服务的。不要把重构变成不断的盲目精简代码。 重构和编程前的计划型设计(Planned Design)结合,使XP的简单设计可行有效。 XP提倡毫不留情的重构(Refactor mercilessly)。 任何人可以重构任何代码,前提是重构后的代码一定要通过100%测试单元测试后才能被Check-in。 可以根据需要,将一个迭代的全部目标定为重构。 不要太在意什么是最简单的设计 —— 愿意在最后重构,比知道如何做简单的设计重要得多。安华明锐科技公司 www.inquiry-tech.com
  • 62. 需求 分析 设计 编码 测试 集成 使用和维护Planned DesignXP Design变化导致的成本增加软件研发 异动曲线简单设计 XP中的演进设计(Evolutionary-design)如果没有它和众多惯例规则之间的耦合,XP的演化设计就蜕化成CODE-FIX。 XP的演化设计是在Up-front design和Refactoring之间找到新的平衡。安华明锐科技公司 www.inquiry-tech.com
  • 63. 简单设计 简单可行,不要增加现阶段不需要的复杂功能。 简单设计 —— Do the simplest thing that could possibly work;You aren’t going to need it(YAGNI)。 标准(依重要性):通过所有测试,可读性高的代码,避免重复,最少数量的类别或方法。 System Metaphor给设计提供了指引,加强Team对设计的理解; 第一个迭代搭建了基本的系统框架。 以后的迭代过程,是在反馈和编程的基础上做交互式设计,减少了设计的投机性。 迭代过程中的CRC卡帮助Team交流设计思想,简化了设计文档。 重构对设计进行优化。安华明锐科技公司 www.inquiry-tech.com
  • 64. 编程规范规定了程序的风格,包括注释如何写,变量命名的规范,代码的格式等等。 Teamwork 的前提之一,其它众多惯例和规则(如Pair Programming, Collective Code Ownership等)的前提之一。安华明锐科技公司 www.inquiry-tech.com
  • 65. 集体拥有代码“我们”的代码,而不是“我”的代码。 任何人可以改动任何一段代码,但改动后的代码必须通过所有相关的测试。 简单设计,编程规范和Pair Programming,使阅读和修改Team内其他人的代码变得实际可行。安华明锐科技公司 www.inquiry-tech.com
  • 66. Pair Programming 两个程序员使用同一台电脑共同开发。XP的必须组成部分,XP中最有争议的规则之一。安华明锐科技公司 www.inquiry-tech.com
  • 67. 持续集成测试先行是持续集成的一个重要前提。 持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。 随时整合,越频繁越好;集成及测试过程的自动化程度越高越好。 每次只有一个PAIR在整合,而且必须运行功能测试。失败通过时间功 能 测 试安华明锐科技公司 www.inquiry-tech.com
  • 68. 频繁地小规模发布软件发布过程应该尽可能地自动化、规范化。 不断地发布可用的系统可以告诉客户你在做正确的事情。 客户使用发布的系统,可以保证频繁地反馈和交流。 保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。 降低开发风险。 随着开发的推进,发布越来越频繁。 所有的发布都要经过功能测试。安华明锐科技公司 www.inquiry-tech.com
  • 69. 平稳的工作效率 平稳的工作效率指Team和个人在很长的时期内保持一定的开发效率。 保证了项目速度和计划过程的有效性和准确性; 保证了程序员可以持续地完成任务,Team可以持续地向客户交付可运行的系统(见敏捷开发宣言); 加班多导致开发效率和质量下降,简洁增加了开发成本; Pair Programming已经加大了工作强度,并且和其它XP的规则一起提高了工作效率,使少加班和维持平稳的工作效率可能而且可行。 提倡平稳的工作效率,体现了XP以人为本的价值观。安华明锐科技公司 www.inquiry-tech.com
  • 70. XP过程
  • 71. TeamProduct Manager/Project manager Coach Team lead Developers Tracker QA (On-Site) Customers安华明锐科技公司 www.inquiry-tech.com
  • 72. 环境既有无隔墙隔板的工作场地,也又单独的工作间; 一个足够宽敞的地方供大家开会; 足够大的白板; 足够长的电脑桌,可以让两个人并排坐在同一台电脑前面; 每一个人都能很容易地看到其他人并和他们交流。 一些白纸或者卡片。 更理想的条件: POP 电视机 Video Game 落地玻璃窗安华明锐科技公司 www.inquiry-tech.com
  • 73. 开发迭代计划CRC卡设计承担Task分解TaskPair进行 测试驱动的开发持续集成和发布迭代结束发布 计划产生Story评估Story开始提炼 Metaphor多个迭代多期 计划安华明锐科技公司 www.inquiry-tech.com
  • 74. 总结
  • 75. EXTREME的来由if the code review is good, we‘ll review code all the time (pair programming). if testing is good, everybody will test all the time (unit testing ) even the customer (functional test). if design is good, we'll make it part of everybody's daily business (refactoring). if simplicity is good, we'll always leave the system with the simplest design that supports its current functionalities (simple design). if architecture is important, everybody will work defining and refining the architecture all the time (metaphor). if integration testing is important, then we'll integrate and test several times a day (continuous integration). if short iterations are good, we'll make the iterations really really short- seconds and minutes and hours, not weeks and months and years (planning game).安华明锐科技公司 www.inquiry-tech.com
  • 76. 惯例和规则频繁的反馈 测试驱动开发 计划项目 On-site Customer Pair Programming 共同理解交流 简单设计 System Metaphor 集体拥有代码 编程规范持续的增量开发 持续集成 重构 频繁地小发布 以人为本 稳定的工作效率安华明锐科技公司 www.inquiry-tech.com
  • 77. 交流交流开发讨论设计Pair ProgrammingQA交谈文档卡片图表代码测试文件编程 规范工作环境会议计划会议Standup Meeting回顾发布 计划迭代 计划System Metaphor代码集体所有Team其它 价值观勇气简单反馈有交流过度的项目吗?安华明锐科技公司 www.inquiry-tech.com
  • 78. 反馈反馈学习程序员 之间回顾CoachPair文档Spike其它 价值观勇气简单交流开发集成测试Pair Programming单元 测试持续集成验收测试迭代小规模发布产品计划评估On-site Customers调控风险时间价值反馈就是抱怨?安华明锐科技公司 www.inquiry-tech.com
  • 79. 勇气勇气Team集体 拥有代码合作统一 规范其它 价值观反馈简单交流态度自信品质好胜骄傲迭代计划开发Refactoring编程配置 管理Simple Design测试取舍安华明锐科技公司 www.inquiry-tech.com
  • 80. 简单简单需求CRCOn-Site Customers项目 计划其它 价值观勇气反馈交流质量持续集成开发轻量极开发环境系统Simple DesignRefactoring做最简单的事情 让系统运行System Metaphor安华明锐科技公司 www.inquiry-tech.com
  • 81. XP ON-SITE Everything is public!宽敞明亮舒适的工作场地。 巨幅的表格挂在墙上,每个人都能马上知道项目的进展情况。 所有的DESIGN都是公开展示的。 巨幅的Story卡挂在墙上,客户正在给程序员们解释需求。 一些程序员正在对墙上贴的TASK卡进行讨论。 一些程序员正在用用CRC卡和客户一起设计一个Story。 不断地见到有人在讨论交流,没有人是独自躲在角落里静悄悄地写程序。 …………安华明锐科技公司 www.inquiry-tech.com
  • 82. XP的局限XP强调发挥人的作用,强调代码的价值,这些的确是软件开发活动中非常关键的因素,与此对应的是实施许多其它过程时,容易陷入文档之中,而忽视了这两个关键问题,导致低效 由于XP的这种哲学,不太适合在大型项目中使用。XP也许把人的能动性和代码的作用发挥到了极至,当它能满足要求的时候,具有很高的投入产出比,但在大型项目中仅仅这样可能就不够了。这时候还是应该考虑RUP,更正式、严格地进行阶段划分、架构设计、抽象和风险管理安华明锐科技公司 www.inquiry-tech.com
  • 83. 自定义过程单一的软件过程不能适用所有的情况 每个开发组织有不同的人员构成、水平、经验、社会经济环境等,项目的类型、大小也会需要不同的开发过程 软件开发组织必须结合具体情况定义自己的开发过程,并根据具体项目进行调整甚至更换 流行的过程应该作为重要参照安华明锐科技公司 www.inquiry-tech.com
  • 84. 人员构成 – 技术人员构成比例金字塔形结构表达了数量比例安华明锐科技公司 www.inquiry-tech.com
  • 85. 人员构成 – 监督管理人员配备安华明锐科技公司 www.inquiry-tech.com
  • 86. 协作 - 小组划分TeamLeaderLeader candidateMember candidateDesignChief DesignerArchitect Senior ProgrammerCodingCoding leaderSenior ProgrammerSenior Programmer, Professional ProgrammerQAQA ManagerQA ManagerQA Engineer安华明锐科技公司 www.inquiry-tech.com
  • 87. 协作 - 分工负责 Chief DesignerQA ManagerCoding leaderPMPlan and progressDefect locatingDesign qualityCode qualityGrasp RequirementSupervision and coordinate 安华明锐科技公司 www.inquiry-tech.com
  • 88. 流程 - 概述Biz analysis, req collectCoding & unit testArchitecture designClass designReq analysisIntegration testSystem testDesign teamCoding teamQA teamConsultantreviewreviewreviewreviewreview安华明锐科技公司 www.inquiry-tech.com
  • 89. 流程 - 从系统工程角度一般地一个系统的开发整体上可以划分为三个阶段:系统策划、产品设计、产品实现,一个软件密集的系统的产品实现步骤即是软件开发 也可以说,一个软件密集型系统的开发整体上可以划分为三个阶段:系统策划、产品设计、软件开发 软件开发是我们关注的一步,是最后一步,往往是工作量最大的一步,软件开发始于需求分析安华明锐科技公司 www.inquiry-tech.com
  • 90. 流程 - 从系统工程角度在开始软件开发之前,进行领域分析,建立业务模型是非常必要的。当然取决于实际项目的业务模型复杂程度以及变化程度,领域模型可以非常正式,也可以非常简略 领域建模可以使用的技术有领域类模型、对象模型(更接近于信息建模);对于工作流为中心的业务可以多采用活动图;一般还要做出业务用例模型,对系统的功能建模安华明锐科技公司 www.inquiry-tech.com
  • 91. 流程 - 需求搜集需求搜集,业务建模,系统策划 成果 业务模型描述,系统策划书,系统外部约束(运行环境、技术上的要求、其它系统接口等) ‘一直在变的不是需求,而是人的认识和理解’ 安华明锐科技公司 www.inquiry-tech.com
  • 92. 流程 - 需求分析需求分析,产品设计 成果 用例模型,用户手册,系统规格书,界面设计 安华明锐科技公司 www.inquiry-tech.com
  • 93. 流程 -数据库设计数据库设计 成果 数据库建库脚本、er图、数据库设计文档 安华明锐科技公司 www.inquiry-tech.com
  • 94. 流程 -结构设计结构设计 成果 软件结构模型(软件层次和模块划分、公共类的定义、职责、关系)安华明锐科技公司 www.inquiry-tech.com
  • 95. 流程 -详细设计详细设计 成果 软件公共接口(公共类的公共函数设计),用例的实现分析(顺序图) 安华明锐科技公司 www.inquiry-tech.com
  • 96. 流程 -编码实现包括单元测试的编码实现,单元测试必须要由函数规格描述(javadoc)来支持,因此代码、函数规格描述和单元测试三者加起来,是这个环节的成果安华明锐科技公司 www.inquiry-tech.com
  • 97. 流程 -集成测试集成测试,验证对设计的正确实现。 包括主线测试,压力测试,边界测试安华明锐科技公司 www.inquiry-tech.com
  • 98. 流程 -系统测试系统测试,验证对需求的正确实现安华明锐科技公司 www.inquiry-tech.com
  • 99. 流程 -系统维护安华明锐科技公司 www.inquiry-tech.com
  • 100. 制度 - 概述安华明锐科技公司 www.inquiry-tech.com
  • 101. 制度 - 人才提供良好工作环境,维持高素质技术队伍 包括待遇、工作环境以及下面要谈到的合理工作时间和加强培训、学习、交流,维持一支金字塔形的技术队伍。安华明锐科技公司 www.inquiry-tech.com
  • 102. 制度 - 质量保证质量 将质量放在第一位,采用各种手段保证工作质量,包括有量化标准的完备的单元测试,有量化标准的完备的javadoc,design review,三阶段code review,自动化的、方案驱动的、专人负责的集成测试(主线、边界、压力)。量化考核交付时万行代码的bug数目,将用户实际使用一个月內发现的错误数目上限作为一个明确指标。 步步为营这句古训在工程项目实施中非常重要,开发中的每一步,都必须按照预定标准扎扎实实做好,不能因为这样那样的意外,随意降低标准,遗留隐患。任何情况下不能在质量上打折扣,企图牺牲质量换取虚假的进度的想法被实践证明只能适得其反 安华明锐科技公司 www.inquiry-tech.com
  • 103. 制度 - 进度保证进度 每个项目设定现实的里程碑,保证每个里程碑按时按质量到达是整个项目组必须完成的任务,是每个人的责任。同时,项目进行中工作安排尽量以明确的任务为单位,每项任务均应该有明确的时间计划,任务的时间计划由项目经理和工程师讨论确定,保证每个任务按时完成和不断调整得到对速度的正确估计是每个工程师重要职责。 项目经理应该根据每个人的时间估计制定合理的计划,不安排超负荷的工作量,保证最高工作效率;而每个工程师则要尽量对自己的每项任务做出准确估计,要建立每个人对自己提出的时间估计负全部责任的气氛,自己定出的目标必须不惜一切代价去完成。建议每个人对每次估计和实际时间进行跟踪,以尽快提高自己的估计准确度安华明锐科技公司 www.inquiry-tech.com
  • 104. 制度 - 劳逸结合合理的工作时间 保证合理的工作时间,以实现高效率和高质量。尽量只安排在正常上班时间内通过提高效率、钻研技术、专心致志可以完成的工作量。 安华明锐科技公司 www.inquiry-tech.com
  • 105. 制度 - 人员构成有效的人员构成 软件开发成功的关键是人,没有足够数量、合理搭配的合格人才,任何好的规范、流程都很难奏效。针对项目的类型、应用领域、技术难度、时间要求,应该按照合适的比例进行搭配,组建足够达到进度和质量标准的项目组。 安华明锐科技公司 www.inquiry-tech.com
  • 106. 制度 -分工负责分工负责 分散责任,并明确责任人。项目组一般由项目经理、设计组、编码组、QA组构成。主设计师对设计质量负责,编码组leader对编码质量负责,QA组leader对需求理解和及时发现系统缺陷负责,项目经理监督各个负责人,并对计划和整体进度和质量负责,等。 安华明锐科技公司 www.inquiry-tech.com
  • 107. 制度 - 利用经验采用业界最佳实践 结合项目具体情况,选择采用经过实践验证的先进理论指导开发,例如RUP、XP、UML、设计模式、迭代开发 安华明锐科技公司 www.inquiry-tech.com
  • 108. 制度 -奖惩分明 严格监督,奖惩分明 对于项目进行过程中各个成员的工作情况,要通过各种手段进行监督检查,全面具体地掌握。 对于一些关键指标如代码质量、进度完成情况、估算准确度、注释编写的正确和完整程度、单元测试的覆盖率不但要随时掌握全面情况,进行记录和统计,还要有针对性的奖惩措施,让制度、流程的执行效果都能有直接的体现安华明锐科技公司 www.inquiry-tech.com
  • 109. 制度 - 其它还有很多其它方面,包括: 重视培训 知识管理 风险管理 积累经验和数据 其它一些较基本的措施,如引入版本控制工具、缺陷跟踪工具,自动化的测试,内嵌的文档等安华明锐科技公司 www.inquiry-tech.com
  • 110. 文化各项要点是相辅相成的,要提高待遇,同时要求大家不折不扣执行制度;做计划时要保证合理工作时间,不计划加班也不要求加班,同时就要求大家必须自己想办法完成自己的估计;准备良好的工作环境,举办各种轻松身心的活动,提高士气和效率,提供各种培训和交流,提高大家的技术水平,这些活动大家都可以选择参加,只要能保证自己的工作按时按标准完成,等等 要建设一个愉快的,高生产率的工作环境,这个环境只适合具备强烈的时间观念、专业精神,能高度自律的程序员 安华明锐科技公司 www.inquiry-tech.com
  • 111. 其它最佳实践大量软件开发组织在多年开发中总结出了许多最佳实践,能够有效地解决开发中的常见问题,提高开发质量和效率 这些实践经验可以在各种过程配合使用,进一步保证项目的成功率 RUP中集成了迭代式开发、需求管理、CBD、可视化建模、检验质量、变更控制等最佳实践 下一课中我们会介绍配置管理、需求管理、缺陷跟踪、内嵌文档、自动测试、团队协作、自动创建等安华明锐科技公司 www.inquiry-tech.com