<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    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 讀書、思考、生活 閱讀(2929) 評論(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年4月>
    2627282930311
    2345678
    9101112131415
    16171819202122
    23242526272829
    30123456

    常用鏈接

    留言簿(20)

    隨筆檔案

    友情BLOG

    搜索

    •  

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲另类自拍丝袜第五页 | 18禁超污无遮挡无码免费网站国产| 亚洲性猛交XXXX| 成年女人A毛片免费视频| 亚洲人午夜射精精品日韩| 日本高清免费中文在线看| 亚洲国产a级视频| 精品国产免费人成网站| 中文字幕亚洲无线码| 岛国岛国免费V片在线观看| 中文字幕中韩乱码亚洲大片| 精品乱子伦一区二区三区高清免费播放 | 亚洲色偷偷综合亚洲av78 | 亚洲午夜av影院| 免费无码又爽又刺激网站| 亚洲av无码国产精品色午夜字幕| 国产成人AV片无码免费| 久久综合亚洲鲁鲁五月天| 大学生美女毛片免费视频| 国产亚洲福利精品一区二区| 久久夜色精品国产亚洲av| 久久久久久影院久久久久免费精品国产小说| 婷婷亚洲综合五月天小说| 亚洲免费中文字幕| 亚洲av无码一区二区三区天堂| 亚洲成A人片在线观看中文| 拍拍拍无挡免费视频网站| 18亚洲男同志videos网站| 在线观看免费大黄网站| 又长又大又粗又硬3p免费视频| 亚洲日韩精品无码专区网址| 100部毛片免费全部播放完整| 亚洲日本久久久午夜精品 | 亚洲第一精品在线视频| 中文字幕无码不卡免费视频| 黄网站色成年片大免费高清| 亚洲V无码一区二区三区四区观看| 国产精品成人观看视频免费| 免费很黄无遮挡的视频毛片| 亚洲午夜久久影院| 免费一级毛片在线播放|