敏捷文檔：平衡速度和知識保留

與其生成相關的各種文檔、工件和過程是瀑布模型的一些主要符號。 借用精益，敏捷將大量文檔視為需要根除的“浪費”，以簡化開發生命週期。

對於許多項目經理來說，理解瀑布階段如何轉變為衝刺並不是一件容易的事——完成了同樣的工作； 它只是以不同的方式組織。 然而，刪除大多數文檔是一種難以下嚥的藥丸，因為它強調了一種完全不同的工作方式。 它需要放鬆控制的韁繩，擁抱未知，並授權交付團隊當場做出決定。

傳統的文檔記錄方法正在受到挑戰

在瀑布方法中，大量時間用於記錄項目需求和詳細說明解決方案。 當需求完全明確並且我們確信捕獲和基線化的內容不會發生任何變化時，此過程才有效。 然而，大多數公司在過去幾十年的經驗表明，這幾乎不是真的。 在當今世界，變化的速度如此之快，以至於當我們完成文檔階段時，客戶的需求發生了很大變化。

敏捷的重點是完成工作並為利益相關者增加價值。 它的構建方式是，該模型不鼓勵在外圍設備和不會直接和立即為客戶增加價值的活動上工作。

瀑布與敏捷中的文檔

每家公司都有不同級別的文檔，即使在項目級別上也可能有所不同。 但這是瀑布和敏捷項目中典型的文檔程序的樣子：

文檔案例

Waterfall 提倡對文檔採取更嚴格的方法，這似乎有些過分。 但在我們將其視為“浪費”之前，有幾個好處是擁有強大的文檔程序。

戰略思維的機會

那些沒有計劃的人，計劃失敗。 文檔迫使項目經理坐下來思考問題，然後提出最佳解決方案。 人們有時會誤解工作軟件相對於綜合文檔的敏捷價值意味著不需要文檔。 然後他們沖向市場，對講機產品副總裁 Paul Adams 將這一舉動描述為向牆上扔東西，看看有什麼東西能粘住。 設計解決方案、制定計劃、考慮行動——這些活動通過節省時間來創造價值，而不是開發想到的每一個功能想法。

用戶體驗和功能一致性

隨著公司從幾個創始人發展到成百上千名員工，許多不同的團隊開始研究相同或相關的產品。 團隊 A 可能認為他們正在做的事情與團隊 B 正在做的事情無關，但對於最終用戶來說，它們都是同一個產品。 與跨職能團隊做自己的事情不同，關於用戶體驗和功能級別的清晰文檔可以避免脫節的用戶流程。

文檔可以轉換為用戶指南

在 Waterfall 中，大量時間用於詳細說明解決方案以及如何使用它們。 為前端開發人員創建高保真設計圖片。 與從頭開始創建它們相比，所有這些資產轉換為內部或外部用戶指南所需的工作更少。

敏捷如何減少文檔需求

反復出現作為強製文件的藉口的一個因素是員工流動率。 當人們離開並有新人加入以取代他們時，經理們擔心會失去機構知識。 他們如何知道已經實施了什麼以及它是如何工作的？ 他們需要多長時間才能趕上？ 當前團隊是否有足夠的帶寬來接待新的團隊成員？

希望好的文檔能讓大部分獨立工作的新員工快速上手。 然而，敏捷本質上通過協作技術減少了對文檔的需求，同時減少了入職時間。 以下是敏捷減少文檔需求的幾種方法。

產品團隊和敏捷團隊成員之間的定期互動

敏捷宣言提倡“個人和互動優於流程和工具”。 由於需求在項目期間往往會發生變化並且會出現新的想法，因此敏捷確保直接從源頭澄清需求，而不是依賴於需要不斷更新的書面工件。

梳理和計划划分任務

待辦事項梳理和衝刺計劃將功能分解為易於理解且可以獨立工作的具體、可實施的部分。 這為新員工創造了一個機會，讓他們能夠在早期提高工作效率，同時還沒有完全了解整個項目的大局。

