从金融学的角度看“重构”

[jayden guan]

前些日子在InfoQ看到篇文章 "抛砖引玉——重构是必要的浪费"
http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.
文中认为 "重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。
个人对这样的解读不太赞同。

我觉得问题核心在于重构对于客户创造了什么价值。
近日从金融学的角度来进行分析，略有所悟。

重构其实提供了"需求变化"的"看多期权"（call）--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大，这份期权就价值越高。而在金融市场上充满了明码标价的期权交易。

以TDD的三步骤(不可运行，可运行，重构)为例，可以看做实现一个功能的"现货价值"并附加该功能需求变化的"看多期权"。
而只完成功能要求程序，不进行重构，只能看单纯含有一个功能的"现货价值"。
对于客户而言，附加有"需求变化看多期权"的程序价值要高于只含"现货价值"的程序。
对于"需求变化看多期权"最坏的情况也就是"需求不变化"，这份期权就没必要行使。
这就是"需求稳定项目（如：学校大作业）"和"需求总是与时俱进的项目"在开发行为上存在差异的原因之一。

事实上，我觉得软件项目开发，充满了时间序列上的发生的不确定性，项目的过程中需要不断的吸收这种不确定性，并追求项目达到更高的价值。这种情况很适合以金融学的视角进行分析。

http://tuti.javaeye.com/admin/blogs/190154

[Steven Mak]

你說的其實跟文中其中一位討論者差不多呢:

-------------
Dec 18, 2007 1:13 PM by Kent Beck

While it's true that refactoring doesn't deliver features to
customers, features aren't the only source of value in software.
Another source of value is the option value of the software--software
that could be made to do any one of five things next is more valuable
than software that can only be made to do two things next. Refactoring
can add to the option value of software. This perspective can also
help teams select the most valuable refactorings out of the seemingly
infinite pool of possibilities. Perform refactorings that add to the
set of available and useful options, defer those that don't.
-------------

On May 9, 4:51 pm, "jayden guan" <jayden.g...@gmail.com> wrote:
> 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.

[ming]

看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了

从game的角度看重构：
注意：本文的重构都不包括过度重构

根据Cockburn的敏捷软件开发，软件开发是“下一盘很大的棋”：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。

所以，对于重构
从短期来看：浪费
从长期来看：必要
从客户来看：浪费
从开发团队来看：必要
从项目经历来看：浪费
从程序员来看：必要

所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。

[ming]

-_-!!

"晚饭"---"玩法"

ps: 该吃晚饭了

[陈之过]

> 所以，对于重构
> 从短期来看：浪费
> 从长期来看：必要
> 从客户来看：浪费
> 从开发团队来看：必要
> 从项目经历来看：浪费
> 从程序员来看：必要

不明白你在说什么?没有重构,怎么敏捷?

2008/5/13 ming <skya...@gmail.com>:

看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了

从game的角度看重构：
注意：本文的重构都不包括过度重构

根据Cockburn的敏捷软件开发，软件开发是"下一盘很大的棋"：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。

所以，对于重构
从短期来看：浪费
从长期来看：必要
从客户来看：浪费
从开发团队来看：必要
从项目经历来看：浪费
从程序员来看：必要

所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。


On 5月9日, 下午4时51分, "jayden guan" <jayden.g...@gmail.com> wrote:

> 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.

[yiding.he]

对客户来说，重构属于开发细节----你能够在我接受的价格内完成这个功能就行了，重构是什么东西我才懒得管。
项目经理应该认识到适当的重构带来的长远利益，否则就是目光短浅。

ming 写道:

看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了

从game的角度看重构：
注意：本文的重构都不包括过度重构

根据Cockburn的敏捷软件开发，软件开发是"下一盘很大的棋"：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。

所以，对于重构
从短期来看：浪费
从长期来看：必要
从客户来看：浪费
从开发团队来看：必要
从项目经历来看：浪费
从程序员来看：必要

所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。


On 5月9日, 下午4时51分, "jayden guan" <jayden.g...@gmail.com> wrote:
  

前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.
文中认为 "重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。
个人对这样的解读不太赞同。

我觉得问题核心在于重构对于客户创造了什么价值。
近日从金融学的角度来进行分析，略有所悟。

重构其实提供了"需求变化"的"看多期权"（call）--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大，这份期权就价值越高。而在金融市场上充满了明码标价的期权交易。

