敏捷不是一般人玩的游戏

        前段时间，很恼火，桩考考试老是不够，第一次车倒到中间熄火了，而且两次机会都熄火，教练没有交代清楚，让我感到十分的莫名奇妙，后经过不断询问身边的同事以及研究前人的经验，终于弄清楚是离合松太快导致的。第二次考试，按道理来说应该会很容易地过，毕竟春节在朋友指导下练了好几把，至少对车会更加熟悉，包括离合、油门、刹车、方向盘等，但是考试还是挂了，第一次原因是在从左边入库时撞杠，原因正如教练考试前提醒一样：从右边出库时太过了;第二次从右边入库时就撞杠了，原因是没有看清杠或者根本没有看到杆，真让人郁闷。有前两次的失败经验，第三次我就更加全副武装，练车戴眼镜、仔细琢磨每个环节（什么样才算到位）、考前提前到教练场咨询训练，当然第三次过了就比较轻松了。

        言归正传，敏捷与桩考有啥关系呢，其实也有其相同之处，即都是要求非常熟悉规则、熟悉环节。且说，桩考，为了应付考试必须按照教练设计的环节来，而且每个环节最好是到位且不超过，很显然在一个环节中超过太多或者差的太远，那么必然会导致后面环节的偏差。

       从这个角度来说，敏捷也是一样的，敏捷想要顺利进行，必然要求各个环节都做好。尤其是架构设计这一环节，架构设计需要有相当丰富的经验，一方面要读懂需求，另一方面要为后面做保障，我们很多人开发都是同时进行的，其实这一步应该先行且必须严格验证，否则会导致后面滥的一塌糊涂，所谓的敏捷则变成了折腾人的事。

     还有敏捷是一伙技术比较精湛人玩的游戏，因为平常人总是会遇到问题：

     1、持续集成没办法完全执行，即后面的程序与前面的程序变动太大，出现模型、函数名、函数功能不一致，导致测试用例必须重写。

     2、需求增加太多，认为敏捷就是可以不断地接纳需求，殊不知架构不支持增量开发。

     3、特性、用户故事、任务划分不清楚，天天一起开会，整天评什么用户故事，说是评还不如说听个把人讲。应该是特性是用户定，用户故事是SE和架构师去划分，所谓的程序员就管往里塞代码就是，即执行任务（按照架构师的意思添加具有一定功能的代码）。

     4、会议太多、太长，永远找不到开会的主题，总是在那些微不足道地小事上吵个不可开交。