对敏捷开发的误解（每天响应不停变化的需求就是敏捷？）

我曾经参与一个软件产品开发，高层管理者（兼系统分析员）每天都有新的Feature源源不断地交给开发人员。而且要求在很短的时间内实现新Feature（往往就是一天）。

好处是高层管理者每天都能看到项目的进展（每天新功能都被加到产品里），但是开发人员压力巨大，疲于奔命，怨声载道。高层管理者说这是 敏捷开发。 因为产品每天都在“敏捷”地变化和前进。

 

真的是这样吗？

拥抱变化是敏捷开发的特征，并不是说想怎么变就怎么变。

 

敏捷开发中，特别强调软件设计的可扩展性，例如软件设计要符合开闭原则。

设计的时候要能预先考虑到某一个方向的变化，这样才能留出相应的接口，才能抽象出容纳变化的整体框架（往往表现为接口或者抽象类）。

 

如果发生了预先没有考虑过的方向上的变化，往往得重构代码，重构接口，抽象类，基类等，以容纳新的变化。这种重构在时间进度不是很敏感的情况下，项目技术负责人和开发人员有时间做重构，这没有问题。

但是现实情况往往是：

 1、进度压力很大，开发人员没有时间去重构。只能用打补丁的方法去容纳新的变化，在代码中往往就是在原来的代码里嵌入比较多的 if 条件判断语句。

 2、久而久之，if 语句越来越多，条件判断越来越复杂，程序结构越来越难以理解，等到即使有时间的时候，开发人员也不愿再去重构了。因为重构的难度太大了。

 3、重构和人的责任心，管理的控制力度，软件设计能力，甚至是人当时的情绪有关系。

  有很多情况下，限于时间和人力因素，可能没有人去review代码，那么程序的结构和代码的质量完全掌握在 写代码的人手里，如果这个人的责任心不强，或者 这个人当时的情绪被外界影响，或者软件设计能力不强，他就不会去重构代码，那么隐患就隐藏在里面了。

 4、管理人员市场人员只看功能和界面，不管程序内部的结构。

  的确，用户根本不管程序内部的结构，用户只管使用软件，但是软件的结构的影响却很深远，虽然一时半刻看不出来，但是随着用户使用的深入，需求的变化，结构混乱的程序维护成本急剧上升。并由此特定情况下数据不准确，用户的抱怨，人员流动，士气低落，不断地救火。所以从本质上看，程序的结构和客户，公司管理层甚至是公司的每个人的利益也密切相关，理解了这个道理， 对于不断地提出需求变化，并要求立刻响应的高层管理者，也应该对此三思而后行。

  5、每天不停地讨论和研究新Feature非常浪费开发人员的时间。

  在我参与的项目中，基本上每天都要花上午最宝贵的2-3个小时去讨论新需求，新Feature。严重占用了本应该用来开发的时间。造成不断地加班。

 

不论多么敏捷，必须要给开发过程一个阶段，即在一个阶段中（1周-1个月）之内，需求相对稳定，即使需求变化，也是在软件框架内可以 “容纳”的变化，而不是想怎么变就怎么变。

有了稳定的阶段，开发人员才有整块的时间去写代码和单元测试代码，去重构软件，而这才是提高开发效率，加快开发进度的关键。