有关项目管理/敏捷开发/代码质量...
一切软件工程相关的研究,都是P话!
截屏的怒吼,才是真实的!

自个儿的活儿,真想作好,就有无穷的办法!
不想作好,就想得钱,就有无尽的借口!

当然,现实 99.999999% 的项目都是 狗屎,完全不知道想作什么, 俺们也只能徦装一起玩软件工程游戏了...

-- 
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://is.gd/6hXIL 简历直投俺就成;-)
-------------- 下一部分 --------------
A non-text attachment was scrubbed...
Name: 2010-01-27-124052_903x616_scrot.png
Type: image/png
Size: 120777 bytes
Desc: 不可用
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20100127/5e742f2f/attachment-0001.png>

> 有关项目管理/敏捷开发/代码质量...
> 一切软件工程相关的研究,都是P话!
> 截屏的怒吼,才是真实的!
>
> 自个儿的活儿,真想作好,就有无穷的办法!
> 不想作好,就想得钱,就有无尽的借口!

看来你并不明白软件工程为何而产生。

如果每个人都有能耐，而且每个人主观上都想把事情做好，那么软件工程本身就不需要了。

我以为，软件工程本身基于的原理是：因为从工程角度不假设我具有一个精英团队，所以我们通过各种方式，使整个团队的生产力达到平均水平，并且使这个达到平均水平的生产方式得以重复的出现。――也就是说面对大量平庸的人，保证你的项目达到平均或者平均偏上的水平。

中国人归根接底还是人治思想为重，当然，拥有一个优秀的团队确实能够保证你很好的完成任务，即使你根本没有动用软件工程。

不过现实是：绝大多数情况是，你要么无法召募到一个优秀的团队，要么无法维持一个优秀的团队始终给你干活不跳槽，要么根本出不起一群牛人的钱。。。

软件工程的根本原理是不过分依赖团队中某一个人的能力和意愿来决定整个项目的成败。――如果你说一个成功的项目要依赖所有人都把自己的活干好，那确实，没有软件工程可言了。

2010/1/27 pan shizhu <pan.shizhu在gmail.com>:
>> 有关项目管理/敏捷开发/代码质量...
>> 一切软件工程相关的研究,都是P话!
>> 截屏的怒吼,才是真实的!
>>
>> 自个儿的活儿,真想作好,就有无穷的办法!
>> 不想作好,就想得钱,就有无尽的借口!
>
> 看来你并不明白软件工程为何而产生。
>

现在想来是有点混乱了, 软件工程,这一名称就反映了其目标:
- 期望可以象建筑工程那样儿有效的进行控制和管理
- 但是软件毕竟不是建築
- 如附件所分析的,软件工程的研究,一直走在限制成员创造力的方向上
- 当然,同时,各个中间件/框架/开发工具 等等厂商也协同一齐来通过软件工程将越来越多的工程师禁锢在越来越复杂的开发过程中
- 幸好有自由软件世界,可以释放创造力 ;-)


> 如果每个人都有能耐，而且每个人主观上都想把事情做好，那么软件工程本身就不需要了。
>

这是最大的悲哀:
- 社会不断增长的高品质软件的需求
- 和永远无法批量制造高手之间的固有矛盾
软件工程,想通过成功项目的开发/管理模式的复用,来解决这一矛盾;

可能嘛?!

> 我以为，软件工程本身基于的原理是：因为从工程角度不假设我具有一个精英团队，所以我们通过各种方式，使整个团队的生产力达到平均水平，并且使这个达到平均水平的生产方式得以重复的出现。——也就是说面对大量平庸的人，保证你的项目达到平均或者平均偏上的水平。
>
> 中国人归根接底还是人治思想为重，当然，拥有一个优秀的团队确实能够保证你很好的完成任务，即使你根本没有动用软件工程。
>
> 不过现实是：绝大多数情况是，你要么无法召募到一个优秀的团队，要么无法维持一个优秀的团队始终给你干活不跳槽，要么根本出不起一群牛人的钱。。。
>
> 软件工程的根本原理是不过分依赖团队中某一个人的能力和意愿来决定整个项目的成败。——如果你说一个成功的项目要依赖所有人都把自己的活干好，那确实，没有软件工程可言了。
>

"软件工程的根本原理是不过分依赖团队中某一个人的能力和意愿来决定整个项目的成败" 非常精确,
不过,在软件世界,这个理想,必须得替换成:
软件工程的根本追求是不过分依赖团队中任意一个人输出的代码品质来决定整个项目的成败;

是也乎,是也乎,

可能嘛?!


-- 
http://zoomquiet.org 人生苦短? Pythonic!
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity) http://is.g...
-------------- 下一部分 --------------
A non-text attachment was scrubbed...
Name: 从组织行为学视角看敏捷开发的实施.pdf
Type: application/pdf
Size: 710317 bytes
Desc: 不可用
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20100127/cddcf83f/attachment-0001.pdf>

