將軟體發展和管理正式化的建議

適用于此 Azure Well-Architected Framework 營運卓越檢查清單建議:

OE:03 將軟體概念和規劃程式正式化。 從已建立的產業和組織標準中繪製。 使用一般、已排定優先順序的待辦專案,以及足夠詳細的規格。 根據結果,推動規劃程式中的持續改善。

本指南說明根據已建立的標準管理軟體發展實務的建議。 您的小組能夠產生高品質的軟體,依賴結構化、共同作業的開發規劃方法。 產品擁有者和經理必須能夠清楚瞭解並表達給專案關係人,讓開發人員隨時在開發週期中執行的工作。 相反地,開發人員必須透過撰寫完善的功能、使用者劇本和接受準則,瞭解開發週期的目標。 已建立的標準會定義應如何執行開發做法,並允許工作負載小組有效地共同作業,降低目標與期望的混淆風險。

主要設計策略

將軟體發展做法正式化,以協助確保產品擁有者、專案經理和開發人員瞭解每個短期衝刺的目標,並將一致的品質傳遞給專案關係人。 若要檢閱開發實務的指引,請參閱 持續整合指南

開發規劃的標準

  • 共同作業:定義工作負載建議變更的程式應該是共同作業工作。 工作負載的大部分變更都會影響多個函式和/或元件,因此盡可能牽涉到多個工作負載小組成員,有助於確保不會遺漏重要的考慮,而且每個人都知道對其特定網域的影響。 共同作業也有助於清楚定義變更的範圍,以及如何將完成變更所需的必要工作分割成定義完善的工作專案,因為跨領域具有專業知識的較大群組將能夠為所需的工作提供體驗支援的估計值。

  • 工具:使用已建立、經過業界證明的工具和程式,例如 敏捷式、 Scrum工作流程看板。 開發您自己的工具和程式是一項重大的工作,需要花費時間和開發週期,否則可能會花費在您的工作負載上。 大部分有經驗的 DevOps 工程師和產品擁有者都熟悉這些類型的工具和程式,因此採用它們的學習曲線應該最少。 同樣地,新進員工的上執行緒序也會受益于使用標準工具和程式,因為它們可能已經暴露在相同的工具和流程中。

取捨:如果敏捷式方法過度規範,可能變得太嚴格。 致力於在定義完善的標準和創新之間取得平衡。

  • 部署:規劃經常使用小型反復部署,而不是大型不常部署。 使用此方法可協助從專案管理觀點管理使用者劇本和工作專案,並在部署失敗時降低大規模問題的風險。

  • 詞彙:將您的 已完成 開發週期的定義標準化,以協助確保順利完成支援的功能,包括測試、檔和協助工具功能。

  • 通訊:定義產品擁有者和專案經理的標準通訊協定,以在內部和外部升級即將推出的版本。 例如,您可以建立與外部合作物件有關即將發行之通訊的標準。 標準可能會指出應該在發行前兩周傳送通訊,並在發行前 24 小時傳送提醒。

  • 使用者劇本:標準化使用者劇本的範本。 請確定每個使用者故事都是從使用者的觀點撰寫的離散工作單位。 撰寫良好的使用者劇本應該具有下列特性:

    • 每個使用者故事應該完全獨立。 讓使用者劇本彼此獨立,可避免與重迭的工作混淆,並協助小組瞭解在特定使用者劇本上的工作是否依賴任何其他工作,這有助於排程和優先順序。

    • 每個使用者劇本都是一件件好事。 終端使用者和工作負載小組成員的觀點都是擷取可短時間內完成的實際使用者劇本不可或缺的。

    • 使用者劇本對使用者而言非常重要。 當您從終端使用者的觀點撰寫使用者劇本時,您會擷取他們感興趣的變更,並為其體驗增加價值。 當使用者故事細分為工作專案時,保持此焦點有助於確保每個部署都能提供更好的體驗。

    • 使用者劇本所需的心力是高度信賴度。 如果沒有能夠接近指定使用者劇本所需的時數,規劃將會很困難,而且遺漏期限的可能性會增加,而可能會導致對其他計畫工時造成串聯效果。

    • 撰寫良好的使用者劇本很小,因此可以在幾周內完成。 較小的範圍劇本可協助保持其可擷取且可管理,並協助讓工作專案保持可完成。

    • 使用者劇本應可測試。 若無法測試已傳遞功能,使用者就無法確信已達成目標。 即使尚未針對指定的使用者劇本撰寫測試,也應該清楚瞭解如何開發測試,以證明功能傳遞。

  • 接受準則:標準化接受準則的範本。 請確定驗收準則與使用者劇本特別相關,而且可以使用一或多個接受度測試明確證明。

  • 追蹤:確定開發程式可追蹤。 您應該清楚地追蹤生產工作負載的狀態,並將相關聯的程式碼回溯到品質保證測試、接受準則、使用者劇本和功能。 例如,在某些情況下,詳細追蹤也可能是法規需求,例如醫療保健。

  • 閱:透過開發週期回顧和事後檢閱定期執行開發實務的內部稽核。 程式反映應該是無責任的,而且應該專注于可套用為改進的學習。 請確定小組會反映使用者劇本和工作在定義必要工作和時間估計精確度方面的有效性。

  • 報告:標準化專案關係人的報告,這些報表提供著重于變更的實用計量。 專注于變更可讓您追蹤產品加速和減速。 有用的計量可以包含下列專案中的變更:

    • 採用的每月成長率。

    • 效能。

    • 定型時間。

    • 事件的頻率。

    報告不應用來作為評估個人工作的工具,因此請避免每個工程師的劇本點或程式程式碼等計量。

Azure 指導

Azure Boards是以 Web 為基礎的服務,可讓小組規劃、追蹤和討論整個開發程式的工作。 它非常適合敏捷式開發做法。

GitHub Projects 是可自訂的專案管理工具,可以使用 GitHub 中的問題和提取要求來組織專案並整合。

營運卓越檢查清單

請參閱一組完整的建議。