BT
x 你的观点很重要!请帮我们完成有关您阅读习惯的InfoQ调研吧

Scrum在中国——企业实施情况调查实录

作者 李剑 发布于 2008年3月30日 |

最近,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模式,同时通过其他的一些手段辅助,来解决当前的这些问题。包括交付新的软件发布版本时间太长、软件维护效率低成本高,等等。

张汉东

我在07年10月份到NibiruTech的时候,初次接触敏捷。当时团队内部普遍的敏捷做法是每天按时召开的例会。当时我不太明白这个例会有什么作用?一直到11月底,强烈的好奇心让我想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛,刚开始项目管理方面只是用Trac和我们公司自己写的管理系 统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就决心在公司推广Scrum。

Q2. 在实施Scrum时采用了怎样的路线,为什么这样做?

璎珞天色

我们不是采用纯粹的Scrum,而是将Agile中的很多理念,包括XP的部分做法,然后结合现有的开发环境与要求,用Scrum的回顾不断地做改进,从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review(审查)做的不好,下个Sprint就会引入新的代码Review机制。这个Sprint觉得重复性的bug较多,下个Sprint就会引入缺陷预防机制。

我们是自底向上,先做小范围试点,再全面推广,中间对过程进行不断改进:

06年3月——06年6月(1个团队,8人左右采用)
06年6月——07年12月(3个团队,25人左右采用)
07年12月——08年1月(一个部门,6个团队,50人左右采用)
08年1月——至今(异地开发,原有团队的Scrum继续走下去。异地的配合方式,工具,流程等建设中……)

kaverjody

主要是自顶向下。我们的组织太大,这样的决策权只有顶层管理人员具有。

张汉东

路线嘛,可以说是自顶向下和自底向上相结合。我把资料拿给我们的CEO看了,同时也把资料分发给同事来看。至于为什么用这种路线推广,我当时只是抱着一心想把好东西给大家分享的心态,其实也没想那么多路线。

随后笔者又向璎珞天色提问道,“在试点时是怎样的实施过程?是针对项目的具体问题,逐步采用各种敏捷实践来加以解决?还是先给团队做培训,介绍敏捷开发的理论实践,然后推行?”,她回答说:

其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商量什么时候上线,商量出来的结果是每个月定期上线。于是就有了一月一个项目的进度(我们是线上服务,没有版本的概念,有一堆需求过来,对技术来说就是在这一个月以内完成这些需求,把这一个月以内的工作叫一个项目)。然后为了管理,我们开始开晨会。然后为了改进,我们开始开项目总结会,把Product review和Team retrospective放在一起,既有产品经理介绍现状,也有大家讨论成绩,不足和挑战。后来总结会上觉得质量不好,我们加入了单元测试和代码Review机制。至于计划会议,一开始我们就采用的Scrum的方法。项目小,MS Project太难调。我们就更换了Scrum的Excel计划表,后来又换了Xplanner。

就这样走了几个月后,我们把大家叫到一起,开了一个Agile方法分享会。把大家之前实践总结一下,然后告诉大家,我们的做法就叫做Scurm ,而且它是很有名的哦。然后再把XP、Agile和Scrum都给大家系统讲一遍。于是大家如梦初醒,原来我们是在走Scurm啊~~~~!!!

同时这个项目组的成绩也得到了高层认可,高层也认为效率提高了。于是让这个团队给周围的团队做分享。并挑几个团队开始试行。因为我们团队成员可能会有轮岗和 互调,一个团队使用Project,一个团队使用Xplanner,有时员工也难以上手。为了部门管理统一,方法统一,工具统一,最后高层下令全部实施Scrum。

Q3. 在实施时遇到的最大的困难是什么,你又是如何解决的?

璎珞天色

首先应该解决领导的问题,解决方式就是拍晕他。拍的方式,一言难尽啊。至于接下来,说实话,我觉得推Scrum这种方式还是很容易推的,不过是一种管理理念。比当年推CMMI那种东西好多了。最困难的是你要不断解决暴露出来的问题。比如说,以下这些呼声:

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。

张汉东说道:

我们公司目前实施Scrum的状态可以说是比较顺畅。所谓的顺畅,也许也包含我自己对Scrum理解不太深入,只是抓着一些自己理解的皮毛来加以应用。但我对敏捷的认知,对Scrum的认知就是那么一条,不断地迭代,不断地成功和失败,找到属于公司自己的Scrum。在有一个项目里,因为需求不太明确,所以在sprint计划会议制定backlog时,粒度控制不是很好。我们的做法是,根据已知的需求先把要实现这个迭代的总体技术步骤列出来,以实现次序做为优先级……我们的迭代期很短,这次是10天。这样大概就可以在整体上把握项目的进度了。然后在每天的每日例会上大家都会有计划地把今天要做的Item写到看板上。这样有个好处,就是激发团队成员的自我管理意识,从而增进团队的自组织能力。

Q4. 采用Scrum后给项目、给公司带来了哪些收益?

璎珞天色

说不上,很难去度量是Scrum给公司带来的收益。说实话,我觉得Scrum所能带来的收益是没法度量的。我们只能通过调查问卷的方式,去感性地得出它所带来的好处。我们的方法是调查问卷,截2张图下来:

kaverjody

我很难在这方面做出一些总结。我所看到的收益包括,更快地获得某些功能的使用反馈,更早地发现一些如多站点开发会出现的问题,更多的机会来发现团队之间合作的问题,并进行反思和改进。工程师在某些软件开发实践和技能方面的能力评估和增长需求(非正式评估,是在不断的开发过程中大家所感受到的能力)更加清楚明确。

张汉东

我 们整个公司现在采用Scrum式的管理,如开发部门,销售部门及HR部都会遵守Scrum规则。因为我们也是初次尝试使用Scrum,所以大家都严格遵守规则。有新人进来的时候,也没有立即给新人讲解Scrum的概念,只是让他在日常的工作中,慢慢习惯Scrum规则。公司暂时完成了两个Sprint尝试,收益不敢说有多大,起码让我们每个人每天的工作都很有目标感,让我们在客户所规定的期限里完成了那个迭代。我们正在准备启动下一个Scrum开发项目。总的来说,一句话,我们也是在Scrum的尝试中。

Q5. Scrum实施为何遭遇失败?

David

我们的问题在于,有些高层错误理解了Scrum和Agile,导致歪曲了某些东西,使得Agile变得形式化。举个简单的例子,当时的Scrum Master负责一个大项目的开发,走的比较顺利,然后有个项目经理发现这个东西挺好,就单独把Daily Scrum拿来进行推广;结果,这个经理并不理解什么是Scrum,他把Daily Scrum变成了Daily Report,而其他Scrum的精华部分都没有推广。

每个员工都要在早上固定时间开Daily Scrum,然后把当天的任务告诉给他,让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了,引起很多人反感;另一点就是很多人认为这样的Daily Report太频繁太低效,而且还有压榨员工的嫌疑。所以逐渐大家谈起Daily Scrum来都是恶心的不得了,于是经理也知趣地取消了Daily Scrum,再到后来在公司内部就没有人谈什么Agile了。

赵师容

我们是分布式开发,当时中方的团队对于敏捷开发只是一知半解的水平(当然,我们都确定外方团队也好不到哪里去)。某一天,国外的PM突然发来几个链接,一看讲的是一个闻所未闻的词,就是Scrum了。好像就给了一两天的时间去看Scrum的介绍文档,然后就开Stand-up Meeting(站立会议)。其实大家都知道沟通进度的重要性,但我们双方7、8个小时时差,那边一上班这边就快收拾东西走人了,就这样还要讲自己今天要做些啥,遇到啥困难,一点意思都没有。而且最关键的问题在于双方文化差异,语言差异,还有项目的整体规划协调。很快Stand-up Meeting就成了形式。后来,我们又间歇性地在自己团队内部做Standup,但最后还是因为不能带给我们太大价值,流于形式,就放弃了。

再 说其他方面,我们没有计划会议,有名义上的Product Owner,但是他不跟我们解释每一个Story具体的细节,也不说如何定义这个Story的完成状态。我们自己搞过Retrospective(回顾),但总结出来的看法反馈到那边就没动静,后来也不做了。在第一次使用ScrumWorks的时候,好歹Product Owner还能来设置优先级,我们估算时间,最后决定哪些故事放到下一个Sprint里面。到后来就只要是人,就能往Scrumworks上扔任务,也不 知道哪些重要哪些不重要,我们自己开发人员看着办,最后剩下几百个小时完不成再扔到下一个Sprint里面去。后来公司里又搞CMMI认证,把我们项目作为Pilot(试验),名义上是改善流程,但实际做法就是为了应付拿证,那就是一强制推行啊,把人搞得想辞职的心都有了。这个项目中间发生的事情太多了,反正磕磕碰碰的还在往前走,但现在我听见公司里有人提到敏捷就犯恶心。

小结

