2007-05-24
敏捷不是一天两天的事情
Google Group 的敏捷讨论组”ａｇｉｌｅｃｈｉｎａ“向来比较活跃。在交流心得的过程中，一些成员发出感慨说推行敏捷挺难的。有开发人员认识上的原因，有行政方面原因，也有技术水平方面的原因。结合我个人的经验和思考，我认为这到底应该说是一种认识上的偏差。敏捷不是一天两天的事情。
敏捷是一种开发方式，CMM也是一种开发方式。但是两者的产生过程完全不同。CMM 是以局外人的角度，对软件开发的"成熟度"进行定义和约束；敏捷则是由众多高水平的项目团队通过总结经验自发的产生出来的，这也是前者遭到开发人员抵制，而后者受欢迎得多的原因之一。
正因如此，推行 CMM 是自上而下，而推行敏捷则应该自下而上。将推行 CMM 的方式用于推行敏捷，只会适得其反。同 CMM 相比，自下而上的推行要困难得多。因为只要少数几个人接受，就可以推广 CMM，而推广敏捷必须先让大多数人接受敏捷的思想。
你可能说：我们可以先做起来嘛，做着做着就有思想了嘛。然而据我在论坛上所见，基本上没有这样的例子。打个比方，我要闹革命，第一步是做什么？苦口婆心的布道？到处发传单？搞暗杀政变？都不是。第一步应该是活跃社会言论。言论活跃起来了，人们就更容易思考，也就更容易接受新思想，比如我的思想。越多的人接受我的思想，我接下来做的事情就越容易被接受，被认同，甚至会有人自发的追随我。
所以，让一个死气沉沉的团队接受 CMM 不难，因为照着领导制定的做就行了，基本上不需要思考；而要推广敏捷，有太多的东西需要思考， ａｇｉｌｅｃｈｉｎａ本身就是个例子。思考体现了人的本质，体现了敏捷把人作为项目核心的本质。
那么是先”敏捷“再思考，还是先思考再敏捷？先”敏捷“再思考，”敏捷“就成了一个包袱，搞什么事情都要想”这算不算敏捷？“所以效果不好。甚至还有的”敏捷“规定只要有人完成一项任务，就大家都停下来做代码复审，搞得怨声载道，这已经跟敏捷背道而驰了。
基于上面的想法，我现在做的就是保持我所在的项目成员的积极性。他们对敏捷基本上不了解，我也不提敏捷两个字，什么测试驱动结对编程持续集成都不提。但是所有阻碍大家相互交流的东西要统统去掉。不要拘谨，不要怕说错话，有问题就说，等等等等。现在在我们项目组讨论是很随便的事情，谁也不怕被别人打断，偶尔凑在一起编东西。但是我们没有持续集成，没有测试驱动，连单元测试都少得可怜。我们离真正的敏捷还早的很，但我希望当有一天别人跟我们中的某位吹嘘什么是敏捷时，我们那位的反应是：
”……去，我以为你说什么呢。“
敏捷是一种开发方式，CMM也是一种开发方式。但是两者的产生过程完全不同。CMM 是以局外人的角度，对软件开发的"成熟度"进行定义和约束；敏捷则是由众多高水平的项目团队通过总结经验自发的产生出来的，这也是前者遭到开发人员抵制，而后者受欢迎得多的原因之一。
正因如此，推行 CMM 是自上而下，而推行敏捷则应该自下而上。将推行 CMM 的方式用于推行敏捷，只会适得其反。同 CMM 相比，自下而上的推行要困难得多。因为只要少数几个人接受，就可以推广 CMM，而推广敏捷必须先让大多数人接受敏捷的思想。
你可能说：我们可以先做起来嘛，做着做着就有思想了嘛。然而据我在论坛上所见，基本上没有这样的例子。打个比方，我要闹革命，第一步是做什么？苦口婆心的布道？到处发传单？搞暗杀政变？都不是。第一步应该是活跃社会言论。言论活跃起来了，人们就更容易思考，也就更容易接受新思想，比如我的思想。越多的人接受我的思想，我接下来做的事情就越容易被接受，被认同，甚至会有人自发的追随我。
所以，让一个死气沉沉的团队接受 CMM 不难，因为照着领导制定的做就行了，基本上不需要思考；而要推广敏捷，有太多的东西需要思考， ａｇｉｌｅｃｈｉｎａ本身就是个例子。思考体现了人的本质，体现了敏捷把人作为项目核心的本质。
那么是先”敏捷“再思考，还是先思考再敏捷？先”敏捷“再思考，”敏捷“就成了一个包袱，搞什么事情都要想”这算不算敏捷？“所以效果不好。甚至还有的”敏捷“规定只要有人完成一项任务，就大家都停下来做代码复审，搞得怨声载道，这已经跟敏捷背道而驰了。
基于上面的想法，我现在做的就是保持我所在的项目成员的积极性。他们对敏捷基本上不了解，我也不提敏捷两个字，什么测试驱动结对编程持续集成都不提。但是所有阻碍大家相互交流的东西要统统去掉。不要拘谨，不要怕说错话，有问题就说，等等等等。现在在我们项目组讨论是很随便的事情，谁也不怕被别人打断，偶尔凑在一起编东西。但是我们没有持续集成，没有测试驱动，连单元测试都少得可怜。我们离真正的敏捷还早的很，但我希望当有一天别人跟我们中的某位吹嘘什么是敏捷时，我们那位的反应是：
”……去，我以为你说什么呢。“
评论
xj4150
2007-05-26
yananay 写道
因为敏捷开发对人员的要求太高了。
但是就目前来说，公司都愿意控制人员成本，所以，
老方法还是占据主要位置的。
但是就目前来说，公司都愿意控制人员成本，所以，
老方法还是占据主要位置的。
嗯。得考虑对人员培训的成本。
yiding_he
2007-05-25
xj4150 写道
可是这个“产生”的过程可能会很长啊。适当的引导也得让被引导的人对这种东西有足够的认识和理解啊，如果他们都不知道这是什么，能干什么，如何引导？“拓荒”的工作不好干啊！更何况敏捷确实“反传统”。
不是会很长，而是会很长很长。如果他们知道这是什么，能干什么，这表示他们已经不需要引导了。要“拓”下去确实不容易，多观察多总结是肯定少不了的。
yananay
2007-05-25
因为敏捷开发对人员的要求太高了。
但是就目前来说，公司都愿意控制人员成本，所以，
老方法还是占据主要位置的。
但是就目前来说，公司都愿意控制人员成本，所以，
老方法还是占据主要位置的。
xj4150
2007-05-25
yiding_he 写道
gigix 写道
这个事情，不光是敏捷的问题，而是引入新东西的问题。泛泛说怎么引入新东西，温伯格《咨询的奥秘》有很多有趣的经验。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
思则求变。一，我认为新的工作方式是在适当的引导下自发产生的。也就是说，如果工作方式有问题，在领导提出疑问之前，成员就已经发现问题了。二，我认为新的工作方式是渐渐产生的。也就是说，团队总是有足够的时间作出调整，保证新的工作量“有价值”。敏捷重在“产生”而不是“引入”。
可是这个“产生”的过程可能会很长啊。适当的引导也得让被引导的人对这种东西有足够的认识和理解啊，如果他们都不知道这是什么，能干什么，如何引导？“拓荒”的工作不好干啊！更何况敏捷确实“反传统”。
yiding_he
2007-05-24
gigix 写道
这个事情，不光是敏捷的问题，而是引入新东西的问题。泛泛说怎么引入新东西，温伯格《咨询的奥秘》有很多有趣的经验。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
思则求变。一，我认为新的工作方式是在适当的引导下自发产生的。也就是说，如果工作方式有问题，在领导提出疑问之前，成员就已经发现问题了。二，我认为新的工作方式是渐渐产生的。也就是说，团队总是有足够的时间作出调整，保证新的工作量“有价值”。敏捷重在“产生”而不是“引入”。
gigix
2007-05-24
这个事情，不光是敏捷的问题，而是引入新东西的问题。泛泛说怎么引入新东西，温伯格《咨询的奥秘》有很多有趣的经验。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
至于敏捷，同样需要由上而下的支持，光靠自下而上的行动是不够的（尽管后者也很重要并且不可或缺）。原因是，敏捷引入了新的工作方式、团队组织方式、项目管理方式、客户合作方式。做这些新的事情对开发团队提出了新的要求。如果不能向领导证明这些改变带来了新的价值，那么就等于团队做这些的努力不被认可。那么问题就摆在推进敏捷的人面前：
你引入了新的工作量，价值是什么？
你必须能回答这个问题，否则敏捷是推不下去的，顶多作为几个积极的开发者提升自己工作效率的手段而已。
yiding_he
- 浏览: 127825 次
- 性别:
- 来自: 湖南
- 详细资料
搜索本博客
我的相册
共 7 张
最近加入圈子
最新评论
-
领悟 JavaScript 中的面向 ...
看一下这篇文章: http://msdn2.microsoft.com/zh-c ...
-- by bopat -
一个对象等待多个线程
好贴正需要。
-- by dongfei999 -
TrueCrypt 为你保驾护航.. ...
这两个目录的名字很诱人啊~
-- by ddppfamily -
领悟 JavaScript 中的面向 ...
楼主辛苦了！这样的文章不错！提倡
-- by sunfengcheng -
在 JavaScript 中如何创建 ...
实在是妙啊！
-- by yvfish
评论排行榜