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