刚整理完这些资料,就在敏捷中国上看到在有关“敏捷测试”的话题中又出现了对“何谓敏捷”的讨论。忽然就想起了席慕容的一句诗:“生命原是要不断地受伤和不断地复原世界仍然是一个在温柔地等待我成熟的果园”。

希望这篇文章可以让尚未接触敏捷实践,或者在推广敏捷实践特别是Scrum中碰到困境的读者有所收获。

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

十分有借鉴意思 by 陈 雷

不管是成功还是失败的尝试,都是给项目管理者提供有益的参考!

Re: 十分有借鉴意思 by 霍 泰稳

文中璎珞天色提到的那个先不告诉开发人员采用的什么方法,先通过实践让大家尝到甜头,然后在告诉之的做法很有智慧。因为通常情况下,自顶向下的推行对于开发团队来说会有许多阻力,需要做大量的说服工作。而通过潜移默化的影响,就有效地将推广的被动化为开发人员的主动需求。

Re: 十分有借鉴意思 by 亮 徐

这样的调查很新鲜,能收集到真正使用这些技术的人员的真实感受,对更清晰地认识某一个开发方法或者技术大有帮助,李剑能否对XP、结对编程什么的再做些调查啊?虽然这些概念提了很久了,但具体什么人什么团队在用,效果如何,好像还没有类似的介绍文章呢。InfoQ中文站应该带头做一下。

Re: 十分有借鉴意思 by Jacky Li

谢谢徐亮的建议,关于下一步进行哪些方面的调查以及如何将调查结果更好的反馈给社区,我们也正在考虑中。无论是从形式还是内容上,都力求有所改进。

有意思的调查 by Zhang Charlie

内容不错,支持!

Scrum 的收益没法度量? by Zhang Charlie


Q4. 采用Scrum后给项目、给公司带来了哪些收益?



璎珞天色:



说不上,很难去度量是Scrum给公司带来的收益。说实话,我觉得Scrum所能带来的收益是没法度量的。我们只能通过调查问卷的方式,去感性地得出它所带来的好处。我们的方法是调查问卷,截2张图下来:




看下来,感觉璎珞天色的公司做得最出色,非常聪明,很 pragmatic 和 practical,很多举措我也相当赞成。



但关于实施效果的衡量,不敢苟同。Scrum 当然也是可以度量的,敏捷度量本来就有一些客观的指标,认为 Scrum 带来的收益是没法度量的,其实是一种认识上的误区。



实际上,在璎珞天色给的图表中,已经出现了 Quality 和 Productivity 两个指标。如果对于二者的评价仅仅停留在所有人比较模糊的感觉上,可能暂时没什么问题,但如果要持续改进,好上加好,没有客观的量化数据,很快就会遇到瓶颈了。你总不能说,上次我们做得很好,这次会做得更好,下次会做得更更好,更更更好 ...



敏捷好不好,不能仅凭感性地去感觉,还要进行理性的分析。敏捷实施的效果,不但可以做到定性分析,也可以做到定量分析。最终,敏捷的好处都应该能够转换成企业真正的收益。



当你向 CEO 汇报说:“很难去度量 Scrum 给公司带来的收益”,甚至“它所能带来的收益是没法度量的”,想想看,你下次还能得到来自公司高层大力的支持吗?



所以,我的建议是(咨询顾问的惯用法):



从敏捷实施项目一开始,就可以把度量计划、衡量指标设计好,平时注意数据的采集,这样就不会出现到结束、总结的时候无法衡量的情况。



赞成实用主义的敏捷 OO 教练 张恂



www.zhangxun.com

如何让 Agile Scrum 不恶心 by Zhang Charlie

我对报告中介绍的两则失败案例很感兴趣。由于比较复杂,先评论第一个。



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

Re: 如何让 Agile Scrum 不恶心 by anchuan qian

前面贵教主分析的挺明白,怎么最后总结的时候,就走邪了?



“根源上,我觉得是这家国内知名的大型互联网公司的制度和文化的问题。不知道作为一家大公司,他们是否有一个专门负责过程改进的部门或人员。”



一个拥有 14y+ 开发和管理经验的人,做了一个案例分析,然后得出这样一个结论,是公司制度和文化的问题。这就好比你关节有问题,挂号找了一个骨科专家,然后骨科专家最后给你一个结论:你需要补钙。那你就慢慢补吧!补个5年或10年的。那时候黄瓜菜都凉了。



恩,居然还建议一个“专门负责过程改进的部门或人员”。这就无疑是说回家成立一个补钙专家小组呗。这不只是一个表象!

Re: 如何让 Agile Scrum 不恶心 by Zhang Charlie


qian anchuan:

一个拥有 14y+ 开发和管理经验的人,做了一个案例分析,然后得出这样一个结论,是公司制度和文化的问题。这就好比你关节有问题,挂号找了一个骨科专家,然后骨科专家最后给你一个结论:你需要补钙。那你就慢慢补吧!补个5年或10年的。那时候黄瓜菜都凉了。


我这里说的就是“制度和文化”问题,怎么你看不懂?


张恂:
第一次尝试是比较成功的。可惜,该公司并没有认真地组织总结成功经验,为什么 Scrum 会有效,什么是成功的关键?也没有在公司范围内有系统地进行推广,处在放任自流的状态。这样才发生了某个项目经理突发奇想,觉得这个好,就可以按照他个人所理解的错误思路来进行推广(从这点看,这家公司的执行力很强)。结局是,在整个公司内搞臭了敏捷和 Scrum,这当然不是 Scrum 方法本身的错。



还有,包括 David 在内的开发人员,其实都看得很清楚:“有些高层错误理解了 Scrum 和 Agile,导致歪曲了某些东西,使得 Agile 变得形式化”。那么,为什么大家的这种正确意见在项目团队、公司内部得不到有效的反映,从而避免错误的发生、实施改进的失败?

敏捷实施首先需要真正的敏捷专家 by Zhang Charlie


qian anchuan:恩,居然还建议一个“专门负责过程改进的部门或人员”。这就无疑是说回家成立一个补钙专家小组呗。这不只是一个表象!


敏捷实施成功的一个最起码条件:




公司内部(不管你内部培养,还是从外部请顾问)要有真正懂敏捷、Scrum 的专家吧。




在这篇报告的 3 个成功案例中,核心人物有 2 名是 Scrum Master,1 名(璎珞天色)就负责过程改进,前一家是创业公司,后两家是知名大型企业;而两个失败案例的直接原因,显然都是源于对 Scrum 和敏捷的错误理解造成的。




这些都说明了人员、专家资源保障的重要性。




对于大型软企,没有专门负责过程改进的部门、小组或人员,是不可思议的。




不要只会说风凉话,你有何高见?既然你觉得你的方子好,请给出你的诊断和良策,愿听其详。




张恂

8 年前我们如是做:任务分配的双向选择 by Zhang Charlie

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

Re: 敏捷实施首先需要真正的敏捷专家 by anchuan qian

敏捷实施成功的一个最起码条件:
公司内部(不管你内部培养,还是从外部请顾问)要有真正懂敏捷、Scrum 的专家吧。

请问是不是没有专家就不能进行敏捷了?怎么才是真正懂敏捷?什么才是Scrum专家呢?


如果您还是


专门负责过程改进的部门、小组
那就请继续很有前途的CMM职业吧!



从敏捷实施项目一开始,就可以把度量计划、衡量指标设计好

别只是站着说话,既然是你的高见,就请把你具体的度量计划和衡量指标的拿出来,给大家Show一下。



当然,高见我没有,但我肯定有话要说。不过还是先等您做完评论。

Re: 8 年前我们如是做:任务分配的双向选择 by anchuan qian

8 年前,张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上,可以说,我们在 8 年前就做到了敏捷,而且是中国式的敏捷。


我的理解能力不太好。所以很想和您确定一下,您是说8年前,你们做到了员工任务的自愿/自主分配,就说明你已经做到了敏捷,而且是中国式的敏捷,是吗?还句话,是不是就等同于:

员工任务的自愿/自主分配=敏捷=中国式的敏捷


实则背离了敏捷的基本原则

再请教什么是敏捷的基本原则?

作为管理者和架构师,我把周任务根据难易程度,分别打上不同的分值(比方 1-10 分)

请问做为管理者和架构师的你,做具体的开发工作吗?如果连具体的开发工作都不做,怎么一个人就这样武断的给所有的任务打分呢?

考核
员工每月完成任务的数量和质量情况,是绩效考核的基础和主要指标。

你一直口口声声谈文化,谈什么“提倡团队文化和集体主义精神”。现在,又提倡“考核”,让团队成员之间有直接的利益冲突,你这不是直接扼杀了前面的团队文化,你这不是在用石头砸自己的脚吗?


而且,你的所有的考核都是建立在你前面的分值上。你的分值本来就是估算,不准确,现在你又拿它做考核。这样不准确的考核,直接带来的后果就是不公平,不公正。请问这就是你口口声声说的“团队文化”吗?


