质量保证系列ppt课件-敏捷项目过程介绍(V).pptx

《质量保证系列ppt课件-敏捷项目过程介绍(V).pptx》由会员分享，可在线阅读，更多相关《质量保证系列ppt课件-敏捷项目过程介绍(V).pptx（39页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、质量保证系列课件质量保证系列课件敏捷项目过程介绍敏捷项目过程介绍 2011年3月Confidential 2010 iSoftStone Group.All Rights Reserved.21.敏捷核心理念敏捷核心理念1.1 敏捷宣言1.2.敏捷原则1.3.敏捷理念1.4.瀑布、迭代和敏捷的区别2.敏捷优秀实践3.敏捷流程介绍目录目录Confidential 2010 iSoftStone Group.All Rights Reserved.1.1 1.1 敏捷宣言敏捷宣言3敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作。我们认为左项具有更大的价值

2、当然这并不意味着右项没有价值个体和交互个体和交互过程和工具过程和工具胜过胜过可以工作的软件可以工作的软件面面俱到的文档面面俱到的文档胜过胜过客户合作客户合作合同谈判合同谈判胜过胜过响应变化响应变化遵循计划遵循计划胜过胜过Confidential 2010 iSoftStone Group.All Rights Reserved.1.2 1.2 敏捷原则敏捷原则41.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好

3、。4.可以工作的软件是首要的进度度量标准。5.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。6.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。7.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。9.不断地关注优秀的技能和好的设计会增强敏捷能力。10.简单 使未完成的工作最大化的艺术 是根本的。11.最好的构架、需求和设计出自于“自组织”的团队。12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后响应地对自己的行为

4、进行调整。Confidential 2010 iSoftStone Group.All Rights Reserved.敏捷=理念+优秀实践+应用理念理念（核心思想）应用应用1.3 1.3 敏捷理念敏捷理念优秀实践优秀实践（经验积累）5Confidential 2010 iSoftStone Group.All Rights Reserved.1.3.1 Value：聚焦客户价值，消除浪费6Source：如何提升软件开发效率08年统计华为：研发版本废弃特性华为：研发版本废弃特性 07.1-08.6年某产品线所有产品中重要特性无应用的比例达22%（需求变更和分析不足占63%）软件业：软件业：45

5、%的软件特性客户没有使用的软件特性客户没有使用Source：Standish Group 来自5万个软件开发项目的调查可以工作的软件可以工作的软件面面俱到的文档面面俱到的文档胜过胜过客户合作客户合作合同谈判合同谈判胜过胜过Confidential 2010 iSoftStone Group.All Rights Reserved.1.3.2 Team：激发团队潜能，加强协作7团队是价值的真正创造者，应加强团队协作、激发团队潜能。团队是价值的真正创造者，应加强团队协作、激发团队潜能。软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本。软件开发是一种团队活动，首先应做到提升沟通效率降低交流

6、成本。效率流行度文档文档录制的视频录制的视频录制录制的音频的音频2人人邮件沟通邮件沟通2人人白板沟通白板沟通2人人电话沟通电话沟通不支持问答形式不支持问答形式支持问答形式支持问答形式业界业界调查调查：5050人团队人团队，每人平均，每人平均30%30%时间用于编码，时间用于编码，70%70%的时间用于与其的时间用于与其他成员他成员交流。交流。需求变更降低比例补充场景数TR4前发现缺陷比例版本周期缩短（周数）无线49.36%8855.90%2.82核心网45%19045.18%3.5网络31%33042.5%2.6业软30%30048.15%2.1公司平均38.84%90847.93%2.76华

7、为华为试点调查：开发试点调查：开发测试拉通，效率质量改善明显测试拉通，效率质量改善明显个体和交互个体和交互过程和工具过程和工具胜过胜过Confidential 2010 iSoftStone Group.All Rights Reserved.1.3.3 Adapting：不断调整以适应变化8能够结合自身灵活应用才是真正敏捷，能够结合自身灵活应用才是真正敏捷，不断的根据经验调整，最终交付达到业务目标的产品不断的根据经验调整，最终交付达到业务目标的产品软件开发是复杂不可预测的经验控制过程软件开发是复杂不可预测的经验控制过程随软件规模增长，需求变化呈非线性增长随软件规模增长，需求变化呈非线性增长响

