软件项目管理论文——敏捷方法

1、1概述1.1 什么是敏捷开发u 敏捷方法的产生-2001年2月，17个方法学家在美国犹他州Snowbird成立了敏捷软件开发联盟()，并共同起草了敏捷软件开发宣言，这标志着敏捷开发的诞生。这一模式随后被硅谷创业公司大量应用，并于近几年被引入国内。敏捷开发模式中，一个项目被分解为多个部分或多个步骤。在每个阶段完成后，项目都可以拿出一定程度可交付的产品。这样做便于实现产品交付目标，降低整个项目的复杂度，同时在项目早期就能拿出初具雏形的产品。u 敏捷宣言的4条价值观1)个体和交流胜于过程和工具2)工作软件胜于综合文档3)客户协作胜于洽谈协议4)回应变革胜于照计划行u 敏捷宣言的12条基本原则l)最优

2、先要做的是通过尽早地、持续地交付有价值的软件来使客户满意2)即使到了开发的后期也欢迎改变需求，敏捷方法得用变化来为客户创造竞争优势3)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好4)在整个项目开发期间，商务人员和开发人员必须天天都工作在一起5)围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作6)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈7)工作的软件是首要的进度度量标准8)敏捷方法提倡可持续的开发速度，责任人、开发者各用户应该能够保持一个长期的、恒定的开发速度9)不断地关注优秀设计的技能和好的设

3、计会增强敏捷能力10)简单使未完成的工作最大化的艺术是最根本的11)最好的架构、需求和设计出自于自组织的团队12)每隔一定时间，团队会在如何才能更有效工作方而进行反省，然后相应地对自已的行为进行调整敏捷方法的过程模型主要的几种敏捷方法的过程模型如下：Ø SCRUMØ 极限编程XPØ 自适应软件开发Adaptive SoftwareDevelopmentØ 精益软件开发Lean Software DevelopmentØ 特征驱动开发Feature Driven DevelopmentØ 敏捷统一开发过程AgileRationalUni

4、fied ProcessØ 动态系统开发方法Dynamic SystemDevelopmentMethodØ 水晶系列方法Crystal这些敏捷方法的共同点是：使用短的固定长度迭代和反馈快速递交测试过的工作软件2 过程模型介绍2.1 SCRUM并列争球法Scrum的英文意思是橄榄球运动的一个专业术语，表示。争球。的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。三大角色：&

5、#216; 产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。Ø 流程管理员（Scrum Master）主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。Ø 开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在510人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprin

6、t的目标。2.1.2 Scrum流程图图1 Scrum流程图如何进行Scrum开发？1、 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；图2Product Backlog2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议）来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是14个星期，然后把这个Story进行细化，形成一个Sprin

7、t Backlog；图3任务看板4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

8、图4每日站立会议6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Sprint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加

9、（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；2.2 XP极限编程那么什么是XP呢？XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：l 在更短的周期内，更早地提供具体、持续的反馈信息。l 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个

10、项目开发过程中不断的发展它。l 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。l 依赖于口头交流、测试和源程序进行沟通。l 倡导持续的演化式设计。l 依赖于开发团队内部的紧密协作。l 尽可能达到程序员短期利益和项目长期利益的平衡。Kent Beck曾经说过“开车”就是一个XP的范例，即使看上去进行得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供方向盘，并且告知我们现在的位置。XP包括写什么呢？如图，XP由价值观、原则、实践和行为四个部分组成，它们彼此

11、相互依赖、关联，并通过行为贯穿于整个生命期。图5XP极限编程四大价值观1. 沟通XP方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性。因此，XP组合了诸如对编程这样的最佳实践，鼓励大家进行口头交流，通过交流解决问题，提高效率。2. 简单XP方法论提倡在工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。正如对传统开发方法的认识一样，许多开发人员也会质疑XP，保持系统的扩展性很重要，如果都保持简单，那么如何使得系统能够有良好的扩展性呢？其实不然，保持简单的理

12、由有两个：Ø 开发小组在开发时所做的规划，并无法保证其符合客户需要的，因此做的大部分工作都将落空，使得开发过程中重复的、没有必要的工作增加，导致整体效率降低。Ø 另外，在XP中提倡时刻对代码进行重构，一直保持其良好的结构与可扩展性。也就是说，可扩展性和为明天设计并不是同一个概念，XP是反对为明天考虑而工作，并不是说代码要失去扩展性3. 反馈在许许多多项目中，当开发团队经历过了需求分析阶段之后，在相当长的一段时间内，是没有任何反馈信息的，整个开发过程对于客户和管理层而言就像一个黑盒子，进度完全是可见的。而且在项目的过程中，这样的现象不仅出现在开发团队与客户、管理层之间，还包括

