敏捷模式到底是好是坏

大约七八年前，异常敏捷开发的风暴席卷了中华大地。这几年中，敏捷的理念在各大公司落地，改变了开发者中瀑布开发模型。敏捷讲求持续交付，每一个迭代都去交付一定的价值，将项目开发的风险降到最小。

以下为敏捷开发的价值观：
人和（人与人的）交互 优先于过程和工具。
可以工作的软件 优先于求全责备的文档。
客户协作 优先于合同谈判。
随时应对变化 优先于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

敏捷开发原则：
对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
可以工作的软件是进度的主要度量标准。
敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
对卓越技术与良好设计的不断追求将有助于提高敏捷性。
简单——尽可能减少工作量的艺术至关重要。
最好的架构、需求和设计都源自自我组织的团队。
每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

实际上，在现实的开发中，敏捷还是会出现一些问题的。
1. 需求人员不清楚哪些需求是重要的，哪些是不重要的。每一次迭代需求人员都会进行需求交底，如果需求人员对需求的重要性误判，很容易导致开发人员回炉返工的现象。因此在项目前期调研的时候就应该把需求的大概情况讲的基本明白透彻，如果把项目比喻成一个项目比作一个大树，那么我们就应该让主干先生长起来，如果只顾着对界面细节等进行修饰，那么后期大树一定不能够长得太高。如果主干长得没有问题，那么树叶终有一天会长得很漂亮。
2. 项目中涉及到结构和流程的需求都是非常重要的，就好比一栋大楼，如果本来就打算盖三层，后来需求突然要变成十八层，那么地基就是问题。如果强制要再只支持三层的地基上盖到十八层，那么对地基进行加固改造将是一项非常复杂的工程，而且不能够保证项目能够成功。因此需求把关非常重要。凡是涉及结构和流程变动的，都是复杂的，难以实现的。
3. 敏捷是一种理念，但是开发实战过程中瀑布模型还是有一定的借鉴意义的。比如从项目的整体周期来说，还是应该分为需求分析，开发，测试，验收，维护等流程。只是在每一个流程中，再使用敏捷的思路来解决问题。每一种开发模型都不应该死板的拿来主义，而是应该在业务的基础上根据业务需要灵活的配置项目管理方式。

希望大家喜欢。