沒有任何計畫在遇敵後還能繼續執行。helmuth von moltke曾說過：「沒有任何計畫在遇敵後還能繼續執行。」我們的敵人不是客戶，不是使用者，不是隊友，也不是管理者。真正的敵人是變化。軟體開發如戰爭，形勢的變化快速而又劇烈。固守昨天的計畫而無視環境的變化會帶來災難。你不可能「戰勝」變化——無論它是設計、架構還是你對需求的理解。敏捷——成功的軟體開發方法——取決於你識別和適應變化的能力。只有這樣才有可能在預算之內及時完成開發，建立真正符合使用者需求的系統。——helmuth von moltke（ 德國陸軍元帥，1848—1916）
業務應用需要開發者和業務負責人互相配合來開發。這種配合的感覺就應像一種良好的、誠實的工作關係。
好的設計應該是正確的，而不是精確的。也就是說，它描述的一切必須是正確的，不應該涉及不確定或者可能會發生變化的細節。它是目標，不是具體的處方。
對於新技術， 需要考慮以下問題：
新技術就應該像是新的工具，可以幫助你更好地工作，它自己不應該成為你的工作。
乙個簡單的工作流程，可以防止你提交破壞系統的**:
你會覺得，不管什麼時候，你的老闆、董事長、質量保障人員、客戶或者你的配偶來公司參觀專案的時候，你都能很自信並毫不猶豫地給他們演示最新構建的軟體。你的專案一直處於可以執行的穩定狀態。
如果你真正做對了，整合就不再會是乙個繁重的任務。它只是編寫**週期中的一部分。整合時產生的問題，都會是小問題並且容易解決。這些工作都應該是無形的。系統的安裝或者部署應該簡單、可靠及可重複。一切都很自然。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-450ganhh-1600072271188)(img/image-20200309122548282.png)]
專案啟動了一段時間之後，你應該進入一種舒適的狀態，團隊和客戶建立了一種健康的富有創造性的關係。
突發事件應極少發生。客戶應該能感覺到，他們可以在一定程度上控制專案的方向。
短迭代讓人感覺非常專注且具效率。你能看到乙個實際並且確切的目標。嚴格的最終期限迫使你做出一些艱難的決策，沒有遺留下長期懸而未決的問題。
你的評估資料會在整個專案中發生變化——它們不是固定的。但是，你會覺得自信心在不斷增加，你會越來越清楚每個迭代可以完成的工作。隨著時間的推移，你的評估能力會不斷地提高。
第4章 持續交付2 0的組織文化
持續交付2.0 強調 持續學習 和 快速驗證 而探索必然會伴隨著失敗，失敗會令人產生挫敗感和不安全感。而學習與成長也通常法神在失敗之後。這就要求組織必須建立 安全 信任與持續改善 的組織文化 第一步 定義想要做的事情 第二步 定義期望的做事方法 第三步 提供相應的培訓 第四步 做些必要的事情來強化那...
《持續交付》筆記 第4章 測試策略的實現
測試是跨職能部門的活動，是整個團隊的責任，應該從專案一開始就一直做測試。摘自本書 支援開發過程的 評判專案的 業務導向的 測試驗收測試 自動的 演示易用性測試 探索性測試 手工的 技術導向的 單元測試 整合測試 系統測試 自動的 非功能驗收測試 包括容量測試 安全性測試等 手工的 自動的 自動化驗收...
讀書筆記 軟體測試的藝術第2章
對於測試，更為合適的定義應該是 測試是為發現錯誤而執行程式的過程 黑盒測試 又稱為資料驅動的測試或輸入 輸出驅動的測試 是一種重要的測試策略。在這種方法中，測試資料完全 於軟體規範 不需要去了解程式的內部結構 如果想通過黑盒測試發現程式的所有錯誤，判定的標準是 窮舉輸入測試 但是基於多方面考慮，窮舉...