有了这样一种机制,必然会在员工中间形成一种攀比,比谁完成的任务分值高,而这种攀比恰恰符合团队的整体利益,也是管理者所乐见的。


你觉得可能吗?有人相信你这句话吗?就别欺骗自己了,好不!

请加强中文阅读能力 by Zhang Charlie


qian anchuan:

8 年前,张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上,可以说,我们在 8 年前就做到了敏捷,而且是中国式的敏捷。

我的理解能力不太好。所以很想和您确定一下,您是说8年前,你们做到了员工任务的自愿/自主分配,就说明你已经做到了敏捷,而且是中国式的敏捷,是吗?还句话,是不是就等同于:
员工任务的自愿/自主分配=敏捷=中国式的敏捷


不要断章取义。



我说的是在“这一点上”,也就是说这种做法是敏捷的 practice,中式敏捷的 practice。而且我用的是商榷的语气(“可以说”)。



你给的等式是错误的。敏捷、中式敏捷的内涵当然还要丰富得多。

Re: 怎么一个人就这样武断的给所有的任务打分呢 by Zhang Charlie


quan anchuan:



请问做为管理者和架构师的你,做具体的开发工作吗?如果连具体的开发工作都不做,怎么一个人就这样武断的给所有的任务打分呢?


你怎么知道我不做具体的开发工作呢?




在我们的团队里,张恂不但做具体的开发工作,而且做最复杂、最难部分的开发工作,包括写代码,写测试。架构师自然是在这个团队里,综合技术水平最高的人,因此才可以做技术主管,而且要身体力行。我对架构师的理解一直如此。




“怎么一个人就这样武断的给所有的任务打分呢”




前面我已经说了,每周有哪些任务,任务的分值如何,可以由任何人提议(包括架构师),大家一起想任务,评任务,最终经计划会议讨论一致通过。


张恂:



这些每周的开发任务是由大家 brainstorming 共同讨论出来的,当然主要部分由架构师建议,最后由管理者综合大家的意见定夺。

qian anchuan,你的逻辑实在太差了! by Zhang Charlie


你一直口口声声谈文化,谈什么“提倡团队文化和集体主义精神”。现在,又提倡“考核”,让团队成员之间有直接的利益冲突,你这不是直接扼杀了前面的团队文化,你这不是在用石头砸自己的脚吗?


正常的绩效考核会造成员工之间的直接利益冲突,而且与团队文化、集体主义精神相冲突,扼杀了团队文化?实在看不懂你的逻辑。




不知您在什么单位工作?福利院?每天只要上班打卡,无需考核,就可以安等着领薪水了?




我怀疑您的大部分问题都是冲着 14y+ 来,是不是不服?难道张恂的 14y+ 真的让您受到了什么刺激?希望你冷静点再发言。

Re: 关于任务分值 by Zhang Charlie


quan anchuan:

而且,你的所有的考核都是建立在你前面的分值上。你的分值本来就是估算,不准确,现在你又拿它做考核。这样不准确的考核,直接带来的后果就是不公平,不公正。请问这就是你口口声声说的“团队文化”吗?


首先,我说了,任务分只是考核的主要依据,并不是全部的依据。




没错,这些分值都是人为指定的,它们只有相对意义,没有绝对意义,它们的作用只是用来相对客观地区分出一个团队中每个成员的贡献大小,所以,任务分的绝对值是没有意义的。我们最终比较的其实是成员任务总分之间的相对差值,这样就可以排出一个名次,知道谁比谁做的更好。




事实上,我们知道体育竞赛的游戏记分规则制定得非常合理,被普遍接受。而张恂的这套方案其实就借鉴了桥牌、棋类比赛的记分原理,当然简单多了。




你应该明白一个重要的原理:




没有绝对的公平和准确,只有相对的公平和准确。




你说我们的任务分值不准确,那么你能不能拿出一个更为准确、合理的考核方案?




关于公平性




我一再强调,这些任务和任务分值是在计划会议上由大家一致提议讨论通过的,而且首先这是一种大家一致认可、共同制定的游戏规则,怎么可能不公平,不公正?




难道你觉得绩效考核的暗想操作,更公平?




如果在计划会上,某人觉得任务分值不合理,他可以提出来,是定高了,还是定低了,如果大家多数接受,当然可以修改。如果大家意见有分歧,就需要像体育竞赛一样进行仲裁,而仲裁人是架构师或管理者。




在实践中,我们确实也发生过分值调整的情况,但走的也是公开、透明调整的方式,因此大家没什么异议。




敏捷 OO 教练 张恂


www.zhangxun.com

Re: 这是历史与事实 by Zhang Charlie


quan anchuan:


有了这样一种机制,必然会在员工中间形成一种攀比,比谁完成的任务分值高,而这种攀比恰恰符合团队的整体利益,也是管理者所乐见的。

你觉得可能吗?有人相信你这句话吗?就别欺骗自己了,好不!


这里我分享了一段过去的历史、经验和事实,张恂还打算把这些经验整理成敏捷组织管理模式(Agile Organizational Patterns)。




在采用了 BTA 之后,我们的团队变得更加团结,工作热情更加饱满,效率也更高,工作面貌确实发生了彻底的转变,出现了我们所期待的攀比工作贡献度的局面。同时这种更为合理的考核办法也不断吸引了外部新成员的加入。




qian anchuan,你或者任何其他人,信不信 BTA 及其效果,这些其实都无关紧要,丝毫不能改变历史和事实。一种方法是否有效,是由它的科学性和客观规律决定的。




而且从你不能理解这种机制所形成的效应来看,显然你也并不了解这样一条已广为人所熟知的经验事实和管理原则(大意):




通常只要管理者将哪些关注点/方面设定为考核指标,那么团队成员就会去努力追求这些考核关注点,并忽视/忽略其他非考核关注点,最终使得这些被考核的关注点/方面得到显著加强。


这条经验法则正是张恂当初设计 BTA 任务分配与考核方法所运用的一条基本原理。




我发现,你不但缺乏软件工程、CMM、敏捷的基本常识,也缺乏基本的管理学常识,而且明显受到了某些技术媒体不当宣传的误导。我怀疑你是刚参加工作不久的嫩手。




张恂也没有必要与一个对自己缺乏基本信任感(trust)的人进行所谓的交流,我觉得可以到此为止了。




敏捷 OO 教练 张恂
www.zhangxun.com

Re: 请加强中文阅读能力 by anchuan qian

8 年前,张恂带领的团队就做到了员工任务的自愿/自主分配。在这一点上,可以说,我们在 8 年前就做到了敏捷,而且是中国式的敏捷。

我给这个等式,明显是在帮助读者理解你的那句话。

我从没有看到也没有听说敏捷中有“过员工任务的自愿/自主分配”这个实践,在资源如此丰富的互联网上也更本找不到这个所谓的实践。那这就是你的杜撰了,哦,不,应该是创新才对。

如果是你个人的创新,我建议你就命名为“张询式的敏捷”。我个人绝对不会再有任何的非议。

Re: 怎么一个人就这样武断的给所有的任务打分呢 by anchuan qian


quan anchuan:
请问做为管理者和架构师的你,做具体的开发工作吗?如果连具体的开发工作都不做,怎么一个人就这样武断的给所有的任务打分呢?


你怎么知道我不做具体的开发工作呢?
该加强中文阅读能力和逻辑能力的人应该是你吧!我明显是在问你是否做具体的开发工作。


前面我已经说了,每周有哪些任务,任务的分值如何,可以由任何人提议(包括架构师),大家一起想任务,评任务,最终经计划会议讨论一致通过。


张恂:
这些每周的开发任务是由大家 brainstorming 共同讨论出来的,当然主要部分由架构师建议,最后由管理者综合大家的意见定夺。

你看明白了,你自己明明写的是“开发任务是由大家 brainstorming 共同讨论出来的”。这里可并没有说对任务的评分是大家共同讨论出来的,你前面只说
作为管理者和架构师,我把周任务根据难易程度,分别打上不同的分值(比方 1-10 分)

如果你觉得还没有想清楚,那可以想清楚了再写。

关于自愿任务:你在撒谎? by Zhang Charlie


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 可能并不是张恂一个人的创新,过去和现在也有很多人尝试过类似的做法,只不过我把它总结了一下,作为一种敏捷实践提了出来。

Re: 关于自愿任务:你在撒谎? by liu ozzzzzz

张导师真的厉害,几下子就把西式敏捷给干掉了,看来中式敏捷真强大啊。
不过这里张大师的说法我觉得应该自己回去好好在过一下大脑思考思考。并且我觉得以张大师十四年的经验和中西贯通,以及文化、哲学全都深入了解,应该不会不知道“自主工作”和“自愿工作”以及“自主任务分配”这些概念之间的细微差别。
最后我想问问张大师是否认为真正的存在“自主任务分配”,是否可以给我们解释一下啥叫自主分配任务。至少从这一点上我觉得张大师是完全的背离了敏捷的方法,而更加类似重型的方式,也就是完全把人当着一组可以被看做无个性以及无性格的组建。
我希望张大师好好解释一下我的这个疑惑,同时也给大家解释一下我这个疑惑究竟是怎么来的。