13、在开发团队内部。反馈对于任何软件项目的成功都是至关重要的，而在XP方法论中则更进一步，通过持续、明确的反馈来暴露软件状态的问题。具体而言就是：在开发团队内部，通过提前编写单元测试代码，时时反馈代码的问题与进展。在开发过程中，还应该加强集成工作，做到持续集成，使得每一次增量都是一个可执行的工作版本，也就是逐渐是软件长大，整个过程中，应该通过向客户和管理层演示这些可运行的版本，以便及早地反馈，及早地发现问题。4. 勇气总之这一切，使得你立刻处于变化之中，因此这时就需要你有勇气来面对快速开发，面对可能的重新开发。也许你会觉得，为什么要让我们的开发变得如此零乱，但是其实这些变化若你不让它早暴露，那么它

14、就会迟一些出现，并不会因此消亡，因此，XP方法论让它们早出现、早解决，是实现“小步快走”开发节奏的好办法。也就是XP方法论要求开发人员穿上强大、自动测试的盔甲，勇往直前，在重构、编码规范的支持下，有目的地快速开发。五个原则1. 快速反馈及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。这也是对反馈这一价值观的进一步补充。2. 简单性假设类似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要

15、时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。3. 逐步修改就像开车打方向盘一样，不要一次做出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理同样适用，任何问题都应该通过一系列能够带来差异的微小改动来解决。4. 提倡更改在软件开发过程中，最好的办法是在解决最重要问题时，保留最多选项的那个。也就是说，尽量为下一次修改做好准备。5. 优质工作在实践中，经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，由于不影响使用就先不管；某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象，这样的坏习惯一旦养成，必

16、然使得代码质量大打折扣。而在XP方法论中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。2.2.3 13个最佳实践图6 XP实践1. 计划游戏计划游戏的主要思想就是先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。“客户负责业务决策，开发团队负责技术决策”是计划游戏获得成功的前提条件。也就是说，系统的范围、下一次迭代的发布时间、用户故事的优先级应该由客户决定；而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险，以及具体的开发顺序应

17、该有开发团队决定。首先客户和开发人员坐在同一间屋子里，每个人都准备一支笔、一些用于记录用户故事的纸片，最好再准备一个白板，就可以开始了。客户编写故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上，这也就是用户故事。开发人员进行估算：首先客户按优先级将用户故事分成必须要有、希望有、如果有更好三类，然后开发人员对每个用户故事进行估算，先从高优先级开始估算。如果在估算的时候，感到有一些故事太大，不容易进行估算，或者是估算的结果超过2人/周，那么就应该对其进行分解，拆成2个或者多个小故事。确定迭代的周期：接下来就是确定本次迭代的时间周期，这可以根据实际的情况进行

18、确定，不过最佳的迭代周期是23周。有了迭代的时间之后，再结合参与的开发人数，算出可以完成的工作量总数。然后根据估算的结果，与客户协商，挑出时间上够、优先级合适的用户故事组合，形成计划。2. 小型发布XP方法论秉承的是“持续集成，小步快走”的哲学，也就是说每一次发布的版本应该尽可能的小，当然前提条件是每个版本有足够的商业价值，值得发布。由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。3. 隐喻相对而言，隐喻这一个最佳实践是最令人费解的。什么是隐喻呢？根据词典中的

19、解释是：“一种语言的表达手段，它用来暗示字面意义不相似的事物之间的相似之处”。那么这在软件开发中又有什么用呢？总结而言，常常用于四个方面。寻求共识：也就是鼓励开发人员在寻求问题共识时，可以借用一些沟通双方都比较熟悉的事物来做类比，从而帮助大家更好地理解解决方案的关键结构，也就是更好地理解系统是什么、能做什么。发明共享词汇：通过隐喻，有助于提出一个用来表示对象、对象间的关系通用名称。例如，策略模式（用来表示可以实现多种不同策略的设计模式）、工厂模式（用来表示可以按需“生产”出所需类得设计模式）等。创新的武器：有的时候，可以借助其他东西来找到解决问题的新途径。例如：“我们可以将工作流看做一个生产线

