论坛首页 综合技术论坛

敏捷到底带给我们什么?

浏览 11963 次
该帖已经被评为良好帖
作者 正文
   发表时间:2009-11-23  
  前两天thoughtworks的李晓童鞋来公司做敏捷分享.闲聊了一个多小时的回顾会议. 这个话题还真是足够精巧. 以至于可以在一个多小时时间内讲完. 并且带大家完成一次模拟的回顾会议..过程当然自不必说..不过题目也确实是太小了. 以至于敏捷的核心内容都无法提及. .不愧是前thoughtworks的员工.深谙咨询之道 ..

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

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

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

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

  敏捷对资本家有利.说到底对你自己也有利..为什么不敏捷起来呢?.
   发表时间:2009-11-23   最后修改:2009-11-23
文化的力量。很多人希望在实施敏捷的同时避免自己在权力上的损失,或者说他们不希望敏捷削弱自己的权力。
0 请登录后投票
   发表时间:2009-11-24  
经济危机,所以大家都在谈lean。
减少浪费。。。。

敏捷就是适合一个团队达成目标的一种方式。
这种方式可能放到别的团队,或者这个团队,别的项目,都是不一定能成功的。
中国人喜欢搞集中制,不适合敏捷,老外更民主一点,团队更容易自组织。
0 请登录后投票
   发表时间:2009-11-24  
每个人身处的环境不一样,重点就会有差异。

迭代不一定很多,但是可以改变一种做事行为。
0 请登录后投票
   发表时间:2009-11-24  
    高强度的tdd确实应该算作是核心.当然前期的userstory同样重要.
  
    在你写出真正的高强度的tdd代码之后. 你会发现tdd把你变得多么像一个机器人.那么精密.甚至差池甚小..甚至编程的成就感都会降低.因为你没有了那种写完一大段代码然后package.  deploy .. run .. 成功的喜悦或失败的沮丧.. .而你事先就知道你肯定会成功..不成功反而变成了是不正常的. .

    所以当李晓讲完回顾会议以后.大家的态度几乎一致的认为没有切到重点..上面我才会说他精于咨询之道. . mock1234的抓住tdd重点的这种方法我也很赞成.. 当然我同时也觉得提升团队的凝聚力跟战斗力同样也是重要的.. 毕竟软件开发是人来做的..
0 请登录后投票
   发表时间:2009-11-24   最后修改:2009-11-24
Saito 写道
    高强度的tdd确实应该算作是核心.当然前期的userstory同样重要.
  
    在你写出真正的高强度的tdd代码之后. 你会发现tdd把你变得多么像一个机器人.那么精密.甚至差池甚小..甚至编程的成就感都会降低.因为你没有了那种写完一大段代码然后package.  deploy .. run .. 成功的喜悦或失败的沮丧.. .而你事先就知道你肯定会成功..不成功反而变成了是不正常的. .

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

这是你的实际体验还是想象?
0 请登录后投票
   发表时间:2009-11-24  
  恰好适逢公司内部在推敏捷..以我这个fib的tdd底蕴告诉我..是这样的..

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

 
0 请登录后投票
   发表时间:2009-11-24  
Saito 写道
  恰好适逢公司内部在推敏捷..以我这个fib的tdd底蕴告诉我..是这样的..

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

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

既然你是实际的体验,那么你的TDD达到了什么样的强度,比如覆盖度达到多少?
0 请登录后投票
   发表时间:2009-11-24  
  呵呵.公司内部推的敏捷美名其约"山寨敏捷"..做法就是把mock1234兄的做法倒过来..改善各种过程..tdd不强求..但一定要有unitTest ..然后hudson做了CI .并且已经完成了3个迭代..并且交付了一期 ..不过我很难把这个跟敏捷联系起来...

  但是我很理解thoughtworks人做咨询的立场.. 我不给你搬敏捷..帮你改善过程就是了.对啊..现在对我们内部来说..过程确实改善了一些..  一定要强求是敏捷么?..倒也不一定..当然从每个成功学大师的眼里来看.. 你没成功..不是因为别的. 是因为你没copy好别人的原型 ..  成功是可以复制的..  呵呵. 暂且相信复制敏捷可以成功.. 那我们慢慢来..
0 请登录后投票
   发表时间:2009-11-24   最后修改:2009-11-24
Saito 写道
  呵呵.公司内部推的敏捷美名其约"山寨敏捷"..做法就是把mock1234兄的做法倒过来..改善各种过程..tdd不强求..但一定要有unitTest ..然后hudson做了CI .并且已经完成了3个迭代..并且交付了一期 ..不过我很难把这个跟敏捷联系起来...

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

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

跳转论坛:
Global site tag (gtag.js) - Google Analytics