|
第一，“所有队员平等”的团队互助的动力从哪里来?人们一定会说：都是在一起工作的同事，怎么会没有互助动力?我们曾经在一个团队实施代码审查，而且是我之前多次提到的那个最好的139团队，很快发生一次事故：一大段4000多行但包含4000多个常数的烂代码逃过了检查者的眼睛进入了代码库，并最后引发客户现场的Bug。当询问代码审查者为何让明显存在问题的代码通过检查?代码审查者很无奈地说：“我刚来不久，虽然我觉得这些代码有问题，但我感觉大家都说他(编写者)是个高手，我也就不想说什么了。其实我本人也觉得这些代码有问题”。这件事情促使我们后来形成了139团队，就是形成层次团队，由师傅来审核徒弟的代码，出问题师傅负责。这不是说所有团队一定要如此，而是说不能简单地把互助建立在“雷锋精神”上面。项目管理者联盟
第二，集体估算的目的何在?很多人认为是领导放权发扬民主，所以投票+平均值就体现了这一点。但如果一个人估10人天，另一个人估计1人天，结果到底是多少呢?总不能真的是5.5人天吧?所以估算的目的其实是想知道有没有更快的方法，有没有人在走弯路……如果为期一天的计划会耗费整个团队10多个人天，但却避免了上百人天的弯路损失，就算真正物有所值。我遇到的单个任务的最大差异是20人天比0.5人天，很可惜他们不做敏捷开发也不做估算，是任务接近尾声的时候被偶然发现的，只用了0.5人天就重写了。在一个139团队中，一般师傅要和徒弟用敏捷估算扑克估计每个任务的工作量;如果刚才这个任务出现在139团队中，师傅不会取值(20+0.5)/2，而是通过与徒弟讨论，让徒弟学会如何用0.5人天来完成这个任务，因为徒弟浪费的时间最后要算在整个师徒小组身上。如果不是139团队，也要找到类似的人们参与争论和坚持自己正确见解的动力。项目管理者联盟
第三，剩下的“主动领取任务”、“互不干涉”等，也要进行相似的分析，不能因为“看上去很自由很敏捷”就采纳。提出这些实践的团队可能与我们所处的情况差别很大，未必能拿来就用。我曾经用过“自由领取任务”，那是在10年前的一个假期里边，我邀请自己关系很近的两个老部下来帮忙做一个软件;一些零散任务就被单独拿出来，谁先做完手头工作就自由领取，其中一个人领取了8个中的5个之多。但在之后的每一个项目中，我都会先想一想，团队是否允许我再次采用这个实践。pmp.mypm.net
团队模型理顺了，计划会所需的共同计划、集思广益、团队协作才能做好。项目管理者联盟
记者：在敏捷开发方法中，Scrum和XP我个人认为比较常见，您能介绍下Scrum与XP的最大区别在哪里?在实践中Scrum与XP只取其一，还是两者都取，或者全都抛弃?项目管理者联盟
陈勇：Scrum主要是关于需求和项目管理的，而XP则主要是技术管理。PgMp.mypm.net
Scrum中关于Product Backlog的全部及Sprint Backlog的形成过程、评审会大部分，可以理解为需求管理内容，包括需求开发，分解，描述，排序以及进展跟踪的过程。而估算、每日立会、燃尽图等内容则属于项目管理。项目管理者联盟
XP则主要是技术管理问题，不过其结构不明确，不好分类。项目管理者联盟
这个差别也可以解释Scrum为何易于推广：因为其整个体系很清晰。比如在我的培训课程中有一个贯穿始终的练习，用三个需求的描述、分解和估算过程来演练Scrum。这个练习能从第一天上午10：00左右开始，断断续续穿插于培训中，一直持续到第二天中午;要用一个练习把所有或者只是大部分的XP实践串联起来则几乎是不可能的。另外Scrum宣贯起来也不需要大的技术革命，主要是人员职责的重新描述，部分管理活动如计划、跟踪的引进，因此门槛很低。不过反过来，由于缺少实际的技术改进，若只得其皮毛而没有利用团队、过程的变化来真正促进开发，那么Scrum失败的概率也很高。talent.mypm.net
Scrum在商业运作上也更成功。这应该归功于Scrum的发明者是项目经理或更高级别的人员，而XP则主要是一线员工，甚至说是Geek们不为过。Scrum推出了认证的Scrum Mast*r和Product Owner两种认证，由于体系相对完整，认证课程目标听众的收入也相对较高，所以推广起来比较容易;多数咨询师更容易理解Scrum的理念而非XP的，也使之得以快速推广。talent.mypm.net
不过长远看来，团队，过程，技术三者密不可分。Scrum覆盖了前两者中的一部分，但如果没有持续集成、自动化测试等方法的支撑，迭代交付将很难完成。所以，未来应该会有并存的需要，即使不再以当前的两个名字存在。training.mypm.net
记者：拙劣的度量指标会产生严重的后果，敏捷度量指标也是一个很有争议的问题，以您的经验如何去解决这个问题?
陈勇：有多个层次的指标可供衡量，下面从基层到高层一层层剖析一下。项目管理者联盟
一、基层度量项目管理者联盟
对最基层活动而言，一般所有度量均不用于个体考核，而只是用于改进。比如个体的缺陷率、工作完成量、按时完成率等。项目经理圈子
之所以这样做，原因是不希望面向个体的考核破坏了团队中原本用来提高生产率的团队协作。团队协作可以消除个体错误，通过共同估算让高手的技能流向新手，等等。如果个体考核让人心有挂念，会产生问题。项目管理者联盟
不过一个不可回避的问题是：不管你们敏捷开发怎么说，但财务终究要把绩效奖金(假如有)发放到个体而非团队的账户上，怎么知道谁应该发多少呢?在一个10个队员且关系互相平行的团队里边，的确没有办法知道，因此也不得不面向个体考核，并最终不可避免地毁掉团队协作。blog.mypm.net
但在一个139团队里边，答案比较简单。139团队，就是1个项目经理，带3个高手(师傅)，每个高手再带3个新手(徒弟);师傅全权负责自己及3个徒弟的工作，从进度，设计到质量;师傅会选择关键时间点与徒弟碰头，以便用最少时间解决最大的问题(这种活动称之为“松结对编程”，在我的“敏捷开发松结对编程系列”中有详细描述);师傅对徒弟的代码进行代码审查;平时徒弟有问题会师傅。在这样一个团队中，项目经理收入最高，师傅次之，徒弟最低。薪水相对固定，如果位置没有变化，无论自己一个人多编码了还是帮别人太多导致少编码了，都差不多。因此要想拿到高薪，不是在短期内多编写几行代码或关闭几个Bug，而是看长期：新人先要达到独立工作能力，然后帮助团队扩张也就是自己带徒弟成为师傅，最后成为可以独自担当一种业务的人也就是项目经理。在这种团队中，人的收入增长不是通过内部竞争，而是通过内部协作做到的。club.mypm.net
因此它是一种兼容敏捷团队精神的个体绩效考核方法。项目管理论坛
二、外部度量training.mypm.net
正如前面所说，外部度量是为了让团队对外透明而做的度量。有这样几个原则：只做外部看得懂的度量;只做外部有人看的度量;尽量少做度量。项目管理者联盟
典型的外部度量是给PO也就是产品经理所作的用户故事的完成情况的度量，比如白板上处于完成状态的故事的数量。这里说故事而非任务，是因为对产品经理而言，任务完成没有意义。项目管理者联盟
生产率也经常是一个被度量的内容，但现在尚无好的方法。有些团队经常使用“故事点”来做度量，方法是：先挑选一些以往的故事作为典型故事;为每个典型故事分配一个点数(一般是当时完成此故事的天数);每次估算新故事时查先看更像哪个典型故事，然后再根据难度差别为新故事设定一个点数;实际完成后，点数/天数=生产率，也就是实际完成点数的速度。这个方法看似有效，但因为大家对典型故事的熟悉程度差别很大，典型故事也很难选择，导致实际使用的人很少。另外一个问题是不同项目的典型故事和点数是不通用的，因此无法做比较。好不容易做了一个想对外发布的生产率，却无法横向比较只能自娱自乐，显然存在问题。未来，这个问题可能会被功能点生产率解决，但现在还没有看到有人尝试。我们自己做了一些宏观尝试，但没有每个迭代都做。项目管理者联盟
此外还有一些度量，但取决于实际的需要。比如在线运行的网络游戏，会度量迭代交付周期长度(直接影响响应时间，因此一般越短越好)。这些度量不全是明确量化的，但公司上下都能说出一个大致的数字来，因此也算是度量。PgMp.mypm.net
三、业务运营与收入度量项目管理者联盟
|