> "软件工程的根本原理是不过分依赖团队中某一个人的能力和意愿来决定整个项目的成败" 非常精确,
> 不过,在软件世界,这个理想,必须得替换成:
> 软件工程的根本追求是不过分依赖团队中任意一个人输出的代码品质来决定整个项目的成败;
>
> 是也乎,是也乎,
>
> 可能嘛?!

可能，还是不可能，这是个问题。

软件工程一直在研究这个问题，可惜这么多年没有人能够给出一个肯定的答案。没有哪个团队敢说自己掌握了高效软件开发的真谛。

的确，软件工程这个思想本身是不是正确的，很值得怀疑。软件的制造是否可以象硬件的制造一样被流程化，这也值得怀疑。

但是，如果你象你那样的理解，那就未必了，因为以我们现在的经验来看，很多时候，某个人的代码品质对整个产品的影响还真不大。有许多的商业软件不是不能开源，是不敢开源，因为代码质量太差。

2010/1/27 pan shizhu <pan.shizhu在gmail.com>:
>> "软件工程的根本原理是不过分依赖团队中某一个人的能力和意愿来决定整个项目的成败" 非常精确,
>> 不过,在软件世界,这个理想,必须得替换成:
>> 软件工程的根本追求是不过分依赖团队中任意一个人输出的代码品质来决定整个项目的成败;
>>
>> 是也乎,是也乎,
>>
>> 可能嘛?!
>
> 可能，还是不可能，这是个问题。
>

不论是否是问题,总得有人去尝试,就算最后证明是错误的,也是贡献哪>..

> 软件工程一直在研究这个问题，可惜这么多年没有人能够给出一个肯定的答案。没有哪个团队敢说自己掌握了高效软件开发的真谛。
>
> 的确，软件工程这个思想本身是不是正确的，很值得怀疑。软件的制造是否可以象硬件的制造一样被流程化，这也值得怀疑。
>

再 OT 一下,现在的云** 应该是这一追求的良好方向;
将所有软件开发中容易出问题的点,逐一云化,
那真的就有 FP 开发时的靠谱感觉了,
团队,仅仅成为业务需求的翻译者,一切实际运行活动都是委托专门云服务;
那么软件,的确就和依赖大量预制件得以工程化的建築获得相同的管理效率了...

> 但是，如果你象你那样的理解，那就未必了，因为以我们现在的经验来看，很多时候，某个人的代码品质对整个产品的影响还真不大。有许多的商业软件不是不能开源，是不敢开源，因为代码质量太差。
>
是也乎,商业竞争中,从来不是最优者胜利的;


-- 
http://zoomquiet.org 人生苦短? Pythonic!
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)

> ÔÙ OT Ò»ÏÂ,ÏÖÔÚµÄÔÆ** Ó¦¸ÃÊÇÕâÒ»×·ÇóµÄÁ¼ºÃ·½Ïò;
> ½«ËùÓÐÈí¼þ¿ª·¢ÖÐÈÝÒ׳öÎÊÌâµÄµã,ÖðÒ»ÔÆ»¯,
> ÄÇÕæµÄ¾ÍÓÐ FP ¿ª·¢Ê±µÄ¿¿Æ׸оõÁË,
> ÍŶÓ,½ö½ö³ÉΪҵÎñÐèÇóµÄ·­ÒëÕß,Ò»ÇÐʵ¼ÊÔËÐл¶¼ÊÇίÍÐרÃÅÔÆ·þÎñ;
> ÄÇôÈí¼þ,µÄÈ·¾ÍºÍÒÀÀµ´óÁ¿Ô¤ÖƼþµÃÒÔ¹¤³Ì»¯µÄ½¨ºB»ñµÃÏàͬµÄ¹ÜÀíЧÂÊÁË...

Ôƽâ¾ö²»ÁËÒ»¸öºËÐÄÎÊÌ⣺¾ø´ó¶àÊýÓû§²¢²»×¼È·µÄÖªµÀ×Ô¼ºµÄÒµÎñÐèÇó¡£

µ±Äã×öÁËÒ»¸ö²úÆ·µÄʱºò£¬Óû§¿ÉÒÔÖªµÀÕâÊÇ×Ô¼ºÏëÒªµÄ£¬»òÕß²»ÊÇ×Ô¼ºÏëÒªµÄ¡£

µ±Äã¸ù±¾Ã»ÓвúÆ·µÄʱºò£¬ÄãÈÃÓû§Ëµ×Ô¼ºÏëÒªµÄÊÇʲô£¬Ëû˵²»ÉÏÀ´¡£