20、”。描述体系结构：体系结构是比较抽象的，引入隐喻能够大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间通过一条传递消息的“管道”进行通信。当然，如果能够找到合适的隐喻是十分快乐的，但并不是每种情况都可以找到恰当的隐喻，你也没有必要强求4. 简单设计Kent Beck概念中简单设计是这样的：能够通过所有的测试程序。没有包括任何重复的代码。清楚地表现了程序员赋予的所有意图。包括尽可能少的类和方法他认为要想保持设计简单的系统，需要具备简单思考的能力，拥有理解代码和修改的勇气，以及为了消除代码的“坏味道”而定期重构的习惯。那么如何开始进行简单的设计呢？XP实践者们也总结也一些具体的、可操作的思考

21、方法。首先写测试代码：具体将在后面详细描述。保持每个类只负责一件事：SRP（单一职责原则）是面向对象设计的基础原则之一。使用Demeter（迪米特）法则：迪米特法则，也称为LoD法则、最少知识原则。也就是指一个对象应当对其他对象尽可能少地了解。用隐喻的方法来解释的话就是“只与你直接的朋友通信”、“不要和陌生人说话”。使用CRC卡片进行探索。5. 测试先行6. 重构重构时一种对代码进行改进而不影响功能实现的技术，XP需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码优化更加容易。通常重构发生在两种情况之下：Ø 实现某个特性之前：尝试改变现有的代

22、码结构，以使得实现新的特性更加容易。Ø 实现某个特性之后：检查刚刚写完的代码后，认真检查一下，看是否能够进行简化。7. 结对编程“什么！两个人坐在一起写程序？那岂不是对人力的巨大浪费吗？而且我在工作时可不喜欢有一个人坐在边上当检察官。”是的，正如这里列举出来的问题一样，结对编程技术还是被很多人质疑的。不过，自从20世纪60年代，就有类似的实践在进行，长期以来的研究结果却给出了另外一番景象，那就是结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度，但慢慢的，开发速度会逐渐加快，究其原因，主要是结对编程大打降低了沟通的成本，提供了工作的质量，具体表现在：所有的设计决策确保不是由一

23、个人做出的。系统的任何一个部分都肯定至少有2个人以上熟悉。几乎不可能有2个人都忽略的测试项或者其他任务结对组合的动态性，是一个企业知识管理的好途径。代码总是能够保证被评审过。而且XP方法论集成的其他最佳实践也能够使得结对编程更加容易进行：编码标准可以消除一些无谓的分歧。隐喻可以帮助结对伙伴更好地沟通。简单设计可以使得结对伙伴更了解他们所从事的工作。结对编程技术被誉为XP保持工作质量、强调人文主义的一个典型的实践，应用得当还能够使得开发团队之前的协作更加流畅、知识交流与共享更加频繁，团队的稳定性也会更加稳固。8. 集体代码所有制由于XP方法论鼓励团队进行结对编程，而且认为结对编程的组合应该动态地

24、搭配，根据任务的不同、专业技能的不同进行最优组合。由于每个人都肯定会遇到不同的代码，所以代码的所有制就不再适合于私有，因为那样会给修改工作带来巨大的不便。也就是说，团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（也就是修改后发生问题），就应该由谁来修复。由于在XP中，有一些与之匹配的最佳实践，因此你并无须担心采用集体代码所有制会让你的代码变得越来越乱：由于在XP项目中，集成工作是一件经常性得工作，因此当有人修改代码而带来了集成的问题，会在很快的时间内被发现。由于每一个类都会有一个测试代码，因此不论谁修改了代码，都需要运行这

25、个测试代码，这样偶然性的破坏发生的概率将很小。由于每一个代码的修改就是通过了结对的两个程序员共同思考，因此通常做出的修改都是对系统有益的。由于大家都坚持了相同的编码标准，因此代码的可读性、可修改性都会比较好，而且还能够避免由于命名法、缩进等小问题引发经常性得代码修改。9. 持续集成可能大家会对持续集成与小型发布代表的意思混淆不清，其实小型发布是指在开发周期经常发布中间版本，而持续集成的含义则是要求XP团队每天尽可能多次地做代码集成，每次都在确保系统运行的单元测试通过之后进行。这样，就可以及早地暴露、消除由于重构、集体代码所有制所引入的错误，从而减少解决问题的痛苦10. 每周工作40小时这是最让

