編著者：張克強 ? ?微博：張克強-敏捷307

軟件工程7原則簡介

美國著名軟件工程專家鮑伊姆(B.W.Boehm，也又另譯為勃姆)在總結軟件工程準則和信條的基礎上，于1983年提出軟件工程的7條基本原則，也是軟件項目管理應該遵循原則。勃姆認為，這7條原則是確保軟件產品質量和開發效率的最小集合，相互獨立但結合得相當完備。

1. Manage using a phased life-cycle plan. 用分階段的生命周期計劃來管理
2. Perform continuous validation. 進行持續的確認
3. Maintain disciplined product control. 堅持有紀律的產品控制
4. Use modern programming practices. 利用現代編程實踐
5. Maintain clear accountability for results. 維護對結果的清晰責任追究
6. Use better and fewer people. 使用少而精的人員
7. Maintain a commitment to improve the process. 保持提升過程的承諾

約束理論TOC的關鍵鏈項目管理

關鍵鏈項目管理（Critical Chain Project Management，CCPM)方法是Eliyahu Goldratt博士在其小說體專著《關鍵鏈》(Critical Chain)中提出的一種新的方法，其支持者們認為，這是一種全新的、革命性的思維方式，可以有效地縮短工期，提高項目滿足進度與預算約束的能力；但是也有人認為，CCPM的獨特性僅僅體現在這一術語上。---摘自百度百科

關鍵鏈被用來替代關鍵路徑分析方法。關鍵鏈區別于關鍵路徑的主要特征如下： 使用資源依賴 缺乏尋求最佳方案的方法。這意味著一個“足夠好”的解決方法已經足夠了，因為： 就目前所知，沒有任何分析方法能找到一個絕對的最佳的（比如，總體的最短關鍵鏈）。 估算上的固有的不確定性，遠遠大于最優和接近最優（即“足夠好”的解決方案）之間的差異。 插入緩沖 項目緩沖（Project Buffer，縮寫為PB） 輸入緩沖（Feeding Buffer，縮寫為FB） 資源緩沖（Resource Buffer，縮寫為RB） 監測項目的進展和緩沖的使用率，而不是規劃個別任務的進展速度。?---摘自百度百科

討論的緣起

@TOC中國?發了條微博 ：1.項目的客戶為什么需要設定里程碑？ 2.客戶希望用里程碑達到什么目的？ ? ?? 張克強-敏捷307 ： 好多項目管理類和軟件工程的書都是這么說的。toc 如何破 ？

? ??TOC中國：回復@張克強-敏捷307:回復@張克強-敏捷307:破什么?

? ??張克強-敏捷307：《關鍵鏈》對此有新做法，我以為你會提，你是要提否？

張克強-敏捷307：回復@TOC中國:在軟件開發領域，請查看鮑伊姆-軟件工程七原則，發表于上世紀80年代初。

然后，我找到個介紹鮑伊姆-軟件工程七原則的網絡文章，做了推薦:?

@張克強-敏捷307?勃姆的軟件工程7條基本原則-文章頁-PChome手機版?http://t.cn/Rv6ah88?@TOC中國

開始爭論

拯救與逍遙：不同層次的管理人員必須嚴格按照計劃各盡其職地管理軟件開發與維護工作，絕不能受顧客或上級人員的影響而擅自背離預定計劃。【第一條就是自說自話了?！?/span>
? ? ? ? ? ?張克強-敏捷307：怎么自說自話了？scrum是符合此條的 拯救與逍遙：SCRUM說了“絕不能受顧客或上級人員的影響而擅自背離預定計劃”？
? ? ? ?Glen-Wang：一切經PO ? ? ? ?張克強-敏捷307：sprint backlog的修改是需各方同意的，注意原文中的“擅自” ? 拯救與逍遙：一方面說 “不成功的軟件項目中約有一半左右源自計劃不周”，另一面有說“絕不能受顧客或上級人員的影響而擅自背離預定計劃”。 這不是邏輯混亂嗎？加上“擅自”不過是留個退路的修辭。如果了解過TOC的 CCPM 項目管理方式，就會知道基于嚴格里程碑計劃的復雜項目，必將失敗。(6月9日 17:23)
? ? ?張克強-敏捷307：回復@拯救與逍遙:我認為其邏輯很正常。計劃不好，項目容易會失敗；未經各方同意修改計劃，更容易失敗。另，scrum的review meeting實質上是里程碑評審，忠實的滿足了此條軟工原則。 (6月9日 18:27)
張克強-敏捷307：回復@拯救與逍遙:你要是用toc能證明軟工原則是錯的，或者已經過時，你就是新一代軟工大師。如果你真有所得，建議寫成論文，有道理的話，發表出來，想來轟動世界。以上我是認真的，絕非嘲諷。(6月9日 18:36)
? ??拯救與逍遙：回復@張克強-敏捷307:我就問一個問題，每個里程碑都按時達成是整個plan按時達成的充分條件 還是 必要條件？至于ccpm項目管理方式已經被收入到pmbok中了，論文早已輪不到我這樣的后生晚輩寫了。 (6月9日 18:51)
? ? ? ? ? ? ?張克強-敏捷307：你這問題本身不恰當。pmbok是如何說ccpm的？有鏈接否？ ? ? ? ? ? ??張克強-敏捷307：pmbok收ccpm可并不一定說明軟工原則失效，項目管理與軟件工程有重合，但不等同 ? ? ? ? ? ??拯救與逍遙：我是在pmbok上看到過，不過說的很簡略。具體哪里要問下pmp專家了?@京東PMO蔡德輝?。網上有更多詳細的介紹，搜一下吧。有本toc的企管小說《關鍵鏈》講這個，有興趣還可以參加近期上海的ccpm的培訓班。
? ? ? ? ? ? 李凱-社會化營銷：回復@拯救與逍遙:這里其實存在兩種不同的假設：里程碑思維里，大概拖延癥，早完成隱瞞不報，多任務下帶來的時間延長等問題是完全可以消除或控制的，進一步就是保護局部就等于保護全局。而TOC是承認這些不確定性的，因此其對應之策是保護影響全局的關鍵路徑，對其他局部采取寬松政策。(6月9日 19:12)

