我以前說過一段話:“花費(fèi)6/7的工作量,去保證那1/7的,有價(jià)值的工作。這不是太浪費(fèi)了嗎?”
結(jié)果純粹思維居然不同意:“老大,你真的是孤陋寡聞了。人均900行/月,已經(jīng)是比較高的productivity了。我們公司人均300行,照樣是500強(qiáng),照樣銷售幾百億美刀?!盎ㄙM(fèi)6/7的工作量,去保證那1/7的,有價(jià)值的工作。這不是太浪費(fèi)了嗎?”,你又錯(cuò)了,如果那1/7的工作有問題的話,你恐怕花100/7都補(bǔ)不回來。好好看看軟件工程的書吧,特別是和software cost相關(guān)的章節(jié)?!?/DIV>
還有這么一段話:“老大,你的思維不會(huì)還停留在認(rèn)為只有代碼才是真正有價(jià)值的東西,或者說只有編碼才是真正的開發(fā)工作,或者打心眼里還是認(rèn)為一來就開始編碼最好的層次上吧?!?/DIV>
代碼才是真正有價(jià)值的東西!
我的確是比較無言以對(duì),只能抄點(diǎn)東西給他看看,鑒于純粹思維同志,比較喜歡中英文夾雜式的表述,我也搞點(diǎn)花樣:
個(gè)體與交互過程 over processes and tools
能夠工作的軟件 over comprehensive documentation
客戶合作 over contract negotiation
隨機(jī)應(yīng)變 over following a plan
能夠工作的軟件 over comprehensive documentation
客戶合作 over contract negotiation
隨機(jī)應(yīng)變 over following a plan
為什么要這樣中英文夾雜呢?因?yàn)槟切┯⑽氖羌兇馑季S同志相當(dāng)熟悉的,而這些中文可能是他根本沒有想到過的!
關(guān)于PMP,我倒是從來沒有覺得一個(gè)PMP有什么了不起,學(xué)習(xí)PMP,只是讓我更加深刻的認(rèn)識(shí)到,以“工程方式管理軟件開發(fā)項(xiàng)目”,是何等的緣木求魚!
至于PV、EV、AV這種紙上談兵的東西,我都已經(jīng)忘光了。所以呢,你不認(rèn)我是個(gè)PMP,就不認(rèn)吧,我現(xiàn)在也的確不是個(gè)夠格的PMP了。

