敏捷到底带给我们什么?

  前两天thoughtworks的李晓童鞋来公司做敏捷分享.闲聊了一个多小时的回顾会议. 这个话题还真是足够精巧. 以至于可以在一个多小时时间内讲完. 并且带大家完成一次模拟的回顾会议..过程当然自不必说..不过题目也确实是太小了. 以至于敏捷的核心内容都无法提及. .不愧是前thoughtworks的员工.深谙咨询之道 ..

  从敏捷在国内靠几个传教士的传播.到现在的各个公司寻求敏捷咨询. 在这个过程中.敏捷的传教士们从严厉的教人们如何敏捷.什么才是敏捷的.什么不是.. 到现在的咨询过程中不提敏捷.只讲过程改善. . 这其中的改变也是意味深长..

  敏捷来自资本主义社会.不管是敏捷还是各种其他方法的最终目的都是怎么能更极力的压榨劳动力.让他在有限时间内给你写更多有质量并且高效的代码 ..在中国这就又有些意思了..似乎有很多员工支持敏捷而公司不存在实施环境 .这本身就颠倒了本源.说到创业团队. 似乎更应该敏捷起来.因为你们是为自己投资..

  当tdd告诉你小步前行并把你改造为code-robot .当你觉得枯燥乏味看不到希望时给你看到每次原型演示的喜悦..当你遇到问题时定期给你一个回顾会议让你去表达..敏捷的各种方式都让身处其中的你能更加专注于工作.写出更高质量的代码..所以实施敏捷相比于传统方式是更累的.因为你是真的专注的写了一天的代码.. 这也是为什么敏捷告诉你.最好不要加班 .. 每天能完整的压榨掉这8个小时已经足够了.这也保证了你明天也能有充足的战斗力..

  敏捷的实施其实更应该是老板们推.而不是员工说我们敏捷吧.. 当然 员工们为了自己的未来去推敏捷当然也是很有好处..分享上也有人问了李晓说. 敏捷会不会对开发人员要求过高.他的回答是. 如果你是一个专业的程序员.那这要求就不算高 .当然任何行业做到专业..对行业内人员的要求都是很高的..他用自己的一个例子做了解说. 他曾经在团队内只有自己一个人写单元测试. 当然是后来补的.不是tdd. 坚持了一年. 结果测试那边反馈说他的bug是最少的. 当然了. 因为别人都没有测试..后来他就去了thoughtworks ..

  敏捷对资本家有利.说到底对你自己也有利..为什么不敏捷起来呢?.

评论

23 楼 swing 2010-02-01  

要说明的是：李晓没有在离开 ThoughtWorks 后以 ThoughtWorks 的名义作过咨询，也没有单独作过咨询，。我只是在一个非常简短的个人说明里面包含了自己仅有的工作经历而已。

之前赋闲在家有时间，一个朋友邀请，所以去了大概是楼主的公司做一次交流，讲个敏捷相关的题目，算是分享经验，没有物质交换。

不能说深谙咨询之道，只是想讲一个东西，讲明白并让受众可以立刻有所得以至于应用要怎么做。

至于 TDD，不是主要内容，随口带到，也是以符合主题的说法出现，不见得就如何如何。意外的是那个故事居然被记得，看来以后不能随口，因为内容简单概要，而上下文不见得被记得，又是临场说出，所以导致误解难免。
谈到对 TDD 的要求，其实哪里有一步到位的说法？我相信，每个人都有过程，只是这过程是长或短，更痛苦还是更快乐而已，我想对于一个不以 TDD 为必要条件的环境，开始在事后写点测试，是一个非常好的开端，一旦开始这么作了，你慢慢从中获得的快乐高于你付出的努力后，后面怎么做其实都不需要别人告诉你了。

有关 tdd 更多的想法是（最近从同事处得知），仿佛下围棋，假设有一个最佳盘面结果是按照最佳的过程得出的解，那么你落子的顺序和你的结果有关么？关系大吗？似乎一般都很有关系，而且关系大。
为什么要这么问？一般来说不见得每次或者说你能够按照最佳过程来落子，每盘棋总是有各种状况，那么，在这个过程中，你可能需要考虑的是，我如何做到落子的顺序最大限度不影响我得到的最佳结果。特别是当我已经落了一些子了的情况下才认识到最佳结果的具体形态。
如果这样考虑了，那么你可能从单一解转变到多解，过程略显次要，于是更容易得到好的结果。
如果你从这个角度出发，后写一些测试就不见得和 tdd 格格不入。当然我和同事讨论这个不是因为后写测试的问题。

