posts - 59,  comments - 323,  trackbacks - 0
我以前说过一段话:“花费6/7的工作量,去保证那1/7的,有价值的工作。这不是太浪费了吗?”
 
结果纯粹思维居然不同意:“老大,你真的是孤陋寡闻了。人均900行/月,已经是比较高的productivity了。我们公司人均300行,照样是500强,照样销售几百亿美刀。“花费6/7的工作量,去保证那1/7的,有价值的工作。这不是太浪费了吗?”,你又错了,如果那1/7的工作有问题的话,你恐怕花100/7都补不回来。好好看看软件工程的书吧,特别是和software cost相关的章节。”
 
还有这么一段话:“老大,你的思维不会还停留在认为只有代码才是真正有价值的东西,或者说只有编码才是真正的开发工作,或者打心眼里还是认为一来就开始编码最好的层次上吧。”
 
我的确是比较无言以对,只能抄点东西给他看看,鉴于纯粹思维同志,比较喜欢中英文夹杂式的表述,我也搞点花样:
 
个体与交互过程 over processes and tools 
能够工作的软件 over comprehensive documentation 
客户合作 over contract negotiation 
随机应变 over following a plan
 
为什么要这样中英文夹杂呢?因为那些英文是纯粹思维同志相当熟悉的,而这些中文可能是他根本没有想到过的!
 
关于PMP,我倒是从来没有觉得一个PMP有什么了不起,学习PMP,只是让我更加深刻的认识到,以“工程方式管理软件开发项目”,是何等的缘木求鱼
 
至于PV、EV、AV这种纸上谈兵的东西,我都已经忘光了。所以呢,你不认我是个PMP,就不认吧,我现在也的确不是个够格的PMP了。
 
我现在的已经进步了,我的确是认为:

代码才是真正有价值的东西!
posted on 2006-01-14 14:13 读书、思考、生活 阅读(2861) 评论(10)  编辑  收藏


FeedBack:
# re: 软件开发项目中的成本比例
2006-01-14 20:11 | fanta
打个不恰当的比喻,战斗机是有战斗力的,而预警机是没有战斗力的,可是一架预警机加10个战斗机可以足够打掉100架战斗机。如果只有代码,我相信是一无是处的,没有任何商业价值,不要说商业软件,就是开源的东西,难道webwork不比struts好吗,但是为什么用struts反而比较多呢?  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-01-14 22:04 | dev
各打50大阪,两个人的家在一起就是正确的  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-01-14 23:35 | GHawk
UP和Agile都是工程过程实践的总结,林德彰先生说过“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非,这只是在不同的实践内容和阶段上的总结。在过程的选用问题上,只有不断地实践才是前进的方向。  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-01-14 23:50 | 读书、思考、生活
林德彰的说法,是一个在校教师,典型的和稀泥的说法,我不同意。  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-01-17 10:05 | guest
"打个不恰当的比喻,战斗机是有战斗力的,而预警机是没有战斗力的,可是一架预警机加10个战斗机可以足够打掉100架战斗机。如果只有代码,我相信是一无是处的,没有任何商业价值,不要说商业软件,就是开源的东西,难道webwork不比struts好吗,但是为什么用struts反而比较多呢?"

请问什么东西才能算起到“预警机”的作用呢?难道不是代码及相关测试吗?难道是所谓的过程规范吗?

那么struts下一个版本基于webwork进行开发又是怎么回事呢?

没有相当的开发经验是体验不出agile宣言中的内涵的。  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-04-22 20:05 | Wang
"林德彰的说法,是一个在校教师,典型的和稀泥的说法"?
老林是在校教师?你应该去看一下人家在美国打拼的经验~~  回复  更多评论
  
# re: 软件开发项目中的成本比例
2006-04-22 21:05 | 读书、思考、生活
to:WANG

他在美国打拼怎么了?还有好多土生土长的美国人,也不鸟那什么UP呢?

