集美大學網絡1413助教總結

可是反觀人生，每一個人出生都掌握着一副被分配到的手牌，無論你拿的是好是壞，總仍是要盡力打的精彩。更況且同一所學校，同一個班級，同一門課程，真的達到了須要咱們去只拼運氣的時候嗎。若是真的足夠重視，回過頭想，在一個很壞的團隊裏，你爲何不能去作那個稍微努力點的人呢。並且若是工做後，想要進入一個好的團隊，不也得須要你本身用能力說服別人嗎？

2. 結對：-- 取其精華

本學期只完成了兩次結對編程做業，私認爲，這是一個很好的學習對方優勢的過程，好比對方解決問題的思路等。

3. 我的：-- 蝴蝶效應

當你老了，回顧一輩子，就會發覺：何時出國讀書，何時決定作第一份職業、什麼時候選定了對象而戀愛、何時結婚，其實都是命運的鉅變。只是當時站在三岔口，眼見風雲千檣，你作出選擇的那一日，在日記上，至關沉悶和平凡，當時還覺得是生命中普通的一天。

——陶傑《殺鵪鶉的少女》

因此，儘量不要虛度年華，也不要放棄，種一棵樹最好的時間是十年前，和如今！！！

4. 時間：-- 合理利用一切時間碎片

推薦你們去讀一下《暗時間》。

珍惜在學校還有人願意教你，還有你討論公平與否的平臺，還有爲你提分的附加做業，可是別人能作到的，請你也儘量作到。好比展現的博客，好比提高能力的coding。

6、關於課程的一點建議：

這是第三次作助教了，張敏老師制定的教學計劃是我見過最爲詳細的，很負責。

1. 博客：

能夠要求一下統一的格式。

2. coding：

建議能夠在課程初期增長對git使用的教學，而且有一個簡單的項目貫穿始終，讓同窗基本每週都會有代碼的check-in和check-out。而不是像最後團隊裏代碼能力好的我的秀。

3. 評分：有同窗建議結對編程過程當中也引進互評。至於評分細則方面，認爲每一次佈置做業的博文中已經很詳細的寫出了，只要認真看，同窗們是不會有遺漏點的。

4. 好多工具都只是走過場，好比leangoo或者PSP，大多數同窗仍是不能體會到其做用，可能得有一個良好的監督及執行制度。

7、感謝：

感謝鄒老師、周老師、張老師給我本次當助教的機會，也感謝大家對個人包容，相比於其餘助教，我作的實在不算好。

願景老是美好的，但從學期初搬家、週中工做、週末學車、途中旅遊散心等，步調偶爾有點落後，感謝鄒老師和周老師的及時督促:)，才堅持下來。我要向大家努力學習暗時間的利用。

感謝羣裏的各位老師，大家都是我學習的榜樣，大家對教學的那種熱情，是我所缺少且敬佩的，我努力向大家學習。

感謝同窗們對我理解和支持，偶爾也讓我會想起了校園時光。

附、同窗們對課程的建議

1. 你認爲每次項目的評分標準存在哪些問題，你認爲的合理評分準則是怎樣的（我的/結對/團體算三個）

同窗一：

我的：對於評分來講，整體上還能夠，每一個具體的得分點列的比較清晰，圍繞整個項目展開，可是編程能力因人而異，有些同窗相對薄弱，對於比較難的編程題目可能要比較長時間才能完成，然而假如老師的時間是一週以內，某些同窗沒有按時完成可是有在努力編程作，我認爲仍是能夠給出相應的分數的。在給我的評分時能夠添加一項進步分，鼓勵編程基礎相對薄弱的同窗再接再礪。再有，我認爲在代碼規範這一塊要佔比較大的分數，助教們對代碼的審覈應該要增強些，嚴格規範你們的代碼編碼形式，指出不符合一個程序員編碼規範的地方。

