敏捷开发 vs 传统开发

说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有一条产品线可以维持公司开支并仅仅刚够盈余，要扩大高速发展还不够，一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢？一个难题，很大的难题！

我们技术团队人员是这样的配置：1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作，能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师，参与新项目开发时间大概有80%。高级工程师要预留项目学习时间，参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目，但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命，属于机动部队。

现在总共有六个老项目在维护，两个新项目需要开发。六个项目的维护总共需要每周4人天时间（人天指需要花1个人4天的时间完成一个事情）。其中一个新项目“项目1”大概估计120人天的开发时间，需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间，需要2周开发完成。而现在的人力按照能够投入的时间算一下，总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天，6个老项目每周需要4人天，一个月4周，需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天，而总共需要120 + 40 = 160天，足足少了44人天，这看起来是一个不可完成的任务。

不过到最后，我们还是使用敏捷开发完成了这两个项目，也没有影响老项目的维护。我们是怎么操作的？最开始我们两个开发，这个时候只要两个人就能够很好的合作把产品开发出来，不需要什么模式。随着人员的扩充，团队间如何协作按时按质按量完成任务就需要好好思考下了。

尝试一，传统软件开发模式。整个过程为需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式，不过套用在我们公司时我们是这么操作的。

传统开发过程

由于公司创业，老板有一个想法，但并不能很好的描述需求，所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成，后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成，资深工程师进行把关，再到测试人员测试，最后再交付用户验收、技术维护。看起来很好的模式，开发了几个产品最终有的延时有的产品离用户的期望差距甚远，参与项目团队的人信心受挫。

为什么会失败呢？后来思考了这些问题：

1、技术总监不是产品经理，不能够承担产品设计的责任。老板是信任技术总监能做好产品，就交给他做。但这里搞混了一个概念，产品经理和项目经理，技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好，责任所在。说到底，就是机制没有把产品设计和项目经理区分开，不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定，变化后改动代价大。由于创业，需求为了适应市场会经常调整，但是一但调整，很多开发计划就会受到相应的调整。如果部分功能已经正在开发，调整需求后很多工作要重新开始，严重影响了技术同事积极性。业务不调整需求是不可能的，他们是为了满足用户的要求，用户满意了才能给企业带来价值。不过如果调整，代价太大，很多代码要重写，大家就会责怪技术总监或者项目负责人没有把握好需求。

3、团队经常加班，但战斗力不强。核心团队疲于应对需求、技术开发、老系统维护，没时间指导新同事技术学习，而新同事技能暂时还没有发挥出来干活效率低，任务经常延期，没有成就感。核心团队事情很多，没有时间整理项目文档，新员工没有文档上手慢。大家每天很多事情，需要加班才能完成，比较疲惫。每个人除了工作还有很多事情需要做，比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作，他能同意，他家人也不一定同意。让大家愉悦的开发，比疲惫的上班效率要高很多。

4、交付软件质量差，离用户期望差距大。创业时大家的想法都是好的，大干一番，做一个所有人都爱使用的产品。现实是残酷的，大家辛辛苦苦做出来的东西，老板不满意、用户不埋单，付出的努力没有人认可。交付的软件没时间自测试，或者自测试不充分，交给测试又是一大堆问题。有些公司还没有测试，直接出去给用户，相当危险。这样交出去的公司不仅仅影响了用户的使用，还影响了整个公司的口碑。

不是说传统软件开发模式不好，只是不太适合我们这种创业公司。开始尝试其他模式，如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

尝试二，敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。

敏捷开发的主旨：

一：个体及交互比流程与工具更具价值

二：可用的软件比冗长的文档更有价值

三：与客户的协作比合同谈判更有价值

四：对变化的响应比遵循计划更有价值

而我们之前的问题，交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试，先看一张敏捷开发的流程图。

创业公司敏捷开发敏捷流程化

敏捷开发简单流程：

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。（backlog可以理解为需求或者要做的事情）
2、召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog。（sprint可以理解为一个团队一起开发的一个任务集合）
3、把sprint的backlog写在纸条上贴在任务墙，让大家认领分配。（任务墙就是把未完成、正在做、已完成的工作状态贴到一个墙上，这样大家都可以看得到任务的状态）
4、举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）
5、绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了）
6、sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品。
7、最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。