Re: 关于自愿任务:你在撒谎? by anchuan qian


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年多来苦苦奉首的团队文化和原则。

我发现,你不但缺乏软件工程、CMM、敏捷的基本常识,也缺乏基本的管理学常识,而且明显受到了某些技术媒体不当宣传的误导。我怀疑你是刚参加工作不久的嫩手。
你这么武断,不尊重事实,就下这样的结论。我很怀疑,有人敢找您去做咨询。不过,说实话。我没有您14y+的工作经验,也没有您那么高的学历,更不能向您那样8年前就开始敏捷了。不过,我还确实在用敏捷,也就才用了4年而已。

这样跟您沟通真费劲,本敏捷Developer还是去写自己的文章了,我会发上来,如果您有非议,欢迎教主的宝贵意见。不过,“保护环境,人人有责”。如果是错的东西,我一定会站出来指正的。

Re: 关于自愿任务:你在撒谎? by Zhang Myhui


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年敏捷所获得的经验和知识与大家分享,而不是缺乏理论支持的技术攻击。

Re: 关于自愿任务:你在撒谎? by Zhang Myhui

张导师真的厉害,几下子就把西式敏捷给干掉了,看来中式敏捷真强大啊。

不知道您从哪里看出来“张导师”把西式敏捷干掉了,他只是把他的敏捷实践称之为中式敏捷,太极敏捷啥的,也没有说西式敏捷不行啊,需要被“干掉”啊。

不过这里张大师的说法我觉得应该自己回去好好在过一下大脑思考思考。并且我觉得以张大师十四年的经验和中西贯通,以及文化、哲学全都深入了解,应该不会不知道“自主工作”和“自愿工作”以及“自主任务分配”这些概念之间的细微差别。

请不要在这里鼓捣文字游戏,请直接指出其理论或实践的错误之处。


最后我想问问张大师是否认为真正的存在“自主任务分配”,是否可以给我们解释一下啥叫自主分配任务。至少从这一点上我觉得张大师是完全的背离了敏捷的方法,而更加类似重型的方式,也就是完全把人当着一组可以被看做无个性以及无性格的组建。
我希望张大师好好解释一下我的这个疑惑,同时也给大家解释一下我这个疑惑究竟是怎么来的。

请问,“这一点”是哪一点,他的实践背离了敏捷的方法,更加“重型”?并且“完全把人当着一组可以被看做无个性以及无性格的组建”?我反而觉得就是因为程序员不是毫无个性和性格的工作者,才会出现敏捷方法对“人”的更多思考和重视,才会有sprint task的自主分配,才会有张咨询师文章中所实践的自主分配方法,您竟然从张咨询师的文章中得出完全相反的结论,实在是太“有趣”了。
敏捷实践,尤其是Scrum这种方法论的实践,本来就是会因人、因环境而变化的。张咨询师提炼出了他在工作中对Scrum的理解、总结和一些实践心得,是很好的啊,虽然其中夹杂着一些广告式的话语或令人不爽的语气,但的确言之有物。
遗憾的是,您的反驳中没有确实的基础和论据,也没有自身敏捷实践的经历心得,让我这个等待不同技术观点发生碰撞的菜鸟,颇为失望。

thanks, Jun by Zhang Charlie

this community definitely needs more sane practitioners like you, other than those two.

Re: thanks, Jun by 冯 尚

this community definitely needs more sane practitioners like you, other than those two.

貌似您二位都姓张

Re: thanks, Jun by Zhang Myhui


我就知道有人会注意这个,:),如果用马甲,还会用类似的id吗?还有特别有意思的一点,我竟然发现这里还有文章后面跟着的回文,也是“Jun Zhang”,我还以为是我的id被盗用了呢,可能是重名,真是巧合阿。不得已,把我的名字改一下,要不然,看着一样名字发表的回文,还真别扭。

无所不包的敏捷和中式的张掌门 by liu ozzzzzz

我有几个问题想请教一下张掌门。
张掌门是搞过cmm的,也是精通rup,对重型方法和传统的软件工程思想是心知肚明的。现在又扛起了敏捷的大旗,自然无人可比,做起了敏捷的教练,是专家级别的任务了。我本是一个草寇,只会叽叽喳喳,不懂软件工程,更不懂敏捷。但是还算认识几个字,但是不敢张扬,只能在厕所里面偷偷看看书。可惜眼睛不好,灯光也黑暗,记性也差,很多东西都忘记了。现在就只能请张掌门这个专家来给我指点指点。
第一我忘记了度量,是不是cmm的一个要求,又是几级的要求,而为啥要把可度量安排在那个级别做要求。而我也忘记了敏捷度量里面都有啥内容,其实又在什么地方说了应该在首先就建立其度量的指标体系。同时我还想问问为什么还需要平时注意采集,而就不能到最后复习或者叫回顾的时候再去收集。
第二我想知道张掌门是否知道,David所在的公司实施SCRUM的具体目标是什么。而假若真如教主分析的,这个经理的目标在于加强控制,这个目标是否已经可以通过他们的这个手段达到了。而他取消了实施SCRUM是因为大家的反对,还是因为目标没有达到。我这个糊涂,而且能力低,没啥管理能力,所以经常见到有人反对敏捷(包括你老我前几年记得你一直是反对我们推广敏捷的,并且一直是重型方法的坚定支持者),所以如果那些人就是反对敏捷的SCRUM,那又如何。况且我私下以为,敏捷的方法强调沟通,主张信息的顺畅交流,那么是不是需要尽量保证人员的在场率为好。况且任务饱满不饱满,领导是不是有责任知晓,是不是有责任调节。难道SCRUM就是大家都自我中心,自我管理?每日晨会自然是有暴露风险,这么一个单一的简单目的,就不能有其他的目的吗?而且管理是不是也可以算一种服务呢?同时调度是不是一种管理的职能呢?
同时我又好奇,难道所有的敏捷实施都必须得到高层的主动推动吗?我咋记得有很多人一直在讨论由底向上的敏捷推广措施呢。并且一次成功是否就已经说明了敏捷的巨大优势,公司领导就该重视,就该总结经验,就该全局推广呢?难道他们就不能再等等,再看看。
我这个人比较笨,做事情经常失败。所以我觉得失败一下很正常,也可以学到很多东西。但是需要总结和实际调查。
而我注意到您的分析过程和结论都是建立在“我猜”的基础上的,你觉得以这样的态度去分析问题和推广敏捷是不是可取的呢?
第三您说:“敏捷实施成功的一个最起码条件: 公司内部(不管你内部培养,还是从外部请顾问)要有真正懂敏捷、Scrum 的专家吧。”
那么如果没有这样的人,我们是不是就该等着,就该盼着你这样的专家从天而降呢?
而且既然我们不能真正懂敏捷,我们怎么辨别这个专家是真懂敏捷还是假懂敏捷呢?
再说您能说说在国内有几个可以被您认可的敏捷专家,这些专家又都是什么价格。如果太贵,或者资源不足,那是不是说请不起的请不上的就该不去敏捷呢?

Re: 无所不包的敏捷和中式的张掌门 by liu ozzzzzz

我还有几个问题有点我的认识,需要同你探讨。
是不是所有的好的东西,都是敏捷的呢?是不是只要是好的,敏捷也就该包括进去呢?
同时我还想跟你讨论一下您那个中式敏捷的实施方法。你一周的任务计划讨论和分值评定,要经过多少时间进行呢?而分数的分配又是如何在最后评估讨论的呢,这个过程又需要花费多少时间呢?同时大家抢任务,都怕不够饱满,那么会不会造成任务过量,从而造成计划的高估呢?而大家存在将分赠送的情况,但是如果大家互相攀比,会不会造成各自之间的矛盾呢?而且由于任务都具有相关性,而每一个人都会有数个任务,那么与别人相关的任务究竟该依照什么原则进行开发呢?同时您又是如何对任务完成的质量进行评估的呢?有啥计量的措施保证吗?而且一个质量问题,你是先定位还是先解决。如果先定位您又是如何定位,并且这个定位会耗费多少时间呢?如果是先解决,那么又该是谁去解决呢?而假若A去给B解决了问题,而B认为A其实是在捣乱,那么您又如何解决这个问题呢?
问题太多,我实在是笨,想不明白。就先问您这么多。等你给我解释清楚了,我再继续问。

Re: 关于自愿任务:你在撒谎? by liu ozzzzzz

我是一个粗人,不懂啥理论,也没啥实际的经验,更加不懂啥技术。所以自然指不出啥问题。
不过我是没看出张教主的讨论中有啥部分是涉及了他对SCRUM的理解和实践。你再啥地方看出来的?
而您说的张先生的自主分配究竟又好在啥地方?而且您有凭什么说那个是sprint task的自主分配?