結對：對於結對編程來講，我以爲最大的問題就是我的工做量的透明度不夠大，這其實也是這種編程模式自己就存在的一種問題，每一個人在結對編程中的貢獻是不同的，我認爲每一個部分的分數應該有相應的規定，而後對號入座，我以爲結對編程能夠嘗試改變一下模式，不是一我的作另外一我的看，而是分工合做。

團隊：團隊評分標準相對來講是比較公平公正的，我認爲最大的優勢就是在團隊互相評分以及提出貢獻比的這種方法，不只只從老師的角度去評判整個團隊，還增強了民主性、公平性。缺點或者不足之處，就是針對不一樣的團隊項目有不一樣的難度，因此這樣針對每一個項目的功能實現的要求應該有適當的區別，好比難一些的項目實現的功能能夠少一些，相對簡單的項目就能夠要求實現更完善更全面的功能，評分標準也就能夠有一些改動，但願除了看展現博客以外還能夠參考其餘的一些內容。我看了其餘班級的最後總評分，有的班級整體成績很高，有的班級偏低。

同窗二：

我的：我認爲我的評分的環節仍是比較合理的，可是我但願能夠再表現的多樣化一點，由於我的做業主要是編程技術，而學好軟件工程這門課並不僅依賴於會編程，因此我認爲在我的評分標準中，還能夠再加入一些其餘的評分，培養一些除了編程以外的能力。
結對：結對編程中就會出現兩人比分太相近的因素，固然這些不可抗力是很難避免的，可是，結對做業中多數同窗都會有出現工做分配不均的，雖然表面上看起來好像是沒什麼，但實際仍是能夠用一些必須運用到專業知識去回答的問題、任務在我的博客中作出解釋，這樣能減輕一些存在明顯貢獻差距的小組卻兩人平分差很少的狀況。
團隊：團隊平分我認爲是三個中最爲公平、最合理的評分體系。首先，有體現各個同窗的區分度，即便是在一個團隊中，每一個人所作的貢獻不一樣，得分天然就有高低；其次，團隊評分有照顧到協做方面的問題，如敏捷開發階段，基本上全部的團員都要輪過一遍到兩遍，天天不一樣的同窗負責不一樣的內容；再者，還加入了各個小組給其餘小組的打分，這又多了一個站在旁觀者角度看問題的方向，這是團隊項目的評分中很成功的一點。

同窗三：

我的：以爲評分細則詳細也基本合理，助教也作了點評，若是有改進的話就是增長自評以及把評分細則量化。（好比5分表明很是好，4分表明很好這樣）
結對：能夠兩我的互相評分，像團隊同樣算出貢獻權重。
團隊：雖然有團隊自評和互評的部分，可是不夠細化，團隊可讓每一個人本身寫對其餘人的評分，最後取平均算團隊權重（這樣你們比較不尷尬…）

同窗四：

我的：我認爲我的評分的環節仍是比較合理的，由於我本身的基礎很差，完成做業的時候也沒有討論的對象，因此評分不能跟結對和團隊的相比。

結對：結對編程是雖然有兩我的一塊兒討論完成的，可是我以爲兩人的分配不同，難度也不同，因此我以爲兩人的評分有必定的差異。

團隊：我以爲團隊評分是最合理的，由於每一個人的難度差異有點大，對於我來講以爲寫代碼的難度很大，還有其餘的分配都難度不同，分數的差異也不同。

同窗五：

我認爲助教對咱們一視同仁。可是吧，個畢竟每一個學生的基礎是不同的，像個人基礎就比較差。我的做業是我本身盡力寫的，是能夠運行的，可是結果並不怎麼好。結對編程就比較靠另外一我的了，本身愛莫能助。團隊做業因爲我我的的緣由沒有及時參與，這是讓我很後悔的事情；就算能力再差可是也沒有主動去與其餘小組進行溝通，這是我在這門課程最失敗的地方。對於評分，助教仍是很用心的常常會有互動，對於我提交的做業助教會以郵件的形式給出他的意見；並且對於評分有異議的地方也能夠直接大膽向他指出。

