体会客户现场

       敏捷宣言中，其中一点就是强调客户现场。其宗旨是要求客户在开发现场提供业务方面的指导，开发人员重点关注技术方面。如果没有客户在场，则需要提供一个可以充当客户角色的人员，例如软件构架师。最近负责了一个法国的开源项目的外包工作，采用的就是客户现场。
      法方派驻一人在项目组，为我们讲解需求，提供已有模块的技术支持，对开发过程中的不确定的地方进行解释。虽然和法方可以通过skype交流，但是这种面对面的交流无疑是效果最好的，最有效率的，避免了很多容易出现的误会。同时，对于一些已有模块的改动，有人在现场指导，肯定比通过email让人能更快上手。
      好坏是通过比较而知的。以前在HW经历过CMM开发流程。HW的IPD,CMM流程在业内来说应该算是比较规范的，具有一定的代表性。开发组首先从系统组得到DS,以此写出需求分析，这里的需求分析完全是开发人员的主观臆断，并不一定符合客户的真实想法。开发人员也没有途径能得到客户的真实想法。虽然SRS写完后，会召集相关人员进行检视，但是限于相关人员精力有限，能力有限等原因，一般是检视不出什么关键问题的。而且很多需求系统组其实也是一知半解，估计其也没有机会能和客户面对面交流。SRS定后，一般是不能再改了，除非在技术实现上有难度，或者实现结果与设计有出入。另外,HW要求实现要和SRS完全一致，不能有一丝差异。这主要是测试部门提出的。测试部门希望能够降低测试验收的难度，避免出现任何待讨论的东西，这样也可以降低对测试人员素质的要求。这样的话，测试人员的需求验收一般就不用付出太大的脑力劳动，只要对照文档就可以了（验收测试都是手工进行的）。
      因为客户的真实意愿是不知道的，所以就由测试人员充当了客户的角色。测试人员也是本着宁可多一万，不能少一个的原则（他们也有来自下游的压力）。就把这种压力传达给开发人员。这就是开发人员和测试人员不断扯皮的根源。测试人员往往会要求开发人员作出十全十美的方案。殊不知每种方案都是有利有弊的。所以开发人员经常会收到测试人员提出的一些在技术上难以解决的问题。多数时候，测试人员为了不承担责任，不会给出建议的解决方案的，同时，研发人员给出的解决方案，测试人员又认为不可接受。这个时候，如果有客户代表在现场说明，我要的是什么样子。相信一切争论都可以避免。客户真实意愿不明朗，是整个研发体系效率不高的一个重要原因。对于hw这样的大公司来说，每个项目组都有一个客户在现场是不太现实。但是可以派驻和客户交流需求的那个人。一件事情，传的人越多，就越容易走样。每个人都在其中加入了自己的理解。
       目前这个项目，在实施过程中，除了人员的技术水平因素外，没有在业务方面产生任何的误解，冗余，遗漏，在效率方面还是控制的很不错的。
       一直想写敏捷越狱，一直没有时间。要忙的事情太多了。