在任務關鍵型系統開發中應用敏捷的 5 大技巧

openkk 12年前發布 | 9K 次閱讀 敏捷

在任務關鍵型系統開發中應用敏捷的 5 大技巧

根據定義,任務關鍵型產品的故障成本非常高。將敏捷方法應用到運行它們的軟件和系統開發中,可幫助預防導致故障的缺陷。敏捷開發方法可提高產品品 質、減低 成本、縮短面市時間和提高成果的可預測性。但是,您需要先對敏捷方法進行一定程度的微調,使它們適合這些復雜且嚴苛的項目。敏捷治理、動態規劃、測試驅動 的開發、增量式開發和高效的風險管理,這些都是敏捷在任務關鍵型系統開發中成功應用的關鍵。

任務關鍵型系統和敏捷開發

任務關鍵型系統對人類安全具有重要的影響。這些系統的故障成本可能非常高,不僅會導致財務損失,還會造成傷害或死亡。針對他們嚴格和復雜的開發而應 用和調整敏捷方法,有助于預防故障,改善質量,提供更可預測的成果,以及減少上市時間和成本。以下 5 大技巧可用于將敏捷性應用于任務關鍵型系統開發中。

技巧 1: 敏捷治理

敏捷治理在于通過避免常常糾纏著傳統開發工作的不必要的阻礙,讓一個環境中的開發團隊可滿足他們的目標。它的理念是,您和您的團隊確定目標并將如何 滿足它們。但是,最重要的步驟是,首先真正制定決策來管理項目。然后,您需要理解您將衡量的對象、您將如何衡量它,以及您將如何應對這些衡量結果。

許多人管理著錯誤的事情,即那些容易衡量的事。敏捷并不在于容易;它在于做出了對于取得成功和避免失敗有意義的事情。您需要決定與您的成功定義相關 聯的關鍵績效指標 (KPI),然后不斷使用它們監控質量和完成進度。一個 KPI 可能是項目速度,它不僅表示您在時間上完成了多少工作,還表示這些工作具有多高的價值。擁有 KPI 后,您就可以使用它們駕馭項目。因此,進度的透明性和可視性至關重要。

技巧 2:動態規劃

敏捷是一種嚴格、井然有序的系統和軟件開發方法。作為一種瀑布式方法,這需要進行規劃。但是區別在于,對于敏捷來說,規劃是動態的。主要前提是 1) 規劃必須基于改善的項目知識而不斷調整,2) 您的計劃只能跟您當前擁有的信息深度一樣詳細。敏捷治理提供了 “現場的真相”,您應該準備至少在每次迭代后進行調整,但常常會每星期或者甚至每天進行調整。您在工作的過程中將了解更多信息,而且該信息應該反饋回您的 計劃。

我還建議采取一種兩級的動態規劃方法。第一級是一個總體規劃,主要基于為 4 至 6 星期所計劃的一組迭代,每次迭代包含構建版本和在該構建版本上的直接測試。第二級是用于每個迭代的更詳細的規劃,或者這個月到一個半月內的進展情況的描 述。在每個迭代結束時,您回顧已完成的工作并將其與計劃進行對比。如果存在差異(也就是說,如果結果與計劃沒有準確匹配),那么返回調整計劃以反映事實。

技巧 3:測試驅動的開發

從完成的軟件中消除缺陷需要大量的工作,可能需要很高成本。事實上,研究已經表明,60% 的軟件開發工作通常都花在測試和消除缺陷上。最好一開始就避免在產品中引入缺陷。為此,可以采用測試驅動的開發。采用測試驅動的開發,您可以不斷地對軟件 進行編寫和測試。您使用 20 - 60 分鐘的微型周期,而且使用微型周期的一半時間來編寫代碼,另一半時間用于執行測試,以證明它有效。您所實施的項目類型決定了您的微型周期。例如,在我曾經 研究的一個航天器項目中,微型周期平均時長為 20 分鐘。結果得到的是質量高得多且缺陷少得多的代碼,減少了在項目結束時測試項目的成本。

另一個敏捷最佳實踐是使用持續集成 將團隊的工作集中起來,通過使用所有組件的功能流證明集成的正確性。持續集成通常在整個項目上每日執行一次,但一些組織每星期執行一次。一般而言,您發現 缺陷或集成問題越早,解決它們的成本就越低、工作就越輕松。在項目結束時,將沒有出現任何集成問題,這些都是傳統軟件開發方法將分開開發的軟件各部分集成 時經常會出現的問題。所以,缺陷的避免總比(事后)缺陷修復更好。

技巧 4:增量式開發

任務關鍵型系統的項目在本質上是困難和復雜的。因此,執行這些項目的最佳方式與我們解決所遇到的大項目時所采用的方式相同:將它們分解為更小的部分。將您的系統構建為一系列迭代(“沖刺”),每個迭代持續 4 - 6 星期。

每個迭代應該有一個任務陳述。目的在于履行其任務,它的任務主要專注于要實現的需求(通常通過用戶案例或使用案例來采集),但也包括要支持的平臺、要包含的架構概念、要緩解的風險和要修復的現有缺陷。驗證和校驗測試在每次迭代結束時執行。

對于我的項目,我們還在每個迭代結束時有一個 “聚會階段”。一些人將此稱為事后檢查,但我將它作為對持續成功的慶功會,而不是確定故障問題的事后分析。我會查看任務陳述,確定我們滿足該陳述的程度, 尋找改善該流程的方式。我們總是會問我們還能如何做得更好、更快、更有效?

技巧 5:動態風險管理

風險是您在一個項目中不知道的所有事物。在我參與的 300 多個項目的經驗中,忽略風險是任務關鍵型系統項目故障的首要原因。許多組織很少執行任何類型的風險規劃,而曾經創建過風險計劃的組織,從來沒有回頭查看 它。這是針對災難的一個處方。您在構建任務關鍵型系統時,必須關注風險。因此,您應該使用動態風險管理計劃(也稱為風險列表)來管理風險并頻繁地更新它。

在風險列表或風險計劃中,您會發現風險是一個兩個值的函數,即您想要避免的成果的嚴重性和發生這一成果的幾率。這兩個值(嚴重性和幾率)是對您可能 跟蹤的風險的定量測量。然后您再執行風險緩解活動,也稱為 “spike”,這是一些減少風險的計劃活動。因為不是所有風險都足夠嚴重或能保證贏得特殊關注,風險緩解活動僅為超過一個閾值級別的風險而創建。當風險 足夠高時,就會規劃一個風險緩解活動,它會變成一個計劃的活動。

結束語

當恰當應用于任務關鍵型任務的開發時,敏捷方法可幫助避免高成本的故障。敏捷方法還可以提高這些系統的品質,減少應用它們所需的工作。敏捷方法將注 意力放在風險上,如果忽略了風險,它們會成為故障的首要原因;敏捷方法還消除了同樣會導致故障的靜態、沖擊式規劃。盡管工具不像方法那么重要,但 IBM Rational 軟件工具(比如 Rational Team Concert、Rational DOORS、Rational Rhapsody、Rational Quality Manager 等)以及 Jazz 有助于帶來減少易于出錯的流程,并改進規劃所需的自動化和透明性。結合敏捷最佳實踐,比如 Harmony 流程中的最佳實踐,您會獲得一個必將取得成功的開發組合。

文/IBM developerWorks

 本文由用戶 openkk 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!