另外我很遗憾的表示你误解了我对张询先生的看法,我是充满了善意并且绝对的没有人身攻击的意思。这是因为我前几年创造杂技派的时候,早就说过等哪一天敏捷成了主流了,某些现在这么反对我们的人会把不跌的说自己敏捷,并且比我们大家还敏捷。我想以张先生这么高的人格,这么好的素质,这么高深的学问,不会这么急不可耐的来印证我这个话的。

关于这个调查 by liu ozzzzzz

这个调查做的很好,因此我希望这个调查再深入一下,并且这个意见也已经传递到了。
实际上就目前这个调查来看,还不能说有成功的案例,最多也就是走向成功的初期。并且各家的情况都存在许多问题,但是由于我的资料来源限制,我不好公开讨论这个问题。
但是有一点我想说一下,就是在实施任何过程改进前(不管你是实施敏捷,还是去实施重型),都要有明确的短期目标,也要有长期的战略考虑。战略考虑方面是公司高层的工作,我不想多说。我只说说短期的目标。
首先一定要明确具体,不能笼统概括,而不能把手段当成了目标——除非这个手段是下一个目标的前提条件。
比如你说为了加强交流,这个说法就很难被量化,也很难被判断究竟是不是成功做到了。而如果你说要做到任务当天全员明确,并且相互明确,这个说法就实际一些。
在比如你说要解决产品路线图不明确的问题,那么你就应该明确的说是要找到一个应对产品路线图不明确这个问题的解决方案,还是找到让产品路线图明确的方案。这两者大有不同。

同时我们还要注意,短期目标一定是短期的,别你来一个一年内我们要如何如何。
因为一次不要胃口太大,少选择几个目标,选择几个重点的目标,逐步的解决。

同时我希望那些才开始SCRUM人士应该多学习一下敏捷各个方面的的知识,特别是其他方法的内容。同时还要学习一下管理和财务,以至于心理学方面的一些内容。同时要搞清楚方法的内核,不要啥好的都是SCRUM,不好的都是不是SCRUM。

同时也要明确,我们是来优化我们的工作的,是来完成我们的工作的,至于敏捷不敏捷其实不是大问题。关键还是务实而有效。

Re: 关于自愿任务:你在撒谎? by Zhang Myhui


不过我是没看出张教主的讨论中有啥部分是涉及了他对SCRUM的理解和实践。你再啥地方看出来的?


而您说的张先生的自主分配究竟又好在啥地方?而且您有凭什么说那个是sprint task的自主分配?


只讨论一下工作任务分配这个问题。


不论是Scrum、xp这种敏捷方法,还是RUP这种相对比较传统的重量级方法论,在具体实施的时候,都有一个共同点,那就是必须根据组织或公司的实际情况,作出一定的调整,不能生搬硬套。对于Rup这种阶段、角色、制品、流程等内容都很清晰和标准的方法论,会适当的进行“裁剪”,才能更好的发挥作用。而像Scrum这种看起来很“简单(角色定义少、过程定义简单、流程简单...)”的方法论,在实施时,因为方法论本身并没有提供实践指南,很多活动描述的也不清晰,则需要更加仔细的进行裁剪和调整,才能取得效果。


具体到工作任务的分配,Scrum只说当工作任务评估完成后,小组成员自己选择任务,然后就可以干了。这就带来很多问题了,如果某个任务没有技术含量,技术人员谁都不愿意选择,该怎么办?如果某个任务涉及到一种新技术,很多技术人员都想去尝试一下,都想选这个任务,又该如何处理?工作任务分配好了,最终采用什么标准考核呢?这些都是会影响实施效果的实际问题。在“张教主”的回文中,他总结了一种工作任务的评估和分配方法,而且,我觉得并不违背Scrum的原则,还取得了很好的效果(鉴于他文章的描述),这不是在理解Scrum的基础上的实践吗?可能我见识浅薄,学识粗鄙,但我的确觉得这是很好的实践。当然,这是建立在他说的情况是真实的情况下的结论。




另外我很遗憾的表示你误解了我对张询先生的看法,我是充满了善意并且绝对的没有人身攻击的意思。这是因为我前几年创造杂技派的时候,早就说过等哪一天敏捷成了主流了,某些现在这么反对我们的人会把不跌的说自己敏捷,并且比我们大家还敏捷。我想以张先生这么高的人格,这么好的素质,这么高深的学问,不会这么急不可耐的来印证我这个话的。


我并不是根据您对张询先生的看法如何才进行回复的,这一点,请您首先明确。我只是想讨论技术问题。从他的回文中,我看到了他的一些实践心得,也想从您这里看到一些您的经验,仅此而已。如果太纠缠于一些和这个主题没有关系的内容,就没什么意思了。

Re: 关于这个调查 by Zhang Myhui

同时也要明确,我们是来优化我们的工作的,是来完成我们的工作的,至于敏捷不敏捷其实不是大问题。关键还是务实而有效


严重同意此观点,不论是叫啥名字的方法论,能取得好效果的,就是“好猫”。

Re: 关于自愿任务:你在撒谎? by liu ozzzzzz

事情不是那么简单,我的意思你也没有完全理解。而我也不想去揭短,所以就不会去再告诉你我的上面的那个分析的全部内容,以免你说我是纠缠于细节,而和主题无关(其实大大的有关)。我仅仅是说说有关一些你的看法的内容。
首先我先说说我对你的发言的一些看法,这些内容不是你所关心的核心所在,但是我却以为是对SCRUM方法的的关键点之一。首先就说RUP的内容是否清醒,这个问题一直引起很多争论,我觉得不需要多说,你可以自己找资料看看。其实这里主要涉及的是RUP这个方法裁剪的困难,以及为何产生这些困难的原因在哪里。这个问题其实可以引起很多我们关于SCRUM方法的思考。
而就SCRUM来说是否是一个流程都很值得深入的进行讨论,我们姑且算它是一个流程,但是这个流程的输入与输出以及处理过程都很模糊。而显然其同RUP相比较来说其显得不足,而RUP显得有余。所以其实应该是对RUP进行裁剪,而对SCRUM进行补充。而实际上我们分析SCRUM的核心内容,少之又少,基本几分钟就可以把这个东西说清楚,也可以侧面说明这个问题。
而请参考在敏捷中国上关于scrum这个方法的讨论,我的观点是这个方法根本都算不是上一个完全的方法,更不是框架。而就是这种特点,才是其强有力的可以适应于多种范围的基础。这些我就不多说了。
而就任务分配来说,我想任何一个方法都在实施的时候都会涉及这个问题。那么是不是我们只要讨论了认为分配,那么就是同scrum相关呢?这逻辑我想你应该明白。当然这个问题我们可以不讨论,即便这样我觉得这样不科学,也不逻辑。谁叫我是一个只会叽叽喳喳的草莽呢。
但是问题在于scrum的方法其实本意是说,把任务划分完毕之后,就又对开发者自由的选择任务,并自主的通过协作完成,这里不存在啥领导分配和调节的问题。当然这样的做法其实我也是持保留意见的,因为我认为这样的做法其实是没有从源头考虑到开发者是具有不同特征的人这样一个前提的做法,是旧有的重型思维的遗存。但是这个问题我不想展开,你也不必过于深究。但是这里我们可以看出,张询教主的做法是同scrum以及xp的不是十分相同的。
而且他说那个时候他就在这一点上做到了敏捷,但是在这一点上敏捷的方法系统中有多种做法。比如你可以去参考FDD,那里的做法就完全不同。因此至少他在这里的说法,就是不准确的,不严禁的。
而这些也不重要,我们还是说说,任务如果这样子分配,会不会最终有些任务就没人去做了。其实这一点早就有过讨论。其实在实际中无人认领的情况很少出现,大部分情况下任务都会被简单的领取。而那些开始被认为很难被认领的任务,其实还是有人愿意去尝试。这一点可以看看www.china-pub.com/6377,《规划极限编程》第98页的“苦活”。
当然我并不是十分赞赏这样的做法,因为我任务从源头上来说,设计和计划分配就应该考虑到将要完成这些结构和任务的人的情况。这里我不再多说,我们来看看张询教主的做法。
他的做法他说的很清楚,其实就是自愿选择和领导支配相结合。我想绝大多数情况下,大家所在的开发团队也都是这样做的,只不过是领导支配的权重与自愿选择的权重谁更大的,大多少的区别。这一般情况下只存在做的好与不好的问题。这个问题其实本与scrum没啥关联,你在实际中可以用也可以不用,关键是你团队究竟适应于什么你自己要清楚。而且假若有人就是能力强大到可以把认为分配的均匀,叫开发者选择任何一个差别也不大,并且开发者自己也清楚这一点。那么这个时候开发者,自己选择是自由选派,还是领导指定,以至于大家抓阄,或者干脆按照工号轮流选择又当如何。也就是说其实在这里存在的问题是,在根据你的具体情况选择一种分配的方式,并且根据变化进行调节。
同时这里还有一个问题是这里没有涉及到的,但是有十分重要的。那就是任务和故事不能画等号。这个方面的内容如果有人想讨论,我在多说点。
而进一步张教主的那个分数的做法,我想可能是适应于他们的团队。但是未必适合所有的团队,而且很可能会是不适合绝大多数团队。这里涉及到是绩效考核的问题,这个问题复杂而针对性强,可以说不同的组织都会有不同的策略。而他那样做也有很多弊端有可能出现,并且操作起来成本一般不会很小。这一点我想你可以自己去分析,也可以参考上面我讨论的时候提出的问题进行思考。我就不过分多说,以免得把话说的太清楚了会有不好的结果。当然如果你觉分析不出,你可以分析分析有些单位按照bug数目扣钱的问题做个参考。而他的做法同这个做法很类似,但是后果会更大。具体是好,是坏就要看各自组织和项目的具体情况了。但是我至少认为,能够这样实施的场景少而又少。(可以主要参考我11:35的发言,当然如果能够全面思考我所有的内容更好)

