最近参与了一个采用敏捷开发的项目收获很丰富，也学到了不少的新东西。在这里结合以前所做的项目在这里写一下自己对敏捷开发的一些体会，与大家探讨项目管理的经验和方法。个人认为：敏捷开发其实是一种思想，并没有什么具体的规章和制度。主要是要省掉开发过程中不必要的交流、文档、管理，把资源最有效的用到满足用户需求和体验的目标上，使项目可以快速灵活的进行。如果把原来传统的瀑布开发比作兵团作战的话，那么敏捷开发就更像是特种作战。
最近这个项目整体规模不小，也很正规。有敏捷教练、站立会议、看板、故事墙…,论条件和资源来说应该说是比较正规比较好的。但就是感觉有点机械式的模仿成功团队的敏捷开发模式，由于团队成员的经验不足以及对敏捷开发认识不透彻。最后敏捷开发就成为需求随意变更的借口和项目组成员长期没日没夜加班的原因。各类站立会议、看板、故事墙等都沦为增加项目组成员工作量的形式主义。当然由于公司支持，资源投入很大，最后项目还是能够正常完成项目的。但这样的项目估计项目组成员没有人想再做一次了，敏捷开发也会在参与项目的所有人心里留下很大的阴影。
好了，令人失望的案例我就不多说了，不然又被说老散播负能量了。说个我认为比较好的案例吧！
其实敏捷开发是一种高效，迭代的开发模式，只要在合理的范围得当的使用会给项目带来很好的结果。所以说武林秘籍也不是对谁都有用的，不是高手练了很容易走火入魔。以前负责的项目有些在原理和思想上也有敏捷开发的，而且这些项目多是比较困难，没人愿意接手，把我顶上去的（为了能愉快的聊天，别问我为啥！），而对于非常规的项目我也只能用非常规的做法了，也感谢公司能容许我这样做。
以其中一个项目为例，项目的基本情况是：用户对该项目不是特别了解，不知道要做成啥样也没把握做成，所以拿出点资金来找我们公司试试水，看情况再扩大规模。而公司的对项目的期望很高，希望能做好以引出后续一系列的项目，这样项目就面临几个问题：
- 时间很紧，用户那边迫于压力希望能尽快看到结果好做下一步计划，从我们的角度如果不尽快拿出东西的话，用户那边的变化会很不确定更别说后期的项目了。
- 系统要尽力满足用户的需求，但需求又不能无限制的变化，否则项目时间也会加长。
- 就是对用户的需求要快速反应，这样才能使用户对我们的团队甚至是公司的技术实力产生信任。
当初我们采用的项目的思想其实就是敏捷开发，但在公司看来这是一种非常规也不正规的做法，却不知道自己不知不觉与国际接轨了。哈哈，真是造化弄人啊。
- 关于文档：项目过程中对公司流程上要求的但项目组认为不必要的文档全部省掉，等到项目结束后会以最终程序为版本为满足公司流程补上。但对程序的架构要尽量确定的，一定意义上可以说系统架构是不能变的，这需要程序设计人员在设计过程中充分考虑变更。因此后期很多需求变化我们只需要改变一下设置就可以实现，却实现了很多用户的关键需求。另外需求变更也是有严格记录的，有专门的文档，确保每次变更原因可以追溯、系统工作量可以计算。如果期间发现变更太多、太大则尽量将其列入下一期的版本中，保证系统预算和项目时间可控。
- 关于人员：团队主要人员严格挑选，基本上在业内都有十年左右的工作经验，这样沟通起来基本无障碍，也很少会出现没有详细的文档写出东西就会有偏差的问题。你要是有低级问题不懂还真不好意思问，自己查资料吧，哪好意思浪费大家时间呢。偶尔的争论和纠缠也一定是会碰撞出新的火花会出现迅速解决问题的奇思妙想。
- 关于会议：正式会议也有，但很少。多数像敏捷开发里的“站立会议”，但基本上是在吸烟室做的，但不限定人员和时间，也不一定是站着（这得看吸烟室是否有座），这样不会把大家的时间浪费在无用的会议上。而且在哪里讨论问题，还其他项目组交流项目建设情况和经验。这样我们经常“亲切友好的气氛中”找到了解决问题的方法。偶尔有必要我们会找间屋子把相关的人叫进来边抽烟边讨论。如果出现由于某人争论而情绪比较激动情况，我们递上一支烟拍拍肩膀立马气氛就正常了，团队内真正实现了和谐有效的沟通。而且这种氛围一般是比较轻松，能够快速把问题说清楚。不像在办公室里坐在一起拿着笔记本开会，让人那么紧张，顾虑。
- 关于需求交流：还有就是与业务人员的交流，我作为项目负责人和接口人与甲方沟通是非常频繁，绝不仅限于正式的汇报和演示。那时我几乎混成业务人员了，很多时候参加他们内部的会议。这样既可以及时指导他们的建设思路，同时也向他们学习业务知识和了解迫切需求。所以我们需求获取才会准确高效。更重要的是这样最后就是我们与甲方共同认可的建设思路，他们也有更高的积极性参与后期系统的使用和优化。
这个项目在时间短，很对因素不确定的情况下，基本实现了既定目标。以我个人的一些经历一下几点体会：
- 敏捷开发对人员要求很高，无论是能力还是责任心。
敏捷开发会省去很多繁琐的文档和沟通环节，但这需要团队成员有很好的理解能力和沟通技巧；成员对项目整体有能对任务整体有全局观；而且系统架构要充分考虑变更；这绝对不是随便找几个人就能做到的。没一定的项目经验最好还是把文档认真写完，然后按传统的瀑布式开发比较好，不然你将陷入无休止的争吵和扯皮当中。
- 采用敏捷开发不能拘泥于形式，采用自己最适合的方法才是王道。
个人觉得敏捷开发是一种思想而不是制度，所有的方法最终的目地都是高效并保质保量的完成目标。你需要确定最适合你的项目制度和方法来实现践行敏捷开发的思想；不是所有板你都要画，不是所以的文档都能省；也不是所有的东西都可以不确定和迭代的，否则你将会在行进中迷失方向。
- 不是所有的项目都适合敏捷开发。
如果你的项目有确定的需求和目标；如果你项目的时间充分；如果你团队里大部分是毕业生或入行不久的新手；建议还是规规矩矩的做项目。把文档写好，把事情交代清楚，让项目按部就班的完成，有时候正常进行本身就是一种成功。