我们怎么结合敏捷开发解决现有项目的问题，要记得任何措施都是为了保证按时按质按量把软件交付给用户，不要为了敏捷而教条实施敏捷，公司不能产生商业价值，任何先进的理念或者技术都是无意义的。我们做了这些措施：

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的，才能被认可。

首先培养测试小妹学习敏捷开发，后续让她承担部分产品责任人和敏捷指导者的角色，原因有：
a、测试要验收功能，必须理解业务需求。
b、测试也是QA质量体系的一块，学习好了对于软件质量有个更深的认识。
c、团队大部分是男生，女生推广更有亲和力一些。
召集所有技术团队开会准备推广。开始和测试小妹好好讨论下，怎么给大家说更有效，更容易接受。她要讲解一定要自己非常清楚敏捷开发，并且准备充分知识点。开会时先指出我们现在问题，让大家看看有什么想法解决问题吗？现在我们做的产品，客户不认可、老板不满意、自己很累没有成就感，有什么办法解决。在大家讨论后，抛出敏捷开发的优势，一般情况下大家都会认可的。大家可能会问到如何执行、落地，可以尝试找一个项目试点，如果实施成功就可以让大家全面推广，不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》。

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说，目的是完成这个项目，需要进行这几步：

先根据各自的能力和意向聚集一批完成这个目标的勇士，不管技术和非技术。如果聚集的人不够，技术总监可以根据总体项目的投入机动调整资源以支持，不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试，除去大家做其他事情的时间，总共可以算作4个人。
充分调动客户（老板和业务同事）参与进项目，他们的参与直接决定了项目成功与否。结合之前的经验，如果他们参与不够，最终做出来的东西就不是他们要的，或者离他们要的差距很大。他们刚开始加入的时候，很迷茫有时会表现的比较抗拒，这个时候一定要耐心坚持让大家把第一个sprint开发成功，使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化，如果有需求变化，就添加任务到任务墙，大家可以对所有任务的时间有个全面了解，如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
技术总监安排和客户沟通，客户这里指老板和业务。测试小妹负责和客户沟通记录，技术总监辅助。多次沟通后，尝试让测试把需求原型用最简单的工具绘制出来，技术总监审核通过后和客户沟通确认，反复迭代，直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行，但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题，过度技术设计产品。
产品设计出来后，召集项目成员分解任务，确定每个任务的时间，可以使用敏捷扑克牌来估计。任务分解尽量控制在 1-2天的粒度，这样大家1-2天就可以做出一个能测试的原型，尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周，不能太长，也不能太短。太长会出现疲劳，太短的sprint会让大家觉得工作太多，做完一个又一个。“项目1”估算结果为120人天，总共投入4个人，需要30天4周时间，我们切成了4个sprint，差不多1个月时间完成，满足业务的时间要求。
分阶段实施sprint，绘制任务墙，划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙，贴到未开始的地方。

创业公司敏捷开发任务墙

每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务，统一管理起来。强调的是一个团体，如果有同事请假，其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，尽量控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
软件开发过程。认领任务后，怎么保证大家开发有质量的代码？团队有资深点的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务，他负责开发团队的概要设计审核，没有审核通过的设计不能开发，并指导大家分析和设计系统。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的，受欢迎的文档只需写出用例分析，表设计，复杂的逻辑需要画出流程序列图。
结对编程。之前这个编程模式被无数人调侃过，其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时，会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时，很多时候都会结对，比如指导新同事、讨论设计模块，而之前这些都没有算在我们的开发工作量里。

创业公司敏捷开发结对编程

项目演示和总结会议。在项目结束后，让所有参与项目的成员都参加，一起演示给客户展示，并解答客户的问题，充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享，并为下一个sprint做准备。

经过敏捷实施后，我们的生产力提高了很多，员工的积极性提高了，业务的参与使整体需求把控也很好，大家沟通多了，30天的任务提前了5天完成。我们多出来的时间，让大家每周有一天或者半天研究自己感兴趣的领域，但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术，最后做完需要写个ppt 给大家分享下。既能让大家做自己想做的事情，也给大家创造了一个互相学习的氛围。

ps：所有的模式都不应该是教条的模式，先进的模式并不是好的模式，适合自己的才是最好的。套用一句俗话：不管黑猫白猫抓得住耗子的才是好猫。

