|
既然敏捷开发说是“交付客户价值”而非文档或代码的，那么一定能改善营收或其他运营指标。项目管理者联盟
比如市场占有率，每日点击数，平均在线人数，每活跃用户收入……等等，这些营收应该都是做敏捷度量的人所需要关注的。Scrum设置了PO来收集、描述、排序最重要的需求，又安排团队在自组织下高速生产出来，通过评审会后交付给客户。因此如果这一切都是真的，没有理由在实现敏捷开发后业务营收不变或下滑。当然可能很多因素制约了企业的营收情况，但如果既不度量也不关心，直接来一句“由于情况很复杂，因此企业营收与研发没有直接关系”，显然只能被作为自我否定和消极逃避的借口。项目管理者联盟
现在有些团队如网络游戏和搜索引擎公司，已经把这些数据引入了开发团队的度量中。但一般不做绩效考核，而是让大家知道最近我们的研发在市场上的实际反馈如何。项目管理者联盟
四、内部创业项目管理者联盟
任何时候想度量的时候都要问：为什么要度量?答案是：度量的目的是为了改善目标。项目管理者联盟
那么如果说企业的终极目标是盈利，而却有一种方法不需要度量就能提升盈利，那么应该怎样?当然就不用度量了!目标永远比方法要重要。项目管理者联盟
比如现在网络游戏团队普遍有一个政策：20%的营收归项目作为奖金。一般这个数字从几十万到上亿的规模，而团队往往不到100人。他们不在通过繁杂的绩效考核系统中的度量项发放奖金，而直接把收入变成开发人员的动力。这种方法跳过了所有繁琐的度量过程，直击问题实质，是一种不度量而改善目标的典范，可以理解为敏捷开发“可运行软件超过繁琐文档”这种尝试弱化中间过程的思想的产物。项目管理者联盟
当然，即使不能“内部创业”，也一样能做到类似的效果。比如降低程序员的基本工资，代之以把公司产品销售的一部分钱拿来做奖金。程序员自然就开始关心客户需求，尝试理解客户到底要什么不要要什么，尝试自觉改善质量防止客户流失，尝试自己带徒弟以便让团队成长进而增加产品竞争力……很多效果是通过度量都难以进行改善的。项目经理博客
最后这个问题的答案，其实回到了问题的本质：敏捷开发提出的目的，其实还不是敏捷宣言中的那四句话左侧的部分(个体与交互，可运行软件，客户协作，响应变化)，而是通过这四点来帮助企业提高营收。因此，敏捷开发的度量，换言之敏捷开发要改善的地方，不能只是一线工程实践，而应该是“客户价值”的改善，也就是营收的增加。否则敏捷开发就可能长期处于基层游击队活动，在敏捷热潮过去之后，被证明又是一个重过程不重结果的空架子而已。项目管理者联盟
记者：您是否能谈谈在项目中，敏捷测试人员的职责和技能要求?项目管理者联盟
陈勇：关于这个问题，有趣的是：“测试活动”比“测试人员”在敏捷开发中出现的频率更高。原因就是敏捷开发中提倡跨职能，也就是所有人都对开发、测试负责，从测试活动的目标的转变上就能看出来。talent.mypm.net
传统认为，测试人员是帮开发人员找Bug的，这是个误区。其实，开发人员才是负责找Bug的，尤其是自己找自己的Bug。打个比方，如果我们在自己家里忘了钥匙放在哪里了，一定不会把家里翻个底朝天，而是会尝试找自己以前习惯放钥匙的地方;但如果让一个客人来找，就不那么容易了，因为客人不熟悉家庭环境，也不熟悉我们放钥匙的习惯。家庭环境就是软件，而钥匙就是Bug，测试人员则是一个不太熟悉家庭环境的客人，开发人员才是那个放钥匙的人，尽管他暂时“忘了放在哪里了”。而且长期而言，只有开发人员才能改变自己的习惯，比如在墙上钉个钉子，习惯性地把钥匙挂在上面。我们在一个项目中密集实践过代码审查活动，在短短27天时间里，通过每天花费半小时观察、记录、分析自己的缺陷，个体缺陷率降低了一半之多。而且好的习惯和规范一旦固化下来，以后无需花费额外时间也能在一定程度上保证代码质量，可谓一劳永逸。项目管理培训
找bug的活被抢走了，传统测试人员怎么办?有两种出路，或者说“职业生涯规划”，都比原来传统测试人员更有前景。项目管理者联盟
一、有开发经验的测试人员应该转向“开发测试”项目经理圈子
“开发测试”是游戏领域的一种工种，对应的是完全不需要对开发有了解的“黑盒测试”，我们可以把它的定义扩展一下用在这里。开发测试在开发活动中主要负责自动化测试、持续集成、回归测试等用于快速保证产品质量的活动。service.mypm.net
为什么叫“快速保证产品质量”而不是“发现Bug”呢?因为开发测试程序的人其实不应该是这里的开发测试，而是开发某个功能的开发人员本身。正如之前所说，具体的功能开发者更清楚功能是什么，可能有哪些潜在的问题，如何验证最好……所以开发并第一次执行(为发现缺陷而执行)的是开发人员;但如何让众多测试用例自动地全部或有选择地再次运行，如何保证更高的运行效率、如何准备自动集成环境，则是开发测试人员的工作。项目管理者联盟
如果有可能，个人感觉最好不要设置全职的开发测试，而是视实际情况由不同的开发人员兼任。这样更容易平衡工作量、保证开发与测试的衔接有效性。pmp.mypm.net
整体上这个出路偏向开发人员多一些。项目管理者联盟
二、“没有开发经验”的测试人员应该转向“产品经理”或“专业测试人员”产品经理不说了，因为出路很窄。这里说说专业测试人员。service.mypm.net
有很多时候我们觉得原来的测试人员不就是“专业测试人员”吗?其实不然。很多测试人员不过是看看说明书，点点鼠标，填填Bug而已，很难说上“专业“二字。talent.mypm.net
个人感觉对测试人员而言，“专业”有两重含义。第一，对所在领域的质量问题和解决方法有深入理解。比如特定的软件，可用率是首位的(比如网站，允许瘫痪但不能总瘫痪)还是故障率是首位的(比如飞机，不允许故障)。Windows经常死机，但是恢复速度很快，用起来也很简单，这在家用软件中就是可接受的“高质量”标准;但用作服务器，可能就有点问题。如果不理解这些就开始测试，结果肯定是事倍功半。第二，对测试方法论应该有深入理解。软件仿真，持续集成，灰度发布……这些都可以称为测试方法论或质量方法论。“专业测试人员”用这些方法论指导前面说的“开发测试人员”进行测试，是一种很好的工作方式。项目管理者联盟
我曾经在松结对编程与139团队系列博客中多次提到一个23个开发人员加2个测试人员的团队，其中两个测试人员就是专业测试人员。尤其是其中的测试经理，会定期基于业务的需要向我们提出测试要求，而我们则帮她编码实现。这种搭配方式最终促成了产品的高质量，它现在正运行在国内60%以上的数字电视台。项目管理者联盟
这里的“没有开发经验”被打上了引号，是因为我无数次听到有人说“我没有开发经验，也不懂开发”，但这个人可能是与开发人员共事很多年的资深测试人员。其实，与相对论相比，开发更像是外语，就是外国乞丐学多了也能学会的东西。因此实在不能用技术壁垒作为借口，要做好可能很难，但要了解的确不难。要做好测试这个工作，不去侧面了解和理解开发，是很不现实的。项目管理者联盟
记者： 在敏捷实践的过程中是否一定要使用一些敏捷工具?能否推荐一些您认为比较好的工具?项目管理者联盟
陈勇：因为我自己也在开发一个敏捷工具“火星人”，所以就不直接推荐工具了，呵呵。不过下面可以介绍一下一些一般原则：项目管理者联盟
|