以TDD的三步骤(不可运行，可运行，重构)为例，可以看做实现一个功能的"现货价值"并附加该功能需求变化的"看多期权"。
而只完成功能要求程序，不进行重构，只能看单纯含有一个功能的"现货价值"。
对于客户而言，附加有"需求变化看多期权"的程序价值要高于只含"现货价值"的程序。
对于"需求变化看多期权"最坏的情况也就是"需求不变化"，这份期权就没必要行使。
这就是"需求稳定项目（如：学校大作业）"和"需求总是与时俱进的项目"在开发行为上存在差异的原因之一。

事实上，我觉得软件项目开发，充满了时间序列上的发生的不确定性，项目的过程中需要不断的吸收这种不确定性，并追求项目达到更高的价值。这种情况很适合以金融学的视角进行分析。

http://tuti.javaeye.com/admin/blogs/190154
    

[Liang Qiao]

不能对客户说："我们要做重构，所以在两个星期（或两个月）内不能交付显式价值。你看到的功能将和原来的一样。"

想像一下，你如果是客户，你会为这句话付两个星期（或两个月）的钱吗？

大体来说（并不绝对），"如何做软件"是承建方的事，"想做成什么样的软件"是客户的事。你是否做重构是"开发团队内部的事！"

也就是说：你在做开发的时候，就应该做重构。而不是把它单拿出来和客户说。

2008/5/14 yiding.he <yidi...@gmail.com>:

[pengfei wang]

我一直认为重构就应该被融入到每天没小时的开发中,就是一种开发习惯,开发人员经常性的都要做重构的工作,这样也不会增加显形的成本.

由此而来，也没有所谓重构是浪费不浪费之说了.

相反,如果大提特提重构,把重构当作一个phase,还需要单独安排多少多少时间来做,比以此作为延迟交付的理由, 实不可取.

[Steven Mak]

我想你對 Cockburn 的開發觀念有些誤解:

Cockburn 提出的是 "Co-operative Game", "Co-operative Game" 和傳統競爭性的
(Competitive) 遊戲就是 "Co-operative Game" 是大家一起合作去達到目標, 謀求的是一起勝出, 付運系統.

Cockburn 提出的一個比喻就是登山隊, 登山隊各隊員都以合作方式去登上山峰. "自己的利益最大化" 最可能的就只是好好合作完成目標, 而
不是盤算自己的 "玩法", 強調的是合作性, 而且目標一致.

On May 13, 9:30 pm, ming <skyai...@gmail.com> wrote:
> 看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了
>
> 从game的角度看重构：
> 注意：本文的重构都不包括过度重构
>
> 根据Cockburn的敏捷软件开发，软件开发是"下一盘很大的棋"：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
> 项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。
>
> 所以，对于重构
> 从短期来看：浪费
> 从长期来看：必要
> 从客户来看：浪费
> 从开发团队来看：必要
> 从项目经历来看：浪费
> 从程序员来看：必要
>
> 所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
> 以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。
>
> On 5月9日, 下午4时51分, "jayden guan" <jayden.g...@gmail.com> wrote:
>

> > 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.

[Anchuan Qian]

是呀，重构是最基础的，是编码过程每时每刻发生的，是默认的。这是开发者和开发团队的事情----本分的事情，根本没有必要去跟客户做negotiation。正如QiaoLiang所说，开发团队还好意思跑到客户面前说："我们代码写的不好，现在很难加入新的功能，我们需要做个重构！"

2008/5/14 pengfei wang <roc...@gmail.com>:

[李雷]

一般的客户根本都不懂这么多名词的，他就关心什么时候把能用的东西给他，毕竟
大家的时间都很宝贵的。

对客户的关系其实也和面向对象软件设计的一些思想很类似，需要针对不同客户设
计不同的交互模式，呵呵。

Liang Qiao 写道:
> 不能对客户说："我们要做重构，所以在两个星期（或两个月）内不能交付显式

> 价值。你看到的功能将和原来的一样。"
>
> 想像一下，你如果是客户，你会为这句话付两个星期（或两个月）的钱吗？
>
> 大体来说（并不绝对），"如何做软件"是承建方的事，"想做成什么样的软件"是
> 客户的事。你是否做重构是"开发团队内部的事！"
>
> 也就是说：你在做开发的时候，就应该做重构。而不是把它单拿出来和客户说。
>

> 2008/5/14 yiding.he <yidi...@gmail.com <mailto:yidi...@gmail.com>>:
>
> 对客户来说，重构属于开发细节----你能够在我接受的价格内完成这个功能