敏捷开发模式流程图相关内容

敏捷开发原则风险大白话学会SSM整合视频教程微服务在线教育平台从设计到实现全流程第2季微服务在线教育平台从设计到实现全流程第1季

原敏捷开发的流程

2015-08-31 20:26:19 fangxin_321 阅读数 4387

SCRUM敏捷开发视频教程

SCRUM敏捷开发视频教程，该课程为你分享SCRUM敏捷开发，理解敏捷的本质，认识中国IT行业对敏捷的挑战，学会让敏捷落地的实用招数。嘉宾介绍：张传波 1. 创新工场创业课程（敏捷课程）讲师 2.软件研发管理佳实践顾问（曾任华为某团队研发顾问） 3. 中国敏捷联盟《ADBOK》（敏捷开发知识体系）项目组成员二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验，亲历“无数”项目，涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域，熟悉软件生命周期的全部过程

10385 人正在学习去看看CSDN讲师

随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.

一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?

先看下面的流程图:

一. 前期准备阶段

有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:

可参考我之前的博客:<<概要设计－－需求定义及描述方式>>

http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html

图2(需求分析格式)

二. 方案评审

这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:

图3(任务分析明细图)

这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.

三. 项目启动会议

正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道

我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.

还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:

图4(作战图示例)

之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.

这就是作战图的优势, 把团队的目标凝聚在一起.

四. 迭代开发

如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.

那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.

在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.

以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的. 所以, 应该想办法让任务风险前移.

当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的.

这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.

在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.

说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:

图5(每日汇报明细)

点击查看大图

这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.

关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.

图7(进度控制超前的燃烧图)

图8(进度失控的项目)

结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.

五. 集成测试

在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.

六. 最后就是发版了.

自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.

http://www.51testing.com/?uid-80857-action-viewspace-itemid-228087

http://blog.sina.com.cn/s/blog_48258fbe0100eehi.html

敏捷开发（Agile）是现在时髦的一个软件开发工程管理方式，其中的很多特征，例如scrum，pair coding，standup meeting等，有很多文章描述，这里我想聊一下敏捷开发中的文档和需求分析。

在传统的软件工程中，无论是瀑布式还是所谓的V型模式或测试驱动模式，基本上需求分析都是要进行的第一步，然后是概要设计，详细设计，编码和单元测试。传统的软件工程对文档要求比较高，而很多公司也为自己做过的大量文档而骄傲，标榜为规范。对于文档量很少甚至没有的软件项目斥之为山寨。

典型的，在这个项目过程中，需求分析占20-30%的时间，然后概要设计20%左右，详细设计也基本上20%左右，编码通常仅仅占10%-15%，剩余的时间机动给测试和需求变更。一旦需求变更——这个几乎是一定会发生的，根据长鞭效应，就会导致一连串的变更，设计，代码和测试，一切都随之变动。最后往往导致所谓的软件灾变。就是软件本身跟不上业务的变动，发布时间一再推迟。

还有重要的一点，就我看到的程序员，几乎没有一个喜欢写文档的，通常把写文档归于无聊，无用的工作。大量的文档任务对士气是一个很大的打击。

在敏捷开发中，号称拥抱变化，在一定程度上，能够降低需求变更和文档对项目的负面影响。

首先，有两点，是我们看待需求的基础：

第一，需求和设计是不能分开的，设计是要实现需求所要求的功能，需求也是在现在技术条件许可下的对期望值的折中。

第二，绝大多数客户实际上并不了解他们的需要，也不清楚他们想要什么产品。这一点，我相信在传统开发过程中，为不断的需求变更头痛的人一定是有体会的。（不过这个你可不要对你的客户说哦，人家会不高兴的）

于是，在敏捷开发中，需求不再是一个一次性的工作，而是一个伴随整个项目进行的，逐步细化的工作。

我们在开发中，设计和需求是混在一起进行的。设计文档有两种，Feature Design，这个可以说是功能设计，也就是类似与原来软件工程中的需求分析吧，另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。

不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析，通常一个一年的项目，这个Feature Design也就10页左右的文档量而已，基本上就是非常粗略地大颗粒地描述要实现的功能而已。往往只描述要达到的结果和效果，对具体的UI，业务流程或者游戏角色等不做描述。

