2020-7-20 無瑕的程式碼 : 敏捷完成篇

[hsiaofung]

敏捷聯盟

個人與互動重於程序與工具

• 如果想要取得專案的成功，我們必須建構的是"具有合作精神、具備自我組織能力的團隊"。鼓勵建構這種團隊的公司，比起那些認為"軟體發展組織只不過是由無關緊要、類似的一群人推砌起來"的公司來說，具備了更巨大的競爭力。具有凝聚力的軟體團隊是最強大的軟體開發力量。
• 建構團隊要比建構環境重要許多。先建構團隊，接著讓團隊基於需要來設置環境。

可用的軟體重於詳盡的文件

• 團隊應該撰寫人類容易讀懂的文件，文件中應該包含對系統及設計決策依據的描述。
• 巨大的文件很難維護和程式碼同步，文件會變成巨大的謊言，並且造成誤導。
• 維護一份不超過一二十頁的系統原理和結構方面的文件，該文件應該短小且能凸顯主題。
  • 凸顯主題 : 應該僅限於論述系統的最高層結構和概括的設計原理。
• 如果只有一份簡短的系統原理及結構的簡短文件，那該如何培訓新的團隊成員，使他們能夠從事系統的相關工作?
  • 我們應當緊密地和他們工作在一起。我們應該坐在他們旁邊，幫助他們，把我們的知識傳授給他們，透過頻繁的培訓和互動使他們成為團隊的一部分。
• 程式和團隊就是最好的文件
• 直到迫切需要且意義重大時，才撰寫文件。

與客戶合作重於合約談判

• 你不能期望將想要的東西告訴開發團隊，然後過一段時間，就能交付一個滿足需求的系統。
• 成功的專案需要定期且頻繁的客戶回饋。絕不是依賴合約或關於工作的那些陳述。
• 成功的關鍵是讓軟體的客戶和開發團隊緊密地工作在一起，並盡可能經常地提供回饋。
• 合約可能包含 : 需求、進度和成本。
• 合約可能早在專案結束之前就變得沒有意義。而好的合約應該要能為開發團隊和客戶協同工作提供指引。
• 每週五把軟體提交給客戶，而在下週一或二，客戶給一份軟體的變更清單，開發團隊把這些變更放在一起並排定先順序，然後將他們安排在隨後幾週的工作中。客戶一週又一週地觀察著每個功能區塊的演進，所以他們知道什麼時候這個功能區塊能滿足他們的需求.。
• 成功的關鍵 : 在於與客戶緊密協作，並且合約主宰此種協作模式，而不是試圖去規範專案範圍的細節和固定成本的進度。

回應變化重於遵循計畫

• 計畫不可考慮得過遠。

  • 因為商務環境可能會產生變化，而這會引起需求的變動。
  • 因為當客戶看到系統開運作，他們可能會改變需求。
  • 因為無法準確地估算出開發時間。

• 做計劃時，較好的策略是 : 為下一週做詳細的計畫。為下3個月做粗略的計畫，再往後就只做極為簡略的計畫。

• 應該清楚知道下周要完成的任務，粗略了解之後3個月要實現的需求。至於系統一年後要做什麼，只需要有一個模糊的想法

• 計畫中這種逐漸降低的細緻度，意味著我們僅僅對於迫切的任務，才花時間進行詳盡的計畫。

• 一旦制定了這個詳盡的計畫，就很難進行改變，因為團隊會根據這個計畫啟動工作並投入相對的動能，然而計畫僅僅支配一週的時間，所以計畫的其餘部分仍可持續保持靈活性。

原則

[hsiaofung]

設計原則

• 這些原則只是為了去除臭味。當沒有臭味，就不用這些原則。
• 僅僅因為是一個原則就無條件遵循是錯誤的。這些原則只是為了幫助我們去除一些壞味道。而不是可以隨意在系統中處處噴灑的香水。過分遵循這些原則會導致"不必要的複雜性"設計臭味。