[调查]伪敏捷是什么样之二:做了什么算伪敏捷?

54 views
Skip to first unread message

ozzzzzz

unread,
Nov 2, 2011, 1:04:44 AM11/2/11
to agilechina
对于你个人的人身攻击对于你自己,对于你个人,对于整个敏捷社区,对于中国的软件事业只有好处没有坏处。我一直关注你的blog,很遗憾在国内还没有比你更加有代表性的伪敏捷我还没找到。至于你说的我没有根据,其实你自己有那么一大堆的文章,大家可以自己去找。而且你可以看看,你在这个社区里面究竟都谈论了些什么,发表过什么看法。这些都是证据。如果你还不认帐,只能说你以及和你在一起臭味相投的人实在跟我们这些人对于敏捷的看法太不一致了。

为什么现在敏捷开始腐败了,开始臭了(当然你可以不承认这一点,因为在你们看来cmm都还是香喷喷的),都马上可以用做对他人母亲的问候语了(其实已经有人开始这么做了)?原因不是在于国家有没有资助(其实cmm就是没有国家资助,也是臭哄哄的),更不在于有没有人做培训和咨询(没有培训和咨询,方法如何推广)。而是在于,究竟推广了什么方法,做了什么承诺,最终是否兑现了这些承诺。其实这就是最根本的敏捷和伪敏捷的差别所在。我上条回复里面的两个标志,也是从这里推导出来的。你也可以用这个标准,在自己身上印证一下。再强调一次,推广了什么方法,承诺了什么和兑现了什么。

你说你做过了什么什么,我懒得知道。我只关心你对敏捷社区做过什么。我没兴趣跟你个人通邮件,也没兴趣知道你是谁。

在 2011年11月1日 下午10:12,张克强 <zhangk...@gmail.com>写道:
你一个人所说的“伪敏捷”并不能代表所有的认识。
调查就是调查,大家愿意发表看法就发表看法。
你这样打压言论,甚至人身攻击,有违一般的论坛游戏规则。
你这样不讲礼貌的发言,对你、对论坛有什么好处吗? 没有。
 
现在政府并没有资助敏捷,无论是个人培训还是组织评估。
这种情况下,讨论敏捷或者伪敏捷,并不会搞臭敏捷啊。
这与CMM/CMMI的情况是不一样的。
 
我抛的砖(指领导要求就需求安排个讨论确认会议)是故意搞成不敏捷的,确实离敏捷还有很远。本来就是征集“做了什么算伪敏捷”。
 
在具体组织工作环境中,当然是踏踏实实去干,追求真正的效果,说不说“敏捷”取决于组织对敏捷的认可程度,有初步认可后,还是可以提的,现在不少公司(华为,爱立信,IBM,TW,诺西等等)也是明摆着搞敏捷。
具体工作环境中如果总是各种专业术语挂在嘴边,限于空谈,没有行动,那是“伪”。
在论坛讨论中,不可避免的需要各种专业术语,比如敏捷和伪敏捷、重构、TDD什么的,这是很正常的。
 
你对我的指责没有根据。 我拥有高级程序员、系统分析师证书,虽然有证书并不能代表什么,但至少证明我曾经通过了那两个考试,那两个考试的通过率一直在10%以下。我参与过多个开发项目和测试项目,包括发包项目,至今我所写的代码还运行在大型钢铁公司和隧道桥梁监控等系统中。
我在百度的blog:http://hi.baidu.com/hespr/ 记录了我近年来陆续发表的博文。
也许我的观点与你的观点并不一致。但是和你不一致,并不是我对什么敏捷方法都没有知识。
 
希望你不要再污蔑我。
 
在论坛里讨论这些,对论坛没有价值,所以直接mail到你了。

 
在 2011年10月31日 下午10:57,ozzzzzz <ozzzz...@gmail.com>写道:

伪敏捷这个说法早就有了,并且早早的我就已经说过了伪敏捷是什么样子。很遗憾你只不过是不凑巧的验证了我前几年的说法。当然很遗憾,如果你早点知道我,早点关注中国的敏捷,今天估计也不会找上门来找我骂你。

我不是想让大家觉得我有多牛,预测多正确。而只是告诉大家,世界变化有规律,莫准了规律就看明白了变化。其实无非就是今天敏捷的名声响亮了,希望来拉大旗做虎皮的人就多起来。其实根本就不需要什么调查,谁在做什么,是怎么做的大家有眼睛就能看的到。只不过规律这东西是隐藏在发展下面的,不是靠眼睛看,而是靠心来体会的。

至于什么是伪敏捷,其实现在有一个很大的特征,就是喜欢Scrum,并且除此之外什么敏捷方法都没有知识。另外一个几乎不要讨论的特征就是一定是玩认证的,并且是认真无比的玩认证的。而且还试图玩自己的认证的。当然其他特征还有很多,但是现在就这两点比较普遍而且显著。

你觉得你冤?很遗憾,我觉得一点有不冤枉你。当然这个话不是完全针对你一个人的,而是针对一批人的。只不过那些鸟人比较聪明,不敢来这个找骂。

在 2011年10月31日 下午8:12,张克强 <zhangk...@gmail.com>写道:

结贴吧。
虽然不回这个贴子,是最好的结贴方式,我还是忍不住最后说几句:
1,关于“伪敏捷”这个说法,已经存在有些时间了,以前不是我提出的;最近出现也不是我首先提的,以后我也不会首先提出。
2,最近又看到这个提法,这个提法虽然只有三个字,但对此的理解并不是很清楚,所以在这里做做调查,加了句“随便聊聊,随便说说”,试图搞个随意的气氛,不想是引发了这样的讨论。而在另一个调查贴:[调查]伪敏捷是什么​样之一:不做什么算伪​敏捷?,倒是收集到了一些有价值的反馈。

3,今天,@杨瑞-敏捷厦门 发了一条微博:“Scrum难度颇高,难点不在于所作之事,而在于不做之事。--Ken Schwaber“ 我很是赞同这句话,之前我已经想到了这个,所以来调查“做了什么算伪敏捷”。