至于Technical design呢，文档量也不大，基本上就是模块划分，接口模式（不是格式哦），关键算法和数据结构等等框架的设计。对具体的数据格式和类型不做定义。

至于费时的详细设计，通常由程序员完成的，在敏捷开发中是真正省略了，是依靠代码的可读性来实现。敏捷的观点是：好的代码本身就是最好的文档。

总之，文档已经很弱化了，基本上就是一个design spec，当然对于软件自身的可读性和注释要求要多一些

敏捷开发讲究的轻量快速迭代。

也就是需求和设计实际上在一起进行的，进行的同时几乎就开始写代码。例如有了一个模糊的需求，就有一个前进的方向，例如可以写一些框架代码，定义一些消息机制和自动机的状态等，写一些接口类，基类，制定设计模式等。

进一步细一些的需求出来，就可以写一些派生类和执行逻辑。继续地，更进一步的需求就会表现在一些派生类上成员和成员函数的添加。就这样逐步细化。

敏捷开发中有迭代（Iteration）和里程碑（milestone）的概念，实际上开发的过程是和用户不断交流的过程，每个迭代基本上指实现一个或几个小Features，甚至是Feature中的一个部分，但是敏捷开发要求保证每个迭代出来的产品是能够使用和能够测试的，这样就可以有基础和客户交流获得进一步详细的需求。换句话说，就是每一吃迭代的工作都有可能得到用户的认可。

每个Milestone可以根据时间来划分，更多是按功能实现的需求的来划分，也就是每个milestone能够推出一个部分满足客户一些需求的产品。

所以在开发中，敏捷开发是一个小量递增，小步快走的过程，需求是逐步细化，设计也是逐步深入的，代码也是伴随这个过程不断生长的。需求分析是作为一个交互的过程，是在整个过程中和design/coding/test混合在一起。

在我们的开发过程中，很常见的情况是最初的feature design只实现了其中70%的功能，但是却另外添加了起初没想到的30%的功能。这也许就是敏捷说声称的“拥抱变化”吧。

这个就是现在时髦的敏捷编程啊，我感觉不错，效率比以前高多了，员工士气也比以前高。毕竟绝大多数程序员是不喜欢写文档的。

好一些的项目管理，往往能够把本项目的alpha测试和debugging的时间和下一个项目的design，甚至frame coding的阶段重合在一起，以最大限度提升效率，或者说榨取程序员的价值。

http://blog.sina.com.cn/s/blog_6296cebc0100pybx.html

敏捷开发(Agile development)

敏捷开发概述

　　敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

[编辑]

敏捷开发的路线[1]

　　图：敏捷开发的路线图

　　Test-Driven Development，测试驱动开发。

　　它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

　　Continuous Integration，持续集成。

　　在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。

　　Refactoring，重构。

　　相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。

　　Pair-Programming，结对编程。

　　在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。

　　Stand up，站立会议。

　　每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

　　Frequent Releases，小版本发布。

　　在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。

　　Minimal Documentation，较少的文档。

　　其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。

　　Collaborative Focus，以合作为中心，表现为代码共享。

　　在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。

　　Customer Engagement ，现场客户。

　　敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。

　　Automated Testing ，自动化测试。

　　为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。

　　Adaptive Planning，可调整计划。

　　敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。

　　敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。

[编辑]

敏捷开发的特点

　　敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

　　（1）敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

　　这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。　　　　（2）敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

　　在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

　　然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。

　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

[编辑]

敏捷开发的价值观

　　实际上敏捷开发运动在数年前就开始了，但它正式开始的标志是2001年2月的“敏捷宣言”（Agile Manifesto），这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的，他们的价值观是：个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对合同的谈判；对变化的响应重于始终遵循固定的计划。

　　个人与交互重于开发过程与工具的原因：一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代的齿轮，但结果却并不成功。敏捷过程是承认每个人都有特定的能力（以及缺点）对之加以利用，而不是把所有的人当成一样来看待。更重要的是，在这样的理念下，几个项目做下来，每个人的能力都从中得以提高。这种人的能力的提高，对公司是无价之宝。而不至于把人当成齿轮，随着时间的推移，人的能力慢慢被消耗掉，最后变成留之无用、弃之可惜的尴尬人物。