同时我再次强调,我这里的任何发言都与主题有密切的关系。只不过各人的情况不同,看到的也不会相同。但是我不想纠缠于一些细节,也不想把问题说的过分清楚。大家可以各自动脑筋去思考思考这里的逻辑,以及同自己的实际情况结合做做沙盘推演。当然如果你真的仔细阅读了我的发言,就会看出点端倪。那些发言看似很分散,但是其实联系紧密。
我说了这么多,其实就这一段同主题关系不大。而仅仅是为你个人所说。

Re: 关于自愿任务:你在撒谎? by liu ozzzzzz

最后我还要再说一下关于张询先生的问题。
前几年张询先生貌似要同我有点冲突,我也一直等着他来找上门讨论清楚问题,而且我也很愿意同他们讨论——无论是公开的还是私下的。
而就在最近张先生说他是敏捷的(其实早在几年前我就开玩笑的说,他早晚会说自己是敏捷的),并且多次表达出他老早以前就是敏捷的。这样的说法是不是实事,是不是真相我觉得是他自己的问题。而他对敏捷的一些解释,比如敏捷就是快,不快就不敏捷等等我是说什么也不会认同的。而大家也可以通过我们发表的言论看看张先生的中式敏捷,同我们这些草莽的敏捷是不是差别很大(至少我看是差别很大,从世界观到方法论再到具体的实践都很有距离)。而张先生也会面临一个问题,那就是如果别人也如我一样关注敏捷很久,并且也一直关注国内的讨论,特别是看了张询先生的文章好几年,有些事情他需要找个机会好好的说清楚。而且即使你现在看看他的观点,他对重型方法(比如CMM那套东西的态度)也还是很暧昧的。
其实如果他能够把很多事情说开,明确的告诉大家他前几年的观点是啥,现在的观点又是啥,是怎么一个发展的轨迹。同时虚心的把自己的情况好好的说个清楚,少把话说的太满会少很多争议。
同时我也劝张先生要明白一些基础性的问题,特别是看明白立论和驳论的不同。不要急于冒进,好好的把自己的想法和做法完善,形成系统,这样会好很多。
任何事情都需要积累,不要以为自己是专科毕业,又有多少年经验就如何如何,未必这样就能成为一个专业人士,更别说是专家。同时少一些急功近利的巧计,多一些实在的总结会好很多。同时也别被一些学问外的东西所拖累,不要分心。多做研究,多做分析。也别把事情想的那么简单,以为把几种东西做个混合就能成为一种新的有用的学术说法,至少要把逻辑线索和内在的构成搞清楚一些。
这些算是我对张先生的一些建议,也是对需要人的建议。当然我这个人比较笨,也没啥学问,更谈不上啥经验,更没有啥资历,自然没有这个的资格。就算我自说自话好了。
说了这么多主题无关的话,大家请谅解。

Scrum 在中国—关于企业实施的真相 by Zhang Charlie

我给大家提供一点信息。



本篇报告中的 Scrum 应用其实还是比较初级的,5 个案子,3 个成功,2 个失败(极其幼稚的失败)。Scrum 在国外出现和流行其实已经许多年了,只是在近期才逐渐得到国内的关注,这有个信息传播延迟和信息不对称的问题。



前些日子,我曾经向微软国内一位作资深研发经理的朋友打听,他告诉我他们确实有不少人在采用 Scrum。同时,张恂也查到了来自微软研究院的一篇调查报告,介绍了敏捷方法在微软公司内部的应用情况,数据表明有将近 60% 的调查者声称他们采用了 Scrum 方法。



我们可以大致得出这样一个印象或结论,这些年 Scrum 等敏捷方法首先在美欧的一些软件研发领导企业、先进企业中得到了积极应用,他们引领了世界范围内敏捷运动、敏捷实践的潮流,而国内的大部分软件企业、研发机构目前其实还处于观望、了解、学习、模仿和跟进的初级阶段。




Large Scale Scrum 与敏捷的前沿




如今,十几个人乃至几十个人的项目团队采用 Scrum 管理方法,早已不是什么难点,可谓小菜一碟。Agile offshore 以及更高级别的、大规模的(涉及成百上千乃至数万人的)、分布并发的、企业级的敏捷和 Scrum 实施才是国际上敏捷软件工程的难点和前沿之一。




敏捷大师 Craig Larman 近年的工作成果和贡献是,升级了精益与敏捷方法,以支持规模为 200-2000 人的单个产品研发团队,分布式、多站点、离岸式外包开发团队,以及大型企业(10,000+)的精益和敏捷组织变革。他将自己的这套经验总结为 LSS(Large-Scale Scrum)方法,并且在遍及亚洲、欧洲与北美的的客户,如通信和大型嵌入式系统领域的 Nokia、Siemens、NSN 和 Xerox,以及全球金融和其他行业领域内的客户中得到了成功应用。




最近,有几家国内排名前 20 的大中型软企与我和 Craig Larman 联系。他们在实施了 CMM/CMMI 体系若干年之后,正在寻求新的改进和突破方向,如何进一步提高效率、优化流程、更有效地面对日益激烈的市场竞争。我想,这些企业的举动也代表了一种正在发展中的良好趋势,相信今后国内的敏捷过程改进实施成功案例将来会越来越多,不但会有许多中、小企业投入敏捷浪潮,许多实施了 CMM/CMMI 的国内大中型软件企业也会同时考虑、借鉴敏捷过程改进与实施,这是可以预见到的未来。




敏捷大师 Craig Larman 是跨国企业 Valtech 公司首席科学家,而 Valtech 在印度就有一个将近 500 人的达到 CMM L5 的研发团队,Valtech 是世界上为数不多的做到 CMM 与 敏捷有机结合的先进企业,我想这方面的经验也可以供许多国内企业借鉴。




在过去几年中,Craig Larman 已经多次来到中国(他现在就在杭州为客户服务),帮助中国的企业(目前主要还是大中型外企)实施 Agile、Scrum 和 Lean 原则与方法,取得了显著的成功。而这些成功、成熟经验都将反映在他的新书 Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Products with Large-Scale Scrum 中。




所以正如作者所言,本报告中所反映的事实和案例仅仅是一个小小的、初级的开始。




我建议国内广大的敏捷初学者、爱好者和实践者们,更多地抱有一种科学、理性的思维,拿出 humble、respect、appreciate 的专业心态,切忌自恋、狂热、狂妄与偏狭、偏执,做到眼观六路,耳听八方,虚心学习,认真实践,这样才有可能获得更多的收获和更大的成功。




* 如需要,张恂可以帮助您联系 Craig Larman(他的服务预约通常要提前 4 个月以上,非常忙)。




Craig Larman 英文站 中文站<>

Re: 关于自愿任务:你在撒谎? by Zhang Myhui

说了这么多,看来您和张询以前还是交流过的,只是观点不完全一致。诚如你所说,Scrum本身有很多模糊的地方,在实施时,非常需要懂得Scrum的人,根据不同的组织特点去进行。从您洋洋洒洒的大段文字中,我能看出您的一些心得体会(就是写的有点散,得仔细看),受教了。敏捷方法学进入中国,在目前这个阶段,正是百家争鸣的时候,不能说只有一种正确的实施方法,谁谁的理解就对,谁谁的理解就不对。因为每个人的经历,其所处的环境都不相同,肯定得出的结论是会有差别的。希望看到您将您的敏捷心得和体验整理出来,大家互相学习吗!


我比较奇怪的是,您为什么总称自己是草莽敏捷?真的很好奇。

Re: 关于自愿任务:你在撒谎? by liu ozzzzzz