> 就行了，重构是什么东西我才懒得管。
> 项目经理应该认识到适当的重构带来的长远利益，否则就是目光短浅。
>
> ming 写道:
>> 看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了
>>
>> 从game的角度看重构：
>> 注意：本文的重构都不包括过度重构
>>
>> 根据Cockburn的敏捷软件开发，软件开发是"下一盘很大的棋"：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
>> 项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。
>>
>> 所以，对于重构
>> 从短期来看：浪费
>> 从长期来看：必要
>> 从客户来看：浪费
>> 从开发团队来看：必要
>> 从项目经历来看：浪费
>> 从程序员来看：必要
>>
>> 所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
>> 以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。
>>
>>
>> On 5月9日, 下午4时51分, "jayden guan" <jayden.g...@gmail.com> <mailto:jayden.g...@gmail.com> wrote:
>>
>>> 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.

>>> 文中认为 " <http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.%E6%96%87%E4%B8%AD%E8%AE%A4%E4%B8%BA>重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。

[Jacky Li]

忽然想起了prisoner's dilemma

2008/5/14 Steven Mak <stev...@gmail.com>:

--
Jacky Li

InfoQ China Agile Lead Editor: www.infoq.com/cn
+86 138 1045 9095

[徐毅]

2008/5/14 Anchuan Qian <qiana...@gmail.com>:

是呀，重构是最基础的，是编码过程每时每刻发生的，是默认的。这是开发者和开发团队的事情----本分的事情，根本没有必要去跟客户做negotiation。正如QiaoLiang所说，开发团队还好意思跑到客户面前说："我们代码写的不好，现在很难加入新的功能，我们需要做个重构！"

重构这个说法在何时诞生？
诞生之前大家在干什么，初构？
transparency不是敏捷一个重要元素吗，为什么说没必要和客户做negotiation？

--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Mater
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[Jacky Li]

这得从人和宇宙的关系开始讲起了，在你身上一直以来就有一个问题缠绕着你。

我生从何来，死往何处？我为何要出现在这个世界上？我的出现对这个世界意味着什么？是世界选择了我，还是我选择了世界？ 我和宇宙之间有必然的联系吗？宇宙是否有尽头？时间是否有长短？过去的时间在哪里消失？未来的时间又在何处停止？我在这一刻提出的问题，还是你刚才听到的问题吗？

2008/5/14 徐毅 <kave...@gmail.com>:

[咖啡屋的鼠标]

我想，重构可以看作是一个保证质量的工艺，同时也是一个成本负担。任何企业，他们都要保障他们产品的质量。这之中必然有成本的投入。成本高自然价格高，体现在软件开发中，就是日期可能会长。这里面就有一个成本控制的问题了。好的企业，质量高，成本控制的好，差的企业一要求质量高，成本就控制不住，但这绝不是怀疑保证质量的工艺的理由。

任何企业也确实很少跟客户沟通说，我质量高，所以我成本高，所以我价格高。但是好的企业的客户自然能接受一分钱一分货的"洗脑"。

2008/5/14 徐毅 <kave...@gmail.com>:

--
鼠标
=======
我的博客：http://www.blogjava.net/tj19832
我的twitter：http://twitter.com/tj19832

[yiding.he]

将重构看做成本的一部分，这是人们的共识；成本控制是软件厂商的事情，客户不需要关心。

另外，重构的目的就是为了降低成本，并不是说做的重构越多，项目成本就越高。

在客户的眼里，质量和功能是成正比的，功能越多，客户就认为质量越高。当然，客户也会关心你的系统架构如何之类的问题，但这不是最重要的。


咖啡屋的鼠标 写道:

我想，重构可以看作是一个保证质量的工艺，同时也是一个成本负担。任何企业，他们都要保障他们产品的质量。这之中必然有成本的 投入。成本高自然价格高，体现在软件开发中，就是日期可能会长。这里面就有一个成本控制的问题了。好的企业，质量高，成本控制的好，差的企业一要求质量 高，成本就控制不住，但这绝不是怀疑保证质量的工艺的理由。

任何企业也确实很少跟客户沟通说，我质量高，所以我成本高，所以我价格高。但是好的企业的客户自然能接受一分钱一分货的"洗脑"。

2008/5/14 徐毅 <kave...@gmail.com>:

2008/5/14 Anchuan Qian <qiana...@gmail.com>:

是 呀，重构是最基础的，是编码过程每时每刻发生的，是默认的。这是开发者和开发团队的事情----本分的事情，根本没有必要去跟客户做 negotiation。正如QiaoLiang所说，开发团队还好意思跑到客户面前说："我们代码写的不好，现在很难加入新的功能，我们需要做个重构！ "

重构这个说法在何时诞生？
诞生之前大家在干什么，初构？
transparency不是敏捷一个重要元素吗，为什么说没必要和客户做negotiation？