È»¶ø£¬ÄãûÓÐ×ã¹»µÄ¾«Á¦È¥ÅãÓû§£¬¸øÓû§¿ª·¢N¸ö°æ±¾µÄ³ÌÐò£¬µÈ´ýËûȥ˵£ºÕâ¾ÍÊÇÎÒÏëÒªµÄ¡£

ËùÒÔ£¬ÎÒÒÔΪ£º³ÌÐòÔ±µÄ´´ÔìÐÔÔÚÓÚ³¬Ç°µÄÀí½âÓû§ÐèÇó¡£Äܹ»ÔÚÓû§Ã÷°××Ô¼ºµÄÐèÇó֮ǰ¾Í¸ã¶®Õâ¸öÐèÇó£¬È»ºóʵÏÖËü¡£¡ª¡ªºÜÏÔÈ»£¬Õâ¸ö²½ÖèÊÇÎÞ·¨±»Èí¼þ¹¤³Ì»¯µÄ¡£ÒòΪ¹¤³Ì»¯µÄÇ°ÌáÊÇÄã׼ȷ¶ø¾«È·µÄÖªµÀÐèÇó¡£µ«Ä㿪ʼ×öÒ»¸öÈí¼þµÄʱºò£¬ÐèÇóÍùÍùÊǼ°ÆäÄ£ºýÓë³éÏóµÄ¡£¡ª¡ªÐèÒª³ÌÐòÔ±´´ÔìÁ¦µÄÒ»¸öDZ²ØÊÂʵ¾ÍÊÇ£ºÄã¾øÎÞ¿ÉÄÜÔÚÒ»¸öÈí¼þ¿ª·¢µÄ³õÆÚ¾Í׼ȷµÄÖªµÀÐèÇ󡣶øÈí¼þ¹¤³ÌÍùÍù´íÎóµÄ×÷³öÁËÕâ¸ö¼Ù¶¨£¬»òÕߺܶàÈ˲¢²»Ô¸Òâ³ÐÈÏÕâ¸ö¼Ù¶¨¡£

¼øÓÚÉÏÃæÕâ¸öÌص㣬¶óɱÈí¼þÈËÔ±µÄ´´ÔìÐÔÎÞÖúÓÚÈí¼þÏîÄ¿µÄ³É¹¦¡£

¡°Àí½â²¢´´ÔìÐèÇó¡±Õâ¼þ×î¾ßÓм¼Êõº¬Á¿µÄÊÂÇéÍùÍù±»¼¼ÊõÈËÔ±ÈÏΪÊÇÎ޹ؽôÒªµÄ£¬¶ø´úÂëÖеÄijЩ¸ñʽÓë¼¼Êõϸ½ÚÕâЩÆäʵ¶Ô×îÖÕÈí¼þÓ°Ïì²»´óµÄÊÂÇéÍùÍù±»ÈÏΪºÜÓм¼Êõº¬Á¿¡£¶ÔÓÚÒ»²¿·ÖÈí¼þÏîÄ¿¶øÑÔ£¬Õâ¸öÎÊÌâºÜ¾À½á¡£¡£¡£

2010/1/27 pan shizhu <pan.shizhu在gmail.com>:
>> 再 OT 一下,现在的云** 应该是这一追求的良好方向;
>> 将所有软件开发中容易出问题的点,逐一云化,
>> 那真的就有 FP 开发时的靠谱感觉了,
>> 团队,仅仅成为业务需求的翻译者,一切实际运行活动都是委托专门云服务;
>> 那么软件,的确就和依赖大量预制件得以工程化的建築获得相同的管理效率了...
>
> 云解决不了一个核心问题：绝大多数用户并不准确的知道自己的业务需求。
>
> 当你做了一个产品的时候，用户可以知道这是自己想要的，或者不是自己想要的。
> 当你根本没有产品的时候，你让用户说自己想要的是什么，他说不上来。
> 然而，你没有足够的精力去陪用户，给用户开发N个版本的程序，等待他去说：这就是我想要的。
>

所以,一直有说:
- 一流企业作标准
  + 坐收专利费不干活
- 二流企业作服务
  + 坐收服务费不作反复开发
- 未流企业作产品
  + 所有没谱的反复的脏活儿...


> 所以，我以为：程序员的创造性在于超前的理解用户需求。能够在用户明白自己的需求之前就搞懂这个需求，然后实现它。——很显然，这个步骤是无法被软件工程化的。因为工程化的前提是你准确而精确的知道需求。但你开始做一个软件的时候，需求往往是及其模糊与抽象的。——需要程序员创造力的一个潜藏事实就是：你绝无可能在一个软件开发的初期就准确的知道需求。而软件工程往往错误的作出了这个假定，或者很多人并不愿意承认这个假定。
>
> 鉴于上面这个特点，扼杀软件人员的创造性无助于软件项目的成功。