分析

張克強-敏捷307：我認為關鍵鏈是考慮了資源瓶頸的關鍵路徑，軟件項目矩陣管理其實已經覆蓋了關鍵鏈的要點，而且關鍵鏈下并不是完全取消里程碑，而是識別了更關鍵的里程碑。我精讀過此書//@拯救與逍遙:有本toc的企管小說《關鍵鏈》
拯救與逍遙：那克強認為ccpm相對于傳統方式的特點在哪里呢？?
張克強-敏捷307：我已經說了啊，其效果在軟件領域不會明顯，在積累大量數據的建筑領域也不會明顯，在其它領域我估計效果會不錯
? ? ? ??趙智平_極普TOC：CCPM,1顛覆了關鍵路徑CPM,2去除學生綜合癥及帕金森綜合癥對項目的影響，3設置緩沖因應不確定性并給出預警機制 拯救與逍遙：在軟件領域不明顯的理由是？
張克強-敏捷307：在軟件開發領域，矩陣管理，敏捷團隊，cmmi，各類模型等等已經覆蓋并超越了關鍵鏈，建筑領域類似
? ? ? ??拯救與逍遙：這個邏輯好奇怪//@張克強-敏捷307:在軟件開發領域 ? ? ? ??張克強-敏捷307：回復@拯救與逍遙:錦上添花 vs. 雪中送炭啊！ ? ? ? ??李凱-社會化營銷：因為對這些方法不懂，所以只能問最基本的問題：這些方法的追求目標是不是與CCPM并不完全一致，實際上還超越了它? ? ? ? ? ??張克強-敏捷307：竊以為大目標是一致的，這些覆蓋并超越了ccpm//@李凱-社會化營銷:因為對這些方法不懂 ? ? ? ? ? ? ? ??李凱-社會化營銷：那么大目標是什么呢？超越的部分又是哪些?這是一個值得學習的突破口 ? 趙智平_極普TOC：軟件開發的最大不確定性是什么?是完成任務的時間?軟件需求?CCPM處理的最大不確定性是任務時間
張克強-敏捷307：敏捷迭代開發利用時間箱，別的行業很難模仿
趙智平_極普TOC：為何要迭代?因為可以鎖定需求?需求被鎖定,不確定性為任務的時間?//@張克強-敏捷307:敏捷迭代開發利用時間箱，別的行業很難模仿
張克強-敏捷307：反過來，鎖定時間，擁抱變化//@趙智平_極普TOC:為何要迭代？
趙智平_極普TOC：以時間緩沖(余量)決定可接受的需求變化,或可引用緩沖侵蝕做決策;需求是最大的不確定性,小批量逐次確認//@張克強-敏捷307:反過來,鎖定時間,擁抱變化 ?
? ? ? ? ? ?張克強-敏捷307：nod，好多toc術語，敏捷騷年一般不喜歡 ? ? ? ? ? ?深圳老曲：ccpm中對人性的解釋（不良多工、帕金森定律、學生綜合癥、墨菲定律等）可以用于敏捷的導入，但ccpm本身缺乏對軟件開發實踐的支持。 //@張克強-敏捷307:nod，好多toc術語，敏捷騷年一般不喜歡 ? ? ? ? ? ?趙智平_極普TOC：CCPM可以支持的最大不確定性是任務時間及有限度地"擁抱"變化//@深圳老曲: ccpm中對人性的解釋 深圳老曲：ccpm以及傳統的項目管理，背后的假設都是項目的內容、工期、質量是能夠同時兼顧的。在軟件工程領域，這個假設是是不成立的，所以敏捷則是固定時間、保證質量，首先交付價值最高的功能。 ? ? ? ? ? ? ? ? ? ? ? ?趙智平_極普TOC:如果我懂SDBR及C#,需求已使用UML定義,可以使用CCPM管理開發進度嗎? ? ? ? ? ? ? ? ? ? ? ? ?深圳老曲：可惜的是，包括UML在內的幾乎所有方法，都不能清晰、準確地把需求定義出來，特別是比較大或沒有參考對象的項目。?

總結

以上是生活随笔為你收集整理的TOC之关键链项目管理遇到软件工程7原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。