--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Mater
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[Steven Mak]

Prisoner's Dilemma 當中至少有以下分別:

1) 信任, 大家都懷疑對方會出賣自己
2) 溝通, 大家都沒法跟對方相量對策
3) 透過出賣對方而讓自己得益

On May 14, 11:41 am, "Jacky Li" <veryfa...@gmail.com> wrote:
> 忽然想起了prisoner's dilemma
>

> 2008/5/14 Steven Mak <steven...@gmail.com>:

[Edwin Chain]

重构是TDD一种方法学，是思考和行为结合的一种模式。就好比中国人吃饭都用筷子，外国人吃饭都用刀叉，能说哪个是对的？个人认为，是否使用，得看他是否比以前的编程方法有更高的效率，是否能提高程序员的工作质量。让实践说话吧！不过，貌似重构要好的多！另外，重构是一种技术手段，跟用户没有关系，干吗把他们扯进来，不是很理解？

2008/5/13 ming <skya...@gmail.com>:

看了前面的帖子，想到刚看的书，不由得想谈谈自己的看法，班门弄斧，见笑大方了

从game的角度看重构：
注意：本文的重构都不包括过度重构

根据Cockburn的敏捷软件开发，软件开发是"下一盘很大的棋"：长期有长期的玩法，短期有短期的玩法；客户有客户的玩法，开发团队有团队的晚饭；
项目经理有自己的晚饭，程序员有程序员的玩法....每个人都是在其中谋求自己的利益最大化。

所以，对于重构
从短期来看：浪费
从长期来看：必要
从客户来看：浪费
从开发团队来看：必要
从项目经历来看：浪费
从程序员来看：必要

所以，基本上客户都不支持重构，程序员都希望重构。短期项目都不倾向重构，长期的则倾向于重构。为了程序员的利益，就有必要建立长期稳定和谐的客户关系
以及上下级关系，然后再进行重构。否则，怎么定性都是没用，就是吃力不讨好，不懂轻重。


On 5月9日, 下午4时51分, "jayden guan" <jayden.g...@gmail.com> wrote:

> 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.

[ming]

恩，我也是初看一遍，可能很多地方理解没到位，希望有机会和你探讨：）

我的理解是：co-operative game是以共赢为目标的游戏，但其实共赢也是相对的。博弈中，如果没有长期合作作为基础，双方是倾向于选择零
和游戏，也就是“挣一把就跑”。但是如果合作关系比较长期，一次收益不能代表最终收益的时候，大家就会倾向于选择正和游戏。所以，重构是为下一次“游
戏”（大游戏，小游戏）作准备的，对于长期游戏就是必须的，对于短期游戏则会看成浪费。

同理，游戏是相互合作，但不同的角色决定了他们看待游戏成功的角度不同。所以针对重构，不同角色的看法肯定会不同（看法，非态度）。

游戏有一个平衡点。在这个平衡点之下的所有行为就是每个参与者都会微妙的认可，就都是必须的，否则就是浪费。

所以，我觉得，如果你认为你将要做的重构是每个人都会接受的，那么就大胆做；否则，就要告知所有相关的人，最后取得一个平衡点，然后动手实施。

[Jacky Li]

有乱琢磨的时间，不如动手干点实事。

2008/5/14 ming <skya...@gmail.com>:

[Jeff Xiong]

有些东西可以negotiate，有些东西不可以，有些东西需要negotiate，有些东西不需要。先做这个story还是先做那个，抓紧时间做更多的story还是紧着这两天发布一个版本，这些是可以并且需要negotiate的；保持必要的质量标准还是舍弃对质量的要求来追求短期的交付速度，这就是不需要、不可以negotiate的。不需要negotiate，因为项目的质量要求应该和scope、budget一样，是在项目启动之前就达成共识的，项目开始了就意味着双方都认可我们要的是一定质量标准基础上的尽快交付；不可以negotiate，因为这是软件开发者的本分之事，就好像你到饭店点菜从来不会附加说明"要做得好吃点"一样──自己想想，如果一家饭店需要你告诉他做得好吃点他才会做得好吃点，你会怎么做？

2008/5/14 徐毅 <kave...@gmail.com>:

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

[徐毅]

2008/5/14 Jeff Xiong <gigi...@gmail.com>:

有些东西可以negotiate，有些东西不可以，有些东西需要negotiate，有些东西不需要。先做这个story还是先做那个，抓紧时间做更多的story还是紧着这两天发布一个版本，这些是可以并且需要negotiate的；保持必要的质量标准还是舍弃对质量的要求来追求短期的交付速度，这就是不需要、不可以negotiate的。不需要negotiate，因为项目的质量要求应该和scope、budget一样，是在项目启动之前就达成共识的，项目开始了就意味着双方都认可我们要的是一定质量标准基础上的尽快交付；不可以negotiate，因为这是软件开发者的本分之事，就好像你到饭店点菜从来不会附加说明"要做得好吃点"一样──自己想想，如果一家饭店需要你告诉他做得好吃点他才会做得好吃点，你会怎么做？

软件开发的公司或组织有进度的压力，客户也一样有，客户需要软件系统也是要上线投入运营的，也有进度的压力。至少我所感受到的，要坚持质量第一，不容易。客户或项目经理总会认为有一部分的质量是可以牺牲的，没有什么是不可以变的。

到饭店吃饭，熟的可以吃，不会让我吐出来是底线。人的口味不一样，我喜欢辣的，有人喜欢清淡。做饭前问一问不是很正常，你到湖南菜馆说，给我一盘不辣的清炒芦笋，估计你吃到要骂人的，人家的锅都是辣的。

如上是我的感受和体会，不代表我赞同或坚持同样的观点，谢谢。

[Bruce Zhang]

还是我说的，不要和客户谈什么方法？不要和他谈什么重构、TDD、结对编程，因为大部分客户都不懂。你只需要和他谈需求，谈进度，谈风险，就ok了。

至于重构做不做，我的意见是要做，而且最好的实践是每天都做。既然每天都做，就需要在安排进度的时候，必须考虑重构的时间。但这个安排对于客户而言，相当于是一个封装的黑盒，客户只关心你每天的进度，关心实现的功能以及质量。

2008/5/14 徐毅 <kave...@gmail.com>:

--
捷道·敏捷堂：http://www.agiledon.com

[thoriod]

1.开发者都不准备对软件质量负责，客户何必负责.
2.对于客户也有级别，低端用户就要用低端手段，高端用户就用高端手段，如果要改善和客户一起改善，否则改善你自己然后换一批客户。
3.我们都不是救世主，没有必要负责整个环境。
4.我们要做的只是改善自身的环节，然后尝试改善其他的环节，如果无法改变说明我们的方法不适合当前的环境了，当前环境的成长也无法和我们匹配，那么就
换一个环境

[韩伊]

开发者都不准备对软件质量负责，客户何必负责，对于客户也有级别，低端用户就要用低端手段，高端用户就用高端手段，如果要改善和客户一起改善，否则改善你自己然后换一批客户。我们都不是救世主，没有必要负责整个环节。我们要做的只是改善自身的环节，然后尝试改善其他的环节，如果无法改变说明我们的方法不适合当前的环节了，当前环节的成长也无法和我们匹配，那么就换一个环节

[Jeff Xiong]

实际上现在软件工程领域最缺乏、最应该引入的恰恰是制造业几十年来早已形成的工程方法和科学管理方法，尽管有些人经常把这些词挂在嘴边。对于很多软件组织来说，现在他们最需要的帮助恰恰是泰勒在伯利恒钢铁和大野耐一在福特汽车所做的事情。而所谓敏捷与重型之争或者该怎么敏捷这样的讨论实际上压根就不应该存在，因为每个软件组织需要和应该做的就是在精算的基础上做自己需要的改进。

这就是在软件这种新兴行业里工作的有趣之处：有很多人高喊着向制造业学习并且致力于把软件变成制造业但实际上他们根本就不知道制造业到底在做些什么。

2008/5/9 jayden guan <jayde...@gmail.com>:
> 前些日子在InfoQ看到篇文章 "抛砖引玉----重构是必要的浪费"

--

[yk where]

同意Jeff说软件组织在大喊向制造业学习的同时，并不知道从泰勒/福特以来制造业工作方式已经发生了很大的变化。

但不太同意把软件简单类比成制造业的模式。软件其实是制造业和服务业的混合体。以往的理论里，制造业和服务业是各有特点的。但在软件业里面，制造业与服务业的特性巧妙地混合在一起，分不开。

----------------------------------------

2008/5/17 Jeff Xiong <gigi...@gmail.com>:

[Steven Mak]

我想重點是在於 "科學管理" 的方法. Scientific Management 的批評已經很多, 目前也不太可能把軟件開發的工作看成像
Scientific Management 的很機械化的生產程序. 在有關的研究卻很少, 學術界在這方面的成果也不多, 從金融角度方面還有點點
進展, 但其他方面就只集中於 modeling, 而且很初步, 無論是 System Dynamics 或者 Agent based
model 也如是.