8、应变化响应变化遵循计划遵循计划胜过胜过Confidential 2010 iSoftStone Group.All Rights Reserved.1.4 1.4 瀑布、迭代和敏捷的区别9瀑布：开发模型重量级：重量级：所有需求统一步伐，全部分析完毕后再开始设计，全部设计完毕后再启动编码重过程：有明显的过程，每个过程不重叠，界线清晰 SRS、HLD、LLD、Coding、UT、IT、ST，开发完毕后集中转测试。迭代：开发模型中量级：中量级：需求分成多批，每批一轮迭代，每轮内都是小瀑布；每轮迭代出一个版本交付测试。没有明显的过程。敏捷：开发模式轻量级：轻量级：需求分解成更小粒度，每个小粒度需求13

9、天实现，并立即转测试。从瀑布、迭代到敏捷，是量变引起质变。（每轮迭代结束时出版本并不是测试的开始，更多的是开发和测试共同结束点）过程：在一个过程框架下，嵌入了很多敏捷实践，并由很强的原则进行约束。开发模式之外，更是一种思想、理念、文化！Confidential 2010 iSoftStone Group.All Rights Reserved.101.敏捷核心理念2.敏捷敏捷优秀秀实践践2.1.迭代开发2.2.持续集成2.3.Story驱动2.4.站立会议2.5.完整团队2.6.可视化管理2.7.结对编程2.8.TDD2.9.RCA2.10.演示3.敏捷流程介绍目录目录Confidential

10、 2010 iSoftStone Group.All Rights Reserved.2.1.迭代开发11什么是迭代开发l迭代开发是将整个软件开发生命周期分成多个小的阶段（一般2-4周），每个阶段都开展需求分析、设计、实现和测试，每个阶段都可以生成一个稳定和被验证过的软件版本。l通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险。l通过提供功能渐增的产品，持续获得客户反馈，根据反馈及时调整，使产品更加符合客户需要。l确保每次迭代交付质量，避免形成技术债务，每一次迭代都必须建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长并不断完善。l每次迭代

11、要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。l如果迭代周期已到，无论任务是否结束，也要求终止当前迭代，未完成任务放到下次迭代再做。迭代开发的好处迭代开发的关键点Confidential 2010 iSoftStone Group.All Rights Reserved.2.2.持续集成12 l持续集成（CI）要求团队成员经常集成他们的工作，以验证新合入的变化没有造成任何 破坏，通常每人每天至少集成一次，每次集成通过自动化构建完成。l维护单一的代码配置库，每个人每天将对代码的改动提交配置库。l实现构建自动化-自动的度量、检查和测试，减少了重复的人力活动l持续集成要尽量快，最好快到5

12、分钟内能完成本地构建，30分钟内完成产品提交构建，8小时内完成每日构建。l持续集成的问题是项目组最高优先解决的问题。l构建成功率和频率是衡量CI效果的重要指标。l每个人都较容易得到最新可正常运行的软件。l持续集成实现“无事件”局面，尽早发现项目存在的问题，减少返工。l降低风险，在缺陷引入的时候即被发现，缺陷容易修复l给频繁的应用部署提供帮助，随时都可能发布软件。持续集成的好处持续集成操作关键点什么是持续集成 Confidential 2010 iSoftStone Group.All Rights Reserved.2.3.Story驱动13Story驱动是指以Story为交付单元进行开发、测

13、试、发布lStory是能够独立交付，能够被用户感知的最小需求lUserStory是Story开发的基准，它从客户的角度描述Story所需要实现的功能传统项目：所有功能Story驱动项目：测试测试测试StoryStory测试测试Story1Story1StoryNStoryN只一个开发周期，所有功能开发完成后，集成进行测试每个Story为一个开发周期，每完成一个Story即转入测试状态，并与已完成的Story不断集成需需求求设设计计CCOOD DE E测试Confidential 2010 iSoftStone Group.All Rights Reserved.2.4 站立会议 团队成员的例行