同窗六：

在我的做業方面，我以爲對於評分標準來講，可能太過於追求細節，沒有注意每一個人，每一個學生的特色，我以爲若是改的話，能夠把學生按照平時表現，分爲幾等，而後進行評分。

在結對編程方面，我認爲兩我的的分工透明度不夠高。到底誰作的多，誰作的少，具體分工又是怎樣，沒有一個明確的評分標準。我以爲能夠像團隊做業那樣，設置一個自評和互評做爲參考。另外還能夠寫上具體的分工，讓助教參考，去給出合理的分數。

在團隊做業方面，我以爲在團隊做業中，團隊中每一個人的貢獻不能按照一個標準來劃分，就像一個隊長和一個編程員的比較，我以爲這就是不能比較的，你們都有用心作，不能按照作的事的重要程度來劃分。其他的我以爲還能夠。

同窗七：

我的做業我以爲挺好的，題目也比較容易，對於我這個基礎比較差的人均可以完成題目基本要求，並且助教對各項評分也很詳細，很棒。

結對編程方面：我認爲兩我的的分工透明度不夠高。到底誰作的多，誰作的少，具體分工又是怎樣，沒有一個明確的評分標準。我以爲能夠像團隊做業那樣，設置一個自評和互評做爲參考。另外還能夠寫上具體的分工，讓助教參考，去給出合理的分數。

團隊做業：我以爲班級映射分有點奇怪啊，爲何要以一個班級最高分做爲評分標準呢？假如我是那個最高分，我會不會想着反正我都是最高分了，下次能夠偷偷懶？另外每一個班的水平良莠不齊，這樣搞的可能某位同窗雖然在本班差一點，但是放在所有人中，他不必定最差啊！我認爲就按照給出的分數算就很好，不必再映射分了。最後一點，我認爲就是助教回覆這一點也算在評分標準裏面，你們都是用我的郵箱註冊是博客，基本上每一個人都是一個郵箱。團隊博客的時候都是臨時找的郵箱，很難作到及時回覆助教的博客。這一點但願改進吧。

同窗八：

我的:無

結對：結對做業評分每一個人的貢獻量不太好評估給分

團隊：--在做業下發的過程當中已經明確將分值分配清楚例如寫什麼佔幾分，感受助教在評分過程當中自主性有點小，但願給予助教對博客的總體評分分值大一點。 --是否能夠把博客互動的評分更換爲獎勵分，就是有互動的能夠加分。不過這樣好像不容易調動積極性。

最後整合評分建議：以班級排名第一同窗的分數爲100分的話是否是缺少與其餘班級的比較性，並且班級第一名越優越那麼總體班級的水平可能會更低，是否能夠四個班級有一個統一衡量標準或者將班級前三拿出來做比較來評定一個比較過的分數。

2. 你的團隊項目是否成功，若是重來一次你是否還會選擇這個團隊，爲何成功／失敗？

同窗一：

我認爲個人團隊項目是成功的，若是重來一次我依然願意選擇這個團隊。首先，個人團隊成員們都很團結，無論是當下遇到什麼事情，或者是時間趕不及，你們都有咱們是一個團隊的思想，去完成當日本身的任務；其次，咱們團隊的PM不管是從編程技術上，仍是管理層面，都把咱們團隊帶領的很好，每週都會作詳細地計劃安排，落實到每個人，這才讓你們有一個更清晰的思惟，更清楚將來幾天本身要如何合理安排時間去完成；最後，整個團隊氛圍很融洽，每當遇到矛盾咱們都會當面溝通解決，避免爭吵，互幫互助，共同進步，來完成咱們的項目。

同窗二：

比起其餘團隊的完成度，團隊項目應該不算成功。失敗的地方是你們對於項目的實際理解和能力不夠，致使項目進度拖延嚴重。至於再重來一次，首先人生沒辦法重來，其次事情發展有時候不取決於我的意願，既然必定要組隊就必定要選一個團隊。若是這個團隊項目不成功，其實也是自身的問題。換一個團隊也是同樣，再來一次也沒什麼特別的選擇傾向。Alpha和Beta都在這個團隊，仍是挺有感情的。

同窗三：

我以爲個人團隊項目是成功的，若是重來一次我願意選擇這個團隊還有以前的團隊，由於團隊的成員交換以後我到了我如今的這個團隊。我以前團隊的項目是做業查重，此次項目是用微信簽到和請假。由於咱們團隊很是團結，每次遇到不會的地方都在羣裏討論或者在開小會的時候一塊兒討論。各個階段都會分配好，還會在開會的時候會總結已經完成的功能和遇到的問題，一塊兒討論要改進地方，提升項目的完整性。

同窗四：

個人團隊組名是男神組合，對於這幾回的團隊項目不管是對我仍是對團隊都是失敗的。首先，組內缺乏有責任心的同窗，對於寫博客都是各類搪塞；其次，咱們這組的平均水平過於低下，在各方面好比編程，設計框架等方面沒有出色水平；最後，也是本身的緣由，太懶散，沒有真正將這個組合視爲一個團隊，不懂分工合做；並且本身也沒有把團隊做業放在心上。若是重來我不會選擇這個團隊，我會積極去組建新的團隊。雖然個人能力有限，可是我能夠學習。真的很是抱歉而且十分後悔沒有加入團隊的工做，若是重來一次我必定好好加入團隊的工做。

同窗五：

個人第一個團隊項目是失敗的，失敗的緣由很簡單，第一：你們都不會，你們都沒積極性，你們都明白對方是怎麼的水平，無論怎麼作也就那個樣子，沒有動力去想把項目作好。第二：你們都不是情願的成爲一個團隊的，固然這不是一羣成年人的作法，可是你們積極性就是調不起來。若是能夠重來，我會去找一個具備自制力和擁有積極性的團隊。

同窗六：

我最開始是在男神組合團隊的，在這裏個人感覺以下：我但願老師之後在組建團隊的時候，詢問班級狀況，強弱搭檔，這樣纔會進步。不要讓你們自由組隊，剩下的人在沒有通過我的的贊成的狀況下，就莫名其妙的成爲一隊了，你們你不情我不肯，去哪寫出好的代碼。

在新的團隊中，我如沐春風，很快融入新的集體，很開心。

總結一下大家團隊在作項目時你們的時間安排狀況，能夠匿名寫；咱們基本上都是在晚上擠時間作的，到了大三了，考研的考公的就業的，都要準備了，還有課程，時間很緊。不過期間就像海綿中的水，只要去擠仍是會有的。可是有時候仍是會出現今天的任務沒有完成，明天去作的，可是仍是隻能默默寫上這是昨天完成的。

同窗七：

團隊項目最終你們認爲完成了各自的目標，我依舊會繼續選擇這一個隊伍，在這個過程當中你們給予了很大的幫助，感謝你們。

3. 總結一下大家團隊在作項目時你們的時間安排狀況，能夠匿名寫

同窗一：

咱們團隊在時間分工安排上還算是比較平均的，負責編寫代碼的兩位主要同窗花費的時間確實是不少的，由於代碼須要不停的調試修復，那他們主要的任務就是完成主要代碼功能；而剩下的同窗，咱們也作了不一樣的分工，採起輪流的形式，需求分析、撰寫博客、測試代碼、展現發佈等等，每一個人都要參與投入。咱們會盡可能避免有個別同窗「打醬油」的狀況發生，例現在天你的任務比較輕鬆，只須要撰寫博客，那你明後天可能就須要配合兩位編寫代碼的同窗，去完善他們寫出來的功能，去測試，去修復bug等等，總之，在合理的範圍內，咱們會盡可能讓每一個人所花在這個團隊項目上的時間平均。

同窗二：

因爲我不是pm，對於你們的安排狀況不太瞭解。alpha版本的時候我的編寫的是代碼的導入功能，必須先導入才能實現後續的其餘功能，因此我很早就寫完功能交付了，後面也參與了前端以及接口的代碼編寫工做，可是因爲技術水平有限，沒有太大產出。其餘零碎的時間就幫助博客的內容撰寫，而後beta階段全部人員就進行bug修復和界面改進。你們上課和本身的事情都比較忙，時間安排比較靠自覺了。

同窗三：

咱們團隊主要時間安排就是每一個人的分工不一樣而所用時間不同，也就是兩個寫代碼的同窗的全部時間最長吧。由於代碼天天都要更新，尤爲是在衝刺階段，可是其他的隊員的所花費的時間也不短，每一個人都有分工好的工做。分工有參與已經寫完的功能進行完善功能，參與測試的，參與界面優化的，撰寫和發佈博客等。時間安排的很均勻。

同窗四：

你們的時間安排我不知道，由於各自的基礎不同，編程的速度也不同。我就說說在男神組合時期，後期由於我自身的關係漸漸沒有參與。在起初建立男神組合的時候，我主要負責寫博客，還有與組長討論關於Java代碼，那段時間由於在複習Java對於Java的編程能力仍是有一些。可是組員的積極性不高，沒有真正的融入到一個組合。因此當我手術結束後，被告知組合解散，而後十分的茫然不知道本身該怎麼作，不懂詢問別的小組，就那樣一我的銷聲匿跡，這是我很是後悔的事情。

同窗五：

在第一個團隊的時候就不說了，項目已經失敗了。在第二個團隊項目中，咱們的時間安排都是按照項目中時間和計劃來規劃咱們本身的時間的。在衝刺的階段中，咱們都保持了一天有1個小時的時間來對項目有具體的改進，咱們都很自覺，積極性也不錯。

同窗六：

時間安排狀況：團隊後期主要進行了分工，代碼能力強的同窗負責程序編寫，審覈測試人員負責測試找漏洞，平常博客管理同窗負責安排平常開會時間活動安排的具體事宜。我的負責不一樣部分，時間很差評價。

4. 軟件工程這門學問有不少「知識點」，這門課強調「作中學」 - 在實踐中學習知識點。請問大家在項目的需求/設計/實現/測試/發佈/維護階段（一共6 個階段）中都學到了什麼「知識點」，每一個階段只要說明一個知識點就能夠。

同窗一：

需求：需求分析必定要適應市場，且要具備競爭性和可行性，不能太理想化。
設計：創建以文字爲主的文檔，用圖形構造模型。
實現：首要任務是完成規定的任務，要按期作進度小結。
測試：可分爲黑箱和白箱，能夠先進入功能測試階段作大致的測試。
發佈：學會接受設計變動，不斷提升軟件質量，修復存在的一些小問題。
維護：進行迴歸測試，總結回顧整個項目。

同窗二：

需求：必須對用戶進行真實的訪問調查，並且必須在alpha階段結束後傾聽用戶的反饋，並根據能力水平，bug來改進需求。能夠用模擬故事場景等方法。
設計：項目正式開始時先進行原型設計，並編寫項目計劃書，這樣整個項目流程才清晰有序，對產品的框架有必定了解。
實現：能夠用leangoo對整個項目進行細化分解，追蹤整個項目進度，最後用燃盡圖直觀顯示。
測試：首先每段代碼編寫後代碼人員必須進行自測，代碼無誤後再上傳Coding，最後項目完成後進行性能測試
發佈：發佈後收集用戶反饋，對beta階段或者項目的優化收集信息，而不是發佈以後就無論了。
維護：按期更新版本，優化系統，修改bug，這樣才能保證項目的活化，不會流失用戶。