用戶故事提供有效的文檔

用戶故事的簡單格式允許項目經理捕捉最低限度的要求，從而在所有團隊成員之間建立共同的理解。 即使用戶故事沒有進入 sprint，創建此文檔工件的浪費也非常低。 隨著用戶故事進入 sprint，它們可以被充實並補充其他所需的信息，例如線框、設計、驗收標準等。這個過程提供了非常有效的文檔交付，它是高度一次性的，並且在最合適的開發階段生成。

減少對代碼文檔的需求

結對編程和代碼審查等技術為在整個團隊中傳播技術知識創造了持續的機會，尤其是向新的團隊成員。 不斷的反饋導致了共同的理解，這種理解也具有適應新環境的靈活性，而不是在某個地方的文檔中很快變得過時。

敏捷儀式

每日站會、衝刺評審和回顧會創造大量機會來解決問題並面對面做出決策，而不是依賴電子郵件和文檔。 所有儀式的有限時間範圍確保只有最重要的信息被優先考慮，而不是花時間記錄一切，即使它可能永遠不會被使用。

以上所有直接或間接地減少了文檔並優先考慮項目目標的交付，同時確保沒有任何東西因缺乏文檔而真正丟失。

文檔的混合方法

一些公司仍然喜歡有一些文檔，即使在敏捷環境中也是如此。 敏捷不是規定性的，因為每個項目都是不同的，並且有一組獨特的情況需要解決。

下面是一些示例，說明如何將敏捷與更耗時的文檔方法相結合。

結合 UML 和敏捷

考慮使用標準建模語言，例如統一建模語言 (UML)，這種語言非常結構化並定義了實體來可視化系統。 這有助於保持內容非常簡單並專注於需要的內容，並確保最少使用書面語言。 StarUML 和 Draw.io 等工具都是方便的選擇。

代碼文檔生成器

另一種方法是通過在類細節、方法細節、參數使用、依賴關係等中引入更多結構化和詳細的註釋來確保代碼更具可讀性。 有許多工具可以自動化從源代碼生成有用文檔的過程，它們被稱為文檔生成器。 它們的範圍從通用到特定於編程語言的。

詳細設計和用戶體驗文檔

使用線框圖、模型、用戶流程圖、序列圖等定義需求有助於簡化項目流程，並使技術團隊清楚地了解需要開發的內容。 設計文檔是擁有不同級別的更嚴格文檔的好方法。 這些任務有多種線框圖和 UX 工具可供選擇。

項目管理工具 自動化文檔

更強大的項目管理和相關工具（如 JIRA、Confluence、Asana 和 Basecamp）提供了一種將所有項目相關信息保存在一個地方的方法。 任務可以鏈接、標記、嵌套和分配給不同的團隊成員，然後他們可以發表評論並報告任何問題。 所有這些操作，以及適應這些工具的靈活性，可以輕鬆創建大量文檔。

此外，從歷史上看，部分文檔需求源於報告要求。 利益相關者希望獲得團隊績效或其他相關指標。 項目管理工具可以輕鬆實現自定義儀表板和視圖的自動化，這些儀表板和視圖反映了項目進度並鏈接回工具內的相關文檔。

文檔管理是一種平衡行為

敏捷宣言的創建者寫道，他們重視“工作軟件勝過全面的文檔”。 然而，他們還添加了一項免責聲明，“雖然右邊的項目有價值，但 [他們] 更重視左邊的項目。” 敏捷並不建議刪除所有文檔，因為某些文檔顯然提供了價值； 它只是建議優先考慮工作軟件，並根據項目情況僅在必要時添加文檔，並且不會嚴重阻礙開發進度。

項目經理必須在花更少的時間在文檔上和花更多的時間在交付工作軟件和實際找出某種形式的文檔對於長期成功所必需的地方之間取得平衡。