14、沟通机制，每天固定时间、固定地点、不超过15分钟，Team成员全体站立参加：n从上次会议之后完成了哪些工作？n在下次会议之前准备完成哪些工作？n在工作进行中存在哪些障碍？n有哪些好的实践或学到了哪些教训？14l增加团队凝聚力，产生积极的工作氛围,及时暴露风险和问题。l整个团队都清楚团队内部所发生的事情。l每日跟进工作进展，快速解决问题或提供帮助。l会议中禁止针对问题的讨论，如果需要讨论，将在会后进行。l会议提出的问题必须被记录，并在会后铲除障碍。l团队是在互相汇报和交流情况，并不是向PO、项目经理或敏捷教练汇报。站立会议的好处站立会议关键点Confidential 2010 iSoftSton

15、e Group.All Rights Reserved.2.4 站立会议案例15目的：通过站立会议实现团队自我管理陈述昨天开展什么工作时，以Story为中心，从工作对象、进展和工作质量等方面进行总结。比如“昨天我开展测试”“昨天我开展哪个Story测试，测试了多少用例，发现了多少问题，其中哪些问题比较严重值得关注”；比如“昨天我编码完成”“完成Story代码写作，findbugs全部清零，自测试通过，合入服务器，编码过程中，我发现某两个类有重复代码，可以优化”每个人都要把觉得对团队有价值的想法说出来；昨天做了什么事情，或是想到什么事情对团队有帮助；你知道哪些事情是大家需要知道的。切忌对别人的话

16、漠不关心、描述从燃烧图上就能看到的进度，比如昨天做某个Story，今天计划做某个Story等,会后又发现很多问题。Confidential 2010 iSoftStone Group.All Rights Reserved.Team：系统、开发、测试、资料在一个团队内，并且全程参与项目 团队之间采用最高效的沟通方式面对面的沟通角色角色主要职责主要职责POProduct Owner（产品所有者），负责将客户的需求信息化并传递给项目组，代表利益相关人（如用户、Marketing、用服、管理者等），对产品投资回报负责Story分解和澄清，确保需求理解一致项目组内维护架构、确保设计思路一致划分Stor

17、y并输出迭代backlog，随时澄清需求参与showcase、验收storyMaster团队的教练和组织者，帮助团队正确应用敏捷实践，引导团队建立并遵守规则组织开工会、站立会议、回顾会议监控整个项目的进度、质量、风险CI-COCI Coordinator（持续集成协调员），负责持续集成的正常运转2.5.完整团队16HSS质量部PM开发测试资料CMO(兼)CI-CO(兼)MasterPOQA质量保证项目组Confidential 2010 iSoftStone Group.All Rights Reserved.2.6.可视化管理故事墙（展示展示StoryStory进度进度）缺陷走势图（展示缺陷

18、解决进展展示缺陷解决进展）特性墙项目组计划墙燃尽图（Burn Down ChartBurn Down Chart）17可视化管理的好处l简单，一目了然，降低管理成本；l实时状态显示，及时暴露问题；l信息同源，使团队理解一致，提升团队凝聚力；l激励先进，鞭策后进，增强团队进取心。可视化管理形式举例Confidential 2010 iSoftStone Group.All Rights Reserved.2.7.结对编程什么是结对编程l结对编程是指两位程序员在一台电脑前工作，一个负责敲代码，另外一个实时检视。负责操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；

19、领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。18l有助于提升代码设计质量，大幅促进团队能力提升和知识传播。l帮助快速培训新手。l来自同伴的竞争压力，能起到有效的激励作用。l知识和良好的实践在两人之间共享。l结对的两人时间要同步。l结对编程要多花15的时间，在时间紧迫时结对是比较困难的事情。结对编程的好处结对编程的风险和挑战Confidential 2010 iSoftStone Group.All Rights Reserved.2.8.TDD19 Test Drive Develop 测试驱动开发，是驱动软件设计和实现的有效手段，是在有测试保证的环境下以一种

20、简单的、增量式的方法构建软件。lTDD可以借助测试的约束帮助开发人员在正确的时间作出正确的决策。l不需要强调一次性把代码写到最好，通过使用TDD和不断地重构代码和测试代码可以让软件最终满足客户需求。TDD五部曲1.针对要新增的功能，编写测试用例（代码）。2.运行测试用例不能通过。3.编写产品代码，直至运行测试通过。4.重构代码，以消除重复设计，优化设计结构。5.执行所有用例通过。Confidential 2010 iSoftStone Group.All Rights Reserved.lRCA（Root Cause Analysis）缺陷根源分析，目的是为了更好地做好缺陷预防,问题如何在后续

