我看“敏捷”

总体而言，“敏捷”就是一个bizword，几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。

这其中有意无意的忽略了一些关键环节，有些地方很恶劣。比如业务，将因为自己业务经验的匮乏，所带来的项目需求变更和交付期延长等风险，全部转嫁给客户。我们假设自家装修，施工队说你怎么说我怎么做，之所以没有做是因为你当初没有说，如果要改，需要另外付钱，会是什么心情。

同时，除了FDD这样的方法论，有一个完整的过程来支撑外，其它的都是一些成功实践，也就是一些经验之谈，容易让学习的人混乱，角色要哪些，日常怎么来管理？在具体的术上，确实有很多优秀之处，但是所处的层次不是在整个项目上，毕竟开发只是项目实施的一个环节，并不是整个的项目。但是一旦要提过程，我估计是自己打自己耳光。

因为含含糊糊的隐瞒了一些东西，使人无法知道过程优化和改善的方法和指标，这与制造业的敏捷无法同日而语。

想起一个讲咨询培训的策略，“励志、颠覆、速成、炒作”，敏捷方法有点这个意思，我觉得还要加一个“仪式”。过一段时间找个东西出来包装，Scrum把任务和会议管理包了包，不知道下一个目标是什么。

评论

22 楼 Durian 2010-01-15  

对结对编程（Pair-Programming）不太感冒。
本人有洁癖，只对自己代码负责，不让别人动，不让别人思想支配。

21 楼 showr 2010-01-15  

呆过的 两个公司代码都乱得要死

然后经理告诉我

这就是 敏捷 开发

得重构的