4,我冤啊,我就找了个话题,试图得到些反馈,活跃活跃讨论气氛。
5,在这里,这个话题无法继续了,我把这个话题发到了另一个google group:  http://groups.google.com/group/AgileImprovement , 欢迎有兴趣的朋友去哪里看看。
同时欢迎无论能否自主选择公司的而又试图学习和采纳敏捷方法的朋友加入到 上述名为“敏捷改进”的google group。  这个论坛将维护“分享”、“畅所欲言”、“友好”的氛围。 

在 2011年10月28日 上午9:57,Bruce Lee <bruc...@gmail.com>写道:
这话说得实在,当你整天把敏捷挂在嘴边的时候,估计离伪敏捷就不远了。

-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina



-- 
张克强

-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina

-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina

Qi Meng

unread,
Nov 2, 2011, 1:38:13 AM11/2/11
to agile...@googlegroups.com
哦,看来o6z批判张克强是要到底了。
为什么现在敏捷开始腐败了,开始臭了?
敏捷在我看来一直没在国内普及开来,也没什么香臭新鲜腐败一说。
但是现在有一个很不好的苗头,就是营销概念,然后就是官倒圈钱。
为什么?给一个分析讨论吧。欢迎大家讨论。

ozzzzzz

unread,
Nov 2, 2011, 2:59:24 AM11/2/11
to agile...@googlegroups.com
我说点大家不爱听的事情。

在我看来,中国大陆还不适合推广任何开发方法。原因是软件开发行业的基本素质还达不到能够掌握任何方法的阶段,还需要学习和改造。当然在这种情况下,推广敏捷方法这种来自程序开发第一线的软件工程方法更加适合这种悲惨的情况。这里我说的基本素质,不仅仅是说开发者的素质,也在指用户的素质,市场管理者的素质。

其次我们必须认识到cmm所代表的一些对于中国软件开发行业有害的看法。首先是,可以利用某种方法,弥补开发能力的不足。比如我们经常可以看到有人说,现在程序员太贵了,应该有种什么什么方法,可以让几个便宜的低层程序员来替代高层程序员。软件蓝领,开发领域内可以大量利用软件蓝领。其次方法可以让你的开发变得简单,容易操作,容易控制。典型的就是cmm了。同时为了简单和容易,就要明确和不容易改变,但是很遗憾明确和不容易改变往往是存在内在的矛盾的。这一点有哲学的证明,大家可以参考语言学和符号学的概念,当然心理学方面也有证明。其实也就是方法需要磨合,磨合需要时间,时间是投资,稳定的团队比稳定的方法更重要。第三,大规模开发,大团队开发,总之人多才是软件开发的未来。而这一点同上面的错误认识结合在一起,危害更大。

当然这三种观念,只是众多错误看法中的典型,其他的错误观念还很多。但是我们必须知道,其实这些错误的观念,今天遇到了敏捷,情况还是如此。比如很多人认为,敏捷很好,而且敏捷没有门槛,所以一群笨蛋也可以使用敏捷方法开发出好软件。其实实际情况是,只要是笨蛋,除非似乎运气超好,否则你根本就开发不出软件来,就更不要说好的软件,也就是有质量的软件。

又比如很多人认为,敏捷方法很轻量,所以实施情况一定是很简单,很容易。而当你遇到TDD和PP这些方法,就会说这些太Geek,不适合我们。遇到重构就会说,这个事情太神奇,我们这里实施不了。看到持续集成,就说我们这里情况特殊,做不到。而其实看不到完整的单元测试,持续的构建,无痛苦的重构,现在已经不仅仅是敏捷,而是整个软件工程领域被公认的优良习惯做法。而这些基本的东西,你还推脱,根本就是没有道理。另外,想尽办法不实施迭代,说我们这里情况怎么怎么,必须瀑布。而实际上不管从什么角度看,只要时间夸大够,实施迭代是没有什么讨价还价的余地的。而总是有些人,希望在不实施这些关键方法的情况下,还是可以声称自己在实施敏捷。另外,有些人认为敏捷方法没必要你们严肃,以及也没有必要有什么门户之见,可以和其他方法,特别是可以和cmm结合使用。很遗憾,我不知道这些人究竟是不懂敏捷还是不懂cmm,或者根本上其实什么都不懂。其实对这个事情,我们只能这么说,使用敏捷方法可以达成cmm的某些要求。这个是最最准确的说法了,再多一点就过分了。比如典型的,如果你没有一个开放的环境和不是重约束的管理流程,实施重构就不可能。而你不能很还的实施重构,还说你是敏捷就是扯淡。而话说回来,你实施了TDD和重构以及持续集成,当然就已经达到了某些CMM的要求。同时很遗憾的告诉大家,敏捷方法没有自己追求的目标,而完全只是为了满足人们开发出更好软件的这个目标的辅助条件。而有些人,依照cmm的习惯,不能认识到这一点。

当然动不动就说什么大项目,大团队,大规模,这个事情不是一天两天了,用这个事情说事也不是一天两天了。这个事情我不需要多说,大家都是有经验的,自己应该都有认识。

而现在这些情况,我们大家其实都可以在各个地方看到。如果你实在没有案例,那看看张克强和另外一些人吧。

而问题在于,有这么多不是敏捷的看法,他们反而还觉得自己是敏捷的人,真是奇怪。其实原因也很简单,cmm在他们看来是官方的,所以不敢反对,敏捷现在是主流也不敢反对。所以这些人其实不仅仅是伪敏捷,而且也是伪cmm。

而进一步来说,有些人其实根本就不在乎你是什么,只要有钱赚,他们就可以随便转向。于是今天你要敏捷,他们就给你一个敏捷;明天你要cmm,他们就给你一个cmm。后天不知道有什么,反正我肯定,只要市场够,他们就会说他们能给你。其实我几年前就说今天会有很多人出来声称自己是敏捷了,原因就是我早就看明白了这一点。这些人只不过是没有胆量,或者是太在意赚钱了。这种事情历来都是一样的。

进一步说,敏捷方法发展到这一步,其实也该走到它的反面了。这块事情,我估计也该有苗头了。我会过几天,写一些东西,专门讲这个事情,算是敏捷10年的纪念。

