新闻
文章：Scrum在中国——企业实施情况调查实录
作者 李剑 发布于 2008年3月30日 下午9时47分
近期，InfoQ中文站就Scrum实施情况与国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例。其中有的来自大型企业，有的来自创业型公司；有的采取自底向上的实施方式，有的自顶向下；有成功，也有失败。在调查中交流的主要问题包括：
1. 在项目中使用Scrum的原因是什么？
2. 在实施Scrum时采用了怎样的路线，为什么这样做？
3. 在实施时遇到的最大的困难是什么，你又是如何解决的？
4. 实施Scrum以后，给项目、公司带来了哪些收益？
5. Scrum实施为何遭遇失败？
这只是一个小范围内的调查，而且每个企业的具体情况也不尽相同；但是，通过关注其他人如何实施Scrum，无论他们成功也好，失败也罢，我们都可以从中汲取营养，做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻。
查看文章全文：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 -
前面贵教主分析的挺明白，怎么最后总结的时候，就走邪了？<p>
“根源上，我觉得是这家国内知名的大型互联网公司的制度和文化的问题。不知道作为一家大公司，他们是否有一个专门负责过程改进的部门或人员。”<p>
一个拥有 14y+ 开发和管理经验的人，做了一个案例分析，然后得出这样一个结论，是公司制度和文化的问题。这就好比你关节有问题，挂号找了一个骨科专家，然后骨科专家最后给你一个结论：你需要补钙。那你就慢慢补吧！补个5年或10年的。那时候黄瓜菜都凉了。<p>
恩，居然还建议一个“专门负责过程改进的部门或人员”。这就无疑是说回家成立一个补钙专家小组呗。这不只是一个表象！</p></p></p> -
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专家呢？<p>
如果您还是
那就请继续很有前途的CMM职业吧！<p>
专门负责过程改进的部门、小组
从敏捷实施项目一开始，就可以把度量计划、衡量指标设计好
别只是站着说话，既然是你的高见，就请把你具体的度量计划和衡量指标的拿出来，给大家Show一下。<p>
当然，高见我没有，但我肯定有话要说。不过还是先等您做完评论。</p></p></p> -
8 年前，张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上，可以说，我们在 8 年前就做到了敏捷，而且是中国式的敏捷。
我的理解能力不太好。所以很想和您确定一下，您是说8年前，你们做到了员工任务的自愿/自主分配，就说明你已经做到了敏捷，而且是中国式的敏捷，是吗？还句话，是不是就等同于：
<p>员工任务的自愿/自主分配＝敏捷＝中国式的敏捷
实则背离了敏捷的基本原则
再请教什么是敏捷的基本原则？
作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分）
请问做为管理者和架构师的你，做具体的开发工作吗？如果连具体的开发工作都不做，怎么一个人就这样武断的给所有的任务打分呢？
考核
员工每月完成任务的数量和质量情况，是绩效考核的基础和主要指标。
你一直口口声声谈文化，谈什么“提倡团队文化和集体主义精神”。现在，又提倡“考核”，让团队成员之间有直接的利益冲突，你这不是直接扼杀了前面的团队文化，你这不是在用石头砸自己的脚吗？<p>
而且，你的所有的考核都是建立在你前面的分值上。你的分值本来就是估算，不准确，现在你又拿它做考核。这样不准确的考核，直接带来的后果就是不公平，不公正。请问这就是你口口声声说的“团队文化”吗？
有了这样一种机制，必然会在员工中间形成一种攀比，比谁完成的任务分值高，而这种攀比恰恰符合团队的整体利益，也是管理者所乐见的。
你觉得可能吗？有人相信你这句话吗？就别欺骗自己了，好不!
</p></p> -
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 年前就做到了敏捷，而且是中国式的敏捷。
我给这个等式，明显是在帮助读者理解你的那句话。<p>我从没有看到也没有听说敏捷中有“过员工任务的自愿/自主分配”这个实践，在资源如此丰富的互联网上也更本找不到这个所谓的实践。那这就是你的杜撰了，哦，不，应该是创新才对。<p>如果是你个人的创新，我建议你就命名为“张询式的敏捷”。我个人绝对不会再有任何的非议。</p></p> -
该加强中文阅读能力和逻辑能力的人应该是你吧！我明显是在问你是否做具体的开发工作。
quan anchuan：
请问做为管理者和架构师的你，做具体的开发工作吗？如果连具体的开发工作都不做，怎么一个人就这样武断的给所有的任务打分呢？
你怎么知道我不做具体的开发工作呢？
前面我已经说了，每周有哪些任务，任务的分值如何，可以由任何人提议（包括架构师），大家一起想任务，评任务，最终经计划会议讨论一致通过。
张恂：
这些每周的开发任务是由大家 brainstorming 共同讨论出来的，当然主要部分由架构师建议，最后由管理者综合大家的意见定夺。
你看明白了，你自己明明写的是“开发任务是由大家 brainstorming 共同讨论出来的”。这里可并没有说对任务的评分是大家共同讨论出来的，你前面只说作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分）
如果你觉得还没有想清楚，那可以想清楚了再写。 -
qian anchuan：
我从没有看到也没有听说敏捷中有“过员工任务的自愿/自主分配”这个实践，在资源如此丰富的互联网上也更本找不到这个所谓的实践。那这就是你的杜撰了，哦，不，应该是创新才对。
要么你在撒谎，要么你不懂 Scrum 和敏捷。
www.scrumalliance.org/articles/39-glossary-of-s...
Sprint Task
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 也是一样的。自愿工作的做法是一种“缺省的”敏捷团队的文化和原则。
的确，XP、Scrum 可能没有把 volunteer for tasks 列为 first-class Practice。难道，敏捷方法是钢板一块的圣经或圣旨？大师们没明确列出来的，明确点明的，我们就一丁点儿都不能补充、改进、推导和完善？
如果你一定要抠“实践”这个字眼的话，我看就是抬杠了。这种机械、僵化的思维恰恰是反敏捷的。
如果是你个人的创新，我建议你就命名为“张询式的敏捷”。我个人绝对不会再有任何的非议。
不错，张恂正是中式太极敏捷以及太极敏捷派的创始人。
我想 BTA 可能并不是张恂一个人的创新，过去和现在也有很多人尝试过类似的做法，只不过我把它总结了一下，作为一种敏捷实践提了出来。 -
张导师真的厉害，几下子就把西式敏捷给干掉了，看来中式敏捷真强大啊。
不过这里张大师的说法我觉得应该自己回去好好在过一下大脑思考思考。并且我觉得以张大师十四年的经验和中西贯通，以及文化、哲学全都深入了解，应该不会不知道“自主工作”和“自愿工作”以及“自主任务分配”这些概念之间的细微差别。
最后我想问问张大师是否认为真正的存在“自主任务分配”，是否可以给我们解释一下啥叫自主分配任务。至少从这一点上我觉得张大师是完全的背离了敏捷的方法，而更加类似重型的方式，也就是完全把人当着一组可以被看做无个性以及无性格的组建。
我希望张大师好好解释一下我的这个疑惑，同时也给大家解释一下我这个疑惑究竟是怎么来的。 -
Sprint Task
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.
人家在描述什么是“Sprint Task”，你就断了其中一句，作为你个人的创新，并美其名曰8年多来苦苦奉首的团队文化和原则。
你这么武断，不尊重事实，就下这样的结论。我很怀疑，有人敢找您去做咨询。不过，说实话。我没有您14y+的工作经验，也没有您那么高的学历，更不能向您那样8年前就开始敏捷了。不过，我还确实在用敏捷，也就才用了4年而已。<p>这样跟您沟通真费劲，本敏捷Developer还是去写自己的文章了，我会发上来，如果您有非议，欢迎教主的宝贵意见。不过，“保护环境，人人有责”。如果是错的东西，我一定会站出来指正的。</p>
我发现，你不但缺乏软件工程、CMM、敏捷的基本常识，也缺乏基本的管理学常识，而且明显受到了某些技术媒体不当宣传的误导。我怀疑你是刚参加工作不久的嫩手。 -
Sprint Task
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.
人家在描述什么是“Sprint Task”，你就断了其中一句，作为你个人的创新，并美其名曰8年多来苦苦奉首的团队文化和原则。
请“qian anchuan”仔细阅读英文原文，该段文字首先简述了什么是“Sprint Task”，接下来，更重要的是，描述了以何种方式将这些任务分配到每个人，这才是此段的重点。而您所驳斥的那名咨询人士，将工作任务分配的方式提取出来，作为一种敏捷实践，有何不可呢？况且，从原文中，也看不出他把这个实践“美其名曰8年多来苦苦奉首的团队文化和原则”这种态度阿。
我发现，你不但缺乏软件工程、CMM、敏捷的基本常识，也缺乏基本的管理学常识，而且明显受到了某些技术媒体不当宣传的误导。我怀疑你是刚参加工作不久的嫩手。
你这么武断，不尊重事实，就下这样的结论。我很怀疑，有人敢找您去做咨询。不过，说实话。我没有您14y+的工作经验，也没有您那么高的学历，更不能向您那样8年前就开始敏捷了。不过，我还确实在用敏捷，也就才用了4年而已。
我对上面咨询人士对您工作经历的“武断”结论，倒不敢苟同。他凭什么能怀疑您是刚参加工作的嫩手呢？但是，从您的回文中，我可真没有看出4年的敏捷实践经验，给您留下了什么宝贵的经验。从这一点上，我认同咨询人士所说的“您缺乏...基本常识”这种结论。
我期待您能在这里将您4年敏捷所获得的经验和知识与大家分享，而不是缺乏理论支持的技术攻击。 -
张导师真的厉害，几下子就把西式敏捷给干掉了，看来中式敏捷真强大啊。
不知道您从哪里看出来“张导师”把西式敏捷干掉了，他只是把他的敏捷实践称之为中式敏捷，太极敏捷啥的，也没有说西式敏捷不行啊，需要被“干掉”啊。不过这里张大师的说法我觉得应该自己回去好好在过一下大脑思考思考。并且我觉得以张大师十四年的经验和中西贯通，以及文化、哲学全都深入了解，应该不会不知道“自主工作”和“自愿工作”以及“自主任务分配”这些概念之间的细微差别。
请不要在这里鼓捣文字游戏，请直接指出其理论或实践的错误之处。
最后我想问问张大师是否认为真正的存在“自主任务分配”，是否可以给我们解释一下啥叫自主分配任务。至少从这一点上我觉得张大师是完全的背离了敏捷的方法，而更加类似重型的方式，也就是完全把人当着一组可以被看做无个性以及无性格的组建。
我希望张大师好好解释一下我的这个疑惑，同时也给大家解释一下我这个疑惑究竟是怎么来的。
请问，“这一点”是哪一点，他的实践背离了敏捷的方法，更加“重型”？并且“完全把人当着一组可以被看做无个性以及无性格的组建”？我反而觉得就是因为程序员不是毫无个性和性格的工作者，才会出现敏捷方法对“人”的更多思考和重视，才会有sprint task的自主分配，才会有张咨询师文章中所实践的自主分配方法，您竟然从张咨询师的文章中得出完全相反的结论，实在是太“有趣”了。
敏捷实践，尤其是Scrum这种方法论的实践，本来就是会因人、因环境而变化的。张咨询师提炼出了他在工作中对Scrum的理解、总结和一些实践心得，是很好的啊，虽然其中夹杂着一些广告式的话语或令人不爽的语气，但的确言之有物。
遗憾的是，您的反驳中没有确实的基础和论据，也没有自身敏捷实践的经历心得，让我这个等待不同技术观点发生碰撞的菜鸟，颇为失望。 -
this community definitely needs more sane practitioners like you, other than those two.
-
this community definitely needs more sane practitioners like you, other than those two.
貌似您二位都姓张 -
我就知道有人会注意这个，：），如果用马甲，还会用类似的id吗？还有特别有意思的一点，我竟然发现这里还有文章后面跟着的回文，也是“Jun Zhang”，我还以为是我的id被盗用了呢，可能是重名，真是巧合阿。不得已，把我的名字改一下，要不然，看着一样名字发表的回文，还真别扭。
-
我有几个问题想请教一下张掌门。
张掌门是搞过cmm的，也是精通rup，对重型方法和传统的软件工程思想是心知肚明的。现在又扛起了敏捷的大旗，自然无人可比，做起了敏捷的教练，是专家级别的任务了。我本是一个草寇，只会叽叽喳喳，不懂软件工程，更不懂敏捷。但是还算认识几个字，但是不敢张扬，只能在厕所里面偷偷看看书。可惜眼睛不好，灯光也黑暗，记性也差，很多东西都忘记了。现在就只能请张掌门这个专家来给我指点指点。
第一我忘记了度量，是不是cmm的一个要求，又是几级的要求，而为啥要把可度量安排在那个级别做要求。而我也忘记了敏捷度量里面都有啥内容，其实又在什么地方说了应该在首先就建立其度量的指标体系。同时我还想问问为什么还需要平时注意采集，而就不能到最后复习或者叫回顾的时候再去收集。
第二我想知道张掌门是否知道，David所在的公司实施SCRUM的具体目标是什么。而假若真如教主分析的，这个经理的目标在于加强控制，这个目标是否已经可以通过他们的这个手段达到了。而他取消了实施SCRUM是因为大家的反对，还是因为目标没有达到。我这个糊涂，而且能力低，没啥管理能力，所以经常见到有人反对敏捷（包括你老我前几年记得你一直是反对我们推广敏捷的，并且一直是重型方法的坚定支持者），所以如果那些人就是反对敏捷的SCRUM，那又如何。况且我私下以为，敏捷的方法强调沟通，主张信息的顺畅交流，那么是不是需要尽量保证人员的在场率为好。况且任务饱满不饱满，领导是不是有责任知晓，是不是有责任调节。难道SCRUM就是大家都自我中心，自我管理？每日晨会自然是有暴露风险，这么一个单一的简单目的，就不能有其他的目的吗？而且管理是不是也可以算一种服务呢？同时调度是不是一种管理的职能呢？
同时我又好奇，难道所有的敏捷实施都必须得到高层的主动推动吗？我咋记得有很多人一直在讨论由底向上的敏捷推广措施呢。并且一次成功是否就已经说明了敏捷的巨大优势，公司领导就该重视，就该总结经验，就该全局推广呢？难道他们就不能再等等，再看看。
我这个人比较笨，做事情经常失败。所以我觉得失败一下很正常，也可以学到很多东西。但是需要总结和实际调查。
而我注意到您的分析过程和结论都是建立在“我猜”的基础上的，你觉得以这样的态度去分析问题和推广敏捷是不是可取的呢？
第三您说：“敏捷实施成功的一个最起码条件： 公司内部（不管你内部培养，还是从外部请顾问）要有真正懂敏捷、Scrum 的专家吧。”
那么如果没有这样的人，我们是不是就该等着，就该盼着你这样的专家从天而降呢？
而且既然我们不能真正懂敏捷，我们怎么辨别这个专家是真懂敏捷还是假懂敏捷呢？
再说您能说说在国内有几个可以被您认可的敏捷专家，这些专家又都是什么价格。如果太贵，或者资源不足，那是不
60 条回复
回复