敏捷方法可以用来开发产品软件吗？

秋高气爽，我忽然有个一个很好的想法，就是用敏捷方法来开发产品软件，今天我们知网郑州软件公司就来谈谈这个思路。

       像Scrum这样的敏捷方法的确解决了许多困扰软件团队多年的问题，但是多数产品经理、用户体验设计师、测试人员，对敏捷方法持怀疑态度，不确定自己应该扮演什么角色。毫无疑问，实施敏捷方法绝对离不开这些人，出现这种情况是因为“原始’’的敏捷方法并不适用于研发产品软件。我发现解释敏捷方法的起源可以帮助人们理解它的适用范围。

   
       Scrum于1 9 8 6年诞生于日本，距今已有二十多年的历史，许多人对此感到惊讶不已（这又一次证明了，新观念要经过很长时间才能被人们广泛接受）。值得注意的是，这些方法起源于定制软件领域，而不是产品软件领域。

       长久以来，开发定制软件困难重重。原因之一是，虽然需求确实存在，但客户通常不知道自己想要什么。他们与软件公司签订合约，把自己的需求告诉开发人员，由开发人员自行开发。等到交付软件时，客户往往发现到手的软件和想象中的相差十万八千里，于是又要求开发人员修改，如此恶性循环，客户屡屡失望而归。但是由于刚性需求一直存在，所以开发人员、软件供应商、相关专业服务机构不必担心没有生意做。

       另外，定制软件领域长期以来很难招聘／留住顶级的程序员。部分原因是顶级的程序员更喜欢为成千上万的用  ：户开发产品软件，因而选择在产品软件公司工作。而且产品软件公司能提供更具竞争力的薪资待遇。产品软件公司  ：必须开发出满足大众需求的产品，否则就得关门大吉，他们懂得只有用高薪吸引顶尖人才，推出优质的产品，才能  ；获得高额利润。所以，多数资质普通的程序员留在了定制软件领域。 

   
       定制软件的客户认为自己了解自己的需求，所以不需要什么产品经理。他们也不需要用户体验设计师，这个原因更复杂，主要是客户不理解什么是用户体验（在定制软件领域几乎没人认识到用户体验的重要性），以及对成本过于敏感（让开发人员设计产品可以节约成本）。另外，用户体验设计人才极度短缺也是不能忽视的原因，即便定制软件公司意识到用户体验的重要性，也很难招聘到合适的用户体验设计师，因为他们早就被当成“香饽饽”被少数几家大公司抢去了。同样，定制软件项目里也鲜见测试人员，本该由他们完成的测试工作都被开发人员包揽了．

   
       定制软件的另一特点是大多数项目规模较小，一般用来支持公司内部运营，比如人力资源、财务、生产系统，有限的用户数量使得可扩展性和性能表现通常不受重视。

       以前，定制软件领域常使用瀑布式开发方法这样做是为了便于客户监督漫长的开发过程。实际上，瀑布式开发方法也同样源于定制软件领域。

       产品软件必须在各方面都尽量做到完美，才能赢得市场。所以必须由产品经理负责收集广大用户的需求；由用户体验设计师创造完美的用户体验；  由测试人员测试产品，保证软件可以像广告里说的那样正常运行。

   
       敏捷方法极大地提高了开发定制软件的效率：增进了客户和开发人员之间的交流；通过更频繁的迭代来大幅度降低风险（客户可以更早看到阶段性的产品，再不必等到整个开发过程结束）；引进了现代软件测试的理念；省去了撰写连篇累牍的产品说明文档的麻烦（这些文档实际上少有人阅读，很快就会被束之高阁）。

   
       我认为敏捷方法同样适用于产品软件的开发，但应用时应该做出相应的调整。我曾经写过相关文章（如何在开发过程中加入用户体验设计，如何管理产品的发布和部署）。敏捷方法唯一不适合产品软件开发的地方是在架构设计方面。

        敏捷方法鼓励开发人员不要拘泥于传统的开发流程，要相信简单重构和快速重新设计架构的优势。这对多数定制软件来说是可行的，但对产品软件系统（比如针对成千上万用户的大众网络服务）而言，这个想法就太天真了。

   
        所以，产品软件团队使用敏捷方法时遇到问题不足为奇，主要是因为他们照搬了定制软件的敏捷模式。至今多数介绍敏捷方法的图书、文章、培训课程依然不涉及产品经理和用户体验设计师（交互设计师和视觉设计师）的作用，因为它们针对的读者群还是定制软件团队。

   
       要想成功转型成为敏捷开发团队，选一位合格的敏捷教练相当重要，他必须理解产品软件与定制软件的差别，了解产品软件的特殊需求，而这正是多数人不明白的。

       希望我上面所谈的一些见解对于大家在从事郑州软件开发的人们有一些启发。
       
       关注成功，关注未来，关注知网郑州软件公司（www.nwisdom.com)