【IT168 分析评论】

    想省掉一些功夫，必须是知道有某种因素存在，所以可以省去，绝对不能忽略风险，贸然地取捷径。

    许多团队的开发流程，看似井井有条、制度完整，但流程中所规画的活动，无法在开发参与者的进行下，达到它应有的效用。很容易让开发人员产生一种负面的印象──开发流程的活动不过是表面文章、敷衍了事、徒做虚功。也让许多开发者，对于开发流程的活动敬而远之。

    不认同徒具形式的流程，许多团队转向轻量级方法论

    因此，在光谱的另一边，也有一类团队，尽可能地裁减所需的开发流程活动。这样子的团队，多半是以开发人员为主的团队，对他们来说，程序撰写以外的工作几乎都会被归类为“额外负担（Overhead）”，就像我们很常见到的，开发人员视写文档为额外负担，因为文件的内容往往不能直接转换成为代码，而且有时候甚至和代码的产出一点关系都没有。

    对他们来说，开发想要更有效率，就要尽可能减少额外负担。当然，文挡的撰写肯定是他们首先要打倒的万恶罪魁，非到万不得已、山穷水尽的局面，绝对不撰写任何文档。

    我甚至看过有些团队的管理者，认为版本管理活动是一种额外负担，因此，虽然他们也设置版本管理服务器，但是，开发者并不利用它进行版本管理的活动。这某种程度算是管理者体贴开发者的一份心意，因为管理者希望让开发人员专心撰写代码，尽量避免其他活动干扰到这最主要的工作。

    对这类的管理者来说，追求制度不过只是形式上的表面功夫，事实上，里子更胜于面子，产品应该以更有效的方式开发。为了达成这目的，应该尽量摒除各种额外负担。

    尤其近来轻量级的开发方法大行其道，这更让这类团队找到一个依靠，当中有许多人宣称他们自己是轻量级的开发方法，因为他们摒除了许多开发流程所带来的额外负担，所以他们认为自己的开发方式轻盈无比。

    XP有12项准则，不能只选甜头，忽略苦差事

    我曾经听过不只一位朋友说过类似的话：“我们采取的开发方法是XP（eXtreme Programming），我们的交付周期很短、需求也变更得很频繁、甚至没有太详细的需求记录文件，几乎不做细部设计。”这看起来，应该算是误解了XP，而且只从XP挑一些对开发人员来说是“甜头”的东西出来实行。

    怎么说呢？XP有12项施行准则，其中有许多准则是互为支持的。例如，倘若你希望小版本的持续交付（也就是说，需求能够变更得很频繁），你得强化单元测试及重构。因为当你的需求变更频繁时，自然造成代码的变更频繁，倘若没有足够的单元测试做为后盾，那么变更频繁的代码，势必经常地造成副作用，对程序的稳定度造成很大的冲击。同样的，倘若没有持续地重构，那么代码最后也会形成叠床架屋的情况。

    小版本持续交付是甜头，因为提出需求方可以很快看到自己的愿望被实现。允许需求变更频繁也是甜头，因为这使得提出需求方能更快地反馈他对开发成果的修正意见。

    但是，许多号称是采用XP开发方法的团队，都不做单元测试，他们也不持续重构，因为这两个工作都是苦差事。单元测试的确是苦差事，在XP强调“测试先行”的情况下，还没写代码之前，就得先写好测试用例，而且每个代码单元都应该搭配相应的测试用例。要开发人员养成写这类用例的习惯，简直比要他们写文档还要命。

    重构也是苦差事，不仅许多开发人员不具备重构的技巧，即使具备重构的能力，也抱着“做好的事，何必再改变”的心态，对于整理代码渐渐产生的遗毒，始终兴趣缺缺。像单元测试及重构这类工作，在许多人的认知里，都是对开发人员的某种“额外负担”。

    所以，许多团队其实是挑软柿子吃，他们的眼里只看到可以抄捷径的地方，却没有在意这些轻量级的开发方法之所以能抄捷径，是因为有其他的配套。

    比如，XP之所以允许对需求的描绘尽量精简，是因为施行准则中有一则是要求客户和开发团队位在同一个地点，因此，客户能够很快看到系统的面貌及行为，也能够面对面和开发团队沟通，减少了所需的文件。倘若没有客户的条件配合，那么过于精简的需求描述方式就会产生极大的危机，因为开发团队对于需求产生误解的机会就会大增。

    徒具形式的开发流程可怕，半吊子的轻量级开发也很凶险

    徒具形式的开发流程固然可怕，但半吊子的轻量级开发也是凶险异常。这样子的开发，表面上似乎提升了效率，但是，骨子里付出许多隐形的额外负担。例如，节省了撰写需求规格文挡的时间，却没有搭配客户的配合，使得开发团队不能准确地捕捉客户需求，因此，时常在开发完成后，客户才发现不合预期，引发更多的修改请求，白白浪费开发的力气。

    又例如，允许频繁的变更，但又无单元测试及重构的活动与之相对应，因而导致修改程序的副作用频繁发生、品质降低，代码架构也渐渐趋向叠床架屋。表面上，开发团队节省了一些功夫，但是无形中可能损失更多。

    有些开发团队由于成员中的开发人员技巧高超，所以即使缺乏某些相对应的配套活动，整体的冲击有可能不那么大，显现出来的负面效应也不明显。但这不意味着抽掉这些活动，对所有的团队来说都是适宜的。

    若要略去轻量级开发的某些活动，必须有其他条件配合

    开发流程是用来辅助开发团队迈向完成目标的一个工具。开发流程中的活动，某种程度来说算是一种额外的成本，但也是投资，我们希望投入一些力气，使得开发的整体成本降低，品质也维持。

    理想的情况下，这个额外的成本自然希望能够降到最低，但又能维持整体成本最低、品质不变（或变得更好）。轻量级的开发，便是希望能够降低投入的成本。

    降低因为开发流程活动而造成的损耗，大方向是对的。但是，究竟能节省那些活动，必须根据所面临的环境、开发的标的物，以及限制条件（包括人力的多寡、素质）决定。

    当开发团队决定采取较为轻量化的开发时，最好先对一般较为重量级的开发方法有基础的认识。因为所有开发方法的发明及设计都有动机，而开发方法中的活动安排也都有原因。你在轻量的开发方法下，之所以能够略去某些活动，必须是因为有其他的条件或是辅助的活动可以相对应，才不致于引发问题。

    开发团队在选用一个开发的流程时，无论轻重与否，都应该根据目前所处的环境及目标，设定开发流程所应具备的条件。例如，开发流程究竟要不要管理需求的变更？你必须知道，要管理需求变更，究竟会付出的代价以及获得怎样的好处。倘若决定不管理需求变更，那么可以省掉多少力气？又会增加多少潜在的风险？而这些风险以该项目的环境及条件，是否可以降低或是接受……