（1）软件开发过程是什么？
软件开发过程是按照软件工业化的标准定义的
在软件开发中必须具有的一系列过程规范； 软件开发过程是定义在软件中的软件需求、软件
设计、软件编码、软件测试、软件部署的实现目标和规范化的管理方法论；
软件开发过程是保证软件工业化生产的法典； 软件开发过程做的是：定义标准和为了达到标准
的路；
软件开发过程要改善的是：软件开发的效率和质
量；
软件开发过程的实现最重要的是：人。 （2）大多数软件项目失败的原因：
a) 不完整、不现实的项目需求 件危机。
（5）A software engineer’s job:
a) Make a working plan.制定工作计划 b) Carry out it.(Do their work according to
this plan)按照此计划工作
c) Try his/her best to produce high-quality
products.尽最大努力生产出高质量产品
(6)3 Key aspects
a)Quality products b)Expected costs
高质量产品
b) 对需求的变更束手无策 c) 脆弱的架构 d) 采用不成熟的技术 e) 测试的不充分性 f)
拙劣的进度计划和评估 g) 缺乏资源
h) 不具备项目管理方法 i)
缺少管理层的支持
（3）软件工程的三个要素：方法、工具和过程 （4）A software project failed if
It is delivered late It is runs over the budget
It does not satisfy the customer’s need It is of poor quality
Classical software development methods have not solved software crisis.传统的软件开发方法没有能够解决软
Quality methods take time to learn and practice,but it will help you in
you engineering career
Establish goals → measure quality → understand the process → change and reure process → measure & analyze the results →
recycle improving Identify the tasks you do (8)敏捷软件开发宣言
个体和交互胜过过程和工具
可以做到工具的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
c)On agreed schedule
PSP is a framework designed to teach
software engineers to do better work
Estimate and plan → track →
improve quality 敏捷开发的原则：
（7）
Summary of PSP
1、 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
尽早交付具有部分功能的系统和质量系统之间具有很强的相关性
2、 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
关于态度的声明，敏捷过程的参与者不惧怕变化，努力保持软件结构的灵活性。
3、 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间越短越好。
关注的目标是交付满足客户需要的东西。它们是敏捷实践区别其他过程的特征所在。
4、 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
有意义的、频繁的交互，必须对软件项目进行持续不断地引导。
5、 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
人被认为是项目取得成功的最重要的因素。
6、 在团队内部，最具有效果并且富有效率的传递信息的方法就是面对面的交谈 。首要的、默认的沟通方式。 7、 工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度。
8、 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、恒定的开发速度。不是
50米短跑，而是马拉松。以快速但是可持续的速度行进。
9、 不断关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获得高的开发速度的关键。保持软件尽可能的简洁、健壮是快速开发软件的途径。
10、 简单—使未完成的工作最大化的艺术是根本的。
不是构建华而不实的系统，更愿意采用和目标一致的最简单的方法。 11、 最好的架构、需求和设计出自于自组织的团队。
任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
12、 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整，环境变化。
XP：
Values of XP : 价值、内容、关系
1.Communication 2.Simplicity 3.Feedback 4.Courage
XP编程实际上是由这四个价值所驱动的，而不是实践所驱动的，也就是说，如果实现某些XP实践，而得不到这四个价值的话，便失去了XP编程的意义。 （1）简单和沟通之间有一种奇妙的相互支持的关系。
沟通得越多，就越清楚哪些工作需要做并能更加确信哪些工作不需要做；系统越简单，需要的沟通越少，但沟通会更加全面。
（2）沟通、简单和反馈是相互联系的；反馈越充分，沟通越容易，系统越简单，就越容易测试盒提供反馈。 （3）沟通支持勇气，因为它带来了高风险、高回报的试验的可能性；
（4）简单支持勇气，因为有了一个简单的系统，你就可以比以前勇敢很多，你无意间将其破坏的可能性也大大减少。
（5）勇气支持简单，因为只要你有可能简化系统，你就会尝试。
（6）反馈支持勇气，因为如果你按下按钮就能够看到测试结果通过（或不通过，这时你可以将代码扔掉），那么即使对代码进行根本的改动你也会感觉安全得多。 5 个 Basic Principles：
1.Rapid feedback 快速反馈：指开发人员通过短的迭代周期，得到反馈信息，并迅速查验他们前面的工作是否满足客户要求。
2.Assume simplicity 假定简单：指将系统开发中的每个问题以尽量简单的方法来解决。没有人能够准确预知未来的需求，因此设计只需要满足现阶段的需求即可。
3.Incremental change递增改变：指用一系列的小改变来逐步解决一个问题。这一原则可用于计划、开发和设计等。
4.Embracing change 拥抱变化：指在解决紧迫问题时，采取的一种包容的策略。程序员要明白客户的要求并不是固定的，因此功能的优先级和功能需求都是在变化的。
5.Quality work优质产品：指工作和产品的质量是不容忽视的，不可以因为时间而放弃质量，并作出让步。 XP的项目过程包括以下6个阶段：
答：考察阶段、计划阶段、多次反复的发布产品阶段、生产化阶段、维护阶段、死亡阶段 XP的最佳实践：
答：1、计划2、发布小版本3、隐喻4、简单的设计5、测试6、重构7、结对编程8、集体所有权9、持续集成10、40-hour week 11、现场客户（客户作为团队成员）12、编码标准 13、开放空间 14、Just rules 结对编程的优点：
1、 所有的设计都是由两个人讨论决定的；
2、 系统的任何一个部分都至少有两个人熟悉，避免了由于人事更替造成的问题； 3、 减少了忽略编写测试用例的几率，因为结对者会互相提醒对方； 4、 在编写过程中与不同的人结对可以进一步增强知识与经验的共享； 5、 所有代码都随时得到检验；
6、 两个程序员可以同时关注操作层面和理论层面，加强了程序的设计。
The Rules and Practices：planning、designing、coding、Testing SCRUM: What is Scrum?
1、 Scrum是一种灵活的软件项目管理过程，可以帮助驾驭迭代，递增的软件开发过程。
2、 Scrum于1995年由Advanced Development Methodologies, Inc提出，并在2001年“敏捷联盟（Agile
Alliance）”形成后受到了更多欢迎。
3、 Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。
4、 它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来
的重大变化。
5、 Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复
使得输入和输出参数更加容易预测和描述，但这并不是当今软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。总结一下：
（1） Developed for managing system development process.用于管理系统开发过程。
（2） An empirical approach applying the idea of industrial process control theory to system development.将
工厂过程控制理论应用到系统开发上的一种经验方法。
（3） Reintroduces the ideas of flexibility, adaptability and productivity.再次把灵活性，适应性和高产性引进到
系统开发过程当中。
Process 的三个阶段：计划阶段、中间开发阶段、结束阶段 (1) 计划和体系结构设计(确定性过程)
a) 将backlog(急待完成的一系列任务,包括:未细化的产品功能要求,bugs,缺陷,用户提出的改进,具竞争力
的功能及技术升级等)按优先级排序形成backlog列表,根据该表和风险评估制定产品交付基线; b) 建立系统体系结构(如为已有系统改进,则只作优先分析、调整),将backlog项按照高内聚低耦合的原则
分解为一系列问题包(Packets,每个packet是一组对象或构件的集合),依据同样原则相应的划分若干个开发小组(Scrum小组),分配各小组合适的Backlog项或问题包,建立开发运行环境.
(2) Sprint(经验性过程)
该过程由若干个迭代的冲刺活动组成，直到风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1-6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个Scrum小组并行开发且必须步调一致（在一个Sprint结束后，均需完成所分配的backlog项并有可执行的产出）。每个Sprint包含以下活动：开发、打包（Wrap）、评审（Review）、调整（Ajust） (3) 交付和巩固（确定性过程）
a) 一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装、系统测试和回归
测试（Regression），准备培训材料，完成最终文档。
b) SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固
活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。 Scrum工作内容：
向管理层、用户和产品拥有者介绍本次冲刺的结果 参与者对产品新增的部分进行评估并决定下一步的活动
可能会提出新的backlog条款（就是说有些新的功能要增加），甚至会改变系统的开发方向。 Scrum价值观：承诺、专注、公开、尊重、勇气 动态系统开发方法DSDM 1、基本观点：
任何事情都不可能一次性完满完成，用20%的时间完成80%的有用的功能以适应于商业目的的2-8原则。 2、基本原则：
积极主动的用户参与
赋予DSDM项目组充分的决策权
强调经常性的产品提交（注重结果而非过
程）
以是否适应商业目标作为工作确认的首要
衡量标准
迭代和增量式的开发方法 开发中所有的变化是可以追溯的
基于软件需求提出的开发计划作为宏观进
度控制的基线
测试活动贯穿于软件开发周期的各个阶段
强调所有项目相关人员的合作 水晶系列方法：
核心理念：软件开发可视为创造和交流相协调的过程
人是第一位的因素
软件开发的首要目标是交付可用的软件，第
二才是保持开发工作的可延续性 原则：
减少中间制品的工作量（开发文档、进度计划）
通过经常产生出可运行的代码，充分利用
人与人之间多种交互的渠道
项目组的惯例随项目具体情况调整 项目不同情况，状态在不停变化
根据人数决定采用的方法
对可靠性要求越高，则采用越严格的过程纪律
由Apache得出的关于开源开发方法的一些假设 结论
1、 OSS developments will have a core of developers who control the code base. This core will be no
larger than 10-15 people, and will create approximately 80% or more of the new functionality.
2、 For projects that are so large that 10-15 developers can not write 80% of the code in a reasonable time
frame, a strict code ownership policy will have to be adopted to separate the work of additional groups, creating, in effect, several related OSS projects.
3、 In successful OSS developments, a group larger by an order of magnitude（数量级）than the core will
repair defects, and a yet larger group (by another order of magnitude) will report problems.
4、 OSS developments that have a strong core of developers but never achieve large numbers of
contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects in the released code.一个开源软件开发项目如果有一组很强的核心成员,但是没有核心成员之外的大量参与者，这样出来的产品虽然会有很多新的功能，但是这个项目最终还是会失败，因为它缺乏足够的人员对发布的产品进行找错改错。
5、 Defect densityin open source releases will generally be lowerthan commercial code that has only been
feature-tested.
6、 In successful OSS developments, the developers will also be usersof the software. 7、 OSS developments exhibit very rapid responsesto customer problems. RUP
1、What is the Rational Unified Process？
答：Rational Unified Process是软件工程化过程，提供了在开发机构中分配任务和责任的纪律化方法以及文档模板。RUP的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品。RUP是Rational公司开发和维护的过程产品。RUP是有效使用Unified Modeling Language的指南。 2、RUP的特点（核心思想）
（1）迭代式开发（2）强调核心工作流程（3）基于角色的开发组织（4）用例驱动（5）以架构为中心 3、Effective Deployment of 6 Best Practices
The Rational Unified Process provides each team member with the guidelines，templates and tool mentors necessary for the entire team to take full advantage of among others the following best practices： a) 迭代式开发软件 b) 管理需求 c) 基于组件的架构
4、Process Overview：Two Dimensions:
the horizontal axis(横轴) represents timeand shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles（周期）, phases（阶段）, iterations（迭代）, and milestones（里程碑）.体现了软件开发过程的动态结构
the vertical axis(纵轴) represents the static aspect of the process:按照活动的内容进行组织，包括活动、活动产生的工件、活动的执行角色、以及活动执行的工作流。体现了软件开发过程的静态结构
d) 建立可视化的模型 e) 不断地验证软件质量 f)
控制软件的变更
The Iterative Model graph shows how the process is structured along two dimensions。 4个阶段：
初始阶段：目标是为系统建立商业案例并确定项目的边界；
细化阶段：目标是分析问题领域，并建立健全体系结构基础，编制项目计划，完成项目中高风险需求部分的开发；
构建阶段：将所有剩余的技术构建和稳定业务需求功能开发出来，并集成为产品，它决定了产品是否可以在测试环境中进行部署要确定软件、环境、用户是否可以开始系统的运行； 移交阶段：确保软件对最终用户是可用的。
The Iterative Model graph how the process is structured along two dimensions。
Two Dimensions，四个阶段，core workflow&Phase工作流程与各阶段的关系
5、对下图的理解：
（1） 开发团队没有实现对过程信息集中访问控制（没有集中的数据库） （2） 团队缺乏在方法和最佳实践上进行自我培训的最新的知识基础
（3） 团队没有使用统一的方式表达和方法沟通过程工程和过程制定，组织级的过程的描述和裁减缺乏
统一的方法。
（4） 开发队伍角色未定义，不协调，团队工作和过程绩效由于执行的间隙和冲突而削弱。
RUP与XP的共性：
基础都是面向对象方法 都采用迭代、增量开发方式 都是基于风险驱动
都重视代码、文档的最小化和设计的简化 差异：
XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念，RUP过程通常以架构为中心，细化
阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。
XP有一个非常关键的假设：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样带来的风险、
开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的。 XP不包括业务建模、部署、过程管理等概念。 RUP更强调项目的可控性。
可以讲XP中的最佳实践纳入RUP中。
RUP经过裁剪后适应各种规模的项目，XP只适用于小团队。
XP实践依赖团队成员的强关系而RUP对团队成员的关系紧密程度要求弱些。 MSF
软件项目成功的障碍： 目标和职能分离 业务和技术分离 缺乏共同的语言和过程
目标不明确
采用动态适应变化的演进式迭代周期 强调需求和测试管理 鼓励用户积极参与
没有范围变更管理
无法以一个团队的方式进行沟通和运作 过程管理不够灵活，难以适应项目的变化 IT如何克服障碍：
理解业务的方向、目标和机会
保证IT项目支持业务目标
保持与业务不断地交流与沟通
IT项目的首要目标是什么？
形成主动的工作环境
组织团队有效地工作
IT项目的首要目标不是更多的技术，而是将其主要力量-丰富的技术知识一同人和过程结合起来，为整个组织服务。
成功项目的标准：
在规定的范围内（时间/资源）完成
按照定义完成功能
确认系统符合质量标准
部署和管理平滑方便
MSF微软过程基本原则：
制定计划时兼顾未来的不确定因素
通过有效地风险管理减少不确定因素的影响
经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性
快速循环、递进的开发过程
从产品特性和成本控制出发创造性地工作、聪明地工作
创建确定的进度表
使用小型项目组并发完成工作，并设置多个同步点
将大型项目分解成多个可管理的单元、以便更快地发布产品
用产品的前景目标和概要说明指导项目开发工作：先基线 后冻结
避免产品走形：检查当前状态与初始说明文档对照
使用原型验证概念，进行开发前的测试：技术可行性等，减少和规避风险
零缺陷概念
非责难式的里程碑评审会：以改进工作为目的，内部、外部会议 MSF团队模型角色、主要工作内容目标及相互关系：
提高用户完成工作的效率
客户满意 MSF的模型和准则 答：团对模型、过程模型
项目管理准则、风险管理准则、就绪管理准则
MSF项目过程模型：阶段及其主要工作任务目标
MSF微软过程的特点：
答：（1）使用迭代+渐进式提交的方式可以保持系统良好的可预见性，也是客户对项目组实施能力更加信任。（2）迭代周期的选择一定是对一组业务用例的实现而不是其他。即每一个迭代周期都可以交付以个可以完成一定业务功能的系统，
在项目中设立里程碑的好处有哪些？
答：
帮助同步工作成果
使项目团队外的人员也可以看到项目的进展情况和质量情况
增加阶段性的审批环节，只有在审核通过后，才进入下一个阶段。 使用MSF过程模型的优点
过程模型可以根据项目的不同情况进行调整
团队可以依据下列指导方针来决定项目需要哪些中间里程碑： 由项目类型决定 考虑外部事件和风险
可在项目进行中纠正偏差
着重于评审项目目标和交付成果
避免长时间没有里程碑 将里程碑与交付成果结合起来
仅使用适合项目情况的MSF推荐的里程碑
利用里程碑评审项目和总结经验：
里程碑评审会议—在客户、干系人和团队之间取得一致，获得项目阶段性成果和继续前进的认可 后里程碑评审会议—交流团队经验，改进后续工作 按版本发布的好处：
在特定版本范围内管理项目的变更和不确定因素：
保证功能的持续增加和完善
缩短交付时间
为团队成员设立明确而可达到的目标
着力解决项目问题 风险管理原则：
风险是每一个项目和过程必然具备的
识别风险是一项正面的活动
首先识别风险、然后管理风险
风险评估是一项持续的活动
强调主动规避风险
不简单的以风险的数目来评估一个项目的价值 TDD
Nightly Test是软件开发中一个保证开发质量的最有效的方法，也是衡量软件质量开发效率的最好的指标。
Nightly Test 就是每天工作结束，所有的代码都Check in到SourceControl后，自动运行所有的Unit Test和Function Test。测试的结果应该自动分发给开发人员和管理层。
两个指标数值：
测试用例的通过率：单元测试必须是100%通过，Function Test应该按计划的通过
单元测试的覆盖率：表明有多少Class被测试过和测试的完善程度。
Test-First Programming是什么？
Test-First Programming首先是一种分析方法
Test-First Programming是一种设计方法
Test-First Programming是一种质量控制方法
Test-First Programming是一种重构和优化的方法
Test-First Programming不是通常意义上的测试技术，它的目的也不仅用来测试你的代码
Test-First Programming是一种面向对象的开发方法 如何做Test Driven Design and Development？
1、 首先确定你要做什么
2、 然后为这个功能（Method）写单元测试例子（Unit Test） 3、 写Production代码 4、 运行Unit Test
风险管理过程的六个阶段
识别：头脑风暴
分析和分级：
计划和调度
跟踪和报告：动态调整风险计划
控制：
学习：知识库 风险管理的最佳实践：
风险管理是项目组全体人员的责任
不要有意无意的造成“惩罚问题发现者”的氛围
只关注一定数量的风险
风险管理列入正式的项目管理活动和计算工作量
使用知识库来提高风险管理的有效性
XP与TDD：XP采用了TDD
答：TDD是eXtreme Programming中必须遵行的一个方法，TDD是XP中Pair Programming的工作模式。
XP中把测试驱动的设计和开发做到极致，TDD的整个流程由两个程序员一起执行。
XP正是因为采用了TDD才能够做到每天的代码都是Production、code和每个小的Release都能够提供具备Production质量的代码并投入使用。
有了TDD，XP才能降低风险，去拥抱变化。
有了TDD，XP才能在计划的时间内完成计划质量的代码。
有了TDD，XP才能减少CodeFix环节，从而减少项目成本。
有了TDD，XP Team才能对自己的工作充满自信。 TDD、程序员和管理层
对程序员来说，通过运行Unit Test和Functional Test，每天下班的时候都可以清楚地知道自己的代码是work的。
对管理层来说，通过Nightly Test的结果，每天一早都清楚地知道项目的质量和开发进度。 什么时候写Test？
如果你要写一个新的功能，请先写他的测试例子
如果你要在没有经过测试的代码上写信的功能，请先写目前代码的测试例子
如果你要Fix一个Bug，请先为这个bug写一个测试例子
如果你要Refactor没有测试过的代码，请先写一个测试例子
如果你发现一个边缘例外值，请为它写一个测试例子。
Refactor-重构
1、 什么是Refactoring？
Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。
Refactoring是严谨地对完成的代码进行清理，从而减少出错的一种方法。
Refactoring的实质是对完成代码的设计进行改进。
Refactoring是XP项目中每天的例行练习。
Refactoring必须和Test-Driven Design and Development伴随进行。 2、 为什么要Refactoring？
改进软件的设计
提高代码质量，可维护性
Refactoring帮助尽早地发现错误（Defects）
Refactoring可以提高开发速度 3、 什么时候适合/不适合做Refactoring?
适合：
在开始增加一个新的功能之前
在修复一个错误的时候
在做Code Review的时候 不适合：
代码太混论，设计完全错误
明天是
DeadLine
Refactoring的工作量显著影响Estimate
4、 Refactoring的流程？
读懂代码（包括测试例子代码）
Refactoring
运行所有的Unit Tests
5、
Bad Smells in Codes
6、 XP中Refactoring:
在XP的日常工作中，Refactoring通常在每个Pair完成Task后做Code Review的时候进行。 Tips：
不要在刚完成代码后马上进行。
PSP与TSP：PSP的process flow：
When programs are small or well understood，you can execute the phases in order。
Produce a plan
Design all modules
Summarize the project data during the postmortem。
Requlrements -> Plan -> Design -> Code -> Complie -> Test ->Postmortem -> Program and Project data. PSP部分：
①
（1）软件开发过程是什么？
软件开发过程是按照软件工业化的标准定义的
在软件开发中必须具有的一系列过程规范； 软件开发过程是定义在软件中的软件需求、软件
设计、软件编码、软件测试、软件部署的实现目标和规范化的管理方法论；
软件开发过程是保证软件工业化生产的法典； 软件开发过程做的是：定义标准和为了达到标准
的路；
软件开发过程要改善的是：软件开发的效率和质
量；
软件开发过程的实现最重要的是：人。 （2）大多数软件项目失败的原因：
a) 不完整、不现实的项目需求 件危机。
（5）A software engineer’s job:
a) Make a working plan.制定工作计划 b) Carry out it.(Do their work according to
this plan)按照此计划工作
c) Try his/her best to produce high-quality
products.尽最大努力生产出高质量产品
(6)3 Key aspects
a)Quality products b)Expected costs
高质量产品
b) 对需求的变更束手无策 c) 脆弱的架构 d) 采用不成熟的技术 e) 测试的不充分性 f)
拙劣的进度计划和评估 g) 缺乏资源
h) 不具备项目管理方法 i)
缺少管理层的支持
（3）软件工程的三个要素：方法、工具和过程 （4）A software project failed if
It is delivered late It is runs over the budget
It does not satisfy the customer’s need It is of poor quality
Classical software development methods have not solved software crisis.传统的软件开发方法没有能够解决软
Quality methods take time to learn and practice,but it will help you in
you engineering career
Establish goals → measure quality → understand the process → change and reure process → measure & analyze the results →
recycle improving Identify the tasks you do (8)敏捷软件开发宣言
个体和交互胜过过程和工具
可以做到工具的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
c)On agreed schedule
PSP is a framework designed to teach
software engineers to do better work
Estimate and plan → track →
improve quality 敏捷开发的原则：
（7）
Summary of PSP
1、 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
尽早交付具有部分功能的系统和质量系统之间具有很强的相关性
2、 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
关于态度的声明，敏捷过程的参与者不惧怕变化，努力保持软件结构的灵活性。
3、 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间越短越好。
关注的目标是交付满足客户需要的东西。它们是敏捷实践区别其他过程的特征所在。
4、 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
有意义的、频繁的交互，必须对软件项目进行持续不断地引导。
5、 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
人被认为是项目取得成功的最重要的因素。
6、 在团队内部，最具有效果并且富有效率的传递信息的方法就是面对面的交谈 。首要的、默认的沟通方式。 7、 工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度。
8、 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、恒定的开发速度。不是
50米短跑，而是马拉松。以快速但是可持续的速度行进。
9、 不断关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获得高的开发速度的关键。保持软件尽可能的简洁、健壮是快速开发软件的途径。
10、 简单—使未完成的工作最大化的艺术是根本的。
不是构建华而不实的系统，更愿意采用和目标一致的最简单的方法。 11、 最好的架构、需求和设计出自于自组织的团队。
任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
12、 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整，环境变化。
XP：
Values of XP : 价值、内容、关系
1.Communication 2.Simplicity 3.Feedback 4.Courage
XP编程实际上是由这四个价值所驱动的，而不是实践所驱动的，也就是说，如果实现某些XP实践，而得不到这四个价值的话，便失去了XP编程的意义。 （1）简单和沟通之间有一种奇妙的相互支持的关系。
沟通得越多，就越清楚哪些工作需要做并能更加确信哪些工作不需要做；系统越简单，需要的沟通越少，但沟通会更加全面。
（2）沟通、简单和反馈是相互联系的；反馈越充分，沟通越容易，系统越简单，就越容易测试盒提供反馈。 （3）沟通支持勇气，因为它带来了高风险、高回报的试验的可能性；
（4）简单支持勇气，因为有了一个简单的系统，你就可以比以前勇敢很多，你无意间将其破坏的可能性也大大减少。
（5）勇气支持简单，因为只要你有可能简化系统，你就会尝试。
（6）反馈支持勇气，因为如果你按下按钮就能够看到测试结果通过（或不通过，这时你可以将代码扔掉），那么即使对代码进行根本的改动你也会感觉安全得多。 5 个 Basic Principles：
1.Rapid feedback 快速反馈：指开发人员通过短的迭代周期，得到反馈信息，并迅速查验他们前面的工作是否满足客户要求。
2.Assume simplicity 假定简单：指将系统开发中的每个问题以尽量简单的方法来解决。没有人能够准确预知未来的需求，因此设计只需要满足现阶段的需求即可。
3.Incremental change递增改变：指用一系列的小改变来逐步解决一个问题。这一原则可用于计划、开发和设计等。
4.Embracing change 拥抱变化：指在解决紧迫问题时，采取的一种包容的策略。程序员要明白客户的要求并不是固定的，因此功能的优先级和功能需求都是在变化的。
5.Quality work优质产品：指工作和产品的质量是不容忽视的，不可以因为时间而放弃质量，并作出让步。 XP的项目过程包括以下6个阶段：
答：考察阶段、计划阶段、多次反复的发布产品阶段、生产化阶段、维护阶段、死亡阶段 XP的最佳实践：
答：1、计划2、发布小版本3、隐喻4、简单的设计5、测试6、重构7、结对编程8、集体所有权9、持续集成10、40-hour week 11、现场客户（客户作为团队成员）12、编码标准 13、开放空间 14、Just rules 结对编程的优点：
1、 所有的设计都是由两个人讨论决定的；
2、 系统的任何一个部分都至少有两个人熟悉，避免了由于人事更替造成的问题； 3、 减少了忽略编写测试用例的几率，因为结对者会互相提醒对方； 4、 在编写过程中与不同的人结对可以进一步增强知识与经验的共享； 5、 所有代码都随时得到检验；
6、 两个程序员可以同时关注操作层面和理论层面，加强了程序的设计。
The Rules and Practices：planning、designing、coding、Testing SCRUM: What is Scrum?
1、 Scrum是一种灵活的软件项目管理过程，可以帮助驾驭迭代，递增的软件开发过程。
2、 Scrum于1995年由Advanced Development Methodologies, Inc提出，并在2001年“敏捷联盟（Agile
Alliance）”形成后受到了更多欢迎。
3、 Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。
4、 它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来
的重大变化。
5、 Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复
使得输入和输出参数更加容易预测和描述，但这并不是当今软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。总结一下：
（1） Developed for managing system development process.用于管理系统开发过程。
（2） An empirical approach applying the idea of industrial process control theory to system development.将
工厂过程控制理论应用到系统开发上的一种经验方法。
（3） Reintroduces the ideas of flexibility, adaptability and productivity.再次把灵活性，适应性和高产性引进到
系统开发过程当中。
Process 的三个阶段：计划阶段、中间开发阶段、结束阶段 (1) 计划和体系结构设计(确定性过程)
a) 将backlog(急待完成的一系列任务,包括:未细化的产品功能要求,bugs,缺陷,用户提出的改进,具竞争力
的功能及技术升级等)按优先级排序形成backlog列表,根据该表和风险评估制定产品交付基线; b) 建立系统体系结构(如为已有系统改进,则只作优先分析、调整),将backlog项按照高内聚低耦合的原则
分解为一系列问题包(Packets,每个packet是一组对象或构件的集合),依据同样原则相应的划分若干个开发小组(Scrum小组),分配各小组合适的Backlog项或问题包,建立开发运行环境.
(2) Sprint(经验性过程)
该过程由若干个迭代的冲刺活动组成，直到风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1-6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个Scrum小组并行开发且必须步调一致（在一个Sprint结束后，均需完成所分配的backlog项并有可执行的产出）。每个Sprint包含以下活动：开发、打包（Wrap）、评审（Review）、调整（Ajust） (3) 交付和巩固（确定性过程）
a) 一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装、系统测试和回归
测试（Regression），准备培训材料，完成最终文档。
b) SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固
活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。 Scrum工作内容：
向管理层、用户和产品拥有者介绍本次冲刺的结果 参与者对产品新增的部分进行评估并决定下一步的活动
可能会提出新的backlog条款（就是说有些新的功能要增加），甚至会改变系统的开发方向。 Scrum价值观：承诺、专注、公开、尊重、勇气 动态系统开发方法DSDM 1、基本观点：
任何事情都不可能一次性完满完成，用20%的时间完成80%的有用的功能以适应于商业目的的2-8原则。 2、基本原则：
积极主动的用户参与
赋予DSDM项目组充分的决策权
强调经常性的产品提交（注重结果而非过
程）
以是否适应商业目标作为工作确认的首要
衡量标准
迭代和增量式的开发方法 开发中所有的变化是可以追溯的
基于软件需求提出的开发计划作为宏观进
度控制的基线
测试活动贯穿于软件开发周期的各个阶段
强调所有项目相关人员的合作 水晶系列方法：
核心理念：软件开发可视为创造和交流相协调的过程
人是第一位的因素
软件开发的首要目标是交付可用的软件，第
二才是保持开发工作的可延续性 原则：
减少中间制品的工作量（开发文档、进度计划）
通过经常产生出可运行的代码，充分利用
人与人之间多种交互的渠道
项目组的惯例随项目具体情况调整 项目不同情况，状态在不停变化
根据人数决定采用的方法
对可靠性要求越高，则采用越严格的过程纪律
由Apache得出的关于开源开发方法的一些假设 结论
1、 OSS developments will have a core of developers who control the code base. This core will be no
larger than 10-15 people, and will create approximately 80% or more of the new functionality.
2、 For projects that are so large that 10-15 developers can not write 80% of the code in a reasonable time
frame, a strict code ownership policy will have to be adopted to separate the work of additional groups, creating, in effect, several related OSS projects.
3、 In successful OSS developments, a group larger by an order of magnitude（数量级）than the core will
repair defects, and a yet larger group (by another order of magnitude) will report problems.
4、 OSS developments that have a strong core of developers but never achieve large numbers of
contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects in the released code.一个开源软件开发项目如果有一组很强的核心成员,但是没有核心成员之外的大量参与者，这样出来的产品虽然会有很多新的功能，但是这个项目最终还是会失败，因为它缺乏足够的人员对发布的产品进行找错改错。
5、 Defect densityin open source releases will generally be lowerthan commercial code that has only been
feature-tested.
6、 In successful OSS developments, the developers will also be usersof the software. 7、 OSS developments exhibit very rapid responsesto customer problems. RUP
1、What is the Rational Unified Process？
答：Rational Unified Process是软件工程化过程，提供了在开发机构中分配任务和责任的纪律化方法以及文档模板。RUP的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品。RUP是Rational公司开发和维护的过程产品。RUP是有效使用Unified Modeling Language的指南。 2、RUP的特点（核心思想）
（1）迭代式开发（2）强调核心工作流程（3）基于角色的开发组织（4）用例驱动（5）以架构为中心 3、Effective Deployment of 6 Best Practices
The Rational Unified Process provides each team member with the guidelines，templates and tool mentors necessary for the entire team to take full advantage of among others the following best practices： a) 迭代式开发软件 b) 管理需求 c) 基于组件的架构
4、Process Overview：Two Dimensions:
the horizontal axis(横轴) represents timeand shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles（周期）, phases（阶段）, iterations（迭代）, and milestones（里程碑）.体现了软件开发过程的动态结构
the vertical axis(纵轴) represents the static aspect of the process:按照活动的内容进行组织，包括活动、活动产生的工件、活动的执行角色、以及活动执行的工作流。体现了软件开发过程的静态结构
d) 建立可视化的模型 e) 不断地验证软件质量 f)
控制软件的变更
The Iterative Model graph shows how the process is structured along two dimensions。 4个阶段：
初始阶段：目标是为系统建立商业案例并确定项目的边界；
细化阶段：目标是分析问题领域，并建立健全体系结构基础，编制项目计划，完成项目中高风险需求部分的开发；
构建阶段：将所有剩余的技术构建和稳定业务需求功能开发出来，并集成为产品，它决定了产品是否可以在测试环境中进行部署要确定软件、环境、用户是否可以开始系统的运行； 移交阶段：确保软件对最终用户是可用的。
The Iterative Model graph how the process is structured along two dimensions。
Two Dimensions，四个阶段，core workflow&Phase工作流程与各阶段的关系
5、对下图的理解：
（1） 开发团队没有实现对过程信息集中访问控制（没有集中的数据库） （2） 团队缺乏在方法和最佳实践上进行自我培训的最新的知识基础
（3） 团队没有使用统一的方式表达和方法沟通过程工程和过程制定，组织级的过程的描述和裁减缺乏
统一的方法。
（4） 开发队伍角色未定义，不协调，团队工作和过程绩效由于执行的间隙和冲突而削弱。
RUP与XP的共性：
基础都是面向对象方法 都采用迭代、增量开发方式 都是基于风险驱动
都重视代码、文档的最小化和设计的简化 差异：
XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念，RUP过程通常以架构为中心，细化
阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。
XP有一个非常关键的假设：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样带来的风险、
开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的。 XP不包括业务建模、部署、过程管理等概念。 RUP更强调项目的可控性。
可以讲XP中的最佳实践纳入RUP中。
RUP经过裁剪后适应各种规模的项目，XP只适用于小团队。
XP实践依赖团队成员的强关系而RUP对团队成员的关系紧密程度要求弱些。 MSF
软件项目成功的障碍： 目标和职能分离 业务和技术分离 缺乏共同的语言和过程
目标不明确
采用动态适应变化的演进式迭代周期 强调需求和测试管理 鼓励用户积极参与
没有范围变更管理
无法以一个团队的方式进行沟通和运作 过程管理不够灵活，难以适应项目的变化 IT如何克服障碍：
理解业务的方向、目标和机会
保证IT项目支持业务目标
保持与业务不断地交流与沟通
IT项目的首要目标是什么？
形成主动的工作环境
组织团队有效地工作
IT项目的首要目标不是更多的技术，而是将其主要力量-丰富的技术知识一同人和过程结合起来，为整个组织服务。
成功项目的标准：
在规定的范围内（时间/资源）完成
按照定义完成功能
确认系统符合质量标准
部署和管理平滑方便
MSF微软过程基本原则：
制定计划时兼顾未来的不确定因素
通过有效地风险管理减少不确定因素的影响
经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性
快速循环、递进的开发过程
从产品特性和成本控制出发创造性地工作、聪明地工作
创建确定的进度表
使用小型项目组并发完成工作，并设置多个同步点
将大型项目分解成多个可管理的单元、以便更快地发布产品
用产品的前景目标和概要说明指导项目开发工作：先基线 后冻结
避免产品走形：检查当前状态与初始说明文档对照
使用原型验证概念，进行开发前的测试：技术可行性等，减少和规避风险
零缺陷概念
非责难式的里程碑评审会：以改进工作为目的，内部、外部会议 MSF团队模型角色、主要工作内容目标及相互关系：
提高用户完成工作的效率
客户满意 MSF的模型和准则 答：团对模型、过程模型
项目管理准则、风险管理准则、就绪管理准则
MSF项目过程模型：阶段及其主要工作任务目标
MSF微软过程的特点：
答：（1）使用迭代+渐进式提交的方式可以保持系统良好的可预见性，也是客户对项目组实施能力更加信任。（2）迭代周期的选择一定是对一组业务用例的实现而不是其他。即每一个迭代周期都可以交付以个可以完成一定业务功能的系统，
在项目中设立里程碑的好处有哪些？
答：
帮助同步工作成果
使项目团队外的人员也可以看到项目的进展情况和质量情况
增加阶段性的审批环节，只有在审核通过后，才进入下一个阶段。 使用MSF过程模型的优点
过程模型可以根据项目的不同情况进行调整
团队可以依据下列指导方针来决定项目需要哪些中间里程碑： 由项目类型决定 考虑外部事件和风险
可在项目进行中纠正偏差
着重于评审项目目标和交付成果
避免长时间没有里程碑 将里程碑与交付成果结合起来
仅使用适合项目情况的MSF推荐的里程碑
利用里程碑评审项目和总结经验：
里程碑评审会议—在客户、干系人和团队之间取得一致，获得项目阶段性成果和继续前进的认可 后里程碑评审会议—交流团队经验，改进后续工作 按版本发布的好处：
在特定版本范围内管理项目的变更和不确定因素：
保证功能的持续增加和完善
缩短交付时间
为团队成员设立明确而可达到的目标
着力解决项目问题 风险管理原则：
风险是每一个项目和过程必然具备的
识别风险是一项正面的活动
首先识别风险、然后管理风险
风险评估是一项持续的活动
强调主动规避风险
不简单的以风险的数目来评估一个项目的价值 TDD
Nightly Test是软件开发中一个保证开发质量的最有效的方法，也是衡量软件质量开发效率的最好的指标。
Nightly Test 就是每天工作结束，所有的代码都Check in到SourceControl后，自动运行所有的Unit Test和Function Test。测试的结果应该自动分发给开发人员和管理层。
两个指标数值：
测试用例的通过率：单元测试必须是100%通过，Function Test应该按计划的通过
单元测试的覆盖率：表明有多少Class被测试过和测试的完善程度。
Test-First Programming是什么？
Test-First Programming首先是一种分析方法
Test-First Programming是一种设计方法
Test-First Programming是一种质量控制方法
Test-First Programming是一种重构和优化的方法
Test-First Programming不是通常意义上的测试技术，它的目的也不仅用来测试你的代码
Test-First Programming是一种面向对象的开发方法 如何做Test Driven Design and Development？
1、 首先确定你要做什么
2、 然后为这个功能（Method）写单元测试例子（Unit Test） 3、 写Production代码 4、 运行Unit Test
风险管理过程的六个阶段
识别：头脑风暴
分析和分级：
计划和调度
跟踪和报告：动态调整风险计划
控制：
学习：知识库 风险管理的最佳实践：
风险管理是项目组全体人员的责任
不要有意无意的造成“惩罚问题发现者”的氛围
只关注一定数量的风险
风险管理列入正式的项目管理活动和计算工作量
使用知识库来提高风险管理的有效性
XP与TDD：XP采用了TDD
答：TDD是eXtreme Programming中必须遵行的一个方法，TDD是XP中Pair Programming的工作模式。
XP中把测试驱动的设计和开发做到极致，TDD的整个流程由两个程序员一起执行。
XP正是因为采用了TDD才能够做到每天的代码都是Production、code和每个小的Release都能够提供具备Production质量的代码并投入使用。
有了TDD，XP才能降低风险，去拥抱变化。
有了TDD，XP才能在计划的时间内完成计划质量的代码。
有了TDD，XP才能减少CodeFix环节，从而减少项目成本。
有了TDD，XP Team才能对自己的工作充满自信。 TDD、程序员和管理层
对程序员来说，通过运行Unit Test和Functional Test，每天下班的时候都可以清楚地知道自己的代码是work的。
对管理层来说，通过Nightly Test的结果，每天一早都清楚地知道项目的质量和开发进度。 什么时候写Test？
如果你要写一个新的功能，请先写他的测试例子
如果你要在没有经过测试的代码上写信的功能，请先写目前代码的测试例子
如果你要Fix一个Bug，请先为这个bug写一个测试例子
如果你要Refactor没有测试过的代码，请先写一个测试例子
如果你发现一个边缘例外值，请为它写一个测试例子。
Refactor-重构
1、 什么是Refactoring？
Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。
Refactoring是严谨地对完成的代码进行清理，从而减少出错的一种方法。
Refactoring的实质是对完成代码的设计进行改进。
Refactoring是XP项目中每天的例行练习。
Refactoring必须和Test-Driven Design and Development伴随进行。 2、 为什么要Refactoring？
改进软件的设计
提高代码质量，可维护性
Refactoring帮助尽早地发现错误（Defects）
Refactoring可以提高开发速度 3、 什么时候适合/不适合做Refactoring?
适合：
在开始增加一个新的功能之前
在修复一个错误的时候
在做Code Review的时候 不适合：
代码太混论，设计完全错误
明天是
DeadLine
Refactoring的工作量显著影响Estimate
4、 Refactoring的流程？
读懂代码（包括测试例子代码）
Refactoring
运行所有的Unit Tests
5、
Bad Smells in Codes
6、 XP中Refactoring:
在XP的日常工作中，Refactoring通常在每个Pair完成Task后做Code Review的时候进行。 Tips：
不要在刚完成代码后马上进行。
PSP与TSP：PSP的process flow：
When programs are small or well understood，you can execute the phases in order。
Produce a plan
Design all modules
Summarize the project data during the postmortem。
Requlrements -> Plan -> Design -> Code -> Complie -> Test ->Postmortem -> Program and Project data. PSP部分：
①