推翻传统开发，加入敏捷开发

之前的开发工作一直是以人为本，根本没有繁琐的需求文档，设计文档和详细说明文档，老大也曾让我写过，但是我憋了半天给弄出来一个流程demo ，好吧，其实他手下也没有这些文档，只是某老板不知在哪里看到的所谓软件开发的工艺，让我们也整上一份留作公司备案，可以这项工作进行了长达一年，直到我离开也没有人给他提供了那套厚厚的文档说明书，留存的demo和功能很容易的交接上了，

有人也许会说，作为一个软件开发项目，没有文档说明算不上一个合格的项目，失败的风险很大，但是我一直不认为有所谓的文档就是一切，这个文档到不如一个功能demo，或者演示之类的PPT来的直观，更容易被人接受。在我还没有入行之前，我接触过敏捷开发，那时候它刚出来，个人还在被学校中奉为“经典”的教材毒害着，所以我觉得不靠谱，估计是几个异想天开的人在折腾而已，但是10年过去了，我又拿出来看看，似乎眼睛有光了，着正是我现在需求的，至少是我目前这个阶段需要的模式——敏捷开发，再次提出。

敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。，他们的价值观是：

• 人和交互 重于 过程和工具。
• 可以工作的软件 重于求全责备的文档。
• 客户协作重于合同谈判。
• 随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。
如果认同这样的价值观，那么我以为你的一只脚已经踏进了敏捷开发的家族或者“团伙”，至少我现在认为这样的模式是我想要个的，以人为本，以客户为本，以功能为本，以解决问题为本，而不是以文档文本，有人利用敏捷开发，发现开发效率提高接近50%，那么我有理由认为，这个50%的时间大多都是来自所谓的笨重的文档，它浪费了太多的时间在项目进展中，一个项目被拖的时间越长，那么死亡率越高，到了后期bug修复，功能变动和文档更新将会异步，带来的灾难将是不可避免的。
这里是敏捷的宣言

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

那么当团队中得人员不稳定，项目将如何安全的平移呢？我觉得应该是敏捷的理念来解决这个被称为救命稻草的所谓文档的的东西。

• 以人为核心、迭代、循序渐进的开发方法。
• 软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
• 建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。
  画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

我觉得能把项目分解为简单的功能模块或者具备集成的小项目才是智慧，这些小项目只需要一个图片，或者说明就足矣平移过度。这才是软件开发的智慧，让我们从原始繁琐的流程心中解脱出来吧，让我们的项目活起来，有冲劲，而不是死气沉沉！