Build to Win

　　——手邊無書，卻欲成此讀書筆記，僅憑記憶與經歷談談自己的感想

　　時隔數月，我仍清晰地記得《最後期限》裏面的一句話：人是經理所要解決的唯一重要的事情。（只可惜我很難想起《構建之法》中有很經典的語句，大概是幹貨太多就難以有所註重吧）

　　這是兩本相輔相成的書——《最後期限》闡述如何解決人的問題，避而不談構建方法，而《構建之法》則是一本厚厚的方法手冊，對人事問題又談及甚少。這兩本書引領著我走入團隊合作的世界，而想起過往在電子設計實踐中的小打小鬧，才發現要讓一個大的團隊緊密合作，任重而道遠。

　　1、管理人的藝術

　　　　在最初的兩個月裏，我就像是瘋了一般，每天加班加點地閱讀有關團隊項目的各種書籍，因為我一想到就要在三個多月後交付自己的作品，而自己對這個領域一無所知，就感到深深地恐慌。我以為隊友們都是抱著這樣的心態，時不時還能看見他們在群裏討論幾句，就沒有過問每一個人的投入與進度。實際上，這是很錯誤的，直到真正開始開發的時候，我才發現自己已經翻閱了接近十本書，而大部分組員閱讀量還不到半本書。如果從開發的一開始就使用《構建之法》中提到的燃盡圖，那麽我想情況將會好很多，當然另外就是我沒有用心去督促團隊裏面的成員，事實上這也是一門藝術，《最》也著重強調過。

　　2、燃盡圖

　　　　敏捷開發流程中燃盡圖是必不可少的，雖然《最》中的主人公看不起這些工具，認為解決好雇傭人的問題就足夠了，然而至少對於我這類新手，這種工具用起來真是得心應手。每一天都要求組員匯報進度、耗時，每半周公告未完成任務、completed hours、 projected remaining hours， 這樣團隊的進度一目了然，再加上目前我對項目開發所需要的技術、所要走的流程都有了較深的認識（得益於之前的學習），這樣就能很及時地發現沒有完成任務的同學，雖然無法開除組員，但能及時將人物分配給其他組員，規避風險。我認為一個優秀的項目經理，掌握大致的底層知識也是必須的，在目前我也擔任類似技術總監的工作，安排每個人的學習任務、編程任務並且指導他們查錯，雖然這與初衷相背離，但我能感受到掌握所有知識的好處——組員無法再用你不懂的借口糊弄你。

　　3、管理項目的思考

　　　　在《構》敏捷開發一章接近最後的部分，提出了如何管理項目代碼的問題，我也有過切身體會：

　　　　1）源代碼控制系統——如何控制簽入、簽出？　　為了避免沖突，需要統計每個人每周有空的時間（因為課程有所不同），盡量按照分組安排修改的時間以避免沖突、每次安排相關性盡量小的任務，實在有沖突需要及時向有關聯的小組聯系。因為沒有用團隊項目管理工具，所以我們主要通過交流的形式進行管理。

　　　　2）如何看到修改與之前版本的差異？　　　　　這是讓我仍然很困惑的地方，github貌似只能回溯版本，而要一覽差異卻不像是個簡單的工作。所以我讓組員們將每一次的修改都匯報給我，而我進行管理、追蹤。　　　

　　　　3）如何合並不同的修改？　　　　　　　　　　這就需要參與者的面對面溝通，所以在敏捷開發中，頻繁地溝通是很有必要的，《最》一書中談到了交流所帶來的效率損耗也是很明顯的，因為每一個人就像是圖上的每一個節點，隨著人數的增長，交流幾乎是平　　　　　　　　　　方增長的，這也是為什麽小團隊容易創造奇跡的一個原因。

第10次讀書筆記