我現(xiàn)在的已經(jīng)進(jìn)步了,我的確是認(rèn)為:
代碼才是真正有價(jià)值的東西!
FeedBack:
# re: 軟件開發(fā)項(xiàng)目中的成本比例
2006-01-14 20:11 | fanta
打個(gè)不恰當(dāng)?shù)谋扔鳎瑧?zhàn)斗機(jī)是有戰(zhàn)斗力的,而預(yù)警機(jī)是沒有戰(zhàn)斗力的,可是一架預(yù)警機(jī)加10個(gè)戰(zhàn)斗機(jī)可以足夠打掉100架戰(zhàn)斗機(jī)。如果只有代碼,我相信是一無是處的,沒有任何商業(yè)價(jià)值,不要說商業(yè)軟件,就是開源的東西,難道webwork不比struts好嗎,但是為什么用struts反而比較多呢? 回復(fù) 更多評(píng)論
# re: 軟件開發(fā)項(xiàng)目中的成本比例
# re: 軟件開發(fā)項(xiàng)目中的成本比例
2006-01-14 23:35 | GHawk
UP和Agile都是工程過程實(shí)踐的總結(jié),林德彰先生說過“UP是正楷,XP是草書。先學(xué)好了UP,才能學(xué)好XP;先學(xué)XP再學(xué)UP就會(huì)亂套?!?
Agile強(qiáng)調(diào)的是“代碼是真正有價(jià)值的東西。”這同樣也是實(shí)踐的結(jié)果。二位對(duì)于過程有不同的看法并不能說明孰是孰非,這只是在不同的實(shí)踐內(nèi)容和階段上的總結(jié)。在過程的選用問題上,只有不斷地實(shí)踐才是前進(jìn)的方向。 回復(fù) 更多評(píng)論
Agile強(qiáng)調(diào)的是“代碼是真正有價(jià)值的東西。”這同樣也是實(shí)踐的結(jié)果。二位對(duì)于過程有不同的看法并不能說明孰是孰非,這只是在不同的實(shí)踐內(nèi)容和階段上的總結(jié)。在過程的選用問題上,只有不斷地實(shí)踐才是前進(jìn)的方向。 回復(fù) 更多評(píng)論
# re: 軟件開發(fā)項(xiàng)目中的成本比例
# re: 軟件開發(fā)項(xiàng)目中的成本比例
2006-01-17 10:05 | guest
"打個(gè)不恰當(dāng)?shù)谋扔鳎瑧?zhàn)斗機(jī)是有戰(zhàn)斗力的,而預(yù)警機(jī)是沒有戰(zhàn)斗力的,可是一架預(yù)警機(jī)加10個(gè)戰(zhàn)斗機(jī)可以足夠打掉100架戰(zhàn)斗機(jī)。如果只有代碼,我相信是一無是處的,沒有任何商業(yè)價(jià)值,不要說商業(yè)軟件,就是開源的東西,難道webwork不比struts好嗎,但是為什么用struts反而比較多呢?"
請(qǐng)問什么東西才能算起到“預(yù)警機(jī)”的作用呢?難道不是代碼及相關(guān)測(cè)試嗎?難道是所謂的過程規(guī)范嗎?
那么struts下一個(gè)版本基于webwork進(jìn)行開發(fā)又是怎么回事呢?
沒有相當(dāng)?shù)拈_發(fā)經(jīng)驗(yàn)是體驗(yàn)不出agile宣言中的內(nèi)涵的。 回復(fù) 更多評(píng)論
請(qǐng)問什么東西才能算起到“預(yù)警機(jī)”的作用呢?難道不是代碼及相關(guān)測(cè)試嗎?難道是所謂的過程規(guī)范嗎?
那么struts下一個(gè)版本基于webwork進(jìn)行開發(fā)又是怎么回事呢?
沒有相當(dāng)?shù)拈_發(fā)經(jīng)驗(yàn)是體驗(yàn)不出agile宣言中的內(nèi)涵的。 回復(fù) 更多評(píng)論
# re: 軟件開發(fā)項(xiàng)目中的成本比例
# re: 軟件開發(fā)項(xiàng)目中的成本比例
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. 回復(fù) 更多評(píng)論
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. 回復(fù) 更多評(píng)論
2008-11-23 21:28 | Tommy
只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。 | ||
![]() |
||
網(wǎng)站導(dǎo)航:
博客園
IT新聞
Chat2DB
C++博客
博問
管理
|
||
| |||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
---|---|---|---|---|---|---|---|---|---|
26 | 27 | 28 | 29 | 30 | 31 | 1 | |||
2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
30 | 1 | 2 | 3 | 4 | 5 | 6 |
常用鏈接
留言簿(20)
隨筆檔案
- 2006年10月 (1)
- 2006年7月 (1)
- 2006年6月 (3)
- 2006年5月 (2)
- 2006年4月 (3)
- 2006年3月 (9)
- 2006年2月 (1)
- 2006年1月 (9)
- 2005年12月 (7)
- 2005年11月 (20)
- 2005年10月 (3)
友情BLOG
- 我在MSN的Blog
- 范凱(Robbin)的BLOG
- 據(jù)說不會(huì)有什么技術(shù)文章
搜索
最新評(píng)論

- 1.?re: AjaxOpenDoc源代碼下載
- 評(píng)論內(nèi)容較長,點(diǎn)擊標(biāo)題查看
- --syt
- 2.?re: [導(dǎo)入]回顧我的BBS生涯——在網(wǎng)易的6年(1)
- 從來沒有深入的去想一想自己有什么信仰,雖然對(duì)工作和生活熱情,卻不知道是靠什么驅(qū)使的,想在你這里找到一些答案,能來給我一些指導(dǎo)?或者一些推薦的書籍。
- --greatghoul
- 3.?re: 還賬——1
-
是在搜索你博客主題的時(shí)候找到了你的站
感覺思考偏重于技術(shù)
呵呵 - --老鷹訓(xùn)練營
- 4.?re: XP應(yīng)該是老板的最愛,而不是程序員的首選
-
您好,我們公司是一家中國境內(nèi)的專業(yè)翻譯公司,從事各專業(yè)翻譯服務(wù),包括筆譯、口譯、同聲傳譯和同聲傳譯設(shè)備租賃等。我們需要招聘兼職翻譯、同傳譯員和外籍英文校對(duì)人員。
希望有機(jī)會(huì)合作. - --replica watch
- 5.?re: AjaxOpenDoc源代碼下載
- sdg
- --gsdg