可以说我们同张询先生关于敏捷的看法完全不一致,而不是“不完全一致”。这种观点从几年前就开始,并且到今天即使他声称自己是敏捷的教练,是“中式敏捷”的创始人,依然可以说完全不一样。
而我不认为现在是敏捷方法进入中国,其实早就几年前敏捷方法就进入了中国,并且一直就在自己的轨道上良好的发展。而且也一直没有所谓百家争鸣的说法,大家只是按照各自的情况在努力实现一种目标。并且在其中逐渐得出,虽然敏捷的方法很多,但是对于敏捷的正确认识却只有一个,不会存在多种的敏捷,更没有所谓多种的结论。
关于我对敏捷的心得和经验,我一直在整理,也一直在相互学习。这个事情我做了几年,至少从我叽叽喳喳的草莽生涯开始前就开始做了。我也已经总结的太多,说的太多,因此有些事情我不喜欢太多费口舌。同时我也要说,同张询先生的交流还是很早很早之前了,还在他大战高展之前。但是从那个时候我对他的为人方式和为学方式就很多地方不能接受,但是我这个人觉得我没有义务也没有责任去管别人的事情。只不过后面张先生一边声称自己发现了银弹存在的证据,一面对我们一些人发出要讨伐的威胁,我们才知道原来张先生根本就同我们不是一类。而后面他到所谓腾讯等地做了培训,我们也进行过了解,得到的结论更加证实他的做法和想法同我们有本质的不同。

其次目前还有一个情况是,敏捷在国内存在着一种庸俗化的趋势,很多人觉得敏捷时髦,来附庸风雅的。特别是最近掀起的scrum热潮更加是虚火上升的体系。重多没有接受敏捷思想的人,仅仅是经过一个短短的培养,就操起了各种各样的旗帜,声称自己是敏捷的,他们的方法是敏捷的,并且得了谁的真传,如何如何有效,并且做出各种各样的承诺,貌似只要上了他们的船,就会乘着敏捷的东风一直开到各种不同的成功的彼岸,可以说敏捷是个cmm之后又在冉冉升起的新星。
我认为距离敏捷成为一种流传广泛的谬误的时间已经不短了。因为众多的人即没有兴趣去研究敏捷的历史,更加没有兴趣研究敏捷在国内推广的历史;也没有心思去研究敏捷具体的内容,更加没有兴趣去研究各式各样的敏捷方法的实现。他们仅仅是追随着人们口中词汇出现的频率,忙不迭的去追求花哨而流行的名词。
不用几年,我们就会在生活中听到这样的话:
“听说你们在实施敏捷?”
“你才敏捷呢!你全家都敏捷!!!!!!”

o6z 这一派的:熊节忽悠敏捷 XP by Zhang Charlie

熊透明忽悠敏捷 XP:评《敏捷的迷思与真实》



这就是他们所谓的敏捷。作为“颠覆软件工程话语体系”的旗手,熊节发表这篇文章的时候,有几年编程经验?居然还是主持了 Fowler 演讲后,假借“教父”的“旨意”。



o6z 和熊节是一伙的吧,现在有点气急败坏了,鄙视!



熟悉这段历史的朋友们可能知道,我在网上批评这群人(包括熊节、o6z等等)其实已经 n 年了。



对于基本专业素质、人品很差的人,我觉得完全没有必要理会。



敏捷 OO 教练 张恂


www.zhangxun.com

o6z 是谁?网混? by Zhang Charlie

有人说是什么大名鼎鼎的江湖人士?



我观察了 n 年,认为 o6z 不过是一个混混的网名,泡分的高手,搞网络政治斗争的吵家。



o6z 对国内的敏捷软件工程到底有什么具体的贡献?除了一些牢骚,多年来针对张恂品格低下的人身攻击之外还有什么?



这些年来,o6z 有什么专业的文章发表,有什么系统性的论述或结论,为大家所熟知,所热议?哪怕一篇像样的、可供大家研究、讨论的专业网文,有么?



我总结不出来,我的印象中好像是没有(容我的固陋寡闻),或者概括不出来,有的只是网络上无数的帖子,杂乱无章的、偏激偏狭的观点。我估计,其中至少有 50% 以上的观点是错误的,经不起逻辑的推敲。



而且,可笑的是,n 年过去了,o6z 都只躲在阴暗处,至今不敢亮明正身。



所以,我的鉴定意见是,o6z 大概既不是专业的程序员,也不是专业的管理者,有的大概只是对敏捷的狂热,对张恂提出太极敏捷的着急和恐慌。对于此类有品格缺陷的网络虚拟人物,张恂的办法是:视而不见。



相比之下,张恂在过去 8 年中,在杂志、网站上已经发表了不少专业文章,有很鲜明的专业观点和论据,也有不少客户,干得都是实事!



即便熊节,作为高产作家,也有很多可供大家研究的文章发表。



那么,o6z,你有什么东西?你算什么东西?



敏捷 OO 教练 张恂


www.zhangxun.com

哈哈 张教主终于忍受不住 by liu ozzzzzz

我是和gigix很熟悉,这在张教主看来就是一伙儿。不过我想我们这一伙儿人也太多了,包括你批过的好多人我们都认识,在你眼里面都是一伙儿。这里面的一大串名字我就不说了,大家可以自己去查一下。
哈哈,我想着又多了个名号叫网混,而且仅仅是虚拟人物。所以张询教主就选择对我视而不见。
当然咱们即没有啥专业文章出版,也没啥专业的论文发表。自然就是没做啥具体的工作了。
不过张先生对我还可以,说他估计我的观点至少有50%是错的。那我是不是还有点正确的呢,哈哈,要是有点正确的我就满足了。
而且叫张教主说对了,我即不是专业的程序员,也不是专业的管理者,我就是一个敏捷的狂热分子罢了。但是我并不会对张询先生提出的敏捷太极感到恐慌,昨天不会,今天不会,明天更不会。并且我十分盼望张教主的作品赶快完成,别再拖了。我这个愿望很真诚,也很强烈的。而且我们保证有这个愿望的不是我一个人,而是我们众多的躲在暗处的人希望啊。
哈哈,继续躲到暗处去了。

Re: o6z 这一派的:熊节忽悠敏捷 XP by Jacky Li

熊透明忽悠敏捷 XP:评《敏捷的迷思与真实》

这就是他们所谓的敏捷。作为“颠覆软件工程话语体系”的旗手,熊节发表这篇文章的时候,有几年编程经验?居然还是主持了 Fowler 演讲后,假借“教父”的“旨意”。


唉,三年了啊,教主您就省省吧,揪一根辫子揪三年,您手不累么?

Re: o6z 这一派的:熊节忽悠敏捷 XP by Xiong Jeff

熊透明忽悠敏捷 XP:评《敏捷的迷思与真实》

这就是他们所谓的敏捷。作为“颠覆软件工程话语体系”的旗手,熊节发表这篇文章的时候,有几年编程经验?居然还是主持了 Fowler 演讲后,假借“教父”的“旨意”。


唉,三年了啊,教主您就省省吧,揪一根辫子揪三年,您手不累么?

重点在于三年来他都还看不出这到底是揪着谁的辫子
骂人固然很有趣,然则骂了他不懂,三年后他还看不懂,这就没趣了
所以俺现在不搭理他了呢

Re: o6z 这一派的:熊节忽悠敏捷 XP by liu ozzzzzz

不过他现在应该能承认有些cmmi5的企业配置管理的基本策略和集成策略存在巨大缺陷这个实事了。好歹他也是应该见识过点场面了。至少我这个虚拟的躲在暗处的人网混都看得见这样的实例,他这个具备专业素质,又有科学的逻辑思维能力,还受过专业训练,又有14年以上的的经验的专家和智者,应该会看到了吧。
我还是继续躲起来不叫大家找到我吧。

Re: o6z 这一派的:熊节忽悠敏捷 XP by Xiong Jeff

不过他现在应该能承认有些cmmi5的企业配置管理的基本策略和集成策略存在巨大缺陷这个实事了。好歹他也是应该见识过点场面了。至少我这个虚拟的躲在暗处的人网混都看得见这样的实例,他这个具备专业素质,又有科学的逻辑思维能力,还受过专业训练,又有14年以上的的经验的专家和智者,应该会看到了吧。
我还是继续躲起来不叫大家找到我吧。

说起来…原来还真有这么一出呢,你不说我都忘了
这条真的是骇人听闻,我希望 CMU SEI 及 CMM 有关人士一定要重视这条新闻。稍微有点常识的软件工程师可能都知道,配置变更管理是满足 CMM 2 级的基本条件。 我们的透明大作家,你能不能告诉大家“很多甚至通过了 CMM 5 级的软件企业却连基本的配置管理、集成策略都不具备”具体是指国内外的哪些软件企业?如果你举报的情况属实,我们应当尽快呼吁让那些作弊的评估师下课,并断然收回那些作弊企业的 CMM 5 级证书,以保 SEI 和 CMU 的信誉。

张教主请注意吧,你现在正在服务的那家CMMI5级企业就是这样一个情况,咱们这些草莽就等着看你收回他们的证书了。