26、开发人员开心的、管理者反对的一个最佳实践了，加班、再加班早已成为开发人员的家常便饭，也是管理者最常使用的一种策略，而XP方法论认为，加班最终会扼杀团队的积极性，最终导致项目失败，这也充分体现了XP方法关注人的因素比关注过程的因素更多一些。Kent Beck认为开发人员即使能够工作更长的时间，他们也不该这样做，因为这样做会使他们更容易厌倦编程工作，从而产生一些影响他们效能的其他问题。因此，每周工作40小时是一种顺势行为，是一种规律。其实对于开发人员和管理者来说，违反这种规律是不值得的。不过有一点是需要解释的，“每周工作40小时”中的40不是一个绝对数，它所代表的意思是团队应该保证按照“正常的时间

27、”进行工作。那么如何做到这一点呢？首先，定义符合你团队情况的“正常工作时间”。其次，逐步将工作时间调整到“正常工作时间”。再次，除非你的时间计划一团糟，否则不应该在时间妥协。最后，鼓起勇气，制定一个合情合理的时间表。11. 现场客户为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的需要将客户请到开发现场。就像计划游戏中提到过的，在XP项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于XP项目而言有着十分重要的意义。其实现场客户在具体实施时，也不是一定需要客户一直和开发团队在一起，而是在开发团队应该和客户能够

28、随时沟通，可以是面谈，可以是在线聊天，可以是电话，当然面谈是必不可少的。其中的关键是当开发人员需要客户做出业务决策是，需要进一步了解业务细节时能够随时找到相应的客户。不过，也有一些项目是可以不要现场客户参与的：当开发组织中已经有相关的领域专家时。当做一些探索性工作，而且客户也不知道他想要什么时（例如新产品、新解决方案的研究与开发）。12. 编码标准XP方法论认为拥有编码标准可以避免团队在一些与开发进度无关的细节问题上发生争论，而且会给重构、结对编程带来很大麻烦。不过，XP方法论的编码标准的目的不是创建一个事无巨细的规则表，而是只要能够提供一个确保代码清晰，便于交流的指导方针。如果你的团队已经拥

29、有编码标准，就可以直接使用它，并在过程中进行完善。如果还没有，那么大家可以先进行编码，然后在过程中逐步总结出编码规则，边做边形成。当然除了这种文字规范以外，还可以采用一些如自动格式化代码工具之类的方法进行代码规范。，事实上，你只需要很好地贯彻执行其他的实践并且进行沟通，编码标准会很容易地浮现出来。13. 配合是关键有句经典名言“1+1>2”最适合表达XP的观点，Kent Beck认为XP方法论的最大价值在于在项目中融会贯通地运用12个最佳实践，而非单独地使用。你当然可以使用其中的一些实践，但这并不意味着你就运用了XP方法论。XP方法论真正能够发挥其效能，就必须完整地运用12个实践。2.3

30、 FDD特征驱动建模FeatureFeature（特征）是一个基本的开发单位，是（FDD）项目中的一个增量，是指用户眼中最小的有用的功能，可以在很短时间内实现（一般在两周之内）。FDD中的角色1. Domain expert(s) ：领域专家2. Chief Architect(s) ：首席架构师3. Chief Programmer(s) ：主程序员Feature Team一般由Domain expert ，Chief Programmers，Class Owners组成，一个Chief Programmers可以带领多个Class Owners。基本流程FDD方法包括5个过程，其中的按照功

31、能设计和构建是反复的迭代过程。图7 FDD基本流程Ø 开发整体模型这是FDD开始一个项目的初始工作，在主设计师的指导下，带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求，然后使用四色原型进行域建模。图8四色原型Ø 构建功能列表这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分，将整个领域分成一定数量的区域（主要功能集），每个区域再细化为一定数量的活动，活动中的每一步被划分称为一个功能，形成具有层次结构的分类功能列表。Ø 计划功能开发项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功

32、能的复杂性，计划实现功能的顺序，完成一个功能开发计划。它提供了对项目的高层视图，让业务代表了解功能开发、测试和发布日期，以便业务代表和部署小组能够计划交付哪些功能的日期。Ø 按照功能设计项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计，得出分析模型、设计模型。由于一次设计并不全面，因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了：详细设计、项目里程碑计划等。Ø 按照功能构建按照设计进行编码实现，由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评