另外一个问题是,不管你实施什么方法,自己的能力总是个基础,这块事情,我希望大家能理解。软件方法,其实不是我们最应该关注的,我们自己的实实在在的能力,才是我们最应该关注的。这个方法,其实就是起到一个查疑补漏的作用。

泥泥

unread,
Nov 2, 2011, 3:30:53 AM11/2/11
to agile...@googlegroups.com
嗯,楼上说的有些我认同,每次想说,都觉得应该是结贴了,但既然扯开了,还不如继续扯呢。
这个帖子的视野已经远远超越张克强的话题、超越敏捷是什么,矛头直指围绕软件行业而生的项目管理(含过程改进、集成产品管理、组织管理等等形形色色概念)咨询行业了。

当然,还包裹着来自各种传统领域的比如产品营销、财务统筹、绩效管理等等。更糟糕的是居然还有包裹着成功学(当然也可以称为伪成功学)。

CMM出来时,很多企业觉得心有余而力不足,但中国向来不缺有钱好办事的能人,当一个垃圾公司过了CMM,会刺激一群更垃圾的公司在荣誉证书数量上赶超垃圾公司。

有精英份子投入到轰轰烈烈的抢钱游戏中。考到SEI营业执照,大规模派发CMM认证,最终被荣幸列入黑名单。这些也就算了,但敏捷运动来了,我一度认为这个不存在认证的运动总算是干净些的。

事实证明我很傻很天真,居然Scrum开了先河,有一拨精英把他资格化了、证书化了,一开始我还有点BS这帮山寨SEI的行为,觉得傻人才会去考,但出乎意料,有理想有抱负的人还是很多。

我知道论坛里有很多同学卖这种大力丸的,这次6z炮制了个吐槽专家不算错的气氛,我机会难得,也就吐槽了。

Stevie Wong

unread,
Nov 2, 2011, 4:28:13 AM11/2/11
to agile...@googlegroups.com
"证"在国内就是一切的基础,信任危机的一块遮羞布。
    祝身体健康,工作顺利!

--
习惯于宿命过往,生命就不再是恍惚年少

王俊(Stevie Wong)
qdl...@gmail.com

Joseph Tseng

unread,
Nov 2, 2011, 5:01:24 AM11/2/11
to agile...@googlegroups.com
再强调一次,
推广了什么方法,承诺了什么和兑现了什么。
 
关注一下:都承诺了什么兑现了什么。

最差的是空头承诺,传播虚假知识,兑现nothing。

无害的是什么都不敢说,或者什么都不说。

有用的大家希望看到的当然是说了一些,承诺了一些, 兑现了一些,在这个社区有很多例子吗?

介于最差和无害的: 什么承诺都做一个很强的假设,当这样的假设不能成立的时候, 就断言什么都做不了。 类似于“因为大部分人本质上都怎么这么样...,所以现状就是这样(无法改变)",这样的结论最是容易,但也最是无用。

这个社区固然有一些空头承诺讲空话的人, 但最后这一类人也是不少。


 
2011/11/2 Qi Meng <smi...@gmail.com>



--
Joseph Tseng

ozzzzzz

unread,
Nov 2, 2011, 6:54:15 AM11/2/11
to agile...@googlegroups.com
首先还是要看推广了什么,因为推广什么往往是主动的。而承诺什么,则是被动的,是对推广什么的承诺。而兑现什么,则是看最终能否达成目标。这个是一个过程的三个部分。但是这个过程中有两个要素,也就是推广的方法和对方法的承诺。

问题在于人们很难在早期就立刻简单的完全看到这两点的结果,但是好处在于人们可以在早期就看到这两者的外观。你至少可以在他们的早期就知道他们要做什么,和想做什么,以及这些做法他们所希望达成的效果。但是最终的结果,他们会说,要慢慢来,一个方法的引入是要有个过程的,bulabula。当然我们承认需要过程,需要时间。但是我们可以分析这些方法和承诺之间的逻辑关系。

比如你上来就推持续集成,而不是强调说要搞简单设计,简单实现,也不搞TDD,更不来重构。这个时候你说过后就可以解决设计腐化的问题。虽然我承认,在某些特殊场合,会达成这个结果,但是概率太小了。这个人虽然看起来也是在推敏捷,而其实相当的不靠谱。

而类似的事情其实经常出现,比如看了点gof,就到处都强调一定不要用new了。这样的做法,显然就是机械化的认识,而没有真正的形成概念层面的理解。

而进一步来说,即便你没有这种推理的能力,其实也无所谓,你也可以投资时间,去验证他们的说法。他们的承诺早晚要兑现,你只不过要经常性的拿出那些承诺来检查一下实际的状况。

我相信,大多数人可以不需要投资时间,就能立刻的看出,对方究竟在搞什么名堂。

Joseph Tseng

unread,
Nov 2, 2011, 8:45:18 AM11/2/11
to agile...@googlegroups.com
o6z所说的这些都是极有价值的事实。 但只有较少的人认识到这些事实,尤其是管理层和客户。 给管理层和客户洗脑成功当然好,但不能把这件事情作为开始做一切事情的前提。 换言之,即便上层管理层就是观念错误:指令式风格、不人本主义、给的人良莠不齐, 我们就撂摊子说不干吗?

Jeff说最根本是自己能干好,底下人不能做,就自己掳袖子上;有某位兄弟也说,不如选择一个对的老板。  我只是想,除了这两个办法,还有别的渐进的办法吗? 就算这次掳袖子上,也希望下次可以不用亲自做完所有事情吧?

是,在我们身上有太多的约束。 只能一件一件事情的摆平。 也许背着某个表面敏捷,实际狗屎的环节先跑着,先把UT、CI逐渐完善起来。  至少,我对于团队的开发成员来说,要做一个对的老板。  问题是,我这个目前还不是敏捷团队的成员,能不能,有没有资格在这里说说我想做的事情呢?

不妨提一个尖锐的问题: 咨询公司会不会拒绝每一个”指令式风格、不人本主义、给的人良莠不齐“的团队?   如果有任何一例没有拒绝,其中的经验是不是就可以帮助到类似的团队? 同样的, 这类型的团队也可以互相借鉴提高,对吧?

