簡介
本原則係表明為專案需求訂製合身的開發流程之重要性。多一點不好,少一點也不好,最好的是,專案的作法、精準度及控制,必須依據各項因素量身訂作,這些因素包括團隊規模及分工、外部設限的程度,以及專案所處的階段。
|
|
好處
|
-
生命週期有效性
-
較高的專案靈活度
-
合乎實際的計劃與評定
|
型樣
|
-
訂製專案需求合身化流程包括:
-
專案團隊的規模與分工
-
應用程式複雜性
-
法令遵循必要性
-
因應生命週期階段調適流程作法
(當不確定性解除時,正式從輕量級展演成重量級)
-
提升流程連續性
-
因應不確定性的程度,維持計劃與預測的平衡
|
反型樣
|
-
最好不時檢討流程並盡可能事先做好周全的規劃:
-
及早進行預測,並遵循預測結果
-
擬定精準的計劃,並對照書面計劃進行專案追蹤管理
|
|
討論
流程多未必就好,也就是說不見得要用較多構件、製作較詳細的文件、開發並維護更多需要同步化的模型,或進行更多的正式審查。應該要訂製專案需求合身化流程。隨著專案規模逐漸壯大,分工也越來越細,使用到更多複雜技術,關係人眾多,且需要遵守更嚴格的法令標準,因此流程需要受到更多的規範。但是,對於並行配置團隊就已知技術所開發的小型專案而言,流程最好輕量化。
促成流程規範量之因素。
決定流程受規範程度的因素很多,包括專案大小、團隊分工、技術複雜性、關係人數多寡、法令遵循需求,以及專案所處的生命週期階段。
專案應當因應生命週期階段調適流程作法。儘管在專案之初總是會面臨許多不確定性,但我們必須積極發揮創造力,開發出能滿足商業需求的應用程式。流程繁雜通常只會降低而非提升創造力,因此,我們必須在視不確定性為家常便飯的專案初期階段,將流程最小化。
另一方面,到了專案後期,則需要加強控管,例如變更編制控管人力、防止不合適的創造力及相關風險,以免在產品開發的最後關頭產生缺陷,而成為流程繁雜化的肇因。
組織應致力於持續改善流程。 可考慮在每次反覆期之後及專案最終進行評估,以記取教訓,並藉此經驗改善流程。 鼓勵團隊全員持續尋求可能的改進機會。
最後一項重點是,在專案的不確定性與專案計劃及相關預測之間取得平衡。
也就是說,在專案初期,很多事情都還不確定時,計劃及相關預測應著眼於大局規劃及預測,而非追求高精準度,因為一切都尚未成氣候。早期的開發活動應鎖定在消除不確定性,逐漸提高規劃的精準度。
|