首先，我先不解释什么是敏捷开发，先来看一段案例：

A公司的销售部千辛万苦的终于拿到了一个单子，士气高涨，回到公司对技术部说：该项目是如何艰辛的才拿到的，而且后续还有很多的项目，因此必须在1个月内将系统上线！

技术部的一群人顿时懵了，你杀了我算了！

技术a说：我们上一个项目还没完，正在开发，根本没时间做啊。

技术b说：地球人都知道，这种项目就凭公司几条枪一个月绝对是不可能做的完的。

技术c说：上个项目已经连续加班1个月了，都已经开始崩溃了，让不让人活？

技术d说：一定要做？行，我走人，你们另请高手吧！

然后，各方老总出面，经过几轮的会议，基于公司的发展宏观考虑，最后涛声依旧：

技术部接招了……

……

一个月后，技术部的已经整的人仰马翻了，再总结一看：系统都还不能联调！要命的是，销售部的电话来了：系统明天可以上线了嘛？技术部的说：还需要一个月！

一个月后，终于看到了曙光，系统已经跑起来了，虽说磕磕绊绊的，但是总算可以交差了，好吧，系统上线吧！

还好，销售部之前和客户的关系做的不错，上线过程虽说一波三折，但是总算通过了。

但是对技术部来说，工作远没结束！因为之前的未经分析的需求、仓促设计、简单的测试等等导致系统非常的不稳定，为了客户能用，至少得保持一个人全力投入维护。

再三个月后，系统趋于稳定了，但是客户已经非常的不满意了。

故事的结尾是：该系统也只能是一个系统，不具备任何的对其他项目的推广和复用，而且该项目也成了一锤子买卖！同时那个最后的维护人员不堪搽屁股的琐碎以及压力，愤然离职！

（说明：上述故事不带任何感情色彩，绝无褒贬！）

上面的故事，在很多公司都在重复，在此，本人基于对系统开发和集成的心得，浅析如何解决这种问题。

首先：销售部来的单子一般都要做，这是合情合理的；所以，剩下的事就是技术部应该考虑如何通过有限的资源协同销售部共同做好这笔单子！

然后就是：技术部如何才能有效的协同销售部完成呢？在不违背事物发展规律的前提下，我认为解决的办法有且仅有一个，那就是：“敏捷”开发！

那么什么是敏捷呢？在业界，敏捷几乎已经人所皆知。在此引用一段原话：

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

首先，敏捷不是制度（制度有利于敏捷的执行），同时敏捷也不是工具（好的工具有利于敏捷的执行），我理解的敏捷核心就是：迭代+重构+任务卡片+团队。

迭代：将一个项目的需求在和用户明确后，细化，并列出优先级，然后分批次实现！用户依次定期可以看到他想要的东西，并及时的提出修改意见！

重构：根据需要在项目的中后期，重构必不可少，大到一周，小到每天，重构的好处，就是能今早的发现系统的不合理，并及时的修补，项目的前期修补成本是最低的！同时在重构的过程中，用户可以及时的参与到项目中来，（往往用户不能参与项目是因为用户无法感知项目，而并非用户不愿参与！）

任务卡片：这种说法来自于Scrum开发模式。就是说，PM（项目经理）将任务以卡片的形式列入白板之上，每天早上，成员拿走属于自己的任务卡片，表示他完成了改任务！同时在参与过程中，卡片的多少直接表明了任务的完成度！

团队：几个人在一起没有协同、没有共同的目标称之为乌合之众；而团队里的成员是有共同的目标，大家朝一个方向努力。敏捷开发中，往往有很多2~3人的小组，遇到一个问题，3人形成三方表决（3人表决肯定有结果！）；

同时在管理、实施模式上，敏捷明显区别传统的开发模式：

1) 敏捷开发要求成员积极参与、强调成员之间的面对面沟通（而不是眉来眼去的邮件、QQ群消息等）；

2) 站立式5分钟会议！每天早上团队成员在一个办公室，站立面对面的简洁说明自己的任务情况，绝不纠缠细节，细节是项目经理要控制和协调的。

3) 仅仅写必须的文档。即敏捷不要求项目组严格按照某一个流程，详细的编写每一分文档。

4) 敏捷要求好的协同，包括版本的控制和相关的配置管理。

5) 敏捷开发要求团队定期的retrospective（回归、反省）。

6) 敏捷开发中，PM重点是对迭代（实施计划）和风险的控制，并及时将用户信息反馈给团队。

对敏捷实施造成致命伤害有如下几点：

1) 没有一个明确、可行、并取得客户理解的实施计划；往往是一个项目来了后，按照客户的要求，一点一滴闭门造车！（再次说明：客户即可以是销售部、也是使用者）

2) 需求未作分析、更没有优先级的定义。

3) 没有一个较好的易于扩展的框架。

4) 一直不停的在造轮子。

5) 没有定期集成、重构的习惯，不到最后一刻，看不到系统的样子。

回到故事本身，显而易见，该故事中的项目是失败的，如果按照敏捷来实施，会如何？

1) 首先，开发团队会详细的分析项目的需求，并和用户一起理解需求。

2) 然后，开发团队和用户一起列出详细的需求优先级，并告知用户如此这样的好处。

3) 开发团队定义开发计划，明确迭代次数和定期发布产品的里程碑（在此明确告诉用户，在什么阶段能看到什么功能）

4) 然后，开发团队选择合适的框架、搭建基本原型（原型的意义：1.验证架构的合理；2.明确界面的风格和样式）

5) 再然后，团队进入迭代过程，定期集成，定期回归、PM定期check、用户定期参与并反馈，整个团队井然有序，前方一片光明。

6) 最后系统分批次的实施！

如果确实超期了，问题不大，核心功能可以用了，系统可以稳定的跑起来。这总比项目无法按期交付、系统动辄崩溃、系统无法复用强的都。何况系统经历多次集成，证明了架构的合理性、实现的功能也得到了用户的认同；同时也具备了良好的扩展，为后续的项目作出了贡献！如此这样，后续的项目都只是功能的叠加。。。。。。

个人心得就写到这里，想到哪里写到哪里，没有刻意排版！时间仓促，难免有说法欠妥或者有误，请勿计较。最后我想阐明一点的是：真正要做到敏捷实施绝不是一朝一夕的事！

最后附录一段：

敏捷宣言遵循的原则

1) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2) 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3) 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4) 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5) 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6) 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

7) 工作的软件是首要的进度度量标准。

8) 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9) 不断地关注优秀的技能和好的设计会增强敏捷能力。

10) 简单是最根本的。

11) 最好的构架、需求和设计出于自组织团队。

12) 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

13) 当软件开发需求的变化而变化时，软件设计会出现坏味道。当软件中出现下面任何一种气味时，表明软件正在腐化。

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。