回帖整理: 反敏捷优越论
其实关于敏捷, 大嘴们说的很多, 一大半都是屁话, 论据论证看似完美无缺, 实际上却少说了很多前提, 这个问题将来我会仔细整理.
更新:
感觉回帖打字多了, 有必要单独提出来. 总体来说, 这些回帖的关键字如果提取出来, 就如下几个: 客户, 钱, 反敏捷优越论(但作为一种在一定条件下起作用的方法, 不反对敏捷本身).
原帖
其实合适某一项目的方法很多, 关键是客户愿不愿意. 比如Fowler也提到, 客户不愿意敏捷是一个障碍, 但他只是一而再再二三的说, 他的客户一旦了解敏捷是啥以后, 就愿意敏捷了. 这是毫无建设意义的屁话.
以敏捷的过程, 怎么估算工作量, 怎么报价? 以我的经验, 相当熟的客户, 也怕事先没谈清楚, 出意外. 单子大的是经济问题和最终能变为经济问题的那些问题: 比如会不会超过预算或者功能达不到而造成的没有取得预期回报; 单子小的是个感情问题. 敏捷在这里的问题是没有做出承诺, 而Fowler们的回答是, 不作出承诺是为了你们好; 站在客户的角度去听, 这靠谱吗?
或者换一个角度, 如果中途迭代的次数过多, 或中途挖掘出其它需求, 以至于工作量所对应的价格超出了客户的预算, 我们愿意贬低自己劳动时间的价值而对客户妥协吗? 是的, 我们可以说, 你客户没想清楚自然是你承担代价; 但这对解决问题无益. 所有的问题都指向一个看起来无法解决的症结: 客户本身.
所 以敏捷的浪潮只是看起来大, 一直都是Fowler, Beck, 这一小撮小型但能扇呼的团队的敏捷: 因为这帮子人可以说, 你看, 那么多开发者都把我们当大师和专家, 专家出手您得多掏点钱吧(另外, 作为技术明星, 他们的客户自然也都是财大气粗, 腿上一根汗毛都能填饱Martin肚子的). 客户掏钱多了, 他们舒服了, 自然什么都好说. 所以很多人说敏捷能解决问题, 可其实问题的关键根本不在于是最重型的过程还是轻量的过程, 唯一的问题是钱, 钱, 钱!
哪怕一个普遍的, 不是最小也差不多的例子: 客户只愿意给2W, 花两个月, 这时候, 敏捷要3个月, 客户勉强接受了, 可是客户不愿意给3W, 这样你的小组平均月收入或者奖金降低了, 敏捷? 这时候只能让敏捷中的持续与客户交流变成经常性的糊弄客户. 毕竟, 客户一旦付了第一笔钱, 就是任咱们宰割而已! 于是就有人说, 尽量只做核心的有用的, 尽量简化, 这话往往还说的富有正义感和责任心, 似乎一切从挖掘客户的真实需要出发; 我不知道很多情况下, 到底是客户真不想要尽量多的功能, 还是他被强奸了?
当然, 瀑布照样不行, 因为瀑布只是把糊弄客户的工作, 从贯穿始终变成了一次性的, 强奸客户还有客户签字的文档去保证, 嘿嘿, 也很爽.
敏 捷也好什么也好, 其实都能成功, 关键是客户总是想少付钱, 而开发人员无论设计还是程序, 也都是贪婪的, 总想多要钱. 什么时候客户变成活雷锋, 愿意养活一堆外人, 什么时候开发公司上上下下都把自己当民工, 忍气吞声一点点钱还赖账也愿意干, 一切就全都顺利了. 症结在于对于开发内容的"信息不对称": 客户对于难度和工作量唯一知道的就是自己不知道, 所以无法信任任何人, 于是往往更愿意根据一开始定好的纸面内容来获取一种"至少我花这么多钱这些可以实现"的安全感.
至 少暂时性的在目前, 不顺利和斗争是必然的, 剩下的全看随机性和运气了.而斗争为的是在我们占便宜和客户占便宜之间取得一个平衡; 另外, 总的来说, 我个人认为各种项目的运气的平均值还是不错的. 项目成功与否, 据我观察, 往往是客户自己抓住关键性问题没有; 客户没有对自己业务的明确认识, 再顺利的过程也是失败的结局, 甚至顺利到一半反而夭折. 客户有一个明确的认识, 再不顺的过程再垃圾的设计和代码, 也能发挥一定的作用.
更新:
@yAYX
"敏捷了客户不一定少给钱……给多少钱那得靠谈的"
不是说敏捷了客户就少给钱, 而是敏捷了客户要多给钱, 但是客户不愿意. Fowler他们的例子经常说的是, 一个6个月的项目, 敏捷后8个月才能完成, 而且客户为这多出的2个月掏了更多的钱, 只是: Fowler总是说, 因为项目的成果运行的更好, 所以多这两个月的时间和钱, 客户也很乐意.
问题是, 你不是Fowler, 客户凭什么相信你?
另外, 你这个说法也没有击中问题的实质: 不是说钱多钱少靠什么, 而是说现在钱只有这么多(已经谈好了), 你们的小组怎么做的"他好我也好"; 只谈来那么多钱, 因为生存问题又不能不接, 这样的情况下: 什么过程方法, 如果它号称能让所有人都满意, 并形容了一个美好的愿景, 就一定是狗皮膏药.
另外, 偶尔靠运气或关系接来的上亿项目款足够重复做这个项目好几遍的那种就不要谈了. 在充足的资金下, 确实有条件选择最正确的开发过程, 甚至任何一种不太离谱的过程都能取得良好的结果. 这样的情况下做出的烂项目, 纯属责任心(尤其是负责人的)问题.
但是这样的项目即使是成功总体来讲也是失败的, 因为一个靠随机性或腐败制胜的机制, 不可能长久.
总之, 没有任何方法说明敏捷或其它过程方法在任一种情况下都是更恰当的, 甚至也不能说某一种方法适用范围就更广; 具体到敏捷, 所需要的前提条件太多了; 这就注定了敏捷过程不可能成为一个广泛适用的学说: 重型的过程方法希望通过一次掌握所有的情况, 再加人的无差别使用而取得成功, 所以显得不切实际; 而敏捷则因为幻想一个完美的外部环境(比如理想的客户), 而变成一种空谈.
"否则两个月的工作量我生产力高了一个星期解决难不成你指给我一个星期的钱？"
首先, 如果其它人都要花两个月的工作量你一个星期解决, 这个时候你确实可以忽悠2个月的钱或者至少一个半月的钱; 但是任何生产力的提高都会在全社会被普及(虽然不见得是从你的组织泄露出去的), 某一个公司掌握一个高达8倍的方法长达多少年, 那是不可能的.
最后你的生产时间逐渐就变为了社会一般劳动时间, 于是很显然, 你这个反问, 只有一个肯定的答案: 没错, 从长远来看, 你一星期解决, 这个项目就只值一星期的钱.
其 次, 你这个说法, 就如上面所说, 并不符合Fowler他们对敏捷过程的描述. 这是一个对敏捷的最大误解: 敏捷其实和速度快不但不是同义词, 甚至经常是相反的. 敏捷一般情况下实质上是通过增加时间来保证更好的项目质量的; 只是通过一定的方法调整, 使得增加的时间控制在一定的范围内, 同时避免重型方法所带来的一损俱损的缺点. 当然, 比起一些重型过程出现来回返工的情况, 有时候敏捷看起来反而更快, 这实际上是一个龟兔赛跑的故事: 敏捷过程号称敏捷, 但是由于其谨慎的本质, 反而是龟; 各种重型过程虽然背负着重型二字, 实质上是盼着美好愿望能够成功而一劳永逸, 是兔.
只是这个误解对敏捷的推广反而起好的作用, 所以Fowler他们为了自己的荷包, 就不象澄清那些不好的误解一样下功夫了.
更新:
感觉回帖打字多了, 有必要单独提出来. 总体来说, 这些回帖的关键字如果提取出来, 就如下几个: 客户, 钱, 反敏捷优越论(但作为一种在一定条件下起作用的方法, 不反对敏捷本身).
原帖
其实合适某一项目的方法很多, 关键是客户愿不愿意. 比如Fowler也提到, 客户不愿意敏捷是一个障碍, 但他只是一而再再二三的说, 他的客户一旦了解敏捷是啥以后, 就愿意敏捷了. 这是毫无建设意义的屁话.
以敏捷的过程, 怎么估算工作量, 怎么报价? 以我的经验, 相当熟的客户, 也怕事先没谈清楚, 出意外. 单子大的是经济问题和最终能变为经济问题的那些问题: 比如会不会超过预算或者功能达不到而造成的没有取得预期回报; 单子小的是个感情问题. 敏捷在这里的问题是没有做出承诺, 而Fowler们的回答是, 不作出承诺是为了你们好; 站在客户的角度去听, 这靠谱吗?
或者换一个角度, 如果中途迭代的次数过多, 或中途挖掘出其它需求, 以至于工作量所对应的价格超出了客户的预算, 我们愿意贬低自己劳动时间的价值而对客户妥协吗? 是的, 我们可以说, 你客户没想清楚自然是你承担代价; 但这对解决问题无益. 所有的问题都指向一个看起来无法解决的症结: 客户本身.
所 以敏捷的浪潮只是看起来大, 一直都是Fowler, Beck, 这一小撮小型但能扇呼的团队的敏捷: 因为这帮子人可以说, 你看, 那么多开发者都把我们当大师和专家, 专家出手您得多掏点钱吧(另外, 作为技术明星, 他们的客户自然也都是财大气粗, 腿上一根汗毛都能填饱Martin肚子的). 客户掏钱多了, 他们舒服了, 自然什么都好说. 所以很多人说敏捷能解决问题, 可其实问题的关键根本不在于是最重型的过程还是轻量的过程, 唯一的问题是钱, 钱, 钱!
哪怕一个普遍的, 不是最小也差不多的例子: 客户只愿意给2W, 花两个月, 这时候, 敏捷要3个月, 客户勉强接受了, 可是客户不愿意给3W, 这样你的小组平均月收入或者奖金降低了, 敏捷? 这时候只能让敏捷中的持续与客户交流变成经常性的糊弄客户. 毕竟, 客户一旦付了第一笔钱, 就是任咱们宰割而已! 于是就有人说, 尽量只做核心的有用的, 尽量简化, 这话往往还说的富有正义感和责任心, 似乎一切从挖掘客户的真实需要出发; 我不知道很多情况下, 到底是客户真不想要尽量多的功能, 还是他被强奸了?
当然, 瀑布照样不行, 因为瀑布只是把糊弄客户的工作, 从贯穿始终变成了一次性的, 强奸客户还有客户签字的文档去保证, 嘿嘿, 也很爽.
敏 捷也好什么也好, 其实都能成功, 关键是客户总是想少付钱, 而开发人员无论设计还是程序, 也都是贪婪的, 总想多要钱. 什么时候客户变成活雷锋, 愿意养活一堆外人, 什么时候开发公司上上下下都把自己当民工, 忍气吞声一点点钱还赖账也愿意干, 一切就全都顺利了. 症结在于对于开发内容的"信息不对称": 客户对于难度和工作量唯一知道的就是自己不知道, 所以无法信任任何人, 于是往往更愿意根据一开始定好的纸面内容来获取一种"至少我花这么多钱这些可以实现"的安全感.
至 少暂时性的在目前, 不顺利和斗争是必然的, 剩下的全看随机性和运气了.而斗争为的是在我们占便宜和客户占便宜之间取得一个平衡; 另外, 总的来说, 我个人认为各种项目的运气的平均值还是不错的. 项目成功与否, 据我观察, 往往是客户自己抓住关键性问题没有; 客户没有对自己业务的明确认识, 再顺利的过程也是失败的结局, 甚至顺利到一半反而夭折. 客户有一个明确的认识, 再不顺的过程再垃圾的设计和代码, 也能发挥一定的作用.
更新:
@yAYX
"敏捷了客户不一定少给钱……给多少钱那得靠谈的"
不是说敏捷了客户就少给钱, 而是敏捷了客户要多给钱, 但是客户不愿意. Fowler他们的例子经常说的是, 一个6个月的项目, 敏捷后8个月才能完成, 而且客户为这多出的2个月掏了更多的钱, 只是: Fowler总是说, 因为项目的成果运行的更好, 所以多这两个月的时间和钱, 客户也很乐意.
问题是, 你不是Fowler, 客户凭什么相信你?
另外, 你这个说法也没有击中问题的实质: 不是说钱多钱少靠什么, 而是说现在钱只有这么多(已经谈好了), 你们的小组怎么做的"他好我也好"; 只谈来那么多钱, 因为生存问题又不能不接, 这样的情况下: 什么过程方法, 如果它号称能让所有人都满意, 并形容了一个美好的愿景, 就一定是狗皮膏药.
另外, 偶尔靠运气或关系接来的上亿项目款足够重复做这个项目好几遍的那种就不要谈了. 在充足的资金下, 确实有条件选择最正确的开发过程, 甚至任何一种不太离谱的过程都能取得良好的结果. 这样的情况下做出的烂项目, 纯属责任心(尤其是负责人的)问题.
但是这样的项目即使是成功总体来讲也是失败的, 因为一个靠随机性或腐败制胜的机制, 不可能长久.
总之, 没有任何方法说明敏捷或其它过程方法在任一种情况下都是更恰当的, 甚至也不能说某一种方法适用范围就更广; 具体到敏捷, 所需要的前提条件太多了; 这就注定了敏捷过程不可能成为一个广泛适用的学说: 重型的过程方法希望通过一次掌握所有的情况, 再加人的无差别使用而取得成功, 所以显得不切实际; 而敏捷则因为幻想一个完美的外部环境(比如理想的客户), 而变成一种空谈.
"否则两个月的工作量我生产力高了一个星期解决难不成你指给我一个星期的钱？"
首先, 如果其它人都要花两个月的工作量你一个星期解决, 这个时候你确实可以忽悠2个月的钱或者至少一个半月的钱; 但是任何生产力的提高都会在全社会被普及(虽然不见得是从你的组织泄露出去的), 某一个公司掌握一个高达8倍的方法长达多少年, 那是不可能的.
最后你的生产时间逐渐就变为了社会一般劳动时间, 于是很显然, 你这个反问, 只有一个肯定的答案: 没错, 从长远来看, 你一星期解决, 这个项目就只值一星期的钱.
其 次, 你这个说法, 就如上面所说, 并不符合Fowler他们对敏捷过程的描述. 这是一个对敏捷的最大误解: 敏捷其实和速度快不但不是同义词, 甚至经常是相反的. 敏捷一般情况下实质上是通过增加时间来保证更好的项目质量的; 只是通过一定的方法调整, 使得增加的时间控制在一定的范围内, 同时避免重型方法所带来的一损俱损的缺点. 当然, 比起一些重型过程出现来回返工的情况, 有时候敏捷看起来反而更快, 这实际上是一个龟兔赛跑的故事: 敏捷过程号称敏捷, 但是由于其谨慎的本质, 反而是龟; 各种重型过程虽然背负着重型二字, 实质上是盼着美好愿望能够成功而一劳永逸, 是兔.
只是这个误解对敏捷的推广反而起好的作用, 所以Fowler他们为了自己的荷包, 就不象澄清那些不好的误解一样下功夫了.