On May 17, 10:28 pm, "yk where" <ykwh...@gmail.com> wrote:
> 同意Jeff说软件组织在大喊向制造业学习的同时，并不知道从泰勒/福特以来制造业工作方式已经发生了很大的变化。
>
> 但不太同意把软件简单类比成制造业的模式。软件其实是制造业和服务业的混合体。以往的理论里，制造业和服务业是各有特点的。但在软件业里面，制造业与服务业的特性巧妙地混合在一起，分不开。
>
> ----------------------------------------
>

> 2008/5/17 Jeff Xiong <gigix1...@gmail.com>:

>
> > 实际上现在软件工程领域最缺乏、最应该引入的恰恰是制造业几十年来早已形成的工程方法和科学管理方法，尽管有些人经常把这些词挂在嘴边。对于很多软件组织来说，现在他们最需要的帮助恰恰是泰勒在伯利恒钢铁和大野耐一在福特汽车所做的事情。而所谓敏捷与重型之争或者该怎么敏捷这样的讨论实际上压根就不应该存在，因为每个软件组织需要和应该做的就是在精算的基础上做自己需要的改进。
>
> > 这就是在软件这种新兴行业里工作的有趣之处：有很多人高喊着向制造业学习并且致力于把软件变成制造业但实际上他们根本就不知道制造业到底在做些什么。
>

> > 2008/5/9 jayden guan <jayden.g...@gmail.com>:

[Jeff Xiong]

泰勒搞科学管理做的第一件事就是精细化度量和持续改进：用高速摄像机拍摄铲煤工人的动作，找出其中的浪费并加以改进。之后所有的高深玄妙都不用讲，因为绝大多数软件组织现在的问题是压根就不知道自己的员工到底每分钟在做什么、浪费到底产生在什么地方。而有些只会依葫芦画瓢的傻瓜却以为科学管理就是劳动重复化，以为把程序员变成铲煤工人就科学管理了，殊不知这正好是造成了最大的浪费，自以为是在学泰勒其实根本就是南辕北辙。

工业管理这个学科发展了小一百年，可学的东西很多很多。然而作为一个新兴行业的软件业，最好是从一些最基本的东西开始学起，比如说首先想办法知道自己的浪费在哪里，想办法消除浪费。不然尽是搞些浮沙高台，全无用处。

2008/5/18 Steven Mak <stev...@gmail.com>:

--
Jeff Xiong

[杨波]

是说现在软件的管理层普遍偏"蠢"吗？反正我是这么认为的。

敏捷是以承认软件工程人的重要性为前提的。因此提高人的工作效率是第一位的。
Scrum一开始就说软件项目是混乱的。所以要做的不是消除混乱，而是承认它，然后将其控制在可接受范围内。

我觉得有很多做管理的人梦想着用那些成熟工业的管理方法管理软件开发（估计一直以来自己太失败了）。但他们似乎根本没意识到这些本质的东西。似乎只要将所谓的成熟管理方法嫁接过来就可以万事大吉了。根本没搞清当前的问题点嘛！没有对症下药的情况下期待银弹，这压根没戏。

2008/5/18 Jeff Xiong <gigi...@gmail.com>:

--
致
礼

杨波

[Liang Qiao]

并不一定是软件的管理层偏"蠢"，只有身处其位，才知其感受！
而可能更多的是需要勇气、信心！

2008/5/18 杨波 <yab...@gmail.com>:

[杨波]

当然，不同位置的人考虑问题的出发点和关心点自然而然不同，随之产生的感受既不相同也不相通。
在其位，谋其职。不可能出问题时总对别人说："你站在我的角度想一想，我也很累的呀。"
所以，我想知道，您所谓的勇气、信心是指下面的开发者鼓起勇气、信心，按照管理层的意思奋战；
还是说管理层鼓起勇气、信心面对老板说："我们这儿要改变一下。虽然短期看来会多很多花费，但
长远是有益的。"

2008/5/18 Liang Qiao <sagittat...@gmail.com>:

--
致
礼

杨波

[ming]

个人孔见，与大家探讨：

传统工业是经历了"小作坊-工场-工厂-大规模合作生产"的过程。如果以此发展模式来理解软件行业，根据目前行业特点，我们应该还处于“工场”-"工
厂"混合阶段，那么我们的下一步就毫无疑问会发展到“大规模合作生产”。那时，软件业成了工业的一部分，而程序员也就成为彻头彻尾的螺丝钉。我想，到那
时，也许就会有程序员来投拍《新摩登时代》了。

