管理篇：敏捷開發
聲明：謹以此篇獻給我的領路人王昊老師以及和我並肩作戰的小伙伴! 該篇所列的觀點不是原創，只是將自己十年敏捷實踐進行了總結。
什么是敏捷？是不是項目管理遵循Scrum就是敏捷，或者說團隊沒采用Scrum就不是敏捷？敏捷是一種工作方式，是一種思想，是小步快速前進。敏捷不是讓你走得更快，而是讓你走得更穩。敏捷不是保證你一定成功，而是在你失敗時你的損失最小。敏捷增強了開發過程中的可視性，這種可視是及時、直觀的。
任務管理
任務分解
任務分解的方向是縱向不是橫向，采用流水線的工作方式，任務要具有可驗收的特性（即完成度可視）。任務必須估計完成時間，任務的粒度要盡可能的細，最大不能超過1-2天，最好是2個小時。太大了驗證周期太長，大任務極有可能是需求理解不准確。當然過小的任務，會給管理添點麻煩。
任務的管理采用看板和燃盡圖，看板讓任務狀態可視，燃盡圖是讓任務的完成趨勢可視。
任務分配的方式是認領，認領后的任務不是個人的，而是團隊的。認領任務是表示認領人對這個任務負責，並不要求認領人要獨立完成這個任務。
法則1. 優先認領，優先級高的任務，必須最早完成；
法則2. 盡早集成，如果提交的代碼讓CI Build失敗超過4個小時，要被懲罰（當時懲罰不是目的，是為了讓你注意這個問題）。
既然這樣，那有成員就會想，沒做完我就不提交了；你想多了，我們還有一個法則。
法則3. 不留代碼過夜，所有的代碼收工前必須提交到CI，否則你只能刪除代碼。
法則4. 集中精力完成一個，一次只能領一個，即只能有一個正在進行的任務，一個人只有一個任務在進行中，甚至一個團隊也只能有一個任務在進行中，當然沒事可做的人除外。
法則5. 及時終止延期，當任務完成的時候超過了預估時間時，請及時中止你的任務。首先請重新確認你對任務的理解，將你的任務再次分解。然后可以試用以下兩個方法：
方法一，將你之前所寫的代碼全部刪除，重新再來，不要害怕刪除；
方法二，在你的團隊尋求技術幫助。
很多人在任務延期時往往會給自己一個預期，也許再多15分鍾就可以做完了，如果真的完成了，那皆大歡喜。但15分鍾如果沒有完成，請及時放棄。因為我們通常發現，這個延期可能會超出你的想象。
說明：這里的任務是泛義的概念，沒有嚴格對應敏捷的Task。
個人任務管理：四象限法則+番茄工作法
我們通常要同時處理多項任務，很多人可以多線程處理，但並不是所有的任務都適合多線程運行（比如開發，開發時被中斷將嚴重影響開發效率）。
神器一：多任務模式下，先用四象限法則（緊急、不緊急、重要、不重要）排列任務優先級，按優先級來完成，優先級要及時進行調整。如果你的任務都是按天計划的，那就沒有意義了，所以我們還要結合神器二。
神器二：將任務按“番茄時間”進行分解並執行，用醒目的標志宣告你在閉關修煉，任何人不許打擾。
番茄工作法：選擇一個待完成的任務，將番茄時間設為25分鍾，專注工作，中途不允許做任何與該任務無關的事，直到番茄時鍾響起，然后在紙上畫一個X短暫休息一下（5分鍾就行），每4個番茄時段多休息一會兒。
會議
會議有毒，世界上最可恨的打擾莫過於開會，而且會議會自我繁殖（一次會議總能引出下一次會議）。對於會議我們可以問幾個問題，這個會議是否一定要開，這個會議是否一定要在這個時間開，這個會議的所有議程是否一定要，參會人員是否一定要這些？
法則1：給會議定個鬧鍾，鬧鍾響起時，散會！
法則2：終止討論，討論通常是無休止，先給出一個初步方案，有意見可以在會后再找時間交流。
法則3：不輕易說不，當你決定對別人的方案和意見說不，你得要提出一個新的解決方案，否則你沒有說不的權利。
計划會議
計划的目標是確定下一個階段要演示的內容，計划的時長一般是1-2周。計划即瞎猜，計划的周期越長，偏差可能就越大。所以我們應該縮短計划的周期，明確要完成的任務，哪些人參與，每個人的參與度如何？計算每個人的有效工作時間，有效工作時間不等於8小時，請將事務性工作從有效工作時間中排除，如：填寫報賬單，學習等。計算團隊兼職人員的投入工作時間，這些人往往有多項任務在進行。
法則1：及時調整計划，盲目遵循不切實際的計划比無計划更可怕。計划是為了讓我們看見實際開發與計划發生了多少在偏差，不是要求我們一定要按計划執行。
法則2：不要計划加班，在你的計划中不要有加班，你的加班肯定會比計划多。
每日例會
會議的主要任務是評估任務的昨天的任務是否有問題，今天的任務有什么建議。所在會議有如下特征：
會議時間短，控制在15分鍾之內；
會議地點應設在任務牆前或看板前；
每個人回答三句話：昨天做了什么，今天要做什么，有什么問題（是否需要協助）
法則1：會議是站着開，哪怕是遠程，當你想坐下的時候，就要考慮結束會議；
法則2：昨天做的要和今天做的不一樣，如果是同一個任務也要明確區分。
評審會
演示可以工作的軟件，盡量讓客戶和所有項目成員都參加。讓客戶盡早看到並使用軟件，解答客戶的問題，盡早發現需求偏差；讓所有成員都看到自己成果，更好的激勵團隊。（當前如果你的任務沒完成的話，可能就是鞭策了。）
回顧會議
回顧會議以輪流發言方式進行，每個人都要發言，總結上一次sprint中遇到的問題、改進和大家分享討論。同時對問題列優先級清單，討論哪一些我們應該在下一個Sprint解決。這里的討論主要是針對開發方式，對軟件開發的效率產生影響，例如：可以是技術分享。這些問題和軟件的Bug一樣重要，甚至更重要。
法則1：拒絕“臣附議”，每個人都必須發言，而且后一個發言人不能重復前面發言人的內容。（你會發現開會的效率瞬間提高）。
法則2：驗收上次回顧會議的改進清單，分析未完成原因，加入到當前問題清單中重新排優先級。
技術分享
技術分享特權，可以在團隊內部申請10分鍾的站立技術分享會，但最好將分享資料提前發給大家，會議可以選擇在晨會后進行，因為大家已經在會場了。
......未完待續......