软件工程过程 第8章 敏捷过程

标签：height   输入   修复   自身   测试程序   过程   最好   资源分配   迭代开发   

• 最优先要做的事是通过今早和持续交付有价值的软件使客户满意。
• 欢迎需求的变更，即使在软件开发的后期。敏捷过程利用项目需求变更来提升客户的市场竞争优势。
• 频繁向客户交付可以工作的软件产品，从几周到几个月，交付的时间间隔越短越好。
• 在整个项目开发周期，业务人员和开发团队应该天天在一起工作。
• 围绕被激励起来的个人来构建项目。提供他们所需要的环境和支持，并信任他们能完成好所分配的工作。
• 在开发团队内部，效率最高、成效最大的信息传递方法是面对面交流。
• 可以工作的软件产品是度量进度的主要标准。
• 敏捷过程提倡可持续开发、负责人、开发者和用户应该能够保持一个长期的稳定的开发速度。
• 不断地关注出色的技术与好的设计会增强敏捷能力。
• 简单——使未完成的工作最大化的艺术——是根本。
• 最好的构架、需求和设计源于自组织的团队。
• 每隔一段时间，团队应反省怎样才能工作能更有效，然后相应地调整自身的行为。

• 极限的工作环境应付变化的环境 
• 极限的需求 
• 极限的设计 
• 极限的编程
• 极限的测试

• 用户故事
• 发布计划
• 迭代
• 种子
• 项目速度
• 连续整合
• 验收测试
• 单元测试
• 重整
• 双人编程
• 小发布
• 集体拥有代码
• 隐喻

• 体系结构定架 P248
• 发布规划 P248~P249
• 迭代开发 P249~P250 
• 验收测试 P250
• 小发布 P250~P251
• XP的哲学

• 输入方面（发布计划即其中列出了要完成的用户故事、时间、资源分配等、下一次迭代即项目速度中规定的尚未完成的任务数、缺陷即导致上次验收失败的所有缺陷）
• 输出方面（经过迭代开发得到的新功能，或缺陷得以修复的最后版本）

• 站着开会
• 集体拥有代码（双人编程、单元测试、残酷重整、人员轮换、使用CRC卡片模拟系统）

• 编写单元测试用例
• 经常集成

• 双人编写同一程序
• 编程之前先编写测试程序，以固定需求
• 程序代码集体拥有，谁都可以改，共同负责，把人员平等推向极致
• 没有固定专职，小组成员都是多面手
• 极度依赖客户介入，客户作为成员参与全过程，并负责写用户故事
• 简单、朴素地开发，一个用户故事直接对应为少许多任务，马上编写单元测试并编码开发
• 全部残酷重整和连续整合有利于形成良好的体系结构软件

软件工程过程 第8章 敏捷过程

标签：height   输入   修复   自身   测试程序   过程   最好   资源分配   迭代开发   

原文地址：http://www.cnblogs.com/zpfbuaa/p/6974060.html