”如果你是一个专业的程序员.那这要求就不算高“ 的说法我想也不算太恰当，也许更准确得说是，问题不是敏捷要求高，问题是做到专业要求高。有一个说法：问题不是你选择了什么，而是在你选择之后怎么做。TDD 自有它的磨难，不 TDD 也有它的磨难。所以，我不认为你选择 TDD 就能少些磨难，问题只是你当初的选择是为什么而已，更不要去说什么对开发人员要求过高，不选择 TDD 自然也能专业，经历磨难也在所难免。好吧，这个话怎么说我自己也觉得难以两全，也许我该把自己的意愿强加给人（假设我们在做 Java，我想我会说：有个东西叫 JUnit，必须用好它），然后有人反驳，然后我说，我认同你观点的存在也是正确的结果。

至于楼主的有关 “ 当tdd告诉你小步前行并把你改造为code-robot .当你觉得枯燥乏味看不到希望时给你看到每次原型演示的喜悦 "，以及 ”敏捷对资本家有利.说到底对你自己也有利..为什么不敏捷起来呢?.“
是快乐，我因为快乐所以选择它，而不是别的，我看到很多人，都是因为这个，包括做软件。

22 楼 xindeman 2009-12-08  

gurudk 写道

“敏捷”这个词包含的东西太多了，每个人理解都不一样。

把事情作对的方式很多，敏捷实践是其中的一种方式，它一方面带来了很多最佳实践，另一方面是一种新的思维方式。

关注问题，关注组织中的浪费，寻求方法进行改进。将敏捷实践看成做出这些改进，可以参考的集合。

如果一味的强调敏捷，就好像寻求银弹一样，在你还不清楚自己存在什么问题的时候，试图去寻找一个解决所有目前和预想未来可能存在问题的工具。

这，是不靠谱的。

完全同意。

21 楼 mht19840918 2009-12-08  

敏捷---本是一种新的思维方式，却被国人更多的和谐化了，以至于过多的形式化，抛开政治目的以及角色，确实是一种最佳实践，但也仅仅是一过度罢了，试问真正做大敏捷的的有几个？大多选择的是一种权衡，一种介于敏捷于瀑布之间的权衡。

20 楼 gurudk 2009-11-28  

“敏捷”这个词包含的东西太多了，每个人理解都不一样。

把事情作对的方式很多，敏捷实践是其中的一种方式，它一方面带来了很多最佳实践，另一方面是一种新的思维方式。

关注问题，关注组织中的浪费，寻求方法进行改进。将敏捷实践看成做出这些改进，可以参考的集合。

如果一味的强调敏捷，就好像寻求银弹一样，在你还不清楚自己存在什么问题的时候，试图去寻找一个解决所有目前和预想未来可能存在问题的工具。

这，是不靠谱的。

19 楼 系统程序 2009-11-28  

mock1234 写道

过去是苦恼于如何写出好的系统概要设计，现在是苦恼于如何进行好的所谓敏捷开发。

我看如果只看形式，那么其实这是软件工程倒退了。过去的苦恼没有解决，反而新添了许多为自己的鼠目寸光行为找的借口。

我觉得XP技术尚且不够有效呢，而Scrum那类则根本就是骗子。所以我只看有没有高强度的TDD测试，而不看在行政手段上搞了许多迭代、会议的那种所谓敏捷。

需求设计是"写"出来的吗? 当用户都不知道该如何做的时候，你怎么“写”出好的概要设计？敏捷其实是抛弃了那些根本不可能达到的目标

18 楼 Saito 2009-11-27  

  看了Doit .嗯. 是李晓介绍的GTD的工具 .. 呵呵.分享中有段插曲.. (由于这东西是用AIR开发的..) 他说在actionScript中没有一整套完整的敏捷工具..实施起来很不爽.

  不过原来他的英文名是 sean li .. 他只是被邀请来做分享的..看了上面TWers的回复.我也很期待跟他pair ..

17 楼 chandler 2009-11-27  

    敏捷开发这东西，就好像中国企业搞什么erp.
    ERP绝对是个十分优秀的管理理念。但是要用好他，从管理层到最低下的看仓库的，生产一线工人都有一定要求。而且越是管理层，要求越高。很多用了ERP的企业管理者都不知道ERP是什么。ERP是需要企业的整体素质达到一定层面才能发挥威力的。不然只会让自己越搞越糟糕。
    但是中国的现状是什么。很多企业不具备ERP的管理的基础。还是想要搞ERP。无外乎好奇，面子等等因素。而不是本身需求。
    所以我觉得，如果搞什么敏捷开发。首先要看看自己团队的整体素质达到了没有。如果没有，还实现提高自身再说。

16 楼 star022 2009-11-27  

貌似大多数人都觉得TDD，XP很复杂~~，有时候是不是可以抓住重点，让其简单化？

15 楼 chenzengpeng 2009-11-27  

