1.1 傳統瀑布式的工作方式
? ? 有太多的項目面臨這樣的困境：進度落后，預算超標，質量低下，甚至最終成果不是客戶想要的產品。造成這樣的困境，并非因為相關人員不聰明，不是因為用錯了技術，也不是因為缺少職業道德或外部競爭。
? ? 1.1.1 問題出在工作方式上。我們在投標前先坐下來審視所有的需求，然后開始規劃如何開發一套能滿足所有需求的系統。我們擁有很多才華橫溢的員工，他們連續幾個月去規劃要做哪些事情，繪制出很多美觀的圖片，解釋每一件必須要做的事，以環環相扣的方式展示整個項目的各個部分，即甘特圖。隨著產品復雜程度越來越高，甘特圖甚至變成了一種藝術品，整個項目中的每一個步驟，每一個里程碑以及日期都詳細地列了出來。這種圖的確令人印象深刻，多方統一后，我們開始跟隨甘特圖進行工作。可惜這種圖唯一的問題就在于，它們往往是錯誤的，無法真正得到落實。艾森豪威爾將軍曾說“戰斗規劃是很重要的，可一旦第一槍打響后，你的規劃就會煙消云散”。
? ? 1.1.2 有時報告本身的重要性甚至超越了事實的重要性。
? ? 1.1.3 如果報告與現實情況有差別，人們普遍認為問題出在現實上，而圖表是正確的。
? ? 1.1.4 瀑布式的工作方式，通過大量文件和圖表，希望實現項目管理的兩個目標：可控性和可預測性。這種美好的設想往往不會變成現實。雖然付出了大量努力去規劃細節，限制潛在變化，并預測未知因素，但試圖把人類行為限制在圖形和曲線里，本身就是一種愚蠢的做法。每一個項目都需要人們去發現新問題，激發自己的靈感。
1.2 一種新思維Scrum
? ? 1.2.1 Scrum，是敏捷開發流程，源于橄欖球運動的術語，原意是團隊通力合作，在場地內傳球。這個過程需要認真配合，信念一致和目標明確。究其本質而言，Scrum方法很簡單，即檢查與調整循環：無論什么時候啟動一個項目，為什么不經常檢查自己正在做的事情，是否朝著正確的方向前進？結果是不是大家希望看到的？是否有辦法改善目標正在做的事情？如何才能做的更好？存在哪些潛在障礙？（從我目前的認知來看，敏捷開發很類似《快速軟件開發》中描述的“漸進交付”和“螺旋形生命期”的配合。漸進交付的優點是通過每次迭代得到實時反饋，再在下一個交付期里調整和融合反饋意見，類似敏捷里說的沖刺和回顧；螺旋形生命期則是基于風險降低的考慮，類似敏捷里說的障礙。）
? ? 1.2.2 敏捷軟件開發的價值：人勝過流程，可用的產品勝過面面俱到的文件，客戶合作勝過合同談判，應對變化勝過遵循計劃。
? ? 1.2.3 基本流程(可類比PMP)
? ? ? ? 1.2.3.1 列出需求
? ? ? ? ? ? 可以采用用戶故事的方式。
? ? ? ? 1.2.3.2 確定需求的優先順序
? ? ? ? ? ? 謹記28原則。這一步比我們想象的更加困難，也更加重要。因為通常人們會說每一個需求都重要。這時你需要問自己，究竟哪些任務能給整個項目帶來最大的價值。
? ? ? ? 1.2.3.3 明確和消除障礙
? ? ? ? 1.2.3.4 設計沖刺周期
? ? ? ? ? ? 確保每一次迭代都可以產出可以交付的產品。周期內的任務必須在規定期限內完成。
? ? ? ? 1.2.3.5 沖刺Sprint
? ? ? ? ? ? 沖刺結束的同時，展示給關心成果的人審閱并獲取反饋。在沖刺時，明確每個任務只有兩個狀態：完成和未完成。
? ? ? ? 1.2.3.6 回顧
? ? ? ? ? ? 在每一個沖刺結束之前，還要聚在一起開個評估會，給產品負責人演示取得的成果，并接受評估意見。他們會評估列表上的任務完成了多少，是領取了太多任務還是領取得太少，這樣大家對速度會有一個基本的認知。在評估成果時，不只是討論過去做了什么，還會思考以下問題：接下來的沖刺如何更好的合作？上階段出現了什么障礙？哪些障礙拖累了工作進度？
? ? 1.2.3 Scrum的強大之處，在于展示，即定期展示成果。
1.3 本章要點
? ? 1.3.1 規劃是有用的，但盲目遵循規劃則是愚蠢的。
? ? 1.3.2 檢查與調整
? ? ? ? 每過一小段時間就停一停手里的工作，檢查已經完成了哪些任務，看看有沒有更好的方法。
