c++敏捷软件开发方法简介【荐】.ppt

11 每周四十小时工作制 在这里40是一个概数，不是确数 如果能够努力地工作8小时，超过这个时间后就不适于 　有效地工作了——8小时燃烧 再学习 你无法改变时间，但是可以改变你的任务 12 代码规范 不变的只是愿望，变化才是永恒。 如果你聆听代码，好的设计就会出现。 3.5　XP讨论：XP和软件设计 XP提倡循序渐进的软件设计方法，以避免在前置设计中 　花费巨大的精力 但这不是回到编码加修正（Code and Fix）的开发方式 初始设计不可能面面俱到 受人员变动影响 设计人员和编码人员之间存在协同问题 设计人员和编码人员之间存在技能差异 不能适应变化的需求 计划设计 缺乏整体性 设计可能不可控 潜在的缺陷可能会引起其它缺陷 修正缺陷的代价可能会呈指数增长 对设计和编码人员要求更高 柔性设计 计划设计 重构 XP中对柔性设计的支持 简单设计 测试先行 持续集成 重构 做可能有效的最简单的事情 Do the Simplest Thing That Could Possibly Work 你将不会需要它 You Aren’t Going to need it 简单的价值 效益 轻装上阵 做且仅做一次 Once and Only Once 不要自我重复 Don’t Repeat Yourself XP衡量简单的标准 通过所有的测试 代码体现所有设计意图：Clever Code 避免重复 类或方法的数量最少 模式\反模式和XP 模式 反模式 对初学者 重构的目标之一－模式 选择使用模式的时机 模式和简单性 UML和XP 最好的UML图也不是产品！ 3.6　XP应用之一：XP在高校科研中的应用 高校研究室\组人员的一般构成： 一名以上的教授\副教授 博士生 硕士生 附属工作人员 临时教学或研究的学生 临时合作人员 高校科研用例图（理工类） 快速反馈 XP提倡尽可能早地、迅速地每天反馈，让编程人员始终 　把注意力放在最重要的软件功能上，促使系统快速演进 XP迭代过程 假设简单性 XP试图把注意力集中在能工作的尽可能最简单的实现上； 　另一方面，可以根据给定的项目资源条件，最优地分配项 　目资源 递增更改 XP认为首次更改就尝试重大更改绝对不会成功，提倡以 　重构概念为基础做小改动，用期望的功能逐步增强系统 提倡更改 最佳策略是在实际解决最重要的问题的前提下保留最多 　选项的那一个，在交付最需要的东西上保留选择余地 优质工作 3.3　XP活动——XP软件开发的基石 编码 测试 倾听 设计 编码 作为一种轻量级方法论，XP明确放弃了系统建档和分析 　以外的任何外在活动 分析保留为一种相当简单，但是在和客户的日常沟通中 　发生的持续活动 文档则明确不予鼓励，所以编码成为XP最主要的活动 测试 为了确保编写好的代码能实践工作，XP提倡编写大量测 　试来检查代码是否正确 倾听 XP编程人员倾听客户和其他编程人员的需求和意图 设计 从日常的编码中返回来进行一些一般性设计，小的设计成为 　XP编程人员日常事务的一部分 3.4　XP的实践——项目成员用户成功执行XP活动的技术 1.现场客户（On-site Customer） 2.计划游戏（Planning Game） 3.系统隐喻（System Metaphor） 4.简单设计（Simple Design） 5.代码集体所有（Collective Code Ownership） 6.结对编程（Pair Programming） 7.测试驱动（Test-driven） 8.小型发布（Small Releases） 9.重构（Refactoring） 10.持续集成（Continuous integration） 11.每周40小时工作制（40-hour Weeks） 12.代码规范（Coding Standards） 过程 团队实践 编程 现场客户、测试、计划游戏、小型发布 简单设计、测试、重构、编码标准 代码集体所有、持续集成、隐喻、编码标准、每周40小时工作制、结对编程、小型发布 XP层次结构 1 现场客户 始终在开发团队中有一位客户 现场客户的工作： 回答问题 编写验收测试 运行验收测试 指导迭代 接受版本 2 计划游戏 以业务优先级和技术估计为基础，决定下一版本发布的范围 3 系统隐喻 在XP中，隐喻是一种概念框架并提供名称的描述系统， 　类似于其他方法中的体系结构（或体系结构基准） 共识 共享的术语空间 例子：Windows风格的界面、网上购物站点的购物车 4 简单设计 系统应设计得尽可能简单 5 代码集体所有 整个团队拥有所有代码 任何人都可以更改他们需要更改的部分 没有唯一对代码有所有权的人 题外话一：编程的乐趣(F P. Brooks) 创造的快乐 开发对他人有