我为什么要听一个海龟来上课呢?
这年头,海龟还不够多吗?  回复  更多评论
  
# re: 软件开发项目中的成本比例
2007-06-12 21:10 | itkui
高人在上,不敢评论  回复  更多评论
  
# re: 软件开发项目中的成本比例
2007-11-28 00:25 | longtimeago
With 11 years plus intensive work expensive in U.S., I have been working in some fortune 500 companies, startup and consulting companies, here is some thoughts from me about software engineer.

0. Requirements collection is the most important part. It defines the scope for the project. It will be a nightmare if you contantly change requirements during development. If it's the case, you need to have several release cycles intead of one and you have to cut requirement changes at certain point for each cycle. In practical, you cannot stop customer to add a requirement if it's really important.

1. A functional software is much more important than the documentation. Many system never worked and only stoped at the spec level.
A design may seems fine and cover its drawbacks, it cannot prove it unless you have a funcational system running.

2. For a released software, you don't need to write one page document to fix a bug or say make a change. A bug tracker tool is enough, open a bug, put some description there, make code change and close the bug. The difference inbetween good enigneers and bad enigineers is the former usually only fix a problem and the later introduce another problem.

3. Without a good team, without good programmers and domain experts, no matter how good the requirements are and no matter how good the spec/design is, the implemented system will be useless. If it ever be able to be implemented, it could be slow and very buggy.

3.5. The implementation will never be exactly same as the original spec. For system software development, usually you align the spec with the implementation during the dev process. The cost to implement the system software(operating system, for example) is much more expensive than the application softare due to high quality requirement. For application software developments, usually the actual system ends without sync of spec.

4. Managers job is hiring good technical people. IT managers shall have many years domain experience before moving up. Development managers shall have many years of coding experience. Product managers(collecting functional requirements) shall have some years of coding experience and some years of business analyst experience. Etc.

5. For all managers, the first line managers shall have less years away from coding/requiements collection, etc. The higher level, the longer years can away from the IT actual development life.

6. The first line archetects, team leaders, senior developers are the actual people to control the quality of the software. Every team member counts. If you have a less experience member writing very low performance code, you won't be able to get anything out from him, considering the customer complains you will get, considering the time other team memebers will spend to fix his bugs. Peel code review is very important and that's how you find out low performance programmers.

6.5 For a bad programmer, no matter how less is his/her salary, he/she does not worth the salary.

6.6 The difference inbetween a good programer and very good programmer is when you meet a very hard problem.

6.7 You need to have somebody who has done it before in your team, otherwise your project is doomed at the very beginning.

6.8 A group junior developer will not be able to get a system implemented, no matter how many of them.

7. Money talks. The first version of software always buggy. The company needs money to for future release. The first version cannot be too buggy, otherwise it will die on the very beginning.

8. India has more CMM5 companies in the world. Have you heard any bigger software company from India? The actual software implelmentation will never same as stated on the books.

9. The difference inbetween the mountain and the hill is the sheer volume. Every line of code is not that hard, million lines of code make a huge difference. To have a true software industry, you need to have some bigger companies with operating system softwares or very large business usuage software.

10. Software shall be self documented. A good software engineer or programmer with domain business knowledge shall be able to fix a bug just by looking at source.

15. Without control of hardware, software is fundamental not secure. Without control of operating system, the application software is fundamental not secure. It's a huge mistake to exchange dometic high tech market with oversea low tech market.  回复  更多评论
  
# re: 软件开发项目中的成本比例[未登录]
2008-11-23 21:28 | Tommy
我来挖一下墓哈:
能够工作的软件 ?= 可运行的Codes 这样对吗?
主要问题?次要问题?
请参阅<人月神话>--没有银弹  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
 
<2006年1月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
2930311234

常用链接

留言簿(20)

随笔档案

友情BLOG

搜索

  •  

最新评论

阅读排行榜

评论排行榜