33、审。在测试和检查通过后检入到配置管理库中进行构建。第5和第4 阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑的继续，直到最后项目的完成。最佳实践Ø 领域对象建模是对象分解的一种形式，主要包括构造类图，用于描述问题领域中重要对象的类型及其相互关系，为系统设计提供了一种整体框架，使得系统可以按照特征迭代增量地进行开发。Ø 按照特征开发按照一组小功能、对客户有价值的功能列表进行开发并跟踪过程。FDD将需求问题分解成可以解决的小问题，对每个问题分解为分层列表的功能需求，即特征。然后，开

34、始设计并实现每一个特征。一旦系统的功能特征被标识以后，它们通常在FDD方法中用于驱动和跟踪开发过程。Ø 类（代码）拥有权FDD规定每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。FDD方法采用的开发技术是面向对象，类定义一个单一的概念和实体，最合适作为最小的代码分配要素，代码的所有权即为类的所有权。Ø 特征小组FDD把类即特征分配给一个确定的开发者。由于一个特征的实现会涉及到多个类及其所有者，因此，特征的所有者（特征组长）需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别：特征小组的组长更像是教练而不是超级程序员。Ø 审查

35、指的是检查软件错误的复审方法，这是FDD确保软件设计和代码质量的一个关键技术。审查将开发小组和FDD以主程序元为主的结构完美地结合起来，这种混合是一种新型的开发方式。Ø 定期构建定期地取出已完成功能的全部源代码和它所依赖的库、组件，组成完整的可以运行的系统。构建增加功能的基线，确保总是有一个可以运行、向客户演示的软件系统，可以使客户观察到系统开发的进度和实现的功能是否是需要的。Ø 配置管理一个FDD项目只需要保证对完成的代码文件最新版本的确认和历史追踪。根据开发软件的复杂性，分析制品、设计制品以及测试用例、测试脚本等也应该受控于版本控制。Ø 可视性进度报告项目成员

36、应该根据完成的工作向各级管理报告工作进度，FDD提供了一个简单、低开销地收集准确和可靠项目信息的方法，提供了大量直观、直接的报告样式，向项目所有相关人员报告项目进度。3.腾讯敏捷研发框架TAPD用简单的公式表示为:TAPO=fFDD(需求分析/建模);Scrum(敏捷过程模型);XP(实践方式)3.1迭代计划在项目启动的时，项目组会制定一份5项目计划6，主要是进行项目的阶段划分，确定重大的里程碑等。以后在每个迭代中，产品人员就会根据当前的项目情况以及用户的反馈来对项目计划中的某些需求进行分解细化，初步确定下一迭代的任务。在下个迭代开始时，开发人员，产品人员通过IPM会议将本迭代的任务明确下来，

37、并制定本迭代的详细计划，采用故事卡来记录本迭代要完成的特性。迭代考虑的因素解释项目紧急程度即一个功能是不是用户当前非常需要的，如果是，则会尽量在早期迭代中实现功能点大小确保选择的功能点可以在2-3周内完成，对于大的功能点，需要再进行分解细化影响人群优先选择大量用户的共同需求，对于个性化的需求，可以在以后完善时实现围绕主题每个迭代要实现的特性，尽可能围绕一个主题采用故事卡记录每个迭代的任务，可以很清晰的描述单个任务，但是任务之间的关联性不好表达，该如何处理这个问题的呢?在项目初期规划的时候，就会画一幅网站地图，该地图很好的描述了产品各个功能间的关系，在每个迭代的任务明确后，产品人员就会在网站地图

38、中将本迭代要做的功能标识为红色，这样，大家就可以从网站地图上清晰的看出本迭代要实现的功能间的联系了。应对需求变更需求变更或有了新的需求时，如果随时加入本次迭代或者在本此迭代内立即调整，尽管从短期来看满足了用户的需要，但是会造成开发团队对计划的不尊重，制定计划时就会不认真，因为大家知道这个计划是不会按时完成的;相反，如果严格执行计划，大家就会严肃对待这个计划，并尽最大努力保证计划的按时完成，这样，团队成员就会信任这个计划，并将其作为自己的一个短期的目标，提高了大家的工作积极性和团队的士气。因此，对于每个新需求要纳入下一个迭代。由于每个迭代的周期都比较短，一般是以周为单位的，所以基本都可以满足到用