21、迭代开发中改进和避免。20 缺陷预防的成本最低。缺陷预防的成本最低。RCA和缺陷预防是和缺陷预防是CMM的优秀实践，希望我们在敏捷项目继续发扬光大。的优秀实践，希望我们在敏捷项目继续发扬光大。2.9.RCAConfidential 2010 iSoftStone Group.All Rights Reserved.Show Case（迭代演示）也称客户验收，在迭代测试阶段PO或测试人员向客户代表做一个全面的演示,能及时定期地提供反馈信息，加强对产品的信心，对于客户反馈的问题可以选择在当前迭代周期内解决或遗留到下一次迭代（也许就是下一次迭代的需求），问题一定要记录跟踪关闭。212.10.演示演示

22、注意事项：l不需要刻意准备，我们只演示已完成的特性l要重点关注功能，不要过多地纠缠细节，要知道参加演示的人员时间都很宝贵。l 提前进行：如果开发过程中，通过口头交流还是难以把握需求（比如界面类需求），可以在功能基本跑通时，就进行showcase，以尽早获得反馈，尽早调整。Confidential 2010 iSoftStone Group.All Rights Reserved.221.敏捷核心理念2.敏捷优秀实践3.敏捷流程敏捷流程3.1.实践选择原则3.2.敏捷开发框架3.2.1.迭代准备3.2.2.迭代3.2.3.发布测试目录目录Confidential 2010 iSoftStone

23、Group.All Rights Reserved.RCARCA?3.1.实践选择注意项23 在充分理解敏捷理念的前提下，因地制定宜地选择适合的敏捷实践站立会议站立会议持续集成持续集成TDDTDD结对编程结对编程迭代开发迭代开发StoryStory驱动驱动完整团队完整团队可视化管理可视化管理演示演示软件公司敏捷项目，要求开展四个基本实践、三类测试活动、三类项目管理会议软件公司敏捷项目，要求开展四个基本实践、三类测试活动、三类项目管理会议四个基本实践：四个基本实践：迭代开发、持续集成、Story驱动、完整团队三类测试活动三类测试活动：Story测试、迭代测试、SIT测试三类项目管理会议三类项目管

24、理会议：迭代计划会议、每日站立会议、迭代回顾会议Confidential 2010 iSoftStone Group.All Rights Reserved.验收准入评估点立项计划实 施施验收发布生命周期可行性评估点计划评估点迭代N迭代2迭代1迭代发布评审点.发布测试发布测试发布测试迭代准备迭代准备迭代开发迭代开发发布测试发布测试3.2.敏捷开发框架24Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.1.迭代准备(1/2)25 组建团队组建团队 敏捷办公环境布置敏捷办公环境布置 可视化管理准备可视化管理准备 搭建持续集成环境

25、搭建持续集成环境Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.1.迭代准备(2/2)26l 评估项目交付范围、规模、复杂度、项目周期、准备采用哪些敏捷实践以及需要哪些培训等。l 制定项目的整体计划（粗略的迭代计划）：根据项目人力、时间等资源，划分迭代，确定迭代轮次、每轮迭代的范围（主要包含Story列表）、最终SIT时间等。项目初始评估、制定项目计划项目初始评估、制定项目计划 项目启动会议项目启动会议 Story Story分析、估计分析、估计l 项目启动是很正式的事情，由所有的利益相关人参加。l 收集各职能团队的承诺，这

26、些团队包括开发组、测试组、资料开发组、质量组、客户、管理组以及其它项目相关的组织。l PO对需求规格进行分解，转换成story条目，设置优先级，完成Story的初步估计，并挑选迭代1的story完成分析。伴随Story要同时输出可接受性测试用例（Acceptance Test Case，简称AT）-必须要通过软件开发人员、测试人员、资料开发人员、客户的评审 Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.2.迭代迭代流程27持 续 集 成 迭代开迭代开发迭代迭代验收收迭代测试迭代测试需求澄清、需求澄清、Story分解分解迭代

