随着敏捷的流行，我们都在追求敏捷这个时髦的词语，感觉在软件行业里面可谓“无敏捷，不软件！”。于是，我们就山寨的山寨，照搬的照搬。由于本人资历甚浅，不懂真正的敏捷是什么，但现在可是深受所谓的“敏捷”所害。

  工作之前，一直对敏捷有着美好的憧憬，然而身处于现在的敏捷环境令我身心疲惫，令我难以致信，于是一遍又一遍的念着《敏捷宣言》，如此优美的句子啊，为何实施起来如此的残酷？

《敏捷宣言》
  个体与交互 重于 过程和工具  
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

   很多公司企图借助敏捷来进行项目的快速开发，应对需求的变化，于是不顾自身的情况实施起来，以Scrum为例，看看如此曲解其敏捷精粹。

站立会议=审问？

  曾经在某处看到国外的Stand up:          而我们的Stand up :            

         stand up1               stand up2                            

   看到这两个图人员的站立形式，一切都懂了。本来站立会议是很随意的，但我们的却是一天中最恐惧的时刻。我们采用问答式，而不是讨论式。L：“你昨天做了什么？”D：“呃~~，**功能还有一点问题没解决。”L：“为什么没解决？那什么时候可以做完？”D：“因为**原因，估计也许大概还要一个上午左右……”

   一大清早给你来个这样的审问，还有什么心情工作？

 

任务墙=甘特图？

再对比这两幅图，艺术的任务墙：          冷漠的甘特图：

mission       project

     相对于左边这涂鸦般的任务墙，右边的甘特图的确让人恐惧，特别对于像我这样的菜鸟，总感觉不自然，一个个明确的进度条显示着你的任务进度。如果进度条每天快速进展则没什么问题，万一从中遇到了一个技术难关，搞上几天都没结果，进度条停止前进，上级还以为你不干事呢。其中的复杂变化，岂是一张甘特图能够表明？

 

敏捷=无文档？

  悲催的是，刚开始工作，入职一个多月，试用期还没过，连续接手两份工作，刚刚熟悉一份又要折磨另外的。没有一个文档，没有一张设计图，甚至连注释都没多少，只有那哥们离开前和我闲聊了半个小时。我心里那个担心呀，就问他：“没有一点文档，我怎么办？”哥们的话很潇洒：“那就看个人的修为了！”。就为这个"个人修为"，我折腾到要哭……

  由于这个文档的不健全，大家闹得热火朝天，从上班闹到下班。出了问题不知道从何查起，因为大家完成了任务，把代码往服务器上签，OK，完事。这样的开发，刚开始的进展是很快，到后来项目庞大了，进展可是缓慢得很，而且很大可能要重写。这样文档不健全的开发，太依赖核心人员了，万一核心人员离职，那可真是难以进行下去了。

 

为了Sprint而Sprint?

  往往把迭代分得很细，没办法，因为版本更新要求很快，可谓是三天一小Sprint五天一大Sprint。我们的工作就是为了迭代那样，往往因为快到迭代周期，大家加班想尽一切办法把功能实现了，而忽视里面潜在的Bug，而往往到后来会为这些潜在的小虫子，付出大代价。

 

杂谈：

  为什么好好的东西一上了岸就变了味？我们喜欢跟风，可要根据自己的实际情况啊，要量力而行，就像最近听到一项目经理说的话“如果连这点文档的时间都玩不起，那干脆别玩敏捷了。”海外的东西是好，回到陆地要用淡水漂上一段时间才能生存的。

延伸阅读

这一段美好时光-Java培训,做最负责任的教育,学习改变命运,软件学习,再就业,大学生如何就业,帮大学生找到好工作,lphotoshop培训,电脑培训,电脑维修培训,移动软件开发培训,网站设计培训,网站建设培训这一段美好时光