万幸的是，泰勒的方法确实很开创性，但因为智力开发的特殊性，目前还没有办法精确到开发过程中的每一步。也许终究会出现软件行业的“泰勒”，但这对程序
员来讲是不利的。所以许许多多的从程序员成长为方法学专家的专家会提出程序员的“自救”－敏捷。

其实敏捷是面团，可以捏成圆的方的。但我想每一个程序员从中都应该更多看到自己的责任，看到其实很多工作可以做，去承担更多的职责，让自己变得更重
要。

On May 18, 9:03 am, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 泰勒搞科学管理做的第一件事就是精细化度量和持续改进：用高速摄像机拍摄铲煤工人的动作，找出其中的浪费并加以改进。之后所有的高深玄妙都不用讲，因为绝大多数软件组织现在的问题是压根就不知道自己的员工到底每分钟在做什么、浪费到底产生在什么地方。而有些只会依葫芦画瓢的傻瓜却以为科学管理就是劳动重复化，以为把程序员变成铲煤工人就科学管理了，殊不知这正好是造成了最大的浪费，自以为是在学泰勒其实根本就是南辕北辙。
>
> 工业管理这个学科发展了小一百年，可学的东西很多很多。然而作为一个新兴行业的软件业，最好是从一些最基本的东西开始学起，比如说首先想办法知道自己的浪费在哪里，想办法消除浪费。不然尽是搞些浮沙高台，全无用处。
>

> 2008/5/18 Steven Mak <steven...@gmail.com>:

[杨波]

谈不上程序员的"自救"。程序员只是一个职业。当现在的程序员职业变成螺丝钉的话，今天成为程序员的人群自然会转到别的职业去，而那时的程序员也会有其他类型的人来充当。
至于程序员该承担什么责任，与敏捷的关系其实不太大。责任和回报是对应的。而对于"程序员"这个职业该做些什么事，会随着市场的具体状况，不断变化并形成共识的。

2008/5/18 ming <skya...@gmail.com>:

--
致
礼

杨波

[Anchuan Qian]

个人觉得，说来说去，就是持续改进，降低浪费，提高生产率。但我觉得，软件行业就是软件行业，制造业就是制造业。任何一个行业或者艺术，如果要上升到最上层，不外乎就是哲学的道理。这些，都在中国传统文化里面。如果真正掌握，想怎么玩就怎么玩。玩武术是武术高手，玩音乐是音乐高手，玩软件是软件高手，玩经济是经济高手。

2008/5/18 杨波 <yab...@gmail.com>:

[Wenyan Yin]

现代制造业生产的是标准化产品，软件行业则不是。生搬硬套制造业的那套方法怕是会淮南橘而淮北枳。

[杨波]

哲学是逻辑的，不是政治的。
不要把中国传统文化当成武侠小说中的老家伙一样，莫测高深，神秘难解，填到哪儿都顶用。
又不是搞哲学、数学研究，我压根不相信存在普适的东西。

2008/5/18 Anchuan Qian <qiana...@gmail.com>:

--
   致
礼

杨波

[咖啡屋的鼠标]

我倒是相信存在一定程度上的普世价值观。
不过价值观而论，打着同样旗号做出来的事情可能背道而驰。
你可以打着"重视沟通"的旗号要求所有人写详尽的文档。也可以打着"重视沟通"的旗号搞结对开发、站立式会议、故事墙。
但是从经济的角度出发，如果后者比前者更有效的话，那么前者其实不能算重视沟通。

2008/5/19 杨波 <yab...@gmail.com>:

[Anchuan Qian]

我说的是哲学。不知道你的政治只的是什么？

"不要把中国传统文化当成武侠小说中的老家伙一样"，你了解中国的武术吗？

很明显，武侠小说上面是夸大其词，很多是无种生有。如果在你眼里，这就是中国的传统武术，那是受了武侠小说的误导。

当然，对这个我也不会。不过，我了解一点，看到一些，亲身接触过一些。在敏捷中国，有一些人比我有发言权。

2008/5/19 杨波 <yab...@gmail.com>:

[杨波]

>个人觉得，说来说去，就是持续改进，降低浪费，提高生产率。但我觉得，软件行业就是软件
>行业，制造业就是制造业。

哲学压根不关心这些。

>任何一个行业或者艺术，如果要上升到最上层，不外乎就是哲学的道理。
哲学可不是自然科学，与实证不符的就是错的。数学尚且在公理受到挑战时需要找寻出路，哲学甚至连这也不需要，逻辑自洽就可以了。因此，可以有两套对立的体系。也就是说，把软件实践提升到哲学高度，还不提具体哲（美）学原则，压根就说明不了任何问题。