27、迭代计划划收尾收尾评估、评估、回顾回顾Story开发过程不断重复，直到迭代计划Story结束Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.2.迭代迭代计划28lPM按照Story的优先级和相关度，将最佳或对客户最为重要的Story作为初始迭代的一部分进行规划，确定本次迭代的目标。l召开迭代计划会议，PO按优先级澄清本次迭代将实现的Story，以明确需求要做成什么样子、验收条件是什么，由团队对每个Story做估算，达成一致，并进行认领，故事交付计划由故事认领人来确定，并作出承偌。l如果会议中，团队觉得Story的粒度需要分解

28、，可以对Story进一步的拆分。Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.2.迭代 迭代开发.流程29故事开发过程不断重复，直到迭代计划故事结束Story分析代码和测试码评审测试代码，代码准备、运行 和重构故事卡AT测试测试用例准备测试用例 评审故事测试检查表更新故事交付检查表更新故事卡相关资料文档开发 资料开发人员进行同行评审软件开发人员评审资料原型S St to or ry y 测测试试S St to or ry y签签收收SDV测试用例自动化测试代码评审资料交付检查表更新Confidential 2010 iSo

29、ftStone Group.All Rights Reserved.3.2.2.迭代迭代开发.Story分析30l在开发某个故事前，PO、开发、测试、资料对复杂的Story进行一个简短的头脑风暴，侧重Story如何实现以及各种测试场景。l建议在头脑风暴之前，熟悉story和验收条件，开发输出Story设计文档，测试输出测试点，然后再召开会议。p有思考后再与会，效果往往会更好。p直接澄清需求是正向理解需求，讨论测试点和实现方案是逆向理解需求，“正向+逆向”能确保需求理解的更充分。l简单的story可以在需求澄清后直接进入编码。l会议简短高效，在座位上召开即可，一般1030分钟。Confident

30、ial 2010 iSoftStone Group.All Rights Reserved.31什么是Story签收？lStory签收是转ST的入口，用于检验开发者与客户在功能理解上的一致性，签收责任人-开发人员（Pair）、故事测试人员、资料人员、PO3.2.2.迭代-迭代开发.Story签收l Story签收必须在持续构建版本上进行，不能在程序员本机环境操作。l 用于签收的AT（可接受性测试用例），必须是已经过团队的评审并达成一致理解的，签收通过的基本条件是AT必须通过。l 签收过程中提出的新需求，尽量启动新的Story跟踪。l 签收的形式可以多样化，可以是签收者直接体验，也可以是开发者演

31、示。l Story必须经过开发人员的自测试，才能进入签收，正常情况下单个Story的签收时间是非常短暂的，大概是几分钟到十几分钟的样子。Story签收注意事项：Confidential 2010 iSoftStone Group.All Rights Reserved.323.2.2.迭代-迭代开发.Story测试Story 测试lStory测试是针对单个Story的功能和非功能测试，并分析其对整个系统的影响。lStory测试的主体是测试人员。l Story测试及问题回归必须在持续构建版本上进行，不能在程序员本机环境操作l Story测试出的问题，开发人员需要停下手头新Story的开发工作优先

32、处理问题单，以保证已完成工作的有效性及完整性。l 当前的Story 测试需要考虑与已完成Story的依赖关系。l 尽量避免只能到迭代末才能提供版本给测试。Story 测试注意事项：Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.2.迭代迭代验收迭代测试 l在完成ST（故事级测试）后，测试组再针对整个迭代范围的所有Story（也会有针对前次迭代的回归）进行完整的功能和非功能测试。l测试的入口条件：所有ST通过。迭代测试要走正式的转测试电子流。l资料开发组评审也是在迭代测试范围内进行。l迭代测试的主体是测试人员。l测试结束后需要

33、给出测试报告。l在迭代测试期间，测试人员的重点是进行探索性测试，重点关注非功能测试，比如性能测试l设计测试用例以便在探索性测试中查找缺陷，使该过程自动化33Confidential 2010 iSoftStone Group.All Rights Reserved.回看过去，分析问题、明确措施、进行改进。回顾会议内容：l1.总结本轮迭代哪些地方做得好。l2.总结本轮迭代哪些地方可以做得更好。l3.得出最主要的改进建议（约3条），并在以后的迭代中持续跟踪。343.2.2.迭代收尾.回顾Confidential 2010 iSoftStone Group.All Rights Reserved.3

