文章
Scrum在中国——企业实施情况调查实录
作者 李剑 发布于 2008年3月30日 下午9时41分
最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。
尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们 的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。
出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：
| 姓名（职务） |
公司性质 |
实施方式 |
实施时间 |
结果 |
| 璎珞天色，负责过程改进 |
某知名大型互联网公司 |
自底向上 |
2006年3月 |
成功 |
| kaverjody，Scrum Master | 某知名大型软件企业 |
自顶向下 |
2005年12月 |
成功 |
| David，Engineer |
某知名大型互联网公司 |
自顶向下 |
失败 |
|
| 张汉东，Scrum Master |
Nibirutech，创业型公司 | 全面推进 |
2007年11月 |
成功 |
| 赵师容，Senior Engineer | 某创业型公司 |
自顶向下 |
失败 |
在交流中谈到的主要问题包括：
1. 在项目中使用Scrum的原因是什么？2. 在实施Scrum时采用了怎样的路线，为什么这样做？
3. 在实施时遇到的最大的困难是什么，你又是如何解决的？
4. 实施Scrum以后，给项目、公司带来了哪些收益？
5. Scrum实施为何遭遇失败？
Q1. 在项目中使用Scrum的原因是什么？
璎珞天色：kaverjody：
由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。包括交付新的软件发布版本时间太长、软件维护效率低成本高，等等。
张汉东：Q2. 在实施Scrum时采用了怎样的路线，为什么这样做？
璎珞天色：我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进：
06年3月——06年6月（1个团队，8人左右采用）
06年6月——07年12月（3个团队，25人左右采用）
07年12月——08年1月（一个部门，6个团队，50人左右采用）
08年1月——至今（异地开发，原有团队的Scrum继续走下去。异地的配合方式，工具，流程等建设中……）
kaverjody：
张汉东：
随后笔者又向璎珞天色提问道，“在试点时是怎样的实施过程？是针对项目的具体问题，逐步采用各种敏捷实践来加以解决？还是先给团队做培训，介绍敏捷开发的理论实践，然后推行？”，她回答说：
就这样走了几个月后，我们把大家叫到一起，开了一个Agile方法分享会。把大家之前实践总结一下，然后告诉大家，我们的做法就叫做Scurm ，而且它是很有名的哦。然后再把XP、Agile和Scrum都给大家系统讲一遍。于是大家如梦初醒，原来我们是在走Scurm啊～～～～！！！
同时这个项目组的成绩也得到了高层认可，高层也认为效率提高了。于是让这个团队给周围的团队做分享。并挑几个团队开始试行。因为我们团队成员可能会有轮岗和 互调，一个团队使用Project，一个团队使用Xplanner，有时员工也难以上手。为了部门管理统一，方法统一，工具统一，最后高层下令全部实施Scrum。
Q3. 在实施时遇到的最大的困难是什么，你又是如何解决的？
璎珞天色：1. “需求太模糊，造成后期开发沟通成本巨大，反复和产品经理沟通花了太多时间。”
2. “发布周期太长，一个Sprint要做3、4周才能上线，产品经理希望每周都能上两次线。”
3. “由于Scrum过程的特点，我们不能很系统地把握历史需求和整个产品的架构。”
4. “上线时间被业务拍死了，哪儿有时间做单元测试，连代码Review的时间都挤不出来。”
5. “目前的Backlog，人和人之间的协调，任务之间的瓶颈什么的都看不大清楚。”
6. “需求上线，至少1周才能分析数据看结果，没法在这个Sprint一做完就提出新的改进方案。”
7. “开发节奏太快，产品开发测试都没有时间停下来仔细考虑，历史需求没有善加利用。”
kaverjody：
而解决这些问题没有一蹴而就的办法，只能持续地进行教育工作。一方面从理论上进行灌输，并通过长期的讨论来回答同事的问题，来消除大家的不安，另一方面，在遇到困难，或出现问题之后，及时地分析并解决难题，然后以此为案例向大家解释为什么要这样解决，以后再遇到这样的问题要怎么处理。
张汉东：
1. 公司高层的支持。我想这应该是个公共问题。但是InfoQ前几天有篇文章（渐进式敏捷：由下而上的敏捷推行策略）也说了，如果高层并不支持Scrum，那么就屏蔽高层，在团队内部开展就行。幸亏我们CEO和CTO都比较支持Scrum。
2. 公司员工的Scrum培训。同事对Scrum都不太了解，于是我组织了一次Scrum培训，来给大家介绍Scrum里的规则，角色及Scrum的特点和它要解决的问题。大家都把疑问拿出来集体讨论。在讨论的过程中，让大家暂时了解什么是Scrum。然后在实施的过程中，大家就慢慢地对Scrum的规则熟悉了。当然前提是推广Scrum的这个人，要对Scrum比较理解。
以上两个问题在我这其实也不算是困难，因为我推广Scrum的过程中几乎很顺利，大家都很支持我的工作。实施的时候基本也没有什么困难，很好上手。可能和我们用来尝试Scrum的项 目有关。客户已经把backlog写成了Tickets发给我们，然后从接受那些Ticket算起，到客户要求的交工时间为一个迭代期，没有超过30天。这些待办事项基本是优先级等同的，团队内部自己挑选能做的Ticket，然后每天例会大家都严格回答Scrum里的三个问题，保持团队的一致。评审会议也是严格按照Scrum的规则来做。所以暂时没有什么问题。我想下一个Scrum尝试项目中可能会碰到细化需求制定backlog的问题，也许可以让客户把优先级排好，或者说帮助客户和客户一起把需求细分出来，排好优先级，然后在优先级的驱动下，漂亮地完成我们的每个迭代。
接着，笔者又请大家对某些具体困难的解决办法进行深入介绍，璎珞天色说：
第二个发布周期长的问题，我们在项目发布之外，还增加了对日常维护需求的管理方法。每周二和周四上班之前，产品经理会汇总所有维护性的小需求，例如页面修改，数据增删等。周二和周四晨会上提交给负责发布的工程师。 周二和周四的下午，会集中发布这些小需求；
第三、四个问题，无药可救，定期重构，业务第一，不做单元测试，只做代码Review。
张汉东说道：
Q4. 采用Scrum后给项目、给公司带来了哪些收益？
璎珞天色：张汉东：
Q5. Scrum实施为何遭遇失败？
David：每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的Daily Report太频繁太低效，而且还有压榨员工的嫌疑。所以逐渐大家谈起Daily Scrum来都是恶心的不得了，于是经理也知趣地取消了Daily Scrum，再到后来在公司内部就没有人谈什么Agile了。
赵师容：
再 说其他方面，我们没有计划会议，有名义上的Product Owner，但是他不跟我们解释每一个Story具体的细节，也不说如何定义这个Story的完成状态。我们自己搞过Retrospective（回顾），但总结出来的看法反馈到那边就没动静，后来也不做了。在第一次使用ScrumWorks的时候，好歹Product Owner还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Sprint里面去。后来公司里又搞CMMI认证，把我们项目作为Pilot（试验），名义上是改善流程，但实际做法就是为了应付拿证，那就是一强制推行啊，把人搞得想辞职的心都有了。这个项目中间发生的事情太多了，反正磕磕碰碰的还在往前走，但现在我听见公司里有人提到敏捷就犯恶心。
小结
刚整理完这些资料，就在敏捷中国上看到在有关“敏捷测试”的话题中又出现了对“何谓敏捷”的讨论。忽然就想起了席慕容的一句诗：“生命原是要不断地受伤和不断地复原世界仍然是一个在温柔地等待我成熟的果园”。希望这篇文章可以让尚未接触敏捷实践，或者在推广敏捷实践特别是Scrum中碰到困境的读者有所收获。
-
不管是成功还是失败的尝试，都是给项目管理者提供有益的参考！
-
文中璎珞天色提到的那个先不告诉开发人员采用的什么方法，先通过实践让大家尝到甜头，然后在告诉之的做法很有智慧。因为通常情况下，自顶向下的推行对于开发团队来说会有许多阻力，需要做大量的说服工作。而通过潜移默化的影响，就有效地将推广的被动化为开发人员的主动需求。
-
这样的调查很新鲜，能收集到真正使用这些技术的人员的真实感受，对更清晰地认识某一个开发方法或者技术大有帮助，李剑能否对XP、结对编程什么的再做些调查啊？虽然这些概念提了很久了，但具体什么人什么团队在用，效果如何，好像还没有类似的介绍文章呢。InfoQ中文站应该带头做一下。
-
谢谢徐亮的建议，关于下一步进行哪些方面的调查以及如何将调查结果更好的反馈给社区，我们也正在考虑中。无论是从形式还是内容上，都力求有所改进。
-
内容不错，支持！
-
Q4. 采用Scrum后给项目、给公司带来了哪些收益？
璎珞天色：
说不上，很难去度量是Scrum给公司带来的收益。说实话，我觉得Scrum所能带来的收益是没法度量的。我们只能通过调查问卷的方式，去感性地得出它所带来的好处。我们的方法是调查问卷，截2张图下来：
看下来，感觉璎珞天色的公司做得最出色，非常聪明，很 pragmatic 和 practical，很多举措我也相当赞成。
但关于实施效果的衡量，不敢苟同。Scrum 当然也是可以度量的，敏捷度量本来就有一些客观的指标，认为 Scrum 带来的收益是没法度量的，其实是一种认识上的误区。
实际上，在璎珞天色给的图表中，已经出现了 Quality 和 Productivity 两个指标。如果对于二者的评价仅仅停留在所有人比较模糊的感觉上，可能暂时没什么问题，但如果要持续改进，好上加好，没有客观的量化数据，很快就会遇到瓶颈了。你总不能说，上次我们做得很好，这次会做得更好，下次会做得更更好，更更更好 ...
敏捷好不好，不能仅凭感性地去感觉，还要进行理性的分析。敏捷实施的效果，不但可以做到定性分析，也可以做到定量分析。最终，敏捷的好处都应该能够转换成企业真正的收益。
当你向 CEO 汇报说：“很难去度量 Scrum 给公司带来的收益”，甚至“它所能带来的收益是没法度量的”，想想看，你下次还能得到来自公司高层大力的支持吗？
所以，我的建议是（咨询顾问的惯用法）：
从敏捷实施项目一开始，就可以把度量计划、衡量指标设计好，平时注意数据的采集，这样就不会出现到结束、总结的时候无法衡量的情况。
赞成实用主义的敏捷 OO 教练 张恂
www.zhangxun.com -
我对报告中介绍的两则失败案例很感兴趣。由于比较复杂，先评论第一个。
David（某知名大型互联网公司 engineer，该公司自称自顶向下实施了 Scrum，结果失败）：我们的问题在于，有些高层错误理解了Scrum和Agile，导致歪曲了某些东西，使得Agile变得形式化 ... 有个项目经理发现这个东西挺好，就单独把Daily Scrum拿来进行推广；结果，这个经理并不理解什么是Scrum，他把Daily Scrum变成了Daily Report，而其他Scrum的精华部分都没有推广
具体的做法是：每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的Daily Report太频繁太低效，而且还有压榨员工的嫌疑。所以逐渐大家谈起Daily Scrum来都是恶心的不得了，于是经理也知趣地取消了Daily Scrum，再到后来在公司内部就没有人谈什么Agile了。
这就是误解、误用敏捷的恶果，简单粗暴的实施造成了“敏捷”与企业文化的冲突，既破坏了弹性工作制，又激起了员工的猜疑，搞得大家都犯恶心。
这种错误当然不干敏捷的事，把错用敏捷归结为敏捷或 Scrum 的失败、恶心，是不公平的。我想失败的关键原因是，这位经理根本没有搞清 Scrum 和敏捷的原理，为什么要这么做，比如：每日站会。
一，我想进一步了解的是，为什么这位项目经理会只觉得 Daily Scrum 有用，进而创造性的把 Daily Scrum 演变成了 Daily Report，又把 Scrum 的其余精华部分都抛弃掉？
我猜，很可能是这位经理感到不通过强制手段，自己就没法控制自己的团队，所以求救于每日跟踪、每日汇报，来掌握项目团队的实际情况。第二个原因是，他要求员工每日“把当天的任务告诉给他，让他来决定工作是不是饱满”，所以，他其实在怀疑、担心自己的员工会偷懒！这种裹着敏捷、Scrum 外包装的监控、监督措施一经推出，员工们自然就会反感，认为领导的动机不纯，有半夜鸡叫的嫌疑。
结果怎么样呢？非但没有加强管理者和开发者之间的信任和团结，反而加剧了团队的分裂，这显然不是 Scrum 和敏捷的初衷。这位经理的所作所为是不是敏捷呢？当然不是。
翻一翻任何一本敏捷经典教材，我们可以发现，不管 Scrum 还是 XP 的每日站会、每日晨会，目的很简单，其实就是为了及时的暴露风险和问题，让经理、管理者通过调度、沟通帮助开发人员排除障碍、提供保障，这本来是一种服务、协作的关系，team building 的绝好机会，可以促进更好更快地实现整个团队的目标。
为什么这位经理不通过自以为的 Daily Report 就不能掌握项目的真实进度呢？是不是他在自己的员工中缺乏威信，无法有效地进行沟通、获得信息，或是高高在上，工作方式不对呢？我觉着，在这背后可能还有更深入的原因。至少从这个案例的简单描述中，我们可以感觉到在这个团队里，经理和员工之间的关系其实是不融洽的，是一种监控与被监控、防范与被防范、猜疑与被猜疑的关系。从大的方面讲，说不定还与这家公司的整个企业文化有关。
在这种管理者和开发者相互不信任的氛围下，敏捷或 Scrum 的实施能成功吗？
二，从整个公司过程改进的范围看，我觉得也存在一些明显的缺陷。
该公司敏捷实施或改进并没有主动式的领导，仅停留在随意的试验层次上。David 提到曾经有过一次 Scrum 尝试是成功的：当时的Scrum Master负责一个大项目的开发，走的比较顺利，然后有个项目经理发现这个东西挺好，就单独把Daily Scrum拿来进行推广 ...
可见，第一次尝试是比较成功的。可惜，该公司并没有认真地组织总结成功经验，为什么 Scrum 会有效，什么是成功的关键？也没有在公司范围内有系统地进行推广，处在放任自流的状态。这样才发生了某个项目经理突发奇想，觉得这个好，就可以按照他个人所理解的错误思路来进行推广（从这点看，这家公司的执行力很强）。结局是，在整个公司内搞臭了敏捷和 Scrum，这当然不是 Scrum 方法本身的错。
还有，包括 David 在内的开发人员，其实都看得很清楚：“有些高层错误理解了 Scrum 和 Agile，导致歪曲了某些东西，使得 Agile 变得形式化”。那么，为什么大家的这种正确意见在项目团队、公司内部得不到有效的反映，从而避免错误的发生、实施改进的失败？
所以，这个案例的失败是谁的原因？是那位缺乏经验的经理一个人的责任？我觉得不是，这只是一个表象。
根源上，我觉得是这家国内知名的大型互联网公司的制度和文化的问题。不知道作为一家大公司，他们是否有一个专门负责过程改进的部门或人员。我想有了好的制度建设和团队意识，这种草率鲁莽的、缺乏群众基础的事情以后应该不会再发生。
拥有 14y+ 开发和管理经验的
敏捷 OO 教练 张恂
www.zhangxun.com -
前面贵教主分析的挺明白，怎么最后总结的时候，就走邪了？
“根源上，我觉得是这家国内知名的大型互联网公司的制度和文化的问题。不知道作为一家大公司，他们是否有一个专门负责过程改进的部门或人员。”
一个拥有 14y+ 开发和管理经验的人，做了一个案例分析，然后得出这样一个结论，是公司制度和文化的问题。这就好比你关节有问题，挂号找了一个骨科专家，然后骨科专家最后给你一个结论：你需要补钙。那你就慢慢补吧！补个5年或10年的。那时候黄瓜菜都凉了。
恩，居然还建议一个“专门负责过程改进的部门或人员”。这就无疑是说回家成立一个补钙专家小组呗。这不只是一个表象！
-
qian anchuan： 一个拥有 14y+ 开发和管理经验的人，做了一个案例分析，然后得出这样一个结论，是公司制度和文化的问题。这就好比你关节有问题，挂号找了一个骨科专家，然后骨科专家最后给你一个结论：你需要补钙。那你就慢慢补吧！补个5年或10年的。那时候黄瓜菜都凉了。
我这里说的就是“制度和文化”问题，怎么你看不懂？张恂： 第一次尝试是比较成功的。可惜，该公司并没有认真地组织总结成功经验，为什么 Scrum 会有效，什么是成功的关键？也没有在公司范围内有系统地进行推广，处在放任自流的状态。这样才发生了某个项目经理突发奇想，觉得这个好，就可以按照他个人所理解的错误思路来进行推广（从这点看，这家公司的执行力很强）。结局是，在整个公司内搞臭了敏捷和 Scrum，这当然不是 Scrum 方法本身的错。
还有，包括 David 在内的开发人员，其实都看得很清楚：“有些高层错误理解了 Scrum 和 Agile，导致歪曲了某些东西，使得 Agile 变得形式化”。那么，为什么大家的这种正确意见在项目团队、公司内部得不到有效的反映，从而避免错误的发生、实施改进的失败？ -
qian anchuan：恩，居然还建议一个“专门负责过程改进的部门或人员”。这就无疑是说回家成立一个补钙专家小组呗。这不只是一个表象！
敏捷实施成功的一个最起码条件：
公司内部（不管你内部培养，还是从外部请顾问）要有真正懂敏捷、Scrum 的专家吧。
在这篇报告的 3 个成功案例中，核心人物有 2 名是 Scrum Master，1 名（璎珞天色）就负责过程改进，前一家是创业公司，后两家是知名大型企业；而两个失败案例的直接原因，显然都是源于对 Scrum 和敏捷的错误理解造成的。
这些都说明了人员、专家资源保障的重要性。
对于大型软企，没有专门负责过程改进的部门、小组或人员，是不可思议的。
不要只会说风凉话，你有何高见？既然你觉得你的方子好，请给出你的诊断和良策，愿听其详。
张恂 -
Bi-directional Task Assignment
8 年前，张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上，可以说，我们在 8 年前就做到了敏捷，而且是中国式的敏捷。
问题
在 这份报告 中，两个失败案例都明显在 'daily' scrum 和任务分配上犯了常见的错误。
一种情况是，管理者“热心”过度，天天盯着任务分配，结果让软件开发工作变得索然无味，甚至令人恶心。
每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的Daily Report太频繁太低效，而且还有压榨员工的嫌疑。
第二种情况是，管理者热度不够，恣意放羊，结果让项目开发偏离正轨，一撒不可收拾。
在第一次使用ScrumWorks的时候，好歹Product Owner还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Sprint里面去。
以上两种情况，恰好形成两个极端，名义上号称敏捷，实则背离了敏捷的基本原则。由外行“专家”来领导敏捷实施，必然是这种结果。
当今的西式敏捷方法非常强调员工的自愿工作，主动性不受干扰，同时提倡团队文化和集体主义精神（whole-team）。那么，咱本土的中式敏捷又是如何做的呢？以下仅举一例。
具体做法
作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分），把任务表贴在开发现场 open space 的白板上，在开周例会的时候，由团队成员自主选择。
这些每周的开发任务是由大家 brainstorming 共同讨论出来的，当然主要部分由架构师建议，最后由管理者综合大家的意见定夺。
为了防止出现任务分配上的不均、不合理情况，在员工自主选择的基础上，我们还设定了一些指定任务，由管理者根据员工的实际情况和项目需要分配给员工。
因而这实际上是一种员工任务分配的“双向选择”。
考核
员工每月完成任务的数量和质量情况，是绩效考核的基础和主要指标。
有了员工任务的自主选择，月末考核就方便多了，有了更公平、公开和客观的依据。我们把员工每月完成的有效任务分值累加起来，就是他完成的月总工作量。这一结果是完全公开、透明的，谁完成的任务数多，质量好，谁的总分就高。
为了在任务考核中反映质量要素，计算有效任务分值，我们加上了质量因子。设原任务分值为 5 分，如果完成得好，达到了质量要求，那么质量因子为 1，有效任务分还是 5 分；如果完成效果不好，质量因子只有 0.7，那么有效任务就只有 3.5 分。
管理者还可以根据需要，添加其他的权重因子和灵活措施。比方，为了鼓励员工之间的紧密合作，互帮互助，我们还约定，任务分值可以赠送，别人帮助你完成工作，你可以把相应的分值送给他，记在他名下。另外，根据团队文化建设的需要，我们还设立了一些额外的奖励分。在实践中，赠送分、奖励分应用得也较为普遍。
当然，最重要的一点，这整套任务分配和考核办法是由管理者提议，所有团队成员大家共同协商讨论，认为公平、合理之后，一致通过和支持的，这样就有了良好的群众基础，并且在实施中得到了不断改进和完善。
有了这样一种机制，必然会在员工中间形成一种攀比，比谁完成的任务分值高，而这种攀比恰恰符合团队的整体利益，也是管理者所乐见的。
效果
您可能很关心我们实施的效果怎么样，回答是：出奇的好！
与其他采取传统措施的团队相比，张恂团队的同事们参加计划会议的热情非常高，每次都是抢着要任务，而且往往勇于挑战分值较高的任务，每个人都生怕自己的任务不饱和，影响了个人月底考核的总成绩（间接地影响 bonus）。
关键一点，我们把原本看似枯燥乏味的软件开发工作，变成了一种近似体育竞赛的团体合作游戏，结果导致每个人在工作时都热情饱满，兴致勃勃，这也算是实施此方法后的一种意外收获。
显然，这与过去由经理们主观生硬地（尤其是根据 WBS）设计任务，向员工指派任务，而月末考核客观依据又不足的局面大不相同，可以说是一种彻底的转变。
我想这种措施的成功，由项目管理者绞尽脑汁生硬地把任务指派给员工，到员工积极地想任务、要任务、抢任务（这一现象真的就发生在张恂的团队中），其实也是一种逆向思维驱使下，管理方法创新的成功。
读者朋友，您在团队任务的分配方面是怎么做的，有什么创新的好方法、好思路？欢迎来信交流。
敏捷 OO 教练 张恂
www.zhangxun.com -
敏捷实施成功的一个最起码条件： 公司内部（不管你内部培养，还是从外部请顾问）要有真正懂敏捷、Scrum 的专家吧。
请问是不是没有专家就不能进行敏捷了？怎么才是真正懂敏捷？什么才是Scrum专家呢？如果您还是
专门负责过程改进的部门、小组
那就请继续很有前途的CMM职业吧！从敏捷实施项目一开始，就可以把度量计划、衡量指标设计好
别只是站着说话，既然是你的高见，就请把你具体的度量计划和衡量指标的拿出来，给大家Show一下。当然，高见我没有，但我肯定有话要说。不过还是先等您做完评论。
-
8 年前，张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上，可以说，我们在 8 年前就做到了敏捷，而且是中国式的敏捷。
我的理解能力不太好。所以很想和您确定一下，您是说8年前，你们做到了员工任务的自愿/自主分配，就说明你已经做到了敏捷，而且是中国式的敏捷，是吗？还句话，是不是就等同于：员工任务的自愿/自主分配＝敏捷＝中国式的敏捷
实则背离了敏捷的基本原则
再请教什么是敏捷的基本原则？作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分）
请问做为管理者和架构师的你，做具体的开发工作吗？如果连具体的开发工作都不做，怎么一个人就这样武断的给所有的任务打分呢？考核 员工每月完成任务的数量和质量情况，是绩效考核的基础和主要指标。
你一直口口声声谈文化，谈什么“提倡团队文化和集体主义精神”。现在，又提倡“考核”，让团队成员之间有直接的利益冲突，你这不是直接扼杀了前面的团队文化，你这不是在用石头砸自己的脚吗？而且，你的所有的考核都是建立在你前面的分值上。你的分值本来就是估算，不准确，现在你又拿它做考核。这样不准确的考核，直接带来的后果就是不公平，不公正。请问这就是你口口声声说的“团队文化”吗？
有了这样一种机制，必然会在员工中间形成一种攀比，比谁完成的任务分值高，而这种攀比恰恰符合团队的整体利益，也是管理者所乐见的。
你觉得可能吗？有人相信你这句话吗？就别欺骗自己了，好不! -
qian anchuan：
不要断章取义。8 年前，张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上，可以说，我们在 8 年前就做到了敏捷，而且是中国式的敏捷。
我的理解能力不太好。所以很想和您确定一下，您是说8年前，你们做到了员工任务的自愿/自主分配，就说明你已经做到了敏捷，而且是中国式的敏捷，是吗？还句话，是不是就等同于： 员工任务的自愿/自主分配＝敏捷＝中国式的敏捷
我说的是在“这一点上”，也就是说这种做法是敏捷的 practice，中式敏捷的 practice。而且我用的是商榷的语气（“可以说”）。
你给的等式是错误的。敏捷、中式敏捷的内涵当然还要丰富得多。 -
quan anchuan：
你怎么知道我不做具体的开发工作呢？
请问做为管理者和架构师的你，做具体的开发工作吗？如果连具体的开发工作都不做，怎么一个人就这样武断的给所有的任务打分呢？
在我们的团队里，张恂不但做具体的开发工作，而且做最复杂、最难部分的开发工作，包括写代码，写测试。架构师自然是在这个团队里，综合技术水平最高的人，因此才可以做技术主管，而且要身体力行。我对架构师的理解一直如此。
“怎么一个人就这样武断的给所有的任务打分呢”
前面我已经说了，每周有哪些任务，任务的分值如何，可以由任何人提议（包括架构师），大家一起想任务，评任务，最终经计划会议讨论一致通过。张恂：
这些每周的开发任务是由大家 brainstorming 共同讨论出来的，当然主要部分由架构师建议，最后由管理者综合大家的意见定夺。 -
你一直口口声声谈文化，谈什么“提倡团队文化和集体主义精神”。现在，又提倡“考核”，让团队成员之间有直接的利益冲突，你这不是直接扼杀了前面的团队文化，你这不是在用石头砸自己的脚吗？
正常的绩效考核会造成员工之间的直接利益冲突，而且与团队文化、集体主义精神相冲突，扼杀了团队文化？实在看不懂你的逻辑。
不知您在什么单位工作？福利院？每天只要上班打卡，无需考核，就可以安等着领薪水了？
我怀疑您的大部分问题都是冲着 14y+ 来，是不是不服？难道张恂的 14y+ 真的让您受到了什么刺激？希望你冷静点再发言。 -
quan anchuan： 而且，你的所有的考核都是建立在你前面的分值上。你的分值本来就是估算，不准确，现在你又拿它做考核。这样不准确的考核，直接带来的后果就是不公平，不公正。请问这就是你口口声声说的“团队文化”吗？
首先，我说了，任务分只是考核的主要依据，并不是全部的依据。
没错，这些分值都是人为指定的，它们只有相对意义，没有绝对意义，它们的作用只是用来相对客观地区分出一个团队中每个成员的贡献大小，所以，任务分的绝对值是没有意义的。我们最终比较的其实是成员任务总分之间的相对差值，这样就可以排出一个名次，知道谁比谁做的更好。
事实上，我们知道体育竞赛的游戏记分规则制定得非常合理，被普遍接受。而张恂的这套方案其实就借鉴了桥牌、棋类比赛的记分原理，当然简单多了。
你应该明白一个重要的原理：
没有绝对的公平和准确，只有相对的公平和准确。
你说我们的任务分值不准确，那么你能不能拿出一个更为准确、合理的考核方案？
关于公平性
我一再强调，这些任务和任务分值是在计划会议上由大家一致提议讨论通过的，而且首先这是一种大家一致认可、共同制定的游戏规则，怎么可能不公平，不公正？
难道你觉得绩效考核的暗想操作，更公平？
如果在计划会上，某人觉得任务分值不合理，他可以提出来，是定高了，还是定低了，如果大家多数接受，当然可以修改。如果大家意见有分歧，就需要像体育竞赛一样进行仲裁，而仲裁人是架构师或管理者。
在实践中，我们确实也发生过分值调整的情况，但走的也是公开、透明调整的方式，因此大家没什么异议。
敏捷 OO 教练 张恂
www.zhangxun.com -
quan anchuan：
这里我分享了一段过去的历史、经验和事实，张恂还打算把这些经验整理成敏捷组织管理模式（Agile Organizational Patterns）。有了这样一种机制，必然会在员工中间形成一种攀比，比谁完成的任务分值高，而这种攀比恰恰符合团队的整体利益，也是管理者所乐见的。
你觉得可能吗？有人相信你这句话吗？就别欺骗自己了，好不!
在采用了 BTA 之后，我们的团队变得更加团结，工作热情更加饱满，效率也更高，工作面貌确实发生了彻底的转变，出现了我们所期待的攀比工作贡献度的局面。同时这种更为合理的考核办法也不断吸引了外部新成员的加入。
qian anchuan，你或者任何其他人，信不信 BTA 及其效果，这些其实都无关紧要，丝毫不能改变历史和事实。一种方法是否有效，是由它的科学性和客观规律决定的。
而且从你不能理解这种机制所形成的效应来看，显然你也并不了解这样一条已广为人所熟知的经验事实和管理原则（大意）：
通常只要管理者将哪些关注点/方面设定为考核指标，那么团队成员就会去努力追求这些考核关注点，并忽视/忽略其他非考核关注点，最终使得这些被考核的关注点/方面得到显著加强。
这条经验法则正是张恂当初设计 BTA 任务分配与考核方法所运用的一条基本原理。
我发现，你不但缺乏软件工程、CMM、敏捷的基本常识，也缺乏基本的管理学常识，而且明显受到了某些技术媒体不当宣传的误导。我怀疑你是刚参加工作不久的嫩手。
张恂也没有必要与一个对自己缺乏基本信任感（trust）的人进行所谓的交流，我觉得可以到此为止了。
敏捷 OO 教练 张恂 www.zhangxun.com -
8 年前，张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上，可以说，我们在 8 年前就做到了敏捷，而且是中国式的敏捷。
我给这个等式，明显是在帮助读者理解你的那句话。我从没有看到也没有听说敏捷中有“过员工任务的自愿/自主分配”这个实践，在资源如此丰富的互联网上也更本找不到这个所谓的实践。那这就是你的杜撰了，哦，不，应该是创新才对。
如果是你个人的创新，我建议你就命名为“张询式的敏捷”。我个人绝对不会再有任何的非议。
-
该加强中文阅读能力和逻辑能力的人应该是你吧！我明显是在问你是否做具体的开发工作。quan anchuan： 请问做为管理者和架构师的你，做具体的开发工作吗？如果连具体的开发工作都不做，怎么一个人就这样武断的给所有的任务打分呢？
你怎么知道我不做具体的开发工作呢？前面我已经说了，每周有哪些任务，任务的分值如何，可以由任何人提议（包括架构师），大家一起想任务，评任务，最终经计划会议讨论一致通过。
你看明白了，你自己明明写的是“开发任务是由大家 brainstorming 共同讨论出来的”。这里可并没有说对任务的评分是大家共同讨论出来的，你前面只说张恂： 这些每周的开发任务是由大家 brainstorming 共同讨论出来的，当然主要部分由架构师建议，最后由管理者综合大家的意见定夺。
作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分）
如果你觉得还没有想清楚，那可以想清楚了再写。 -
qian anchuan：
要么你在撒谎，要么你不懂 Scrum 和敏捷。
我从没有看到也没有听说敏捷中有“过员工任务的自愿/自主分配”这个实践，在资源如此丰富的互联网上也更本找不到这个所谓的实践。那这就是你的杜撰了，哦，不，应该是创新才对。
http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1129Sprint Task
XP 也是一样的。自愿工作的做法是一种“缺省的”敏捷团队的文化和原则。
In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.
的确，XP、Scrum 可能没有把 volunteer for tasks 列为 first-class Practice。难道，敏捷方法是钢板一块的圣经或圣旨？大师们没明确列出来的，明确点明的，我们就一丁点儿都不能补充、改进、推导和完善？
如果你一定要抠“实践”这个字眼的话，我看就是抬杠了。这种机械、僵化的思维恰恰是反敏捷的。如果是你个人的创新，我建议你
59 条回复
回复