sean现在在你们公司吗？
很珍惜跟他在一起的工作岁月，真正认识了敏捷，了解了敏捷，很感谢sean

14 楼 freej 2009-11-25  

Saito 写道

  不过说到SOA.据我了解.国内各大企业内部都有相应的解决方案..所谓SOA水土不服一说.可以说是不存在的..另外公司没到有这种需求的时候.其实失败也是自然..

  不过要说到国外各大企业的SOA产品..确实ibm oracle jboss都有相应的解决方案..如果大家都说SOA是忽悠的话那确实神也挡不住..毕竟他们忽悠的是自己的产品..至于概念...其实SOA落地到组件化开发..你说SOA是忽悠..基本就等同于说组件化开发是忽悠..

  对于中国人的思维模式..确实值得探讨一些..敏捷中的一些做法..确实对于我来说还是有些西化..或许是我们开惯了国人会议的原因. ..总有一些适应的过程. .

组件化开发是一种已经相当成熟的思想了，不能说SOA落地之后就是组件化开发，只能说是组件化开发模式被SOA所引用，就像AOP建立在OO思想上一样。

SOA并不是在忽悠，只是还没有本地化的强有力外部条件，大环境还没有做好准备，所以推广起来很困难。当然，我这里说的是针对企业的SOA思想，并不说是IBM之类的SOA产品。所以说，技术上已经就绪，但是机会尚未成熟。在没有成熟的本地化实践环境的前提下，过早的大面积推行SOA只能给人一种不好的第一印象。

13 楼 Saito 2009-11-25  

  不过说到SOA.据我了解.国内各大企业内部都有相应的解决方案..所谓SOA水土不服一说.可以说是不存在的..另外公司没到有这种需求的时候.其实失败也是自然..

  不过要说到国外各大企业的SOA产品..确实ibm oracle jboss都有相应的解决方案..如果大家都说SOA是忽悠的话那确实神也挡不住..毕竟他们忽悠的是自己的产品..至于概念...其实SOA落地到组件化开发..你说SOA是忽悠..基本就等同于说组件化开发是忽悠..

  对于中国人的思维模式..确实值得探讨一些..敏捷中的一些做法..确实对于我来说还是有些西化..或许是我们开惯了国人会议的原因. ..总有一些适应的过程. .

12 楼 雁行 2009-11-25  

很排斥TDD的过客，虚心聆听大牛论道。。。。。。

11 楼 freej 2009-11-25  

gurudk 写道

经济危机，所以大家都在谈lean。
减少浪费。。。。

敏捷就是适合一个团队达成目标的一种方式。
这种方式可能放到别的团队，或者这个团队，别的项目，都是不一定能成功的。
中国人喜欢搞集中制，不适合敏捷，老外更民主一点，团队更容易自组织。

没错，敏捷思想在中国受到了广大开发人员的追捧（说实话，我觉得这种追捧有些盲目），但是在中国特色的大背景下，敏捷是不太符合中国人，尤其是中国老板的思维模式的，就像SOA的模式不能在中国很好的运用一样。实践SOA的大前提是企业组织结构要率先进行相应的调整，可中国企业并不能适应，或者说不愿意进行这种调整，N多SOA计划都是这么搁浅的。说回敏捷，也是如此，在中国老板看来，权利下放是一件很危险的事，尤其是下放给拥有所有开发实施项目人员的独立团队，似乎是很难控制的一件事。另一方面，大多数开发人员都是有足够的自觉性和上进心的，并且他们宁愿八小时满负荷工作，也不愿意成天加班。同时，合格开发人员所具备的对新技术和新方法的探索精神，也诱使他们对敏捷颇感兴趣。我想这就是为什么造成了老板不推员工推的想象，终归还是一句话——中国人的思维模式。

10 楼 Tin 2009-11-25  

1个小时的时间显然不能让你走马观花到敏捷的全部。但是当你见识了敏捷的大部分以后，你发现它的核心思想就是很简单。按着去做，不断的改进就好了。
TDD这个东西，不是质量驱动的一个东西，而是一个帮助你不断改善设计的工具。我听过很多人为他bug频出且丑陋的代码辩护，说它能工作就是好的，极力避免各种设计债务后面的实践上的缺陷。
能够在一个小时里抽出时间帮你做回顾，我想那已经是非常照顾你了，因为我在敏捷团队里感觉最有用的工具就是回顾，大家找到问题，解决问题，改进每日做事的方式，这就是自组织团队的精髓。
李晓是非常NB的前TWer，也是非常NB的TDDer。作为个体程序员，和他结对经常会让你想哭，但是哭过以后你发现自己进步了。这就是导师的作用。我非常珍惜和他工作的经历。

9 楼 gigix 2009-11-24  

