久久久久国色AV免费观看,色综合久久无码中文字幕,久久影视综合亚洲

從編程到工程——系統地分析軟件工程

《大道至簡》的第六章“從編程到工程”，我認為是全書的精髓！作者以自己深厚的積累、豐富的經驗，用精煉的文筆深刻闡明了“軟件工程”的內涵和外延，講清楚了代碼、方法、過程、工程與組織的關系！非常值得我們深入學習和研究！

本章所有內容都是圍繞作者給出的一張圖——EHM模型圖，完全可以說，這張圖充分顯示了作者深厚的功底：

既可以說這幅圖展示了軟件工程內涵的各個層面，也可以說這其實就是軟件工程的發展史：從最早只追求程序實現到后來有完善的組織和管理。

在本章的后面若干節內容中，作者分開描述EHM各個組成部分。我想下面這一段“方法”可能比較對技術人員的口味：

原文推動這種邏輯向前發展的，是“方法”和“方法論”的出現。長期的編程實踐，自然的歸演與總結，必須沉淀為某種( 軟件開發) 方法，于是“過程”出現了，于是“對象”出現了，于是相關的方法論也就出現了。

這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，微軟不提出某個方法，IBM 也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。

方法并不神秘，因為它就是你今天正在做的、從事的和實現的。正如“模式”是一種方法，而模式就是你昨天書寫代碼的那個行為。只不過，GoF 歸納、抽取、提升了這些行為的內在規律。

你看不到你做事的行為，也就不能理解“模式”作為一種方法的價值。所以大師們眾口一詞：模式需要一定的編程經驗才能理解。

同理，理解過程也需要編程經驗，理解對象也需要編程經驗，理解MDA與SOA還是需要編程經驗。

——這可能就發生在你去回顧你上一行代碼編寫的經過，或者上一個項目失敗的經歷的那一瞬息。經驗來源于回顧、理解與分析，而不是你將要寫的下一行代碼。

有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。

GoF 因為無數次的代碼回顧而得道。

而這一段“組織”可能讓項目經理比較感興趣：

原文工程理論其實是包含組織學的。然而我在上面的那張圖中，將組織與工程分離開來，并在二者之間畫下了一道縱向的線。

如果說工程關心的是“需求”、“配置”和“文檔”等等這樣一些要素，那么這樣的工程還是停留在技術層面的：關注的還是工程的實現細節，而非目標。從角色的角度來看，這是項目經理和技術經理所共同關注的那一部分。

然而項目經理還必須關注于人力資源、項目資金以及多個項目之間的協調等等。這些與工程本身并沒有直接關系，而是“組織”方面的內容。

所以在工程環節中“文檔管理”和“配置管理”等等中的那個詞匯“管理”，是管理的具體技術和方法；而在“組織”這個環節中的這個“管理”，才是真正的管理學上的用詞。

我在這張圖上，試圖從這個角度上來說明：作為項目經理，你必須有一部分的工作是非技術性的。甚至，你可能絕大部分的工作是非技術性的。——因為與技術相關的管理技能( 需求、配置、過程管理等) 可以由開發經理來做，或者公司對于這一方面有較統一且成熟的規范，因而無需投入過多的精力。

你必須更關注于對這個( 或這些) 工程的組織與計劃。站在“組織者”這個角色上，你現在要考慮的內容可能會是：

為項目的各個階段建立計劃，并逐漸地細化計劃的內容，以及確立項目過程中每一個環節、每一個計劃階段的優先級和復雜度；
確立項目或者產品階段目標，成果的準確描述、定位，以及整個項目的質量目標及其評核辦法；
對團隊中的不同角色展開培訓，以指導并協調角色間的工作，從而消除因為工作習慣的差異帶來的影響；
為每一個人準備他所需要的資源，這不單單是把一套shareware 變成正式版或者把512M 內存變成2G，還包括準確地評估他的工作量，以及決定是否為他增加一個( 能協同工作的) 副手；
決定在哪些環節上反復審核和回顧，而在哪些環節上采用較為寬松的方式以加快進度；
習慣于開會、組織更短而有效的會議以及建立激勵機制，當然也不要忘記讓每一個成員意識到這一項目的風險；
不要樂觀。

即使你做好這一切，可能項目的結果仍然不夠理想。但是你應該知道，好的項目經理并不是不犯錯誤的人，而是以盡可能少的失敗來獲得成功的那個人。

無論是你的團隊成員，還是你的老板，對重復的錯誤以及可預料的錯誤都是不會寬容的。——在一個團隊中，失去了組員的信任比失去老板的信任更為可怕。

所以回顧每一個項目，或者項目中的每一個階段，以及與每一個團隊成員交流的細節，是你的日常工作。

當然，了解一下BOSS的定位和主要職責也是很有幫助的：

原文很多人以為BOSS 是給自己發錢的那個人，這其實是錯誤的。發錢的決策通常是由三個角色來做出的：

部門／團隊經理。你的直接上司，他是雇傭你的人，是他用薪金的多少來衡量你的價值，或者反之。
紀效經理。如果你的公司有這個角色的話，那么他總是盯著你的錯誤以決定從你的薪水里的扣除比例。
財務經理。有錢？沒錢？沒錢？有錢？……

BOSS 并不決定你的薪水。

BOSS 在公司中解決的是“經營”問題。這其實是在比“組織”更靠外側的一層。——在前面的圖例中并沒有給出，這也意味著“經營者”與“工程”基本沒有關系。

在一個更大規模的組織機構里，你可以會更直接地觀察到“經營者”與“組織者”之間的差異。例如公司的大小股東是“經營者”，董事會通常是解決經營問題的地方；而總經理、執行經理以及各個部門經理則是各級的“組織者”，經理辦公會則是解決組織問題的地方。

你應該清楚，真正的BOSS是經營者。

這有助于你明確你被雇來的原因，你的工作是面向哪一個層面的，以及你或者你的上司有沒有權限來決定是一個項目是否應該立項，或中止。

BOSS(經營者) 決定了一個方向，組織者保證決策與這個方向是同步的，而工程是在這樣的一個方向、決策的構架下的一個具體行為。

工程中沒有BOSS。

從編程到工程，本文系統地分析了軟件工程的方方面面。EHM給出的是完整的軟件工程架構，不是一個小程序，也不是單獨的過程。這是一套體系，在這套體系中，軟件工程的所有參與人基本都能找到自己的位置，包括那個只是偶爾出現來指手畫腳的BOSS。

作為軟件工程體系中的一個角色，找對自己的定位，明確自己的職責，對以后的工作無疑會有巨大的幫助。經常讀讀本文吧~

posted on 2013-07-16 17:01 Tim 閱讀(291) 評論(0) 編輯收藏引用所屬分類: 品讀《大道至簡》

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: 品讀《大道至簡》團隊缺乏的不只是管理——“體制病”的猛藥是思考還是思想——靈活的軟件工程思考項目成本的經理——忽略細節，把握關鍵從編程到工程——系統地分析軟件工程失敗的過程也是過程——軟件工程的模型和過程跟隨螞蟻——軟件開發團隊管理思想是懶人造就了方法——做思維勤快的懶人為不存在的角色留下溝通的渠道——讓項目的歷史有據可查流于形式的溝通——溝通需要用心準備

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

無我

從編程到工程——系統地分析軟件工程

導航

統計

公告

留言簿(9)

隨筆分類(173)

IT

Life

搜索

積分與排名

最新隨筆

最新評論

閱讀排行榜