如果QIR能够换回项目成功,我愿用一生敏捷

　　何为QIR，就是快速原型Quick Prototype 迭代Iterator 重构Refactor.

　　敏捷软件过程大家都叫了这么多年了，Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (Agile UP or AUP), Crystal, and Dynamic Systems Development Method (DSDM)每一种其实都是针对特定的问题提出的。当然每一种方法都有他的用武之地。

　　不过我觉得敏捷最核心的概念，或者说需要实践的地方只有三个，那就是QIR。
只要这三个概念能掌握好，其它的敏捷方法就可自然贯通。

　　1 快速原型
　　原型大家都做过，通常的意义就是设计程序的界面。有人用Visio画原型，也有人用HTML设计简单的页面。

　　但是这样设计出来的原型通常意义不大，我这么说的意思是，通常这些设计好的界面图对项目的真正开发只能起一个很小的参照。光是这样的原型是不够的。

　　什么是快速原型？为什么说需要快速原型?

　　在这个对项目进度要求越来越高的时代，软件开发周期内的每一步都必须发挥最大限度的作用，这就好比起跑时候的起跑动作，赛车发动时候的占位等等。每一步都要为后续步骤做铺垫。

　　快速原型开发不仅仅是设计界面，而是通过在设计界面的过程中，也能完成所有系统数据表的设计以及编写好常用的测试数据。也就是说设计界面的时候，心中要想到这些数据在表中如何存取。设计表的时候也要想到这个结构在界面上怎么呈现最舒服。原型还需要有简单的代码支撑，这样我们就可以看出来这个原型那些设计的不合理。

　　带着这个思想去做，我们发现在原型设计阶段，我们就已经开始对原型进行迭代和重构了。

　　这样原型就不简单的是画界面了，原型就要求把框架，数据库全部都连上。如果我要展示一个表单，不能仅仅画一个html的表单，而要实际的把里表的测试数据从库里面调出来。这样就会发现，原来某些表单项可以通过冗余字段来实现，某些表单项必需要弹出窗口来选择。

　　当然这样对原型设计者的要求就比较高，原型设计者必须熟悉常见的界面设计模式，数量掌握各种软件，包括桌面，web的界面设计技巧，还要懂得数据库设计的知识等等。对于大项目为了实现快速原型设计，这个工作就不是一个人能够完成了。因此整个团队必须对设计的每一步过程都共享。团队必须能毫无成见的交流，leader要能采纳好的建议，给出最佳决策。

　　人们都说好的开始是成功的一半。其实好的原型也应该是整个项目成功的一半。

　　2 迭代
　　迭代要实现敏捷，首先要具备的因素就是快，如果没有快，迭代就是增加你额开发成本。

　　既然要谈到快，一个重要的前提就是，项目最初的模块调最核心的做。代码用最简单的实现方法。

　　例如一个CRUD有四个操作。既然要快，我们就只实现CR。代码中如果需要复杂数据结构的，我们先用一个长的hash表来存储。查询界面我们先给出几个固定的测试值。

　　这里就对项目完成的监控提出了考验。因为我无法按要求每天完成n个模块。也许有人会觉得这样不好。但是，请你想想，一旦你开发过程中客户需求发生变化了，你需要重新修改字段，界面的时候，正因为原来的设计都很简单。因此可以大方的将那些代码抛弃。你付出的总的代价就最小。

　　所以这里关键要有一种放的下的勇气，告诉你的代码，先这样吧，I'll be back!

　　3 重构
　　重构和迭代其实是密不可分的。其实QIR的三个过程都是密不可分的。对一个你从来没有接触过的行业来说。你开发的产品一定要经过两次大的重构，主体架构才会趋于稳定。不要问我这个两次是怎么得出来的。等你自己做过你就会明白，这是两种不同思维的人在一起碰撞产生的。

　　用最简单，最愚蠢的方法，把程序先运行起来。等闲暇的时候再慢慢过来重构。当然也不能太愚蠢，你的初始代码也必须具有一定的可重构性，也就说也要遵循一些基本的模式。举个例子，如果你的CMS的导航结构SEO的URL设计的很好，那么你后面重够的时候就会很方便。

　　当然不管什么方法论，如果你完全没独立开发过项目，那都是白谈，因为你不可能理解其中的精髓所在，只有你亲身体验了，你才会明白其中的奥妙。

　　团队之间必须积累开发经验库，所有以前开发过的项目，模块都应该可以共享，可以让每一个人作为参照。

　　每一个人都必须具备广才，就好比一只足球对，如果每个位置的人都可以进攻，那么这个球队就相当让人敬畏，例如荷兰的全功全守。

原文转自：http://www.ltesting.net