再说了,出现伪XX的空话、假话是一个正常社区的组成部分,没有伪,哪儿来的相对的真呢? 把伪赶出去了,禁绝讨论,只有绝对的一元的“真”,这个“真”也就快变成伪了, 历史上有屡见不鲜的证明。

请各位慎重考虑一下。


2011/11/2 ozzzzzz <ozzzz...@gmail.com>



--
Joseph Tseng

Joseph Tseng

unread,
Nov 2, 2011, 9:00:18 AM11/2/11
to agile...@googlegroups.com
而总是有些人,希望在不实施这些关键方法的情况下,
还是可以声称自己在实施敏捷。另外,有些人认为敏捷方法没必要你们严肃,以及也没有必要有什么门户之见,可以和其他方法,特别是可以和cmm结合使用。

碰到这种情况,直接迎头痛击就好了,这和张克强这帖的初衷不也是相似么。 从邮件上看,他本来就是想诱出一些错误的认识来分析的。

 
2011/11/2 Joseph Tseng <air...@gmail.com>



--
Joseph Tseng

ozzzzzz

unread,
Nov 2, 2011, 3:47:12 PM11/2/11
to agile...@googlegroups.com
其实我这个人说话是很给人留面子的,只不过张克强之类的人根本就理解不到我在给谁留面子,也根本不知道我给什么人留下了什么面子。其实我们还是中国人,人情必然是我们要考虑的事情。你看就算gigix这个小子,也说现在有很多责任,不能如何如何。而其实造成今天的局面,当然有些人应该担负更大的责任。而究竟该谁对中国软件行业今天推广敏捷中遇到的麻烦,有最大的责任,其实我以及另外几个人都是心里有数的,但是不能直接说出来。而作为你,我觉得也应该可以看出点端倪。所以这个方面的内容,我绝对不会公开说。

但是不要以为,我不说这个方面的内容,我的话就没有了力量。我正是很仔细的研究了我要说的内容,以及我要说的人,所以我的话都是有力量的,至少是有论据的。至少我是从头看过某些人的博客的,至少我是一直关注新水软工论坛的,至少我是一直关注这里的。所以别说什么我是污蔑。

其实说的再好听,这个事情也是某些人想往敏捷里面掺沙子。只不过我这次还没有等他们开始动手,就直接站出来,断了他们的行动。因为我花了这么多的时间和精力,看了他们表演这么多次,所以才出来这么猛烈的攻击。你也别说我是没有警告过他,其实这次已经是我这么直接的说这些话的第二次。只不过第一次,我只是说了说要是他再这么搞,我就会出手。当时据说他也很担心了一下,也问过我的事情。但是可能后面看我没真的动手,于是就又开始搞起来。并且越是搞越大,并且和另外一些更加不靠谱的组织和个人联手做乱。于是我就兑现我的承诺。

你也不要给我们和浆糊,你还不具备这样的能力,也没有这样的面子。倒是,我觉得你可以认真的去看看他的过往言论,对照自己的心得看看你有什么看法。

我再一次要警告大家,蛇欺骗女人的把戏,并不是直接否定 神的话。而是说,吃了不一定死,而且紧跟着说是——怕你也有了智慧。其实这样的把戏,在生活里面多的不能再多,所谓打着红旗反红旗,也就是说的这个路子。

而关于自己掳起袖子自己上,这样的说法不是gigix先说出来的,而是我早就提出过的。我这里不是想跟gigix争功劳,而是我知道这个提法,一定会被非常非常多的人反对。gigix现在还有些事情需要顾及,而我没有,所以应该是我担负更多的被攻击,而不是让他冲在前面。反正我这个人被说成是偏激,被说偏执,被说没有修养,被说人品低俗,也不是一年两年了。我是几十年如一日,一直被别人这么说。而且也不是一个人这么说,而是很多人都这么说。但是不管怎么说,我想做的事情,我都做成功了,我希望看到的结果都实现的,我给出的预言至少到现在也都被证明是正确的了。总之我的存在是一个事实,我一直持一贯的观点和方法。攻击和反对我的人,换了几批,最早的我都不知道现在跑什么地方去了。很遗憾,从最早我说TOP这样的公司要付出代价,于是一个一个的事实就不断证实我的看法。但是我没有一点高兴的心情,因为随着我的这些预言的实现,进跟着是我们这个行业受到的损失,一次跟着一次的损失。人们争先恐后的,去证明我几乎成为一个 神的能力,恰恰是更加证明我们这些行业到现在还没有真正的反思和学会反思。说真的,我更加希望别人能够用事实驳斥我的说法和做法,让我服软,让我老实起来。

其实并非我聪明,而是我更加不相信什么常识,我信事实和逻辑,而且我勇敢的承认事实推理出的结论。什么权威,什么教授,什么专家,在我这里都没有地位,我只相信事实和背后的逻辑。

自吹自雷这么多,我说点实在的。当然人都希望不是每次都自己亲自一个人冲锋,也希望别人能担负点。但是很遗憾,你首先需要具备自己等独自完成任务的能力,这之后你才可能要求别人能给你些支持。这首先是因为,你如果不具备这样的能力,那你就很难真的知道,你需要别人给你究竟什么支持才是有用的,你才可能知道别人给你的支持是你想要的而且是能接受的。实际工作中越帮越忙的事情,几乎每天都出现在我们面前,这样事情我不需要给大家做解释。而进一步说,你必须具备这样的能力,才可能在你愿意的前提下去培养别人也具备这样的能力。因为这种能力,是一直思维的能力,需要已经想明白的人传递给还没想明白的人的能力。这一点大家可以参考学习学或者教育学以及认知心理学的相关内容。同时也正是需要你有这样的能力,你才可能从整体上观察这个能力的实现过程,从而部署和安排实现的流程,安置不同的角色,达成角色之间的协作。而只有在这个的基础上,才可能进一步把角色岗位话,具体人化,数据化和非人化,并最终理论化和科学化。当然也正式需要你具备这样的能力,你才可能全面的预知你需要什么样的物质基础已经在什么时刻需要这些客观的条件。我们也要承认你具备了这个条件,才能看到这个能力的来源究竟是什么,从而为培养和组织自己的成熟组织做好铺垫。同时我们还需要承认,即便你已经有这个能力,但是还是不能保证你的成功率就很高,更何况你还不一定就真具备了这样的能力。