Re: o6z 这一派的:熊节忽悠敏捷 XP by Jacky Li


这条真的是骇人听闻,我希望 CMU SEI 及 CMM 有关人士一定要重视这条新闻。稍微有点常识的软件工程师可能都知道,配置变更管理是满足 CMM 2 级的基本条件。 我们的透明大作家,你能不能告诉大家“很多甚至通过了 CMM 5 级的软件企业却连基本的配置管理、集成策略都不具备”具体是指国内外的哪些软件企业?如果你举报的情况属实,我们应当尽快呼吁让那些作弊的评估师下课,并断然收回那些作弊企业的 CMM 5 级证书,以保 SEI 和 CMU 的信誉。

张教主请注意吧,你现在正在服务的那家CMMI5级企业就是这样一个情况,咱们这些草莽就等着看你收回他们的证书了。

这一出挺有意思的,等着看掌门解释什么叫做“稍微有点常识”。

什么东西到了中国,最后都这样了。 by Zhang Myhui

文人相轻啊。技术的争论,最终都会上升到人品,分帮成伙的互相讨伐,无趣无趣。

Re: 什么东西到了中国,最后都这样了。 by liu ozzzzzz

嘿嘿,这个判断可以留在这里,明眼人一看就知道是非曲直。
不过我觉得对自己还是要严格点要求,有疑问要多做调查,少做猜测。凭感觉,看表面,是简单的,但是往往又是无趣而无聊的。
而这个事情本就不仅仅是技术的争论,是非曲直自有其背景和发展的过程。不去考察这些东西,简单的下个结论是容易的,也是草率的。

Re: 什么东西到了中国,最后都这样了。 by Xiong Jeff

您二位一唱一和那就是高山流水,我们这就是分帮成伙党同伐异,没办法,谁教咱们是草莽不是硕士更不是教主呢。所以有样也不能学样,学不了啊。

Re: 什么东西到了中国,最后都这样了。 by Zhang Myhui


请 Jeff Xiong 仔细看看我的回文,我只是指出,在这里,这个社区,应该更多关注技术的讨论,而不是将你们互相之间先前的嘴仗在这里继续延续。就算在你们眼里,别人的观点是错误的,名称是可笑的,口气是狂妄的,也没必要将你们的轻蔑和不忿发表在这样一个站点吧,你们不都有自己的网站和博客吗?互相发在对方的网站上,那多直接痛快。


还有,我在这里发文反问你们的文章中的论点,就是和别人一唱一和了?请问,我们二位唱在哪里,和在哪里。我只是觉得,一个人不要光否定别人的观点,也把自己认为正确的结论提出来,这才是交流,也让我这些连草莽都不是的人学习学习,仅此而已。


我不知道你们以前唇枪舌剑的历史,也没有兴趣了解,但在这个网站上出现这些陈芝麻烂谷子,确实是无趣,而且无聊。

Re: 什么东西到了中国,最后都这样了。 by liu ozzzzzz

我觉得你这个同志缺乏就是调查和研究,而且又自己觉得自己调查和研究得很充分了。“将你们的轻蔑和不忿发表在这样一个站点”的事情是谁先开始的,又是谁几次三番一直在做的,请你自己去搞清楚。
而说我们没有观点,也没有结论,那更加不能令我们接受。
而你既然没有兴趣了解历史,觉得无趣也无聊,那么我觉得你也就没有必要去下什么判断。而且我觉得你也就没有能力理解我们的观点究竟是什么。
对别人下道德判断是容易的,但是因此就免不了别人对你自己下道德判断。

Re: 什么东西到了中国,最后都这样了。 by Zhang Myhui


如果你指的是调查研究你们以前的历史,抱歉,没有那份心思,缺乏研究是必然的。至于都有谁几次三番的在轻蔑对方,不忿对方,上面的帖子清楚的摆在那里,大家都看的到。你有观点,有结论,我承认,只是,观点和结论不是光靠说的,没有具体实例的论据和论证的结论,不令人信服,无论是反驳别人,还是自己立论。


至于在后面那些回文,更是没有看出和本主题有什么联系,只能是无趣。


还有,了解不了解你们交战的历史,和弄清楚这里要讨论的技术主题,根本就没有联系。至于无趣也无聊的判断,是针对后面回文中体现的和本主题无关的内容,当然,那是和你们有关的,在你们眼里,肯定不是无聊的,更不是无趣的。


对别人下道德判断是容易的,但是因此就免不了别人对你自己下道德判断。

这一点,您别抬举我,我可没有那份闲心给你们的德行打分,至于对我的道德判断,更不是我在这里所关心的。


最后一点,不要把我和你们口里的教主分成一伙,不是谁都喜欢这种“群体活动”的。还是那句话,不要把不应该属于这里的东西带进来,没劲。

Re: 什么东西到了中国,最后都这样了。 by Jacky Li

如果你指的是调查研究你们以前的历史,抱歉,没有那份心思,缺乏研究是必然的。至于都有谁几次三番的在轻蔑对方,不忿对方,上面的帖子清楚的摆在那里,大家都看的到。


如果你有理智,有清晰的判断力的话,那我想问一下,难道眼见就一定为实么?你看到了上面的帖子,但你知道除了这篇文章之外,还有多少帖子是你看不到的么?

Re: 什么东西到了中国,最后都这样了。 by Zhang Myhui


很好,你说的就是我强调的。在这里,InfoQ这个调查的主题下,大家讨论一下相关的主题不好吗?我看不到的哪些帖子,如果和这个主题无关,也没有必要拿来作为讨论的必要吧。我在前面的回文说了,你们说的教主的文章里,描述了他的敏捷实践和取得的效果。你们可以怀疑他说的效果,他的实践不敏捷,但是,你们也应该把自己的实践和效果说出来,否则只是简单的否定别人,也难让人信服啊。


可能,“张教主”以前先搞传统方法,现在又搞敏捷,在这个过程中,又和你们有过争论(从你们的回文中得出),但是,这些不能作为你们否定他的论据啊。我只是觉得,你们如果从理论和实践的角度提出自己的见解,再去反驳别人,才更容易让人接受。而且,不要偏离主题。

Myhui Zhang,支持你的专业观点! by Zhang Charlie

我支持你前面绝大部分的发言,这些是一名专业程序员和职业软件工程师所应该具有的正确观点。




这群人在 InfoQ 中文站、CSDN、javaeye 网站中都有他们的势力,核心人物是 Jeff Xiong 和 o6z,我与他们的斗争从 6 年前的 UML 三大硬伤论就开始了。




作为一名软件工程专家,张恂与他们(善于利用媒体的投机者)的价值观、逻辑系统可以说完全不同,而且是针锋相对的。研究熊节现象对于中国软件技术媒体、软件工程行业的发展、对草莽浮躁的程序员文化的形成是张恂多年以前,早就确立的课题。所以,我会不受干扰地把这项研究坚持进行下去,花上 10 年、20 年都是值得的。




所以,Myhui,相信你自己,相信你的专业观点和价值取向。完全没有必要与国内那些职业道德和做人品质低下的业余草莽多费口舌,浪费自己的宝贵精力。



再次感谢你对我一部分观点、做法的支持!科学事实终将证明一切。




中西合璧的敏捷 OO 教练 张恂


www.zhangxun.com

Re: 关于自愿任务:你在撒谎? by Li Guanglei


这是因为我前几年创造杂技派的时候,早就说过等哪一天敏捷成了主流了,某些现在这么反对我们的人会把不跌的说自己敏捷,并且比我们大家还敏捷。我想以张先生这么高的人格,这么好的素质,这么高深的学问,不会这么急不可耐的来印证我这个话的。

2002年中国队出线后, 当保米派想找倒米派清算的时候, 却发现找不到人了, 所有的人都成保米派了

嗷嗷的~ 掐架了也 好热闹啊 by 天色 璎珞

终于扫完了
俺严重认为InfoQ的某老师应该站出来组织各位牛逼的大爷们现场PK
然后制作成图片新闻MP3视频 用各种形式发到网上让小弟们观摩学习 绝对火爆

Re: 嗷嗷的~ 掐架了也 好热闹啊 by Jacky Li

晕,出来看热闹的了

Re: 嗷嗷的~ 掐架了也 好热闹啊 by wang xumin

引用INFOQ的文章的话:
我们要做该做的事情,至于是否敏捷(且不论是否有判断敏捷与否的标准),是否用了Scrum,“吹皱一池春水,干卿何事?”
请允许我借用Jeff Xiong在敏捷中国内说过的一段话作为本文的结尾:
我不要敏捷
我要致力于消除软件开发中的一切浪费

我个人就在上述所说的NSN杭州工作,我可以明确的负责任的说scrum目前执行的很失败,几乎所有项目都delay。归根到底就是为了scrum而scrum造成的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

60 讨论

深度内容

提供反馈
错误报告
商务合作
内容合作
InfoQ.com及所有内容,版权所有 © 2006-2014 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT