1） 回顧你的課程計劃 （第一周的計劃）， 你完成的程度如何？請列出具體數據和實際例子

　　在做第一周的計劃時，我對自己的能力評估如下：

　　通過在ASE課程的學習過程中，我自己設想要提高的幾個方面並沒有全部鍛煉到。在幾次團隊項目中，認為自己進步比較大的是編程的實現以及交流能力，

　　Programming: Implementation

　　在詞頻統計項目和對聯小程序項目中，我負責了一些函數的底層實現工作以及前端頁面的實現測試工作，編程能力得到了明顯提高。尤其在和項目隊友的合作中，學習到很多好的編程習慣。前端工作我以前比較陌生，這次能迅速熟悉前端語言並完成分派任務，一定程度上也提高了我的學習能力。我認為現在可以給自己的編程實現能力打4分。

　　Programming: Communication

　　ASE涉及到的編程工作大部分都是團隊項目，所以我的交流能力有明顯的進步。在和隊友結對編程時，要盡量讓自己的代碼具有可讀性，提前溝通好各自函數的的接口；有時更要互相遷就，通力合作把既定目標完成。在更大的團隊裏面時，我身為前端人員要虛心接受、仔細琢磨別人提出的意見；身為測試人員要學會更形象的描述bug，更耐心更講策略地與開發人員交流。我認為現在可以給自己的交流能力打5分。

　　幾次項目我也學到了不少個人代碼管理的知識，可以給自己打3分。

　　其他的能力可能短時間內在這一門課上難以覆蓋，希望以後可以通過組內的項目以及個人的努力盡快達到自己滿意的水平。

2） 你在課程開始快速瀏覽了《構建之法》，提了 5 個問題， 請回顧那些問題， 自己回答它們。如果不能回答，為何軟件工程課不能讓你回答這些問題？

　　問題一：

那麽，初級軟件工程師如何成長呢？我認為有以下幾種成長：

……

3.對通用的軟件設計思想和軟件工程思想的理解

我對軟件設計思想以及軟件工程思想的概念並不是特別清楚，也不太明白怎樣通過學習好的思想來提高自己。第5章“團隊和流程”中提到的像瀑布模型、RUP等開發流程算不算是軟件工程思想呢，第11章提到的分析設計方法算是軟件設計思想嗎？我讀完後感覺不同的開發流程、設計方法適用的工程場景是不同的，最適合項目的流程似乎更符合“更好的思想”這個概念。那麽通用一詞又如何理解？如果是指放之四海而皆準的設計思想，我覺得似乎有點“銀彈”傾向；如果是指大家常用的各類思想，不分場景和資源約束的比較兩種思想的好壞，我覺得沒什麽意義。 而且我還覺得像Team Software Process這種開發原則也可以稱之為思想，這種思想是需要我們遵守並且努力達成的目標。最後我對於怎麽評價一個工程師有沒有思想、境界的高與低仍然有所迷惑。

　　實踐才是硬道理，同一個項目中在不同階段可能有不同的人員配比，不同的開發需求，要根據實際情況在不同階段選擇合適的軟件工程思想。掌握工業界常見的思想和軟件設計方法，有利於PM的靈活運用。

　　問題二：

我覺得協會或是企業組織的執業資格考試一定程度上代表了行業對一個程序員的認同標準，那麽這種考試是不是真正的反映了程序開發人員的基本素質呢，企業真的要求我們要有這種素質嗎？除此之外，我還有別的途徑可以準確地衡量自己的編程水平嗎？

　　企業招員工，PM招程序員都是講究效率的，因此很難有時間去全面的衡量一個程序員的水平。等級考試無疑是一個敲門磚，可以過濾到大多數不那麽專業的程序員。作為IT行業的學生，我們要勤修內功，形成自己解決問題的一套方法，培養自己的學習能力，這些是我們立足IT領域的根本；同時我們也要兼修外功，有板有眼的招式、專業的表達能力有利於我們找到更多的機會和平臺。

　　問題三：

閱讀過爵士樂模式的特點，我感覺這種模式和敏捷流程的相似度幾乎沒有，不知道類似點在哪裏。由於在網上沒有搜索到應用這種模式的實例，我根據自己的理解談談對這兩種模式的看法。從特點上來看，爵士樂演奏時沒有譜子，而敏捷流程雖然講究保持簡明，但是仍然堅持 Product Backlog、Sprint Backlog、Sprint三步走的策略來更新叠代開發過程，是一種非常註重策略的流程；爵士樂沒有現場指揮，成員們放飛天性，但敏捷流程是以有進取心的人為核心的團隊，講究自我管理，第六章6.3節也強調了一個好的Scrum Master對於項目成功的關鍵；爵士樂的模式，“架構師”吹出主題，其余人員各自發揮，最後”架構師“回應主題，而敏捷開發十分註重面對面的交流和工作進度的共享，講究互相幫助，紀律性遠超爵士樂模式。

　　我覺得老師的解釋很有道理，從“心意相通”的角度上理解，爵士樂模式和敏捷流程的確頗為相似。無論是爵士樂的自由發揮，還是敏捷流程的簡明思想，都要求大家對項目的目標以及實現的方法都十分清楚，彼此“心照不宣”。

　　問題四：

3.不同的團隊模式如何影響團隊績效的評估？

　　在剛結束的團隊項目中，alpha階段和beta階段我們小組內部通過投票對個人貢獻度進行了評分。我認為這個方式很適合我們的項目，在項目裏面，我們互相之間沒有太大的利益沖突，合作關系遠大於競爭，通過投票得出的結果可以比較真實的反應我們內心的想法。

3） 看看還有什麽新的問題產生，請列出來

　　問題四仍有疑問，在團隊成員間利益沖突比較大情況下，如何更好地評估每個成員的貢獻呢？如果由PM一言堂，會不會因為PM可能存在的偏見而引起成員不滿呢？如果是由投票來解決，會不會出現功勞大的人反而被其他人集體“做掉”的情況呢？

4）你看了一些軟件工程的文獻， 你的團隊也做了一兩次 “事後諸葛亮”分析， 可以再去看一遍，現在有什麽新的感想？

　　事後諸葛亮分析不僅要提出問題，更重要的是反思不足，提出解決問題的方法。我們在alpha階段提出的問題，會在beta階段有所改善，這就是進步；同樣地，出現的問題不去解決，問題會繼續存在，甚至會成為真正棘手的問題。

5）對比一些技能評價表，你有什麽提高？ 還有什麽收獲是不能用數字衡量的？

　　提高的技能，在問題一中已經回答過了。其他收獲：團隊項目中，與隊友合力做出一個滿意的項目，在此期間獲得的協作能力、溝通能力以及傾聽能力很難用數字衡量，相信這些能力也會對我以後的研究工作有很大的幫助。

6）設想一年之後， 你到了你職業發展的下一個階段（高年級， 讀研，工作），回頭看這門課， 你對於這門課的教學方法， 老師和助教的工作，和其他課程的銜接，有什麽意見和建議？

　　 軟件工程應該是一門和工業界零距離的課，我認為在alpha和beta階段review的時候，鄒老師的團隊以及諸位同學的mentor提出的意見都非常有啟發性，往往切中要害。在團隊項目的日常開發中，可不可以讓真正的軟件開發工程師參與到團隊的例會或是事後諸葛亮會議當中呢？他們可以不參與實際工作，只提出問題。相信這樣會讓菜鳥團隊更快的成長吧！

最後一周總結