但最终也没见到重构后的代码 `..

20 楼 whaosoft 2010-01-14  

jili 写道

人月神话说过，没有银弹。
敏捷也不是，它也有适用范围，限制条件
但不能因为它无法解决所有问题而否定

这句话我赞同 我以前有个很可笑的同事就不懂这个

19 楼 xindeman 2010-01-14  

itqtfeng 写道

我们公司刚开始准备使用敏捷，现在就看到了这个帖，真是不知道这个开发方法在实践中会带来哪些好处及弊端呢~~~期待~~~

你们公司推行敏捷的大背景是？如何准备的？打算怎么上路？

18 楼 itqtfeng 2010-01-14  

我们公司刚开始准备使用敏捷，现在就看到了这个帖，真是不知道这个开发方法在实践中会带来哪些好处及弊端呢~~~期待~~~

17 楼 partech 2010-01-13  

coolyzg 写道

所以然是通过自己去悟的，什么都说的很白，接受者又容易产生别人把自己当傻瓜的感觉

敏捷主要是以人为本，通过各个实践来持续改进保证质量，调动人的主观性
以这个为思路，也许可以体会敏捷的实践为什么要这样做

这同程序员开发功能,然后让他去猜功能背后的意图和背景有多大区别?

16 楼 coolyzg 2010-01-13  

partech 写道

一蓑烟雨任平生 写道

总体而言，“敏捷”就是一个bizword，几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。

写程序的人一向比较直接，我也来批批“敏捷”。

我记得martinfowler当初批RUP的理由是,没有给出一个如何裁剪的指导,正所谓"多则惑";

我要批"敏捷"的就是它更多的只给出了一些原则,模式和实践,但却没有清晰的给出背后的目的,背景和场景;
没有给出"敏捷"背后的原理.

这就如同做功能一样,目的,背景和场景是要比具体如何实现重要得多的东西.知其然,还需知其所以然,"敏捷"少这个.

所以然是通过自己去悟的，什么都说的很白，接受者又容易产生别人把自己当傻瓜的感觉

敏捷主要是以人为本，通过各个实践来持续改进保证质量，调动人的主观性
以这个为思路，也许可以体会敏捷的实践为什么要这样做

15 楼 chenjianjx 2010-01-13  

很好。

一蓑烟雨任平生 写道

那么实践的结果怎样？

14 楼 一蓑烟雨任平生 2010-01-13  

那么实践的结果怎样？

13 楼 chenjianjx 2010-01-13  

是的。这本书很全面地指出了那十几项实践的意义，以及实践之间的关系。

partech 写道

chenjianjx 写道

要系统地看一本书，才能被“敏捷”充分说服。推荐Kent Beck 的《拥抱变化》

你被此书说服了?

12 楼 partech 2010-01-13  

chenjianjx 写道

要系统地看一本书，才能被“敏捷”充分说服。推荐Kent Beck 的《拥抱变化》

你被此书说服了?

11 楼 chenjianjx 2010-01-12  

要系统地看一本书，才能被“敏捷”充分说服。推荐Kent Beck 的《拥抱变化》

10 楼 partech 2010-01-12  

一蓑烟雨任平生 写道

总体而言，“敏捷”就是一个bizword，几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。

写程序的人一向比较直接，我也来批批“敏捷”。

我记得martinfowler当初批RUP的理由是,没有给出一个如何裁剪的指导,正所谓"多则惑";

我要批"敏捷"的就是它更多的只给出了一些原则,模式和实践,但却没有清晰的给出背后的目的,背景和场景;
没有给出"敏捷"背后的原理.

这就如同做功能一样,目的,背景和场景是要比具体如何实现重要得多的东西.知其然,还需知其所以然,"敏捷"少这个.

9 楼 ronghao 2010-01-12  

楼主的论断太偏颇了吧。

我家要装修，我找了两家施工队，简称专业A和专业B两家都很专业，其中专业A每隔一段时间都会邀请我参观和了解一下装修的进程，提出意见，你觉得我会对哪家比较满意呢？

好吧，我家又要装修，我又找了两家施工队，简称山寨C和山寨D，山寨C会不停的询问我意见，这让我很烦，因为我对装修不了解才找的他们，他们什么都问我，他们都是吃屎的吗？不得已，我上网搜了搜，告诉他们漆用什么，腻子要剐几遍。。。。山寨D则什么都不说，装修完就发现漏水、掉漆。你觉得我会对哪家比较满意呢？

楼主现在用专业B和山寨C进行对比，明显就没有可对比性。

专业的事情要找专业的公司，这是一个非常浅显的道理。一家开发方法敏捷的公司不一定能够提供某些专业领域的服务，这也是非常浅显的道理啊。

8 楼 jiangshaolin 2010-01-12  

firebody 写道

专业的事情肯定需要专业的人士来做。
如果不是专业的人士，即使套上“敏捷”这个牌子，也没法作出专业的事情。
能够掌握“敏捷”精髓的人肯定是专业人士，能够做专业事情的人不一定需要“敏捷”这个方法论。
这世上本没有敏捷这个词眼，只是一套专业人士的成功方法论，专业的人士永远有自己的一套方法论，他可以叫他“scrum”，也可以叫他的别的名词。 

赞楼上 ,BS所谓的专业人士.

7 楼 firebody 2010-01-12  

稍微有些赞同LZ。
专业的事情肯定需要专业的人士来做。
如果不是专业的人士，即使套上“敏捷”这个牌子，也没法作出专业的事情。
能够掌握“敏捷”精髓的人肯定是专业人士，能够做专业事情的人不一定需要“敏捷”这个方法论。
这世上本没有敏捷这个词眼，只是一套专业人士的成功方法论，专业的人士永远有自己的一套方法论，他可以叫他“scrum”，也可以叫他的别的名词。
方法论永远只是方法论而已，他的实施必须得靠人来推行，实施的好换也靠人来左右。
从这个角度来说，”敏捷“和书市上摆的一堆堆的营销/推销畅销书籍（×××成功宝典）没啥两样。
要做成专业的事情与其强调方法论，不如多强调人本的素质提高之路，不多，几个词足以：
态度，能力，专注。

态度是前提，能力要培养，不断提高。专注是耐心、细心的概括。

有这几点，你的团队的核心存在具备这些词的人吗，不多，只要两三个，就够了，你就不用担心。

我所做的管理也在围绕着几个词来管理团队的人员，要让他们从骨子里理解这几个词，理解了，团队也就有后来人了，不理解的即使读再多的”敏捷方法论“，也是白搭。

6 楼 gigix 2010-01-11  

一蓑烟雨任平生 写道

比如业务，将因为自己业务经验的匮乏，所带来的项目需求变更和交付期延长等风险，全部转嫁给客户。

你说“敏捷”这两个字，从字面上来理解，究竟是指的什么呢？究竟什么东西“被敏捷”了呢？

5 楼 一蓑烟雨任平生 2010-01-11  

现在的用户能够清清楚楚的说清要怎么做的很少，稍大一点的项目每个人都只是知道自己的事情，自相矛盾的时候很多，光分析没经验是做不到的。再说，用户还希望能通过你知道一些行业经验，希望你能带来一些东西。

那么业务顾问的角色职能、技能，是不是应该在过程中体现？但是不怎么说，简简单单的带过，为什么？

如果不说，要么是有意隐瞒，要么就是觉得开发人员可以搞定一切，如果是前者，我说它居心不良，如果是后者，那就要把前提说清楚。当然还有一种情况，就是它自己都不知道怎么做。

4 楼 photon 2010-01-11  

一蓑烟雨任平生 写道

我们假设自家装修，施工队说你怎么说我怎么做，之所以没有做是因为你当初没有说，如果要改，需要另外付钱，会是什么心情。

尽管敏捷有其问题和适用范围（任何方法论都这样），但我觉得敏捷好像没倡导忽视用户需求。敏捷倒是会在征得客户同意后确定那些需求先做，哪些后做，哪些可以不做。

3 楼 jili 2010-01-11  

人月神话说过，没有银弹。
敏捷也不是，它也有适用范围，限制条件
但不能因为它无法解决所有问题而否定