>这些，都在中国传统文化里面。如果真正掌握，想怎么玩就怎么玩。玩武术是武术高手，玩音
>乐是音乐高手，玩软件是软件高手，玩经济是经济高手。

中国传统文化说了些什么？和上面提哲学有点类似，大而笼统。真正掌握？掌握什么？孔孟？老庄？古往今来那个人敢说自己掌握了中国传统文化？！各个行业想怎么玩就怎么玩，毫无疑问天真的想法，即便是SAP一个软件面对不同行业还有好多不同的定制，不少特别的最佳实践。或许通用的指导原则有，但细节问题肯定一大堆。这也是为什么专家称之为"专"家了。
祭出一个庞然大物然后作为论证依据，我第一反应就是武侠小说中的那些老态龙钟的世外高人。人家只要倚老卖老，就可以天下无敌了。

2008/5/19 Anchuan Qian <qiana...@gmail.com>:

我说的是哲学。不知道你的政治只的是什么？

因为你的论述压根莫名其妙，我以为是打官腔呢。

"不要把中国传统文化当成武侠小说中的老家伙一样"，你了解中国的武术吗？

？？
更加莫名其妙。我了解武术干什么。

很明显，武侠小说上面是夸大其词，很多是无种生有。如果在你眼里，这就是中国的传统武术，那是受了武侠小说的误导。

当然，对这个我也不会。不过，我了解一点，看到一些，亲身接触过一些。在敏捷中国，有一些人比我有发言权。

所指不明。

--
   致
礼

杨波

[Anchuan Qian]

"任何一个行业或者艺术，如果要上升到最上层，不外乎就是哲学的道理。"

我这句写的很清楚了。这是我的观点。我说了，是传统文化，是哲学。这个东西，本身不带来吃不带来穿。有些人觉得它一点都没有用，但有些人觉得它很有用。

"因为你的论述压根莫名其妙，我以为是打官腔呢。"

我的论述前面的：软件行业就是软件行业，制造业就是制造业。再说具体一点，有很多相同的地方，但本质是有区别的，如果非要上升到最上层，又是一样的东西，不外乎就是哲学的道理。这就是我的观点。当然，你可以有不同的认识和观点。也非常欢迎讨论。

关于中国传统文化，我只是知道一点，了解了一点。但，我觉得自己没有资格在这里论道。

2008/5/19 杨波 <yab...@gmail.com>:

[杨波]

好吧。既然你喜欢那终极真理说事，我也无话好说。
我还听说过，宇宙的真理是：42。

2008/5/19 Anchuan Qian <qiana...@gmail.com>:

--
   致
礼

杨波

[Anchuan Qian]

我的观点是：软件行业就是软件行业，制造业就是制造业。如果你非要只取后面一句的内容，我也当然无话好说。

2008/5/19 杨波 <yab...@gmail.com>:

[thoriod]

最近学习管理学和投资以及某些方面的商业知识，发现2方面：
第一，投资模式、市场适应度始终需要不断的摸索和改进，因为客户在变，去年合适的款式可能不适合今年。然而需要改变的并不是整体，同时对于前期的投资，
推翻就是破坏自己的投资。。。。说白了，应该顺应环境，客户需要，面临改变，就该做好改变的准备，长期投资需要不断的精简改进，使得你的投资学会学习很
成长。
第二，如果说你需要精简的话，始终记住一点，人是无法用数字代替的部分。可以看一下戴明博士对目标管理和绩效考核的批判（不过那是一种极端，因为完整的
绩效管理必须附带上改进过程，虽然很多时候很多东西无法用数字表明，比如火箭队的巴蒂尔）。顺便阐述下绩效考核（目标管理）。制定目标和标准，就此对对
象（部门或者个人）进行工作统计，针对统计结果制定改进计划，然后改进过程，接着循环整个过程。不过过年的绝大多数企业忘记了改进的步骤，而且因为有考
核制度的存在，做为国人（中考，高考，毕业，N多证书）如此的制度自然马上进入了应试状态。久而久之，如同应试教育一般。
其实我不是很想说敏捷或者软件开发等等，因为我并没有太多的经验，只是我觉得软件开发永远是人的工作成就，毕竟这是人思想的结晶。如果流于形式而忽略了
真正核心—“人”，那为什么不去好好研究研究怎么可以把人全都赶出去。

拿来不是拿来，拿来你又能抓的住吗？敏捷是我们的吗，我们能抓住吗？