從軟體開發到軟體交付
世界正在日益依賴於軟體的交付效率――特別是改善經濟產出的軟體。軟體生產更多涉及經濟學而不是工程學。在過去的25年，ibm的rational團隊和數百家軟體組織結成夥伴關係，參與了數千個軟體專案。我們的使命是雙重的：首先，為顧客帶來軟體最佳實踐，其次，直接參與他們的專案，學習成功和失敗的模式，這樣就可以辨別哪一種實踐是最佳的，以及為什麼它是最佳的。rational團隊沒有發明迭代式開發、物件導向設計、uml、敏捷方法，或者ibm®rational®統一過程捕獲的最佳實踐，我們只是吸取了行業的成功經驗。
大多數依賴於軟體的組織正在努力把它們的生命期模型從開發聚焦轉到交付聚焦。這個用詞上的微妙差別表達了驅動管理哲學和治理模型的原則正在劇烈變化。也就是說，面向「軟體開發」聚焦於開發過程中所需要的各個活動，而面向「軟體交付」聚焦於過程的結果。傳統工程治理和經濟驅動治理的區別如下表。
軟體開發：工程驅動
軟體交付:經濟學驅動
明確的開發階段
持續演化系統
從開發團隊到維護團隊，有明確的交付物
共同的過程、平台和開發維護團隊
從需求到設計到編碼到測試到運作，有清楚的、順序的活動
可用的能力序列，而且不斷增值
階段和角色特定的過程和工具
協作平台，整合了定製的工具和過程
共處一地的團隊
地理上分布，基於web的協作
有完整計畫和需求，強調早期精確，
隨著不確定性的解決，演化精確
通過度量工件生產和活動完成來治理
通過度量增量產出和進度/質量趨勢來治理
精確完整地定義需求/計畫，針對靜態的計畫和範圍跟蹤進度
減少不確定性，管理差異，度量趨勢，通過持續協商目標來調整航向
比起使用象橋梁建造那樣的傳統工程專案技能，軟體開發更類似於電影製作。大多數軟體專業人員沒有物理、材料性質上的限制來約束他們的問題或者解決方案，他們只受限於人類的想象力。軟體產品的質量度量沒有公認的原子單位。可能除了可靠性之外，大多數質量判斷都是非常主觀的，更象是選美，而不是精確的數學和物理計算。
當前各種軟體生命期模型使用了許多不同的術語，例如:螺旋式開發、增量開發、演化式開發、迭代式開發和敏捷開發。這些模型在思想上有許多東西是共同的：反瀑布開發。
ibm是結對程式設計和極限程式設計等敏捷技能的先鋒之一，我們現在有乙個有活力的技術社群，成千上萬的實踐者加入其中。這些年，我們致力於把敏捷諮詢和過程成熟度諮詢統一起來。這兩者都有管用的技能，內在精神是一致的，但帶著不同的行話和偏見來解決同樣的問題。這裡沒有絕對的對和錯，關鍵是上下文和規模，每乙個專案或組織都需要混合的技能、過程變體、常識和領域經驗。
迭代式軟體管理的頭10條原則
在2023年代，rational軟體公司開始演化乙個現代過程框架，更加形式地捕獲迭代式開發的最佳實踐。我們的首要目標是幫助行業從「計畫和跟蹤」管理風格(瀑布模型)遷移到承認需求、設計和計畫不確定性的「掌舵」領導風格。
以下是從2023年代到2023年代早期，我的頭10條迭代式開發原則:
1.基於架構先行方法的過程.
2.建立及早遭遇風險的迭代生命期過程.
3.把設計方法遷移到強調基於元件的開發.
4.建立乙個變更管理環境.
5.通過支援雙向工程的工具提公升變更自由.
6.以嚴格、基於模型的表示法捕獲設計工件.
7.調整過程以得到客觀的質量控制和進度評估.
8.使用基於展示的方法來評價中間工件.
9.根據演化詳細級別將使用場景分組，來計畫中間的發布.
10.建立乙個經濟上可伸縮的可配置過程.架構先行的方法強迫讓整合進入設計階段，在那裡，大多數重大的不確定性得以暴露和解決。早期的展示沒有消除設計斷裂，只是使它發生在可以高效解決的時候。下游的廢料和返工大大減少，得到更加健壯和可維護的設計。中期的里程碑提供看得見摸得著的結果。設計現在是「有罪推定」的，直到展示目的達到之前，專案不會前移。而度量理念體系也從瀑布模型中對活動做度量，遷移到迭代模型中對可執行發布中的廢料和返工趨勢做度量。
達到「規模化敏捷」:敏捷軟體交付的頭10條原則
經歷了十年的迭代式開發，我們用從幾百個專案裡積累的經驗更新了管理原則，將其更新到更先進的敏捷軟體交付經濟學科。以下是為了使得敏捷軟體交付成功，我建議的頭10條原則。
1.先做出架構密切相關的決策，以減少不確定性.
2.建立自適應的生命期過程，進一步減少變異.
3.通過資產復用和中介軟體，減少定製開發的數量。
4.調節過程以度量變更成本、質量趨勢和進度趨勢.
5.和所有涉眾誠實溝通進展和阻礙.
6.定期和涉眾協作，重新協商優先順序、範圍、資源和計畫.
7.在演化寬度和深度上持續整合發布和測試使用場景.
8.建立協作平台，提公升潛在分布團隊的團隊協作
9.通過自動化提公升變更計畫、範圍和**發布的自由度.
10.建立保證參與人員創造自由的治理模型.
需要組合探索、生產、評估以及掌舵式的領導風格，才能做到以可**、有利潤的方式成功交付軟體產品。「掌舵」一詞意味著積極參與管理，並且頻繁修正路線來產生更好的結果。所有涉眾必須協作，會獵移動的獵物，以上的原則刻畫了達到良好掌舵機制所必需的經濟基礎。從這些原則和實踐經驗可以得出三個重要的結論，如下圖所示。
下圖提供了這個重要度量模式的另乙個例子。這個圖所展示了質量度量有形的演化(在這個例子中，即嵌入大規模命令和控制系統中的軟體展示的mtbf，即平均無故障時間)。然而，傳統過程不得不在大多數生命期隨機地處理這個關鍵的效能需求，使用了現代敏捷交付方法的專案在達到這個需求時，在專案進度的足夠早期消除了不確定性，團隊可以高效地折衷剩餘的資源，投資來追求更好的執行時效能，新增功能，或者改進系統交付的利潤。這樣對所有涉眾來說都有重大的經濟影響力。
ibm，特別是rational，將繼續致力於研究和實踐軟體經濟治理更先進的知識，以便我們的顧客可以利用成熟的敏捷軟體交付業務過程。
軟體經濟學及其改進
實話，我是乙個剛剛畢業1年多得軟體工程師 希望真的有資格稱呼自己這個 談軟體經濟學這個話題，純粹是個人興趣，也是看書的乙個心得報告。談經濟，首先要明確輸入是什麼，即引數 思考問題的核心點在那裡。軟體經濟學一般來說有五個引數，分別是規模 過程 人員 環境和質量。這五個點每個都是一門學科，但是這五個點絕...
軟體的經濟學
如何在軟體開發過程中創造最大的價值，這就涉及到了軟體的生命週期的問題，是在乙個較長的時間裡推出一套比較完整的功能獲得利潤，還是在在適當的時間裡推出不同的版本來分期獲得價值那？貼現值，現值等概念在經濟學和金融學裡已是最通俗的概念，但真正的將這些咚咚用到具體的實踐中，卻是微乎其微的，作為商務 科班 的我...
軟體工程改進的經濟學 環境偏
人員 過程之後，我想說說乙個不可忽視的引數 環境。因為看的多是翻譯過來的文章，所以起初搞不清楚這個詞多應得英文到底應該是什麼。因為以前接觸過的可以作此翻譯有 envirnoment,context 等等。應該說在這個地方似乎都還合適。不過我想了想還是選擇了 enviroment 這個詞可以脫離技術遠...