探索持續規劃
持續規劃是八個 DevOps 功能的其中一個。
探索需要持續規劃的原因
我們將逐步解說一個案例研究，該案例是政府機關在 2000 年和 2005 年之間所開發的軟體應用程式。 此專案在 2005 年 1 月正式放棄時並未接近完成，結果可說是完全的失敗。 除了浪費了一億美元外，此次失敗也使該機關及其主管機關受到廣泛的批評。
第二個專案在 2006 年啟動，但仍是類似的災難性結果。 這兩個專案皆使用了大型前期設計及瀑布型 (Waterfall) 開發方法，並且規劃了經典的大型上市活動。 但結果什麼都沒有，而且還花費了數億美元。
這些嘗試失敗的原因為何？
- 大型前期設計 – 200 人小組花了六個月的時間來建立需求。
- 轉移優先順序 – 專案進行中途發生國家級災害，導致大範圍的變動，而另一組 300 人小組花了六個月的時間產出 600 頁的需求。
- 做白工和工作重做導致交期延誤，也使得小組疲憊不堪 (撰寫和重新撰寫了 700,000 行程式碼)。
在 2010 年 12 月時，他們設定及共置了 Scrum Studio。 員工從原本專案上的 400 人縮減為 40 人。 設計從 600 頁的需求變更為 670 個使用者案例。 小組每兩週遞交程式碼及示範新功能。 在幾個短期衝刺之後，他們已經能夠預測概略的時幅，並規劃遞增式的業務變更。 這些都是 2011 年 12 月前的程式碼完成。
但為什麼難以進行詳細的規劃？
Alan Turing 在第二次世界大戰期間開發了可破壞加密裝置的機器，也就是廣為人知的「恩尼格瑪密碼機 (Enigma Machine)」。
Turing 必須不斷地破解新代碼來拯救生命。 Turing 知道，只有破解微小細節，才能獲得更巨大的成果，而不是因為似乎永無止盡的複雜細節而放棄一切：
「我們只能看到前方一小段距離，但可以看到許多能做的事。」
抱負遠大的軟體專案總是很複雜。 但千萬不要屈服於複雜的細節。 而是應該從明確的地方著手：也就是短期目標。
透過目標和關鍵結果 (OKR) 來提供明確方向、焦點和靈活性，以持續且有效率地進行規劃
在定義持續規劃之前，我們必須先介紹一個重要的概念和架構，以協助您在具有明確方向、焦點和靈活性的狀態下，進行持續且有效率的規劃。
目標和關鍵結果 (OKR) 是一種目標設定架構，其設計目的是要將領導階層的策略性目標與執行小組的日常活動連結在一起。
重要
OKR 可協助您找出最佳可能結果，並釐清真正的成功應是什麼樣子。
為了擁有明確的焦點和靈活性，OKR 通常會以每一季為基礎來設立。
目標指的是方向，而關鍵結果必須是可測量的。 您可以在最後檢視且毫無爭議地判定：我做了哪些事，或是我沒有做哪些事？ 是？ 否？ 簡單。 其中無需任何評判。
OKR 會在組織內的所有小組之間本地化，以表明一致性和透明度。
什麼是 OKR？
OKR 有三個基本層面：
這些層面構成定義明確目標的架構，讓組織中所有層級的意圖和方向清楚明確。
並且能夠利用可測量的關鍵結果來加強。 關鍵結果是用於測量成功的成效。
其推動了成效思維文化，清楚地將輸出思維轉移至成效思維。
OKR 範例
以下是 OKR 範例：
目標：在 1970 年前將太空人放到月亮上。
關鍵結果：
- 在 1965 年前建造 40000 磅以下的太空船。
- 在 1967 年前訓練太空人，使其能在月球上登陸。
- 成功將太空船放置在月球上。
- 安全地將太空人帶回地球。
此 OKR 範例會識別在 1970 年前將太空人放在月球上的目標。
注意
目標必須易於了解、設定清楚方向並提供動機。
在此範例中，關鍵結果是將測量目標成功進度的量值。
注意
關鍵結果必須能夠測量，進而找出達成目標的方法。
OKR 的主要優點
OKR 有五個主要優點：
- 聚焦：每個目標的方向應一致。 至於關鍵結果，每個目標上不應超過五個關鍵結果。
- 一致性：管理者和參與者都會將其日常活動與組織的全公司願景連結。 此連結的術語為「一致性」，且不能誇大其值。
- 承諾：調整排程和資源，以確保所有同意的承諾都會實現。
- 追蹤 OKR (從輸出到成效)，是為什麼頂層公司喜歡依據目標來進行管理的原因。 每個 OKR 都應該能透過其撰寫過程中建立的計量來加以追蹤。
- 延展：OKR 本身就會促使組織更加努力，比他們想像的還多。
比較持續規劃和靜態規劃
持續規劃是一種做法，規劃人員、架構設計人員和敏捷小組必須持續在企業間整合他們的方案。
在持續規劃中，Scrum 式規劃方法和新興設計可讓小組將規劃提升為執行層級。
具有能因應變更的高階計劃 (但以明確的願景和用途作為引導) 是非常重要的。
瀑布式與敏捷式開發方法的權衡鐵三角，可說明持續和靜態規劃之間的比較。
在靜態方法中，規劃範圍是固定的。 您會決定專案將花費多少時間，以及其成本是多少。
在採用持續規劃原則的敏捷方法中，為符合營運目標，時間會是固定的。 唯一可協調的是範圍。
鐵三角形通常會顯示時間、資源和功能。 Gartner 在此敘述上新增了品質，因為持續時間和成本是相互關聯的，而品質通常會被遺漏。
但是，這兩個方法的成功率如何？
敏捷專案更成功的原因之一，是因為小型的批次發行可提高獲取知識的機會。
請將四件事牢記在心：
- 商務需求經常變更，而且會在很短的時間內發生。
- 敏捷專案有規劃機制，可掌握商務變更。
- 績效高的小組也可能輕易且快速地走向錯誤方向。
- 獲取知識可降低風險。
瀑布和敏捷方法都會遇到挑戰。 敏捷專案現在的成功案例也只比 30% 多一些。
探索持續規劃的六個原則
持續規劃有六個原則：
- 價值簡化
- 敏捷式軟體開發 (Agile Software Development) 宣言
- 設計思考
- 反覆與漸進式開發
- 精實管理
- 估計的正確性
持續規劃原則 #1：價值簡化
第一個持續規劃原則是價值簡化。
「如果你無法簡單說明一件事，表示你不了解那件事。」
- 亞伯特‧愛因斯坦
持續規劃原則 #2：敏捷式軟體開發 (Agile Software Development) 宣言
第二個持續規劃原則是敏捷式軟體開發 (Agile Software Development) 宣言。
宣言與軟體交付有關。 這與軟體開發有關 (而不是專案管理或設計)。 其位於持續規劃和 DevOps 的核心。
我們會藉由執行此原則及協助他人執行此原則，來發掘更好的軟體開發方式。 在這項工作中，我們的價值觀如下：
- 個人與互動，更甚於流程圖和工具
- 工作軟體，更甚於完整文件
- 與客戶共同作業，更甚於合約交涉
- 因應變化，更甚於遵循計劃
持續規劃原則 #3：設計思考
第三個持續規劃原則是設計思考。
設計思考採用以人為中心的創新方法。 其著重於存續性、可行性和需求性的交集，目的是建立界限及減少浪費。
持續規劃原則 #4：反覆與漸進式開發
第四個持續規劃原則是反覆與漸進式開發。
有些人會因為不知道將獲得什麼結果而感到擔憂。 反覆開發可解決此問題，因為專案關係人可在反覆的意見反應迴圈中提出需求和優先順序。 對使用者而言，每個反覆項目都是完整、可用且實用的。 如此可提高功能性，並以最重要的功能性為優先。
持續規劃原則 #5：精實管理
第五個持續規劃準則是精實管理。
價值的定義來自從終端客戶的觀點。 此程序中會識別價值流 (value stream)，並將未傳遞價值給客戶的步驟識別為浪費並加以移除。
此程序會再次開始，使用持續改善來追求完美的狀態。
持續規劃原則 #6：估計精確度
第六個持續規劃原則是估計精確度。
估計值是耗費時間、所需成本或可傳遞功能數目的分析預測。 估計值有兩個屬性：正確性 (accuracy) 和精確度 (precision)，兩者完全不相關。 估計值是由工程小組所負責。
目標是商務需求的陳述：我們想要花費多少時間、我們想要花費多少成本，或是我們想要獲得多少功能。 目標是由業務小組所負責。
承諾是在特定日期前交付功能和品質的保證。 承諾是共同負責的項目。
重要
持續規劃的目標是保持估計值、目標和承諾之間的一致性。 否則，我們將無法滿足組織內外的期望。
說明 OKR 與 Scrum 之間的關聯性
現在您已了解 OKR 的「起因」和「內容」，以及持續規劃的相關資訊，而下列是這兩者之間的連結。
使用 OKR 這類技術來結構化工作，將會降低不確定性 (至少短期來說是如此)。 因為 OKR 必須要以串聯方式定義，所以這會開始變更管理者展現其管理風格的方式。
OKR 這類技術可讓您快速且有效率地開始脫離專制管理風格。
