計劃驅動開發
出自 MBA智库百科(https://wiki.mbalib.com/)
目錄 |
計劃驅動開發指軟體開發過程中，前一階段的輸出作為規劃隨後過程活動的基礎。
計劃驅動開發的步驟[1]
計劃驅動開發起源於系統工程和質量規範，建立系統工程的原則，協調大量需要精確協同工作的組件。通過從需求到已完成的代碼等一系列代表物來推動軟體開發的過程，計劃驅動開發非常精確地依賴於明確的步驟。典型地，瀑布模型，軟體開發周期劃分成若幹個階段：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼與單元測試、綜合測試、軟體維護，各階段的工作自項向下，從抽象到具體順序進行，每個階段都必須完成規定的文檔，只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果，就好像奔流不息的瀑布，從概念直到最終產品。
計劃驅動開發的關鍵是過程的定義和管理，和過程改進聯繫在一起，強勢在於標準化所帶來的可比較性和可重覆性。過程需要進行定義、標準化並需要逐步改進以提供控制、管理其操作所需的數據。定義過程執行的方法，和工作產品形式化的方法，對過程的實施者進行良好的培訓。需要管理層的支持、組織化的基礎設施以及良好的環境。
敏捷軟體開發與計劃驅動開發的對比[1]
從以下特征中比較敏捷軟體開發和計劃驅動開發之間的不同：應用：項目的主要目標、項目環境和應用環境；管理：客戶關係、計劃和控制，以及項目溝通；技術：需求定義、開發和測試的方法；人員：客戶特征、開發人員的特征，以及組織的文化。
1.應用
(1)主要目標：敏捷軟體開發的目標是快速交付價值和響應變更，在快速變更的環境中，反應式的態度具有優勢，但有一些風險。計劃驅動開發的目標是可預見性、穩定性和高可靠性，提前行動的態度對於穩定的環境非常有效，認證需要有計劃和規格說明：
(2)規模：敏捷軟體開發最適合規模比較小的項目，事實證明，敏捷項目的規模難以擴大。傳統的嚴格性對大型項目更有效，對於大型、複雜的項目來說，計劃驅動開發是必需的；
(3)環境：敏捷軟體開發適用於頻頻變更的環境，但有一些風險，關註於眼前的產品，成功主要出現在內部環境，假設用戶系統是靈活的，足以進行演化。計劃驅動開發需要穩定性，範圍包括系統工程、組織結構、外包。
2.管理
(1)客戶關係：敏捷軟體開發提倡專職的、在一起工作的客戶，重中之重是客戶代表和用戶之間的介面，敏捷開發者通過可以工作的軟體來建立客戶信任。計劃驅動開發依賴於合同和規格說明，重中之重是開發者和客戶之間的介面，計劃驅動開發者使用已形成的過程成熟度來建立客戶信任；
(2)計劃和控制：敏捷者把計劃看作一種達到目標的手段，敏捷軟體開發是“計划行為驅動”而非“計劃驅動”。計劃驅動開發用計劃來進行溝通和協調。兩種方法都使用過去的經驗來使計劃變得準確；
(3)項目溝通：敏捷軟體開發依賴於隱式知識，依賴於頻繁的、人和人之間的溝通，依賴於隱式知識是有風險的，隱式知識的規模難以擴大。計劃驅動開發依賴於顯示的、文檔化知識。敏捷軟體開發和計劃驅動開發中都同時使用了這兩種知識。敏捷軟體開發在需要時會編寫文檔。計劃驅動開發則通常是去掉一些不必要的內容，一旦指定，再去除文檔就很難了，會遭遇“裁剪”綜合症。
3.技術
(1)需求：敏捷軟體開發把非正式的、由用戶指定優先順序的素材作為需求。計劃驅動開發偏愛明確的、形式化的需求，計劃驅動開發中沒有廣泛使用優先順序這一概念。計劃驅動開發可以更好地處理非功能需求(比如：可靠性、吞吐量、滿足實時限制和可伸縮性)；
(2)開發：敏捷軟體開發提倡簡單設計，簡單設計依賴於低成本的改寫和快速變更，但無法保證低成本的改寫，低成本的改寫無法伸展，簡單設計意味著你不會需要它的(You are’t going to need it)。計劃驅動開發提倡使用架構來預測變更，在快速變更的環境中，架構會造成一些資源的浪費；
(3)測試：敏捷軟體開發在編碼之前開發測試，然後增量地測試。計劃驅動開發測試的是規格說明。
4.人員
(1)客戶：敏捷軟體開發非常強調專職的、工作在一起的客戶代表，成功依賴於客戶代表必須易於協作、有代表性、有授權、盡責和在行(collaborative，representative，authorized，committed，knowledgeable，CRACK)。而計劃驅動開發則依賴於大量預先的，客戶和開發者之間的合同計劃和規格說明方面的工作，也需要CRACK型的客戶，但可以不是專職的，計劃驅動開發中最大的客戶挑戰是不要讓項目控制落入過度官僚(他們認為遵守合同比取得項目成果更重要)的合同管理者手中；
(2)開發人員：敏捷開發者需要具備更多的技能。不管是敏捷團隊還是計劃驅動團隊，都應該儘快識別出也許具有一些技術能力，但是不能或者不願意，合作或者遵循公共的方法的人員，讓他們從事一些非決策性質的工作。通過培訓能夠完成程式性的方法步驟(例如，對簡單的方法進行編碼，進行簡單的重構，遵循編碼規範和CM規程，運行測試)的人員，經過相當多的指導，可以在計劃驅動環境中很好地工作。而通過培訓能夠完成任意的方法步驟(例如，把素材分解成適合增量開發的大小，組合使用模式，進行複雜的重構，進行一些複雜的商品成品集成)的人員，經過一些指導，可以很好地在敏捷團隊中工作。能夠對方法進行裁剪以適應有先例可循的新情況的人員，可以很好地管理一個小型、有先例可循的敏捷或者計劃驅動項目。但對於大型或無先例可循的項目，需要能夠對方法進行修訂(違背其規則)以適應無先例可循的新情況的人員；
(3)文化：敏捷者喜歡更多的自由度，計劃驅動者需要清晰的過程和角色。一旦一種文化已被良好地建立，改變就會非常困難和耗時，文化的慣性是集成敏捷軟體開發和計劃驅動開發時面臨的最大挑戰。
