在五月末的時候，老師針對我們團隊的狀況提出了幾點建議和解決方案，而這半個月裡，我們嘗試性地運用了其中的幾件工具與方法。
我們採用的是《構建之法》書中的燃盡圖模型，通過 projected hours 與 remaining hours 觀察團隊的活躍度以及所能支配的時間。這一種模型不大適合我們的團隊，因為它甚至敏捷開發都是基於乙個有強大向心力的、能力都比較強的團隊而設計的，這顯然不適合像我們這樣臨時拼湊，不久便分道揚鑣而且水平參差不齊的團隊。不過我仍然學習到了很多東西，對於乙個優秀的團隊，燃盡圖是乙個不錯的工具，它能時刻提醒組員尤其是 pm 一周剩下的支配時間，再結合團隊專案的進度，便能對計畫完成的程度進行預估，並作出相應的調整。而每日總結則是激勵每乙個組員強有效的方式，每晚每人相繼匯報自己完成的工作，對於不做事情的成員是一種壓力；這也是進行績效評估的依據，在一週末的組會中公開考核成績的時候，滑水的成員也難以找到求分的藉口；這還是評估任務進展最有效的根據，當某乙個成員的進展落後時，稍微敏感一點的 pm 都能察覺得到。乙個很不錯的成果就是以前一直滑水的兩個隊友，終於開始參與團隊專案，大概在科大 gpa 是能讓鬼推磨的神器吧。
我們曾嘗試性地使用過這個工具。任務板的想法是不錯，我也能感受到它的魅力，但是並不適合我們現在的團隊。在實踐的時候，它能很明晰地展現出任務的流程，能體現出對團隊最重要的關鍵節點，還能體現出團隊專案的進展，想象這樣乙個場景，每乙個努力的員工在清晨、傍晚都看看團隊的任務板，那麼每個人都能知道團隊的進展，並督促自己完成最重要的任務。但是它湊效的前提是：成員都在乙個相對固定的地點。顯然，因為我們的成員是分散的，而即使是聚在一起程式設計的時候地點也是一直在變化的，任務板的魅力也因此大打折扣了。
以前我感覺用qq檔案管理的方式就挺不錯，每個人有一點進展，標註上修改的時間就可以發到群裡，這樣交流也很方便，不過 github 提供得更多。
分支管理——1）隨時都有可以發布的版本 2）自由地合作開發分支，避免了對主專案的衝突。
修改管理——提交時通過comment注釋修改的內容，一方面便於回溯，另一方面也能體現專案的進展
面對面的交流總能更快地解決問題和傳達思想。1）經常我在qq群裡強調了好幾遍的東西，隊員們也會忽略掉，大概是 qq 已經成為了吵雜的代名詞，大家都已經習慣了忽視這一台不停嗡嗡作響的機器。然而面對面的時候，我能根據每個隊員的反應，推測出他們是否真的get到我所要傳達的最重要的東西。2）每個人掌握的知識是不一樣的，在一起程式設計的時候，總能更快地解決問題，而不是一兩個人在一邊瞎忙活一下午還不敵另乙個人幾分鐘的指導。
面對面是敏捷開發的前提，敏捷也不是所有的團隊都試用，老師在考量推廣敏捷的時候應該謹慎它的前提條件。
軟工教給我了許多東西，尤其是團隊方面的，讓我深刻體會到建設乙個團隊的重要性，也學習到了其中的些許方法。雖然我以後很有可能不會進入程式猿的領域，但是管理團隊所積累下來的經驗以及管理專案所採用的工具能讓我終身受益。剩下時間所能學到的東西可能就比較少，不過就算是給自己的專案畫上乙個完美的句號了吧。
軟工 六月心得體會
本月著實匆忙至極，一方面各學科都臨近尾聲 加緊衝刺，另一方面考試周近在眼前。而軟工課毫不出人意外地又來了乙個所謂的 加速出成品 將alpha版產品截止日定在了6月20日左右，毫不怯於自己2學分的體量，理直氣壯地與各大主要學科爭搶寶貴的考試複習時間，可謂壯哉。當然，這麼做是有充分理論依據的 根據老師統...
英語總結 六月
在提高班學習了很多英語 兒童詞典 牛津詞典 羅塞塔 english class 從零開始學英語等等。但是對於我來說其實只有兒童詞典 english class 從零開始學英語是我有始有終的認真學下來的！除了這些之外的其他英語資料學習的效果和狀態都不是很好！大都是有認真的開始，卻沒有堅持下去的耐心和毅...
程式設計六月定律
上週，我被迫對乙個很老的專案做一些修改。麻煩是，當開始著手時，我真的記不清這個專案究竟有多老了。這實際上是我使用codeigniter實現的第乙個mvc專案。開啟專案檔案後，很多東西都讓我頭暈。首先，沒有版本控制，第二，沒有注釋。id iframe 0.719018345291395 src dat...