34、53.2.2.迭代收尾.回顾每轮迭代末，或进展不畅时，都应召开回顾会议。迭代回顾会议是促进团队持续改进的最有效手段。建议议程：开场：开场：致欢迎词；每个人用一两个形容词描述对本次回顾会议的期望；分析：分析：回顾本轮迭代所有度量数据、图表、完成的特性、重要问题、周边评价等信息；信息收集：信息收集：发给每人贴纸，10分钟写出白板上要求的内容，并自行贴到白板上；快速归类：快速归类：主持人发动大家一起归类；快速分享：快速分享：主持人念出贴纸上的内容，让大家知道；探讨探讨TOPTOP问题根因问题根因&解决方法：解决方法：针对TOP35问题，使用头脑风暴进行讨论，并得出措施（可以分组也可以一起讨论）；会后

35、跟踪：会后跟踪：解决措施在下轮迭代就应立即实施，努力让本轮TOP问题不再是下轮TOP问题。准准备备开会开会跟踪跟踪关键道具关键道具Confidential 2010 iSoftStone Group.All Rights Reserved.3.2.3.发布测试l发布测试（Release Test），有时也称SIT、系统验收测试。l测试范围：所有迭代的综合测试，包括功能和非功能测试，尤其关注性能测试等非功能测试。l测试的主体在测试人员，要给出测试报告。l每次正式的release前建议都要有这样的测试。36Confidential 2010 iSoftStone Group.All Rights

36、Reserved.37参考资料参考资料l端到端定制敏捷开发生命周期端到端定制敏捷开发生命周期.ppt.pptl软件公司敏捷项目过程介绍软件公司敏捷项目过程介绍V2.6.pdfV2.6.pdfl敏捷参考过程敏捷参考过程.pdf.pdfConfidential 2010 iSoftStone Group.All Rights Reserved.推荐书籍推荐书籍38针对管理者：ScrumScrum敏捷项目管理敏捷项目管理KEN SCHWABER清华大学出版社 PMPL必读，Scrum理论与实践的重要奠基之作，作者是Scrum的缔造者。敏捷迭代开发敏捷迭代开发 管理者指南管理者指南Craig Larm

37、an 中国电力出版社 PMPL参考手册，了解敏捷的多个流派，里面有很多的checklist可以参考。敏捷估计与规划敏捷估计与规划MIKE COHN清华大学出版社 了解优秀的计划由哪些东西组成，如何才能使计划也成为敏捷的。人月神话人月神话 Frederick P.Brooks，Jr.清华大学出版社 很多人都知道了。针对需求分析人员：User Stories AppliedUser Stories Applied MIKE COHN Addison-Wesley 敏捷项目需求分析人员必读。针对系统设计、开发人员：大规模大规模C+C+程序设计程序设计John lacks 中国电力出版社 经典之作，C

38、程序员也应阅读。敏捷软件开发敏捷软件开发原则、模式与实践原则、模式与实践Robert C.Martin清华大学出版社 OOD最经典的一本书，使用过程化开发语言也可借鉴其中思想。修改代码的艺术修改代码的艺术MICHAEL FEATHERS 人民邮电出版社 了解如何重构大型的、无测试的遗留系统。产品历史3年以上的开发人员必备书籍。重构重构 -改善既有代码的设计改善既有代码的设计Martin Fowler 中国电力出版社 了解重构的基本技巧和思想，编码过程中如何进行重构。持续集成持续集成:软件质量改进和风险降低之道软件质量改进和风险降低之道Paul M.Duvall等 了解持续集成的基本原则、工具和方法。计算机程序的构造和解释计算机程序的构造和解释 Harold Abelson,Gerald Jay Sussman,Julie Sussman 机械工业出版社 英文名：SICP:Structure and Interpretation of Computer Programs 麻省理工计算机系教材。Confidential 2010 iSoftStone Group.All Rights Reserved.谢谢 谢！谢！