Saito 写道

  呵呵.公司内部推的敏捷美名其约"山寨敏捷"..做法就是把mock1234兄的做法倒过来..改善各种过程..tdd不强求..但一定要有unitTest ..然后hudson做了CI .并且已经完成了3个迭代..并且交付了一期 ..不过我很难把这个跟敏捷联系起来...

  但是我很理解thoughtworks人做咨询的立场.. 我不给你搬敏捷..帮你改善过程就是了.对啊..现在对我们内部来说..过程确实改善了一些..  一定要强求是敏捷么?..倒也不一定..当然从每个成功学大师的眼里来看.. 你没成功..不是因为别的. 是因为你没copy好别人的原型 ..  成功是可以复制的..  呵呵. 暂且相信复制敏捷可以成功.. 那我们慢慢来..

要是李晓按照他一直遵循的方式来要求你们，第一你们会很痛苦，第二你们还是没办法学会多少，第三你们能自己坚持下去的改进很少。
所以，我相信李晓做的是对的。全面敏捷也许能根治你们的某些病，但这剂猛药你们现在受不起。根据自己的客观条件做一些切实的改进，才是实在的态度。
另外李晓已经离开ThoughtWorks一段时间了。他是个非常好的TWer，但给你们做的这个咨询不代表ThoughtWorks。

8 楼 Saito 2009-11-24  

  呵呵.公司内部推的敏捷美名其约"山寨敏捷"..做法就是把mock1234兄的做法倒过来..改善各种过程..tdd不强求..但一定要有unitTest ..然后hudson做了CI .并且已经完成了3个迭代..并且交付了一期 ..不过我很难把这个跟敏捷联系起来...

  但是我很理解thoughtworks人做咨询的立场.. 我不给你搬敏捷..帮你改善过程就是了.对啊..现在对我们内部来说..过程确实改善了一些..  一定要强求是敏捷么?..倒也不一定..当然从每个成功学大师的眼里来看.. 你没成功..不是因为别的. 是因为你没copy好别人的原型 ..  成功是可以复制的..  呵呵. 暂且相信复制敏捷可以成功.. 那我们慢慢来..

7 楼 daquan198163 2009-11-24  

Saito 写道

  恰好适逢公司内部在推敏捷..以我这个fib的tdd底蕴告诉我..是这样的..

  当然..人跟人是不同的.. .这不跟我说这坨臭豆腐很香..总有人不同意不是一样的么?

但是人跟人的区别毕竟是有限的，有的时候沟通不畅导致人们看起来区别很大
这就好比臭豆腐，总有人光用鼻子闻一下就断定它吃起来也是臭的

既然你是实际的体验，那么你的TDD达到了什么样的强度，比如覆盖度达到多少？

6 楼 Saito 2009-11-24  

  恰好适逢公司内部在推敏捷..以我这个fib的tdd底蕴告诉我..是这样的..

  当然..人跟人是不同的.. .这不跟我说这坨臭豆腐很香..总有人不同意不是一样的么?

 

5 楼 daquan198163 2009-11-24  

Saito 写道

    高强度的tdd确实应该算作是核心.当然前期的userstory同样重要.
  
    在你写出真正的高强度的tdd代码之后. 你会发现tdd把你变得多么像一个机器人.那么精密.甚至差池甚小..甚至编程的成就感都会降低.因为你没有了那种写完一大段代码然后package.  deploy .. run .. 成功的喜悦或失败的沮丧.. .而你事先就知道你肯定会成功..不成功反而变成了是不正常的. .

    所以当李晓讲完回顾会议以后.大家的态度几乎一致的认为没有切到重点..上面我才会说他精于咨询之道. . mock1234的抓住tdd重点的这种方法我也很赞成.. 当然我同时也觉得提升团队的凝聚力跟战斗力同样也是重要的.. 毕竟软件开发是人来做的..

这是你的实际体验还是想象？

4 楼 Saito 2009-11-24  

    高强度的tdd确实应该算作是核心.当然前期的userstory同样重要.
  
    在你写出真正的高强度的tdd代码之后. 你会发现tdd把你变得多么像一个机器人.那么精密.甚至差池甚小..甚至编程的成就感都会降低.因为你没有了那种写完一大段代码然后package.  deploy .. run .. 成功的喜悦或失败的沮丧.. .而你事先就知道你肯定会成功..不成功反而变成了是不正常的. .

    所以当李晓讲完回顾会议以后.大家的态度几乎一致的认为没有切到重点..上面我才会说他精于咨询之道. . mock1234的抓住tdd重点的这种方法我也很赞成.. 当然我同时也觉得提升团队的凝聚力跟战斗力同样也是重要的.. 毕竟软件开发是人来做的..