所以不管怎么说,首先要确定的是必须有人已经具备了这样的能力,才可能在此基础上进行下一步的工作。自然选择一个好老板,也是这个原理的一直应用方法。

但是我必须要承认,并非所有的时候你都有这样成功的条件。但是这样的情况下,你也没有资格说,我确定可以找到一种方法,可以让我们能成功的开发出成功的软件。这个显然是一个真命题。当然我承认,你确实可以寻找一种方法,让你在开发过程中即使失败,也不会输的那么惨。但是希望成功,我觉得与其依靠方法,不如祈求运气。

同时这就又有另外一个问题来了,也就是对于咨询公司应该对此持一个什么态度。当然如果你纯粹就是为了赚钱,你当然可以承诺客户所有的要求,只要价钱合适就好。但是问题在于,有些客户的要求确实是无理的,这个时候就要考验各个公司的道德底线了。总是在中国怎么做都有理,因为道德特别是职业道德根本就不值钱。

当然我上面的话不是针对敏捷说的,而是针对所有务实的开发者说的。并且我也不认为,敏捷是唯一的方法,更加不认为敏捷是最好的方法。因为我知道,我们还可以在敏捷的基础上再进一步,再寻找更加有效率和有逻辑的方法。但是在我看来,我们肯定不能后退,不能回去搞重过程,搞文档驱动开发那一套。我们只能是在敏捷的基础上再前进一步,就如同敏捷是在cmm的基础上前进了一步一样。但是话要说清楚,不管怎么搞,个人的开发能力是前提。就如同你足球不管怎么踢,个人的基本素质和基本控球能力永远都是最关键的基础要素。人们会随着比赛积累各种经验,尝试各种方法。但是不可能说,你要寻找一种布局,可以让不会踢球的能战胜职业运动员。这样事情是不会有的。那种说中国有多少多少人,怎么就找不出11个踢球的人的说辞,如果是普通老百姓说说也就算了。如果你是专业人士,或者干脆就是脑子还能自主思考的人是不会这么说的。

其实我对各位的要求不高,你是否真的实施敏捷我并不在乎。就算你是伪敏捷,只要你认了,我也不会吃了你。而且就算你不认,我也吃不了你。这些事情没那么关键。但是如果你总是说些外行人才说的话,或者是拿外行人的话来招惹我,那我就绝对不会对你客气了。不要跟我说什么礼貌之类的大道理,就跟不要去耽误专业人士本就缺少的时间一样。让专业人员去做专业的事情,如果你想跟专业人员交流一些他们的专业,那请你至少也要先专业一下自己。这个事情其实才是最大的礼貌,最大的道德。

不管怎么说,现在敏捷的知识到处都存在,我觉得我至少可以要求参加讨论的人能够多角度、多层次的看问题,多用自己的脑子思考问题。而不是总是说一些老声长谈,总是让我说十年钱就说的话,并且是一遍又一遍的说,只不过我说的对象总是变。中国的敏捷社区也不是才出现,以至于我们可以认为中国的敏捷社区和实践在世界范围内其实都是比较先进的。这个事情对大家应是个好消息,也应该是个鼓励,同时也应该是压力。

好了,今天就说这么多。太晚了,没时间查错了,请大家原谅。同时做个预告,我一定会在最近写一个敏捷十年总结以及敏捷过后我们的新追求的文章。这次觉得不会拖太久。

张克强

unread,
Nov 2, 2011, 7:04:58 PM11/2/11
to agile...@googlegroups.com
1,论坛、群组本身就是大家发言讨论的地方。如果不赞同某人的发言,当然可以反驳。但是如果因为不同意某些人的发言,而进行全面的打压,这不符合论坛通行的规则。 这里没有竞选州长的竞争对手。
2,讨论具体问题时,扯到中国敏捷发展的高度,好像要为敏捷在中国的传播负责一样。作为一个个人,没有必要担负这样的职责,也没有资格。更没有必要以为担负了这样的职责就来“正本清源”。敏捷的世界丰富多彩,一个人的认识不可能全面覆盖。
3,如果讨论的问题正好是某人以前说过的,不妨敏捷的马上回复“这个问题某某在N年前早就说过,是这样说的 .........."。不要东拉西扯一大堆之后,放到15楼以后。
4,敏捷推荐自组织,论坛也需要自组织。
5,敏捷推崇价值,现在这样的讨论对这个群里的成员有什么价值? 转为私下直接讨论,会不会更好些?
6,敏捷推崇简单,洋洋洒洒数千言,除开攻击类文字外,剩下了些什么,能不能浓缩些?看文字也挺费时间的
7,除去招聘和活动广告,最近3年来,我在这个论坛发起的话题数量是最多的。我一直试图就具体问题(比如回顾会议,比如重构,比如多级项目规划,迭代开发,等等)来征集大家的意见,希望给我给大家一些启发和借鉴。我对这个敏捷社区是有贡献的。
8,关于忽悠,这个论坛成员都是成年人了,也都是聪明人,各自有各自的判断,所讨论话题不是传销洗脑和邪教宣传,何必担心忽悠?我也没有看到这里有什么忽悠。

Jeff Xiong

unread,
Nov 2, 2011, 9:09:31 PM11/2/11
to agile...@googlegroups.com
再次重申本邮件列表的规则:

1. 本邮件列表严格反对假话大话空话。
2. 本邮件列表原则上不鼓励骂人。

综上两点,观点清晰有理有据的言论,不论是打压某人还是洋洋洒洒,都不在本邮件列表反对的范围内。我解释清楚了吗?

请不要把“论坛通行的规则”套用在本邮件列表头上。作为管理员,我没有把这两条规则正式写在邮件列表的首页,由此造成的误解,我深表歉意。

2011/11/3 张克强 <zhangk...@gmail.com>:


> 1,论坛、群组本身就是大家发言讨论的地方。如果不赞同某人的发言,当然可以反驳。但是如果因为不同意某些人的发言,而进行全面的打压,这不符合论坛通行的规则。
> 这里没有竞选州长的竞争对手。