　　可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始，并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长，以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待。

　　寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力，合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢，要么大家一起输。换句话说，就是希望开发小组和客户在面对项目的时候，以一种合作的态度共同向目标前进。当然，合同是必需的，但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力。

　　对变化的响应重于始终遵循固定的计划的原因：敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外，用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法，也许今天看起来是必需的功能，明天就会觉得不那么重要了。随着小组获得更多的知识和经验，他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说，一个计划是从某个角度对未来的看法，而具有多个不同的角度看问题是有可能的。

[编辑]

项目的敏捷开发方法

　　敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作；按短迭代周期工作；每次迭代交付一些成果；关注业务优先级；检查与调整。下图是典型的敏捷过程总图，下面介绍其有关的特点。

　　1、敏捷小组作为一个整体工作

　　项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然，尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同，但愿则基本上是一样的。第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。

　　2、敏捷小组按短迭代周期工作

在敏捷项目中，总体上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工作（分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。

　　3、敏捷小组每次迭代交付一些成果

　　比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。

　　4、敏捷小组关注业务优先级

　　敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。

　　5、敏捷小组检查与调整

　　任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对于项目投资最大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，因为两次迭代之间是提供变更的机会，周期太长，变更机会就可能失去；周期太短，会发生频繁变更，而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑，对于一个复杂项目，迭代周期选择4周还是有道理的。

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是：

　　1、至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。

　　2、开发团队具备运作多个产品的工作经验。

　　3、很早就致力于构建和提供内聚的架构。

　　从这个报告中所透露出的信息告诉我们，认真研究敏捷过程对软件项目的成功是非常有意义的，它的意义在于：

　　1）给开发小组的自组织提供了机会

　　经典项目管理就好比一个具备中央调度服务的航空管理系统，这个系统是自治的，而且是封闭的，但现实中更庞大的系统，似乎并不属于中央调度控制系统，但也同样也是有效的。假如我们开车到某个地方，我们可以任意选择所需要的路线，我们甚至不需要准确计算停车，只要我们遵守交通法规，驾驶员可以临时根据路况改变某个转弯点，在驾驶游戏规则的框架内，依照自身最大利益做出决策。成千上万的驾驶者，并不需要中央控制和调度服务，人们仅仅在简单的交通法规的框架内，就可以完成综合起来看是更庞大的目标，很多事情从管理的角度只要抓住关键点，并不需要多么复杂的规则，往往会更有效。随着系统复杂度的提高，中央控制和调度系统面临崩溃。仔细研究交通系统的特点，我们会发现这样的系统中独立的个体在一组适当的规则下运行，并不需要设计每个个体临时变更的方案，而每个个体只需要知道目标和大致的状况，他们完全可以利用自己的聪明才智来决定自己的行为。

　　2）缩短了反馈通道

　　敏捷过程有效运作的另一个原因是，它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候，便需要有一种方法在比较短的时间内发展完善。事实上，所有的过程改进都不同程度的使用着戴明循环，以研究问题、测试解决方案、评估结果，进而根据已知的事实来进行改进，这就称之为基于事实的决策模式，我们都知道，这比前端预测的决策方式更加有效。

　　3）易于集思广益

　　敏捷过程能有效应用的另一个原因在于，它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候，总有某些人员知道问题所在，但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸，事后分析出了各种原因，但这种调查也提供给我们一个惊人的事实，就是部分工程师早就意识到这些潜在问题，却无法说服他人重视这个担忧。对这些事实的深入思考，促使我们研究我们应该采取何种管理系统，使前线工作人员的经验、观点及担忧得到充分的重视呢？

[编辑]

对敏捷开发的误解

　　误解一：敏捷对人的要求很高

　　很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么？软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。

　　从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显着的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显着。

　　敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。

　　误解二：敏捷没有文档，也不做设计

　　这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是“必要且意义重大”？这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写；再如，架构设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人（比如lead）来决定。

　　至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构），使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。

　　误解三：敏捷好，其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。

　　从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目－这恰恰是现在很多项目的共性。

　　因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。

　　误解四：敏捷就是XP（极限编程），就是Scrum

　　XP 和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。

　　即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。

　　误解五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准

　　没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

　　同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不现实的。银弹从来就没有过，在有限的将来也不会存在。