但是 CMMI 就是在全力扼殺开发的创造性,用过程的体系,将开发的创造风险,转嫁给用户或是产品经理;
- 你项目文档写不好,批不过,就不开发!
- 只要开发出来的和文档一致,我管你软件是否好用哪!
- 想继续修改到好用? 给钱!重走流程!

>
> “理解并创造需求”这件最具有技术含量的事情往往被技术人员认为是无关紧要的，而代码中的某些格式与技术细节这些其实对最终软件影响不大的事情往往被认为很有技术含量。对于一部分软件项目而言，这个问题很纠结。。。
>

`理解并创造需求` 咔咔咔，这个更加邪恶哪！包含了可循环的迭深问题哪！

- 软件工程试图将软件开发也分工细化，将 需求/开发/测试/部署/运营 等等原先都是程序员作的事儿,拆到创造出的不同部门和专业领域(人群)中
- 本质上创造了就业,制造了软件开发的内部问题,以及沟通成本
- 现在各种UE 设计思想,都是 KISS ~ 其实就是不给用户过多选择,只给最直觉唯一的选择!
- 程序员的创造性不是 超前的理解用户需求 ;其实应该是:

  - 要不创造出用户可以摸索出自个儿问题核心的工具
  - 要不给出全新的唯一的用户行为过程/文化/习惯/心理需要...

明显,后者来钱多和快,就象 Jobs ,批量制造 FANs
前者就是找罪受了...



-- 
http://zoomquiet.org 人生苦短? Pythonic!
工作的层次(依靠谱程度从低到高)=有做-＞做完-＞做对-＞做好-＞帮助他人做好

>> 所以，我以为：程序员的创造性在于超前的理解用户需求。能够在用户明白自己的需求之前就搞懂这个需求，然后实现它。——很显然，这个步骤是无法被软件工程化的。因为工程化的前提是你准确而精确的知道需求。但你开始做一个软件的时候，需求往往是及其模糊与抽象的。——需要程序员创造力的一个潜藏事实就是：你绝无可能在一个软件开发的初期就准确的知道需求。而软件工程往往错误的作出了这个假定，或者很多人并不愿意承认这个假定。
>>
>> 鉴于上面这个特点，扼杀软件人员的创造性无助于软件项目的成功。
>>     
>
> 但是 CMMI 就是在全力扼殺开发的创造性,用过程的体系,将开发的创造风险,转嫁给用户或是产品经理;
> - 你项目文档写不好,批不过,就不开发!
> - 只要开发出来的和文档一致,我管你软件是否好用哪!
> - 想继续修改到好用? 给钱!重走流程!
>   
不同的工程环境需要不同的管理方法论，CMMI要解决的是组织一个庞大的团队、经 
历一个较长的周期去开发一个大型的复杂系统，是非常必要的，这么多年的工程事 
件也证明了这一点。反之，一个5人的创业团队，强调的是如何研发出一个创新的 
产品。目标不一样，所需要的管理办法不一样，不能一概而论。

小团队是做乘法，大团队是做加法。
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20100128/1ddc0a17/attachment.html>

2010/1/28 Bill Xu <bill在zeuux.org>:
>
> 所以，我以为：程序员的创造性在于超前的理解用户需求。能够在用户明白自己的需求之前就搞懂这个需求，然后实现它。——很显然，这个步骤是无法被软件工程化的。因为工程化的前提是你准确而精确的知道需求。但你开始做一个软件的时候，需求往往是及其模糊与抽象的。——需要程序员创造力的一个潜藏事实就是：你绝无可能在一个软件开发的初期就准确的知道需求。而软件工程往往错误的作出了这个假定，或者很多人并不愿意承认这个假定。
>
> 鉴于上面这个特点，扼杀软件人员的创造性无助于软件项目的成功。
>
>
> 但是 CMMI 就是在全力扼殺开发的创造性,用过程的体系,将开发的创造风险,转嫁给用户或是产品经理;
> - 你项目文档写不好,批不过,就不开发!
> - 只要开发出来的和文档一致,我管你软件是否好用哪!
> - 想继续修改到好用? 给钱!重走流程!
>
>
> 不同的工程环境需要不同的管理方法论，CMMI要解决的是组织一个庞大的团队、经历一个较长的周期去开发一个大型的复杂系统，是非常必要的，这么多年的工
> 程事件也证明了这一点。反之，一个5人的创业团队，强调的是如何研发出一个创新的产品。目标不一样，所需要的管理办法不一样，不能一概而论。
>
> 小团队是做乘法，大团队是做加法。
>
这应该不是软件工程的最终目标吧,
大团队如果是小团队的有效叠加，
那么，就应该可以将 加，统一倍增成 幂关系了...
可惜...


-- 
http://zoomquiet.org 人生苦短? Pythonic!
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.