> 4,敏捷推荐自组织,论坛也需要自组织。


> 5,敏捷推崇价值,现在这样的讨论对这个群里的成员有什么价值? 转为私下直接讨论,会不会更好些?
> 6,敏捷推崇简单,洋洋洒洒数千言,除开攻击类文字外,剩下了些什么,能不能浓缩些?看文字也挺费时间的

--
Jeff Xiong
www.Gigix.me

Zoom.Quiet

unread,
Nov 2, 2011, 9:15:42 PM11/2/11
to agile...@googlegroups.com
在 2011年11月3日 上午3:47,ozzzzzz <ozzzz...@gmail.com> 写道:
...

> 自吹自雷这么多,我说点实在的。当然人都希望不是每次都自己亲自一个人冲锋,也希望别人能担负点。但是很遗憾,你首先需要具备自己等独自完成任务的能力,这之后你才可能要求别人能给你些支持。这首先是因为,你如果不具备这样的能力,那你就很难真的知道,你需要别人给你究竟什么支持才是有用的,你才可能知道别人给你的支持是你想要的而且是能接受的。实际工作中越帮越忙的事情,几乎每天都出现在我们面前,这样事情我不需要给大家做解释。而进一步说,你必须具备这样的能力,才可能在你愿意的前提下去培养别人也具备这样的能力。因为这种能力,是一直思维的能力,需要已经想明白的人传递给还没想明白的人的能力。这一点大家可以参考学习学或者教育学以及认知心理学的相关内容。同时也正是需要你有这样的能力,你才可能从整体上观察这个能力的实现过程,从而部署和安排实现的流程,安置不同的角色,达成角色之间的协作。而只有在这个的基础上,才可能进一步把角色岗位话,具体人化,数据化和非人化,并最终理论化和科学化。当然也正式需要你具备这样的能力,你才可能全面的预知你需要什么样的物质基础已经在什么时刻需要这些客观的条件。我们也要承认你具备了这个条件,才能看到这个能力的来源究竟是什么,从而为培养和组织自己的成熟组织做好铺垫。同时我们还需要承认,即便你已经有这个能力,但是还是不能保证你的成功率就很高,更何况你还不一定就真具备了这样的能力。

- 怎么确认自个儿有这种能力?
- 目前流行的檢驗方式是
- 看你所在的领域,你吃的亏是否是周围人里最多的
- 这样,才可能明确这一领域想干成一件事儿,哪些苦逼的事儿坚决不能作

...


> 好了,今天就说这么多。太晚了,没时间查错了,请大家原谅。同时做个预告,我一定会在最近写一个敏捷十年总结以及敏捷过后我们的新追求的文章。这次觉得不会拖太久。

严正期待这篇文章,看 ThoughtWork 的各种软文时间长了,需要真正一线的聲音!

...

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

kingfish

unread,
Nov 7, 2011, 9:35:11 AM11/7/11
to 敏捷中国
错过了很多精彩的邮件。

回想若干年前的自己,为了做好手中的软件,面对开发中种种的问题。我现在都无法忘记,当第一次看到XP的那些实践的激动心情。因为我想要更好的做软件,
因为我认为就应该做得更好。

CMM疯狂的时候我也在SPEG组里面,我感觉对于其他人来说明白几个过程方面就应该算是进步了。虽然说对应到具体做事情上更为“狗血”,但起码让一部
分人思考做事情为什么会这样“狗血”。认证真是害人不浅,但投领导所好。md,这些领导都不是干实事的领导。

敏捷也有点这个意思。记得在敏捷大会之后的餐桌上,一个南方口音的女士拼命问我:我TDD了,CI了,写Story了,开迭代会议了,程序员结对编程
了,我还能做什么?做什么能更敏捷? 我愕然⋯⋯

Gigix的观点我比较赞同,让大家知道应该写点测试,应该有个CI就非常不错了,我也很悲观。我希望自己认为是在推行敏捷的人,告诉你的听众。为什么
要有迭代?为什么要写测试?为什么要有CI?我在这里鞠躬了。 如果你再告诉你的听众,你可以质疑任何事物,包括我现在说的(证书照给)。我在这里给你
磕头了。

可能敏捷这个词会变臭,但追求卓越软件的追求没变

////
说点别的,我个人喜欢有鲜明倾向的人,他们一般走得更远,且更为积极。做事情,就需要这样。我问一个人你做软件喜欢用瀑布还是敏捷的迭代?这个人说:
tmd,一说敏捷我就来气,什么东西⋯⋯。我喜欢和这样的人共事。

;)


On Nov 3, 9:15 am, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:


> 在 2011年11月3日 上午3:47,ozzzzzz <ozzzzzz....@gmail.com> 写道:
> ...
>
> > 自吹自雷这么多,我说点实在的。当然人都希望不是每次都自己亲自一个人冲锋,也希望别人能担负点。但是很遗憾,你首先需要具备自己等独自完成任务的能力,这之后你才可能要求别人能给你些支持。这首先是因为,你如果不具备这样的能力,那你就很难真的知道,你需要别人给你究竟什么支持才是有用的,你才可能知道别人给你的支持是你想要的而且是能接受的。实际工作中越帮越忙的事情,几乎每天都出现在我们面前,这样事情我不需要给大家做解释。而进一步说,你必须具备这样的能力,才可能在你愿意的前提下去培养别人也具备这样的能力。因为这种能力,是一直思维的能力,需要已经想明白的人传递给还没想明白的人的能力。这一点大家可以参考学习学或者教育学以及认知心理学的相关内容。同时也正是需要你有这样的能力,你才可能从整体上观察这个能力的实现过程,从而部署和安排实现的流程,安置不同的角色,达成角色之间的协作。而只有在这个的基础上,才可能进一步把角色岗位话,具体人化,数据化和非人化,并最终理论化和科学化。当然也正式需要你具备这样的能力,你才可能全面的预知你需要什么样的物质基础已经在什么时刻需要这些客观的条件。我们也要承认你具备了这个条件,才能看到这个能力的来源究竟是什么,从而为培养和组织自己的成熟组织做好铺垫。同时我们还需要承认,即便你已经有这个能力,但是还是不能保证你的成功率就很高,更何况你还不一定就真具备了这样的能力。
>
> - 怎么确认自个儿有这种能力?
>     - 目前流行的檢驗方式是
>     - 看你所在的领域,你吃的亏是否是周围人里最多的
>     - 这样,才可能明确这一领域想干成一件事儿,哪些苦逼的事儿坚决不能作
>
> ...
>
> > 好了,今天就说这么多。太晚了,没时间查错了,请大家原谅。同时做个预告,我一定会在最近写一个敏捷十年总结以及敏捷过后我们的新追求的文章。这次觉得不会拖太久。
>
> 严正期待这篇文章,看 ThoughtWork 的各种软文时间长了,需要真正一线的聲音!
>
>
>
>
>
>
>
> > 在 2011年11月2日 下午9:00,Joseph Tseng <airl...@gmail.com>写道:
>
> >>> 而总是有些人,希望在不实施这些关键方法的情况下,
> >>> 还是可以声称自己在实施敏捷。另外,有些人认为敏捷方法没必要你们严肃,以及也没有必要有什么门户之见,可以和其他方法,特别是可以和cmm结合使用。
>
> >> 碰到这种情况,直接迎头痛击就好了,这和张克强这帖的初衷不也是相似么。 从邮件上看,他本来就是想诱出一些错误的认识来分析的。
>

