你一个人所说的“伪敏捷”并不能代表所有的认识。调查就是调查,大家愿意发表看法就发表看法。你这样打压言论,甚至人身攻击,有违一般的论坛游戏规则。
你这样不讲礼貌的发言,对你、对论坛有什么好处吗? 没有。现在政府并没有资助敏捷,无论是个人培训还是组织评估。
这种情况下,讨论敏捷或者伪敏捷,并不会搞臭敏捷啊。这与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 , 欢迎有兴趣的朋友去哪里看看。在 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
--
张克强blog: 从高效过程到卓越结果
--
敏捷中国 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
再强调一次,推广了什么方法,承诺了什么和兑现了什么。
而总是有些人,希望在不实施这些关键方法的情况下,还是可以声称自己在实施敏捷。另外,有些人认为敏捷方法没必要你们严肃,以及也没有必要有什么门户之见,可以和其他方法,特别是可以和cmm结合使用。
1. 本邮件列表严格反对假话大话空话。
2. 本邮件列表原则上不鼓励骂人。
综上两点,观点清晰有理有据的言论,不论是打压某人还是洋洋洒洒,都不在本邮件列表反对的范围内。我解释清楚了吗?
请不要把“论坛通行的规则”套用在本邮件列表头上。作为管理员,我没有把这两条规则正式写在邮件列表的首页,由此造成的误解,我深表歉意。
2011/11/3 张克强 <zhangk...@gmail.com>:
> 1,论坛、群组本身就是大家发言讨论的地方。如果不赞同某人的发言,当然可以反驳。但是如果因为不同意某些人的发言,而进行全面的打压,这不符合论坛通行的规则。
> 这里没有竞选州长的竞争对手。
> 4,敏捷推荐自组织,论坛也需要自组织。
> 5,敏捷推崇价值,现在这样的讨论对这个群里的成员有什么价值? 转为私下直接讨论,会不会更好些?
> 6,敏捷推崇简单,洋洋洒洒数千言,除开攻击类文字外,剩下了些什么,能不能浓缩些?看文字也挺费时间的
--
Jeff Xiong
www.Gigix.me
- 怎么确认自个儿有这种能力?
- 目前流行的檢驗方式是
- 看你所在的领域,你吃的亏是否是周围人里最多的
- 这样,才可能明确这一领域想干成一件事儿,哪些苦逼的事儿坚决不能作
...
> 好了,今天就说这么多。太晚了,没时间查错了,请大家原谅。同时做个预告,我一定会在最近写一个敏捷十年总结以及敏捷过后我们的新追求的文章。这次觉得不会拖太久。
严正期待这篇文章,看 ThoughtWork 的各种软文时间长了,需要真正一线的聲音!
...
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
回想若干年前的自己,为了做好手中的软件,面对开发中种种的问题。我现在都无法忘记,当第一次看到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 »
2011/12/18 Kula <kula...@gmail.com>:
--
Jeff Xiong
www.Gigix.me
Jeff Xiong <gigi...@gmail.com>编写:
前几天,有幸参加了姜志辉老师的培训,收获了很多的知识,他对XP,TDD,UCD等方面有很深的造诣,敏捷真的要落地,真的要继续发展,在中国来讲,他们是不可忽视的力量。从这个角度来讲他们也是导师,也在做着对人们有益的事情。
--