39、户的需求。迭代任务确定后的工作分工在确定了本次迭代的任务后，并不急于分工，而是先进行工作量的评估。对于一个任务，每个人给出自己评估的工作量，如果评估的很不一致，则表明大家对需求的理解还不是很到位，此时，产品人员再解释一下需求，然后进行第二轮的评估。一般情况下，经过2-3轮的评估，大家对这个任务所需要的工作量就可以达成一致了。当每个任务的工作量估计都确定后，由开发人员自己挑选任务。先评估工作量再分配任务，可以使工作比较透明，任务分配也比较公平。同时，由于大家共同确定工作时间，而不是某个人拍脑袋，也提高了计划的准确性。而且，因为每个人都要评估所有的任务，也使得大家对项目更加了解，团队合作也更加顺畅

40、。3.2需求开发需求开发是将大模块拆分为各项特性，根据特性的大小再拆分为各个功能，达到对整体需求的细化;根据各项特性的重要性定出优先级;按照优先级和关联性将各个功能分配到每次迭代开发中，让开发人员清晰的知道各个特性需要实现的时间。定期对各项特性表进行维护，拥抱变化，实时根据具体需求来调整远期计划，并及时通知到开发的相关人员。特性列表里面明确列出了当前版本所包含的特性，下个迭代所包含的特性，以及后期对特性的规划。3.3 UI设计互联网应用软件中，UI(UserInterface)设计是最重要的环节之一。TAPO提出了:1)需求沟通2)需求确认，3)评审，4)合作，5)质量和进度五个方面进行UI设

41、计。1) 需求沟通产品经理召开常规需求分析会议，用邮件通知到UI人员。UI设计人员有选择参与需求阶段的讨论，参与需求评审，频繁与产品经理沟通，保证每周有一次固定沟通。产品经理可能会参与交互稿件的原型(简易原型)设计，后期设计师再参与修正。同样，设计师为了更好的为产品服务，也参与需求讨论，提出问题。双方在需求前期也会有工作的交叉。2) 需求确认产品经理尽量避免在迭代周期内变更需求;产品经理在需求确定后提交给UI的需求需包括时间、质量、优先级等方面的要求。UI人员在收到需求后一天内反馈UI实现进度，如有困难或问题及早与产品方沟通。3) 评审视觉/交互设计评审采用公开和扁平化的方式进行。评审工作一次

42、完成，尽量避免多层的评审4) 合作产品经理在UI资源紧缺情况下，可自行完成交互设计原型，后期再由交互设计师再进行修正。必要时，产品经理完成交互原型设计。UI设计人员充分了解需求，可对产品经理提出有建设性的建议;UI设计人员在产品经理需要时候提供设计工具和其他相关培训。在UI资源紧缺情况下，为避免进度受到影响，产品经理可以在需求说明中自行完成交互设计原型，后期再由交互设计师再进行修正。UI设计与产品经理的充分沟通和相互信任。产品经理和UI设计人员双方在长期的合作中达成默契和信任，是项目能够顺利推进的首要前提。5) 质量和进度控制对于一般质量要求的UI，优先保证项目进度。为配合项目计划时间加快进度

43、，可适当降低质量。3.4 每日晨会晨会上每个人的发言不超过3分钟为宜，整个会议15分钟为宜。这是按照5人团队来制定的。如果团队人数超过5人，甚至达到10人、20人，那么建议成立两个团队。Scrum的晨会是站立着开的，一方面是为了不让会议拖沓，另一方面也是为了让大家注意力集中（如果坐下肯定有人会顺便打开电脑，然后开始上网）。在每天的晨会上，团队成员每人都叙述对昨天的工作做一个总结，总结由Scrum Master记录在白板上。总结的内容包括：1. 工作完成的情况。只需要选择以下状态即可：未开始、正在开发、已完成。2.工作遇到的难点（如果未按时完成）；工作中值得注意的地方（可以是系统框架的体会、业务的特殊性、封装了哪些公共功能等）。3.今天要做什么（如果昨天的工作已完成）。当某人遇到问题的时候，其他成员如果有解决办法或者建议，那么可以“举手”，但不用说出解决的办法，由Scrum Master安排两人结对编程。后来也做了一些改进比如为了让成员的参与程度更强一些，现在多数团队就会采取每个人轮流主持的方式;还有些分布式团队会通过即时通信软件每天去交流，最后由一个人去统