> >> 2011/11/2 Joseph Tseng <airl...@gmail.com>


>
> >>> o6z所说的这些都是极有价值的事实。 但只有较少的人认识到这些事实,尤其是管理层和客户。
> >>> 给管理层和客户洗脑成功当然好,但不能把这件事情作为开始做一切事情的前提。 换言之,即便上层管理层就是观念错误:指令式风格、不人本主义、给的人良莠不齐,
> >>> 我们就撂摊子说不干吗?
>
> >>> Jeff说最根本是自己能干好,底下人不能做,就自己掳袖子上;有某位兄弟也说,不如选择一个对的老板。
> >>> 我只是想,除了这两个办法,还有别的渐进的办法吗? 就算这次掳袖子上,也希望下次可以不用亲自做完所有事情吧?
>
> >>> 是,在我们身上有太多的约束。 只能一件一件事情的摆平。 也许背着某个表面敏捷,实际狗屎的环节先跑着,先把UT、CI逐渐完善起来。
> >>> 至少,我对于团队的开发成员来说,要做一个对的老板。  问题是,我这个目前还不是敏捷团队的成员,能不能,有没有资格在这里说说我想做的事情呢?
>
> >>> 不妨提一个尖锐的问题: 咨询公司会不会拒绝每一个”指令式风格、不人本主义、给的人良莠不齐“的团队?
> >>> 如果有任何一例没有拒绝,其中的经验是不是就可以帮助到类似的团队? 同样的, 这类型的团队也可以互相借鉴提高,对吧?
>
> >>> 再说了,出现伪XX的空话、假话是一个正常社区的组成部分,没有伪,哪儿来的相对的真呢?
> >>> 把伪赶出去了,禁绝讨论,只有绝对的一元的“真”,这个“真”也就快变成伪了, 历史上有屡见不鲜的证明。
>
> >>> 请各位慎重考虑一下。
>

> >>> 2011/11/2 ozzzzzz <ozzzzzz....@gmail.com>


>
> >>>> 我说点大家不爱听的事情。
>
> >>>> 在我看来,中国大陆还不适合推广任何开发方法。原因是软件开发行业的基本素质还达不到能够掌握任何方法的阶段,还需要学习和改造。当然在这种情况下,推广敏捷方法这种来自程序开发第一线的软件工程方法更加适合这种悲惨的情况。这里我说的基本素质,不仅仅是说开发者的素质,也在指用户的素质,市场管理者的素质。
>
> >>>> 其次我们必须认识到cmm所代表的一些对于中国软件开发行业有害的看法。首先是,可以利用某种方法,弥补开发能力的不足。比如我们经常可以看到有人说,现在程序员太贵了,应该有种什么什么方法,可以让几个便宜的低层程序员来替代高层程序员。软件蓝领,开发领域内可以大量利用软件蓝领。其次方法可以让你的开发变得简单,容易操作,容易控制。典型的就是cmm了。同时为了简单和容易,就要明确和不容易改变,但是很遗憾明确和不容易改变往往是存在内在的矛盾的。这一点有哲学的证明,大家可以参考语言学和符号学的概念,当然心理学方面也有证明。其实也就是方法需要磨合,磨合需要时间,时间是投资,稳定的团队比稳定的方法更重要。第三,大规模开发,大团队开发,总之人多才是软件开发的未来。而这一点同上面的错误认识结合在一起,危害更大。
>
> >>>> 当然这三种观念,只是众多错误看法中的典型,其他的错误观念还很多。但是我们必须知道,其实这些错误的观念,今天遇到了敏捷,情况还是如此。比如很多人认为,敏捷很好,而且敏捷没有门槛,所以一群笨蛋也可以使用敏捷方法开发出好软件。其实实际情况是,只要是笨蛋,除非似乎运气超好,否则你根本就开发不出软件来,就更不要说好的软件,也就是有质量的软件。
>
> >>>> 又比如很多人认为,敏捷方法很轻量,所以实施情况一定是很简单,很容易。而当你遇到TDD和PP这些方法,就会说这些太Geek,不适合我们。遇到重构就会说,这个事情太神奇,我们这里实施不了。看到持续集成,就说我们这里情况特殊,做不到。而其实看不到完整的单元测试,持续的构建,无痛苦的重构,现在已经不仅仅是敏捷,而是整个软件工程领域被公认的优良习惯做法。而这些基本的东西,你还推脱,根本就是没有道理。另外,想尽办法不实施迭代,说我们这里情况怎么怎么,必须瀑布。而实际上不管从什么角度看,只要时间夸大够,实施迭代是没有什么讨价还价的余地的。而总是有些人,希望在不实施这些关键方法的情况下,还是可以声称自己在实施敏捷。另外,有些人认为敏捷方法没必要你们严肃,以及也没有必要有什么门户之见,可以和其他方法,特别是可以和cmm结合使用。很遗憾,我不知道这些人究竟是不懂敏捷还是不懂cmm,或者根本上其实什么都不懂。其实对这个事情,我们只能这么说,使用敏捷方法可以达成cmm的某些要求。这个是最最准确的说法了,再多一点就过分了。比如典型的,如果你没有一个开放的环境和不是重约束的管理流程,实施重构就不可能。而你不能很还的实施重构,还说你是敏捷就是扯淡。而话说回来,你实施了TDD和重构以及持续集成,当然就已经达到了某些CMM的要求。同时很遗憾的告诉大家,敏捷方法没有自己追求的目标,而完全只是为了满足人们开发出更好软件的这个目标的辅助条件。而有些人,依照cmm的习惯,不能认识到这一点。
>
> >>>> 当然动不动就说什么大项目,大团队,大规模,这个事情不是一天两天了,用这个事情说事也不是一天两天了。这个事情我不需要多说,大家都是有经验的,自己应该都有认识。
> >>>> 而现在这些情况,我们大家其实都可以在各个地方看到。如果你实在没有案例,那看看张克强和另外一些人吧。
>

