主题：【原创】闲聊敏捷编程——测试驱动开发（一） -- 代码ABC

小羊现在的项目实践主要在web应用方向，和开发组商量着用了几回“山寨版”的敏捷方法，还是受益匪浅的。就说说我们的山寨版敏捷过程吧。

小羊的理解，敏捷的路数，所谓的拥抱变化，是一个从没有需求到完成需求的过程，需求分析和软件开发的过程是合二为一的，拿web应用开发来说，我们的美工和客户肩并肩坐着，客户说这里要个banner，就出来一个banner，客户说这个button要是黄色的，就出来一个黄色的，客户说页面布局应该是两栏三行，页面就是两栏三行，对于一个一般规模的web应用而言，基本上一到两天结束战斗。

然后客户转战到前台程序员组，还是肩并肩，把页面上每一个交互元素都趟上一遍，客户说这个input丢失焦点的时候，应该在旁边提示输入是不是合法，程序员就随手写一段javascript代码，不管怎么样都在旁边提示一下，以此类推，一个凑合能动的“假”应用也差不多就是三五天的事儿。在这个过程中，后台组的哥们儿就在旁边站着，记下来每一个能动的玩意儿应该怎么动，行话说，叫用例吧。

到这里，客户可以退场了，开发组开始写测试用例，顺便说一句，如果稍微NB一点，跟着前台程序员观摩的时候，测试用例已经写的差不多了，从用例抽象出数据模型，然后找来玩儿后台数据库的，提出自己的数据模型需求，等到系统数据模型建立完毕，再找来前台程序员肩并肩，这个时候是前台程序员说需求了，前台的兄弟说这块儿我要一个包含什么内容的json,后台的兄弟就写一个controller返回一个包含什么内容的json，模型层满足不了controller的要求了？没关系，那哥们儿就在旁边一米远，立马改。完了跑跑测试，测试ok之后，不仅单元ok了，实际上集成也ok了。

最后一关，交活儿，客户就是不花钱的集成测试员，直接抓过来让他点鼠标，美工和前台程序员坐旁边，小修小改，顺带着就把浏览器兼容性问题解决了。

至于大的页面和功能调整，目前还没有碰到过，感觉整个过程中，用户也在根据面前的原型不断的调整和表述自己的需求，是一个思考固化的过程，所谓大的调整其实已经分解成了若干个小的需求。

同时，眼看着一个应用程序从无到有展示在自己面前，无论是客户还是开发人员都反映挺有成就感的，而且快速的需求——实现反馈会不断的增强用户和开发人员的信心，客户最后点鼠标的时候就是最high的时候，小羊一般在这个时候会找来业务人员，等客户high到顶点的那一霎那，就把项目验收确认书的字儿也签了，嘿嘿。

总结这个过程，小羊的心得是————要想玩儿的爽，客户要配合，需要客户配合，就得让客户有热情，要让客户有热情，关键是快速的需求——实现反馈，为了快速的反馈，就必须：

第一，开发工具必须能够快速的建立原型，快速的修改并且反馈结果，html,css,javascript,ruby,php,python这样的都行，java那样的就算了，building过程就能谋杀掉客户的所有耐心，要是完了再抛出几个错误，把戏就不用玩儿了。

第二，需求的获取、传递和使用要讲究传递的层次和传递过程中的解构，客户是消息的源头，美工、前台、后台、建模都是消息的消费者，消息的消费者各自从消息源获取对自己有用的消息，同时信息传递过程中，需要“翻译”的要求越高，距离消息源就应该越远，基本不需要加工的直接传递，像页面、前台，没什么专业术语，平时说的就是人话，就直接从客户处获取；稍微需要一点翻译是后台程序员，列席客户和前台的交流，记录用例，他真正需要的信息是前台程序员传递过来的；距离最远的就是建模，他完全不参与和客户的沟通（沟了也白沟，鸡同鸭讲），他仅仅从后台程序员处获取信息。

第三，由于需求信息分层传递和各取所需的设计，整个系统架构就必须充分解耦，当然这个是系统设计的正常要求，只不过如果使用敏捷编程的方法，就变成了强制要求，要不然经过这么复杂的反馈过程，项目足以成为一个超级焦油坑，不可收拾。

第四，项目组人员越少越好，敏捷编程对于项目人员的要求还是很高的，靠翻文档写代码的不成，打字慢的也不行，尤其是后台程序部分，要在客户和前台程序员建构系统原型的时候就做到对用例和功能模块心里有数，要求不是一般的高，项目成员——尤其是参与信息的获取和传递的——一块短板足以搞垮整个项目。越玩儿敏捷编程，越发现适合小项目组，最好就一个牛人，和客户商量着就把事儿办了。

总而言之，小羊觉得，所谓敏捷编程，就是以我万变之不变，应对用户不变之万变，只要我写的快，改的稳，管你千变万化我都不怕，所以，敏捷编程，小羊觉得于其称之为软件工程的方法论，不如说是对软件业界的一份QA指南，对于语言、工具、分工都提出了自己独特的要求。