題記：老大開始在團隊推行敏捷。記錄目前自己理解的優點，還有敏捷不適應問題。
一、自己理解的敏捷
1.風險分散。這點，我是非常肯定的。親身的體會，jim負責A模塊，以前做法：項目經理pety，在A模塊快提交的前期去和jim溝通模塊的完成情況。現在做法：每天jim向prty匯報自己的進度情況和問題。幫助pety對項目的可控性提高很多，風險也能盡早的暴露出來。帶來的問題：必須對A模塊進行更細的任務分解，如何分解？時間如何評估？誰來評估？（團隊做法：由jim自己細分A模塊，再與pety確認計劃，此時pety可以給出自己的意見，共同來評估時間。）
2.可視化。同意這點。之前做法：每天發郵件周知大家進度情況；團隊目前做法：看板（貼每個人具體細分的任務），每天匯報具體的進度和遇到的問題。其實兩種做法的目的是一樣，都是想讓別人知道自己的進度和問題。但第二種方法優點：a.閱讀郵件，是每個人獨立的行為，是分散的，看板上任務的匯報是大家在一起的，此時面對面的溝通是更高效的；b.對于我的感覺，看板比郵件更加可視化；c.基于看板，后期的后顧和總結也更加方便。
3.團隊化。jim負責A模塊，jeny負責B模塊，當A模塊jim可能存在跟多問題（前期沒有評估到），希望jeny可以幫jim完成其中的部分。問題：jeny根本不熟悉A模塊，熟悉A模塊所花費的時間，以及對B模塊的影響，都是需要評估的。自己的理解：對于多人同時開發的項目，此方法還是可以試用的；但是對于單兵作戰的日常，大家的精力都是有限的，很難說A做大一半的時候，讓B來幫忙。這也是目前大家爭論的焦點。
二、團隊目前的做法
1.細粒度的任務分解。比如：搜索頁面智能導航，分解的任務：a.了解接口需要的參數，以及返回的結果的格式 b.請求參數處理 c.返回xml結果解析 d.后期根據業務邏輯的處理。整個任務肢解的力度非常細，對項目風險的把控更加有好處。
2.看板。分為：任務、開發中、done（三部分）。根據每天大家反饋的情況，更新項目剩余需要的工時（細粒度到時間）。
3.晨會。早晨站在看板前，每個對著看板，說自己“昨天干了什么&是否遇到什么問題、今天準備做什么”，對應的調整看板的內容和任務所需時間。
4.總結。這點目前做的不夠好，不是大家都來提建議，可能整個團隊還是“一個大腦”，只是一個人在想問題（當然這與團隊的氛圍是有關系的）。
三、難點
1.個人的積極性和參與度
敏捷是需要團隊的每個人都以主人公的態度參與進來的，當然團隊也要能夠給予他認同，這是軟實力的問題；比如：相互提建議，但是這首先需要團隊安全的環境，對老大說的話，大家可以提出不同的意見，否則始終是“一個腦袋”在思考，大家習慣于去服從；同時也要克服養成的“中庸之道”，當然也要注意提建議的方式。
2.任務的細分和工時的評估
需要項目經理對團隊成員有很熟悉的了解，才能合理的安排任務。根據不同的人確定不同的工時，大家都能在一種被尊重和快樂的氛圍中工作，此時的效率肯定是高。
3.團隊的成就感
需要自下而上的，獲得的成就是每一個人的，而不是簡單是他的或者我的。每個人都能找到被認同的感覺，樂于分享自己的收獲，此時整個團隊的每個人都會成長，團隊的戰斗力肯定也會大大提高。
總結：發現難點的地方，還是團隊軟實力的建設。