> >>>> 而问题在于,有这么多不是敏捷的看法,他们反而还觉得自己是敏捷的人,真是奇怪。其实原因也很简单,cmm在他们看来是官方的,所以不敢反对,敏捷现在是主流也不敢反对。所以这些人其实不仅仅是伪敏捷,而且也是伪cmm。...
>
> read more »

Kula

unread,
Dec 17, 2011, 11:26:16 PM12/17/11
to agile...@googlegroups.com
此贴一出,这个邮件列表就没人敢说话了。哈哈哈。

可见敏捷导师们心有多虚了


2011/11/7 kingfish <niu...@gmail.com>

Jeff Xiong

unread,
Dec 20, 2011, 10:41:41 PM12/20/11
to agile...@googlegroups.com
那倒不一定。新历年前通常是培训旺季,各家公司的预算要赶紧花掉。敏捷导师们也可能是去赚新春大礼包了。

2011/12/18 Kula <kula...@gmail.com>:

--
Jeff Xiong
www.Gigix.me

Kula

unread,
Dec 20, 2011, 11:23:22 PM12/20/11
to agile...@googlegroups.com
希望是这样吧..

2011/12/21 Jeff Xiong <gigi...@gmail.com>

Peee Kongyee

unread,
Dec 20, 2011, 11:55:42 PM12/20/11
to agile...@googlegroups.com
突然想到的,经常见到而又恶心的问题是越位的问题,管理层跑过去指责执行层的问题,执行层不停的去做替代管理层做管理工作,最后大家一团糟,早几年觉得CMM是解药,这几年觉得敏捷是解药,其实解药就是自身的问题,能否很好的把握自己在团队中的角色,以及如何扮演好这个角色,相信无论是何种方法都是适用的。

泥泥

unread,
Dec 21, 2011, 12:14:29 AM12/21/11
to agile...@googlegroups.com

普遍适用只是一个神话-摘自《平衡敏捷和规范》


当我们发现某样东西有效时,就很容易认为它普遍适用。这正是银弹的特性,软件生产力联盟的Sarah Sheard对银弹的生存周期进行过令人愉快的描述。银弹的生存周期是这样一个过程:发现→成功应用→对成功的宣传→要素的建立和公布→首次(轻微的修改)重复运用→早期采用者的证实→无知的中层管理者在迥然不同的环境中对其进行过程化和实施→资金不足以及误用→由于最初思想的退化导致回报逐步变少→最终被丢弃并开始新的发现 

jayden guan

unread,
Dec 21, 2011, 12:47:55 AM12/21/11
to agile...@googlegroups.com
   这是因为,瓶颈的位置发生了变化。

Xu Yi

unread,
Dec 21, 2011, 1:11:15 AM12/21/11
to agile...@googlegroups.com
还因为,瓶子的形状发生了变化。
- - - - - - - - - -
Xu Yi, Kaverjody
Senior Agile Consultant @ HP Enterprise Services
Blog : http://blog.sina.com.cn/kaverjody
Sina Weibo : http://weibo.com/kaverjody
Skype : kaverjody
- - - - - - - - - -

Peee Kongyee

unread,
Dec 21, 2011, 1:23:09 AM12/21/11
to agile...@googlegroups.com
也许瓶子大小根本没有变化只是形状变了一下,其实这也就是考察企业的综合实力,以及实力分布是否和自身业务开展向符合

korbenzhang

unread,
Dec 21, 2011, 8:11:21 AM12/21/11
to agile...@googlegroups.com
那敏捷导师汇报一下干什么呢呗

Jeff Xiong <gigi...@gmail.com>编写:

LiHongxi

unread,
Dec 23, 2011, 9:54:18 AM12/23/11
to agile...@googlegroups.com
        前几天,有幸参加了姜志辉老师的培训,收获了很多的知识,他对XP,TDD,UCD等方面有很深的造诣,敏捷真的要落地,真的要继续发展,在中国来讲,他们是不可忽视的力量。从这个角度来讲他们也是导师,也在做着对人们有益的事情。

Kula

unread,
Jan 5, 2012, 3:52:06 AM1/5/12
to agile...@googlegroups.com
这些话,基本上等同于废话。

2011/12/23 LiHongxi <lihx...@gmail.com>
        前几天,有幸参加了姜志辉老师的培训,收获了很多的知识,他对XP,TDD,UCD等方面有很深的造诣,敏捷真的要落地,真的要继续发展,在中国来讲,他们是不可忽视的力量。从这个角度来讲他们也是导师,也在做着对人们有益的事情。

--

LiHongxi

unread,
Jan 6, 2012, 9:40:04 AM1/6/12
to agile...@googlegroups.com
个人认为:有一些事情说的太宽,太大,不追求本质,或者加入一些市场方面的因素,也是不正确的。
有很多的客观世界的事物要抽象出一个比较清晰的概念,形成逻辑的线索,才能迅速地找到答案。
Reply all
Reply to author
Forward
0 new messages