開學初對自己的期望
【集美大學1411_助教博客】2017軟件工程開跑啦。。。。
在本學期的開始，我就對自己有以下希望：
- 及時與任課教師溝通，遇到任何問題，或者有任何建議，都能在最早的時間與張老師進行溝通。
- 多參加課程設計，比如作業的協作，對課程的設計提出個人的見解等。
- 及時完成博客評論，并給出更加有成效的點評，多跟蹤評論，反復交流才會答到更好的效果。
- 提高自己的專業技能。
除了第3條在出差的過程中完成得非常不好，個人覺得一學期下來，自己比第一次做助教時長進了不少，下面我詳細總結一下我自己本學期的助教工作。
班級情況
班級博客:軟工-網絡1411（集美大學）
教師:張敏老師
本學期發布的助教博客
【集美大學1411_助教博客】2017軟件工程開跑啦。。。。
【集美大學1411_助教博客】個人作業1——四則運算題目生成程序 成績
【集美大學1411_助教博客】個人作業2——英語學習APP案例分析 成績
【集美大學1411_助教博客】團隊作業1——團隊展示&選題 成績
【集美大學1411_助教博客】團隊作業2——需求分析&原型設計 成績
【集美大學1411_助教博客】團隊作業3——需求改進&系統設計 成績
【集美大學1411_助教博客】團隊作業4——第一次項目沖刺（Alpha版本） 成績
【集美大學1411_助教博客】團隊作業5——測試與發布（Alpha版本）
【集美大學1411_助教博客】團隊作業6——展示博客（Alpha版本）
【集美大學1411_助教博客】團隊作業7——Alpha沖刺之事后諸葛亮
【集美大學1411_助教博客】個人作業3——個人總結（Alpha階段） 成績
【集美大學1411_助教博客】團隊作業8——第二次項目沖刺（Beta階段）
【集美大學1411_助教博客】團隊作業9——測試與發布（Beta版本）
【集美大學1411_助教博客】團隊作業10——項目復審與事后分析（Beta版本）
分而治之（Work Breakdown Structure, WBS）
累計評論博客350篇
根據個人筆記本manic time記錄的時間sum(excel+cnblogs+edu.cnbglos+markdownpad2+shimo+coding)=60H，本學期在軟件工程這門課上投入60小時。當然這其中可能也有屏幕開著但可能在洗臉等沒有干活的時間，但這其中沒有包括在單位的零碎時間，以及出差時在旅途中的零碎時間。本學期一共16周，所以每周用在軟件工程上的時間大概4小時左右，這樣看來應該是比去年當助教時效率提高了。
本學期與教師的互動較多，應該超過50次吧，只算和張老師的個人聊天記錄我的發言就超過30多條了。
與同學們互動至少200次吧，沒具體統計，在班級博客中發言就超過100多條。
在石墨中制定的評分標準或參與修改的作業達10余項。
同學們對課程的建議
1.你認為每次項目的評分標準存在哪些問題，你認為的合理評分準則是怎樣的（個人／結對／團隊算三個）
同學一：
我認為平時分的評定有些不合理的地方。我認為對于平時分的映射不應該以成績最高的為標準，而是應該確定一些容易評分的標準，做到的拿分，沒有做到的扣分，如果做得超出預期的加分。對于個人/結對/團隊分，個人作業比重可以稍微少一點，結對較個人多一些，團隊的評分可以讓團隊貢獻比占得更大一些。
同學二：
個人：個人的得分點都很細致，沒有什么槽點。
結對：兩人的貢獻肯定不一樣，這里也需要結對貢獻分來讓出力更多的人得到更高的分數
團隊：（1）團隊貢獻分那里，我們按照貢獻多少，給了主力較高的分數，結果后面我們的個人貢獻分就和組里最高的分數對比映射，導致我們組其他的人分數較低，然而滿分五分，每一組的主力都是五分，我們給主力較多的分數也只是拉低了我們自己的分數，并沒有給主力帶來什么更多的獲益，反而我們只要每個人的分數差不多，那么所有人的貢獻分都會很高，導致了有的組所有組員貢獻分加起來遠超其他組。這里的評分公式是不是存在問題呢？我覺得應該給每個團隊固定的分數，讓他們自己按比例分配自己應得的分數。（2）同班的隊互相評分，難免有所失真，可以班與班之間互評，才比較公平
同學三：
個人：助教的評分總體來說是比較合理的，每個給分點都劃分的挺細致的，對照得分點就可以知道自己哪方面沒有做好。如果能夠再細致地說明某個點該如何改進就會給我們更加明確的方向，下次該如何完成。但是個人認為有一點小小的不足，有些給分點在給題目的時候說是附加分，但是到了評分結果出來的時候就變成了必做的項目，沒做會被扣分，感覺不大合理。
結對：結對作業，有領航員和監督領航員的兩個角色，那么負責代碼的人工作量比較多，得分都一樣，這樣可能會導致不大公平。
團隊：團隊作業是耗時間和精力最多的一個部分，每個人工作量不同能力不同，貢獻分比較公平，所有團隊成員的積極性都比較高，大家都非常認真積極參與到項目中去，發揮自己的作用努力完成項目不拖后腿。通過老師評分和各組互相評分得到民主的得分。但是在第一階段的評分老師先給出了各組的排序，這樣導致其他小組很容易跟著老師的排序排名，我認為不太合理，應該同學先評，老師后評比較合理。
同學四：
個人的評分標準沒得說，自己一個人做的，該得幾分就幾分，沒什么好說的。結對和團隊兩個階段來說，評分還是比較合理的，雖然大家基礎不一，對程序編寫的能力相差會比較大，像我可能只能做些比較簡單的代碼，做代碼覆蓋率、單元測試這樣的事情、代碼來說，可以說是根本不知道怎么做，從哪里入手。所以后期，除了自己要做的，代碼基本上是靠大神來帶我。
同學五：
團隊：團隊每個人的貢獻分那塊，是按照最高分為5分然后再映射其他組員的分數，那只要每個人的貢獻比在比較接近的情況下每個人都能得到相對較高的分數。這樣子的話團隊貢獻分還是沒能夠起到協調團隊中主力與打醬油的分數差。個人認為可以給定一個團隊貢獻的總分，然后在按貢獻比來分配這個總分。還有，團隊博客的得分得分點的設置有的地方不是很合理，比如在beta階段的得分點設置為任務結果是2分，而代碼簽入是1分，代碼的簽入通常就是會簽入當天完成的可執行代碼，而運行結果就是把它進行運行的一個結果或者說在博客上展示出來就只是一張截圖而已。完成這兩個得分點的任務在時間上不是一個量級的，但是分數上卻是顛倒的。我們組就因為在寫博客時沒有注意，沒有上傳結果截圖吃了虧。。
還想提一個就是總分的問題。不同的班級之間的分數差異較大，雖然這是不可避免的。。。每個人的成績是班級最高成績的映射，這個就是會導致如果班級的最高分特別高，就會導致班級的其他人的分數相對較低。但是我們是一整個專業，這就又導致班級間的分數差異更大了。
同學六：
第一，分數差異
問題：一個就是各班的成績評分有高有低，有的班整體分數都比較高，有的班整體分數就比較低。這就導致最后平時分的劃分的矛盾。雖然量化是標準的，但人這個變量是不統一的。
解決：暫無
第二，指標量化
問題：還有一個現實的問題就是團隊項目是一個大的項目，我們判斷一個團隊給高分量化標準到底是什么？
是完成即可高分還是說要功能的完善？【如果完成即可高分那么結果請參照上世紀人民公社化的故事，結果怎么樣我就不細說了...
解決：我建議加入自評分和相關說明。
即闡述你為什么能得到這個分數，老師和助教也就可以針對你的自評來進行提問和打分。
沒有任何人比自己更清楚自己的項目是怎么樣的。自評分是對自己的認識，也是幫助別人來理解你的項目代碼，闡述優點或者功能，或者數據結構，也可以更直觀方便評分。
而這會更清楚的看出各個組在功能實現上的差異，哪個更難，哪個更簡單，我想一目了然。這也回答了我上面的問題。
第三，展示博客
問題：團隊的展示博客有時間和評分的兩個問題。
在我看來，團隊項目過程和結果同樣重要，而到最后卻因為考試沒時間進行全體的項目結果展示，我認為這還是有些問題。應該調整一下，因為還是要有一個展示的過程在。而且，到了beta基本上就開始有期末考試的問題在了。
在評分上，Alpha階段我當時生病回家沒在學校。導致我們組alpha階段展示只進行了前端展示，但同樣出現展示問題的有好幾組，最終老師給了我們最低分。老師的提先打分影響了大家的打分，因為大家也不會認真看展示內容，然后就按照老師打的排下來了。我們最后就是光榮的最后一名。
解決：時間方面，提前一下時間進度，留有時間作beta和展示。打分方面，建議是老師最后打分先讓小組互評分，減少老師打分的影響，而互評分建議是其他班進行打分，而不是本班互相打分。
第四，博客&代碼？
問題：有些人基本沒寫過代碼，只是博客寫得特別特別好，就可以拿高分？諸君如何看待這個事情呢？我承認這是嚴苛的博客評分制度的必然產物。
解決：我，無言以對，得分，但求心安。
其他。（后面還附有一些建議）
個人和結對倒是沒有什么特別的評分問題。【我害怕沒按照要求寫，又得扣分了】
同學七：
個人：雖然已經做到了量化每次作業的每個部分，各個助教都協調好了一個評分標準，但是從第一次博客作業下來，就有的班級分數普遍偏高，有的班級分數普遍偏低，同學之間難免會問會比較，對于分數的落差心里還是又點兒小失落，希望之后的助教評分準則更統一。但是對于每個部分都量化出來真的特別好，特別仔細。
結對：結對過程希望也有兩個人的貢獻分的比較，不能只看博客打分，如果一個人代碼做的很少，實驗截圖都是用的一樣的，一周都只是在很用心的寫博客，這樣分數卻比另一個編代碼的高，可能會有寫不公平，可以把結對作業做兩個評分標準，一個是代碼貢獻量，一個是博客展示，這樣對那些工作量大的人更友善。
團隊：團隊過程整體都考察的很全面，有組內的成員貢獻分，有老師和助教的評分，也有其他小組的評分，但是在復審階段，讓同班之間進行復審會存在大家都為了得一個不太壞的結果，相互牽制相互打高分，可以互換班級，讓一班評二班的，二班評三班的，三班評四班的，四班評一班的。
整體來說還是不錯的，第一次試驗可以想到這么多已經很完美了。
同學八：
①個人：個人的評分標準很好，很完善。我個人覺得都挺好。
②結對：結對作業應該也可以設置一個貢獻分，就我的體會來說，結對作業時也肯定有工作多和工作少的。非個人就必定應該有區分，有功勞大小。
③團隊：這個方面我覺得最大的問題就是團隊復審，本班間評價會存在一些不公平因素。（這個大家也都清楚、明白）我的想法是，這個復審可以直接讓老師和助教（四個助教）評分。助教和老師來評也會更加的專業吧。當然也可以把模式做的貼切畢設答辯，找幾個專業的老師來看每個組項目并做出評價和打分。復審的展示（同學間）可以作為一次交流、分享經驗。不做評分，這樣大家才更愿意提問題，找問題，解決問題。
④整體來講我個人覺得還有兩個問題，一是評分分班級分別映射的問題（這個自是解決了各個助教可能評分嚴寬尺度有分）但是又會萌生另外一個問題，就是各班的情況不一樣，可能有些班級整體做的都很好，你追我趕；可不排除有班級整體都做得不甚如意。然而映射卻是以班級最高分（和最低分）來映射，這似有不妥。具體解決的方法，我個人覺得還是盡量保證各班助教評分尺度一致（這確實會有難度，但。。。）也沒更好的方法啦。還有一個就是貢獻分，感覺貢獻分其實并沒有發揮什么作用（1-5）的區分，這實在不妥。我個人覺得可以直接和團隊總分掛鉤，比如團隊得分100分，那30（貢獻分滿分6人 120分的情況下）那這個同學就得到25分。剩下的再分別按比例分下去，這樣才會起到絕對的區分目的。（僅是個人考慮）
2.你的團隊項目是否成功，如果重來一次你是否還會選擇這個團隊，為什么成功／失敗；
同學一：
我覺得是成功的。再重來一次還是會選擇這個團隊，我們團隊各斯其職，每個人都認真地完成自己的部分，不存在互相推諉的情況，我們的隊長龐龐也很好地帶領我們，我們初次接觸前端，還不懂如何修改，隊長會給我們介紹工具和資料讓我們學習，同時作為團隊主力她也很辛苦地爆肝寫代碼。
同學二：
我覺得我們的團隊是成功的。我經歷了兩個團隊。首先第一個團隊對我的影響比較大，畢竟是從一開始就跟的團隊，也是在這個團隊里面，我第一次接觸到了前端，也激發了自己學習前端的興趣。雖然我我們的水平參差不齊，大多數的成員都是沒有項目經理，但是我們團隊中的每個人都處于積極向上的狀態。在我們的PM 的帶領下，每個人都周到了興趣點，對于每次的任務都能夠按時的完成；每次有什么設計點，都會在我們的討論組里積討論；在博客的撰寫方面，也是分工合作，每個人都有參與感與存在感。我的第二個團隊，在一開始還是非常不熟悉的，全新的項目以及不一樣的小伙伴。團隊里有一個強大的隊長，能夠安排好所有的工作，在他的帶領下，很輕松愉快地就完成了beta階段的沖刺，有什么不懂的，也都會在群里面討論。很榮幸很夠參與到兩個這么優秀的團隊當中。
同學三：
是成功的。我仍然會選擇這個團隊。
首先團隊里的組員大家都是極其向上的，想做好每一件事的人。每一次分配任務，寫日志都會及時的完成。這是我們團隊完成還算不錯的基礎。我并不算是一個鐵腕的人，想想如果是另外的組員，想必會很難搞。
坦白講，團隊里很多女孩子都沒有項目經驗，對于開發，產品，PM也沒有什么概念。
不過令我感到最開心的事是，大家找到了自己的興趣點。
通過這個團隊項目，有些人開始想學學python了，去看書，去找一些資源，去寫寫小東西。
有些人對前端感興趣了，鉆研前端，甚至以后想做這方面的工作。
有些人漸漸了解了PM，產品，運營的工作職責，也漸漸懂得了自己真正想做的事情。
在我看來，這是極好的！拿多少的分數從來不是授課的最重要的意義，因為在漫漫人生長路，這并沒有任何意義，【當然我這個要出國的留學狗要GPA除外】而更重要的是找到一個方向，繼續學習下去。
我從來不是一個講空話的人，也沒那么多宏圖韜略，唯有實事求是。我敢確認團隊中的每個人都有事情做了，或多或少的參與了開發，不是坐著拿成績吃空餉的人。
我認為團隊開發十分有意義，踏實做的項目比上那些空有其表的東西要實在的多。而主觀的說，我們還可以寫在簡歷上。
感謝團隊的每個人，團隊項目BETA結束后我們還去聚了餐。十分開心！！！
同學四：
我覺得我們團隊還是挺成功的，如果再來一次我還是會選擇我們這個團隊。我們經歷過失敗然后再逐漸追趕差距，到最后完成我們團隊的任務，我們組員之間的默契磨合的越來越好，我們在第一階段失敗的原因是，由于工作分配和組員間協調不好以及大家的積極性都不高導致的，在第二階段，人員調動后，我們又重新安排任務，每天給沒人分配各自任務，及時督促監督組員，并每天開會溝通交流，解決問題。
同學五：
我認為不算成功，但我還是會選擇這個團隊。前幾周完成情況較好，在alpha階段取得了較好的成績，但是在beta階段由于和期末考復習沖突很多成員就沒有足夠的時間來完成相應的任務，再來一次會規劃好時間，按質按量完成任務。
3.總結一下你們團隊在做項目時大家的時間安排情況
晚上晚上晚上，因為白天課程比較滿，而且實驗課程也比較多（這意味著要拿出很多的課余時間繼續完成實驗）。有時候甚至會在某天閑的時候多完成一些內容，然后等到第二日時間比較少的時候就把前一天的部分內容拿過來充當這一天的。（雖然確實很尷尬，但是有時候一天八節實驗課（上機課）很多內容要完成，就。。。）
其它
同學一：
1、這門課是不是太注重博客了，現在情況是只要博客寫得好就可以高分，是不是太武斷和片面。
2、有個小小的問題，如果我什么都不做，放棄期末考，直接選擇補考，補考沒有平時成績，那么我補考認真復習通過，一整年豈不是都很輕松？
3、希望這門課能夠早點開課，這門課花費時間較多，收貨也最大，最好大一大二就開課，讓學生早點明白一整個項目的流程。
同學二
1.建議使用Github。其實我不太知道為啥不使用Github，提交代碼和coding基本一致，唯一差別大概是語言環境的不同。而Github上資源更加豐富，在求職的時候有些公司還會特意看你的github記錄，如果是放到Github上，真的是項目參與的痕跡體現。
2.對于課程沖突的問題，大三下的強度挺高的，課程沖突這個問題無法避免。我建議把很多功能實現從扣分改為加分。每個人的追求是不同的，有些人過就好，有些人想學更多，有些人想拿高分。目的不同，上心程度也不一樣，更重要的，編程程度也不同。如果一味的把要求定的太高，那學習成本就會陡增，編程水平一般的同學為了不扣分會花費更多的時間成本在上面。基礎部分是必要完成的，其他的一些功能可以加分的，而且加分的觀感比扣分要更好~
同學總結
同學一：
第一次體驗到這種方式的教學，真的非常不適應，還懷疑這種方式是否是有效的。剛開始的時候還是想學習點真本領，從第一次的個人項目到最后的團隊項目，真的付出了很多，而且我還修了二專，非常辛苦，說實話我們的作業量是很大的，但我都努力完成自己的任務。并且團隊大家都非常努力的做好本職工作，互幫互助，大家一起學習進步。這個期間老師助教的付出也是很大的，所以非常謝謝老師們和助教的幫助和指導。大家提出了很多建議，希望老師們可以借鑒一些好的建議，下一屆這門課越來越好。
同學二：
這應該是最后一次寫軟工的博客了（終于等到你~），在學習軟工的過程中經歷了很多，也收獲了很多。如果軟件工程師以前的那種上課的模式，我們可能能輕松地考個試就拿到學分，但是對我們個人而言是沒有成長的。但是現在，你們要是問我大學讓你映像深刻的課有哪些，軟工絕對排的上號。衷心祝愿軟工的這門課能夠越上越好。最后說一句，老師、助教你們辛苦啦，謝謝你們一路相陪！
同學三：
課程基本結束，回看過去的三年。軟件工程這門課的改革十分有意義。
本來是空洞的文字和概念，如果不通過動手實踐，那它永遠是空洞的文字。還是很感謝這個課程的改革，讓更多的人進行了參與，參與可能會萌發興趣。之前的很多實驗也好，課設也好，大家都并沒有真正上手去做，而這一次的軟件工程卻做到讓很多人開始嘗試。這也是我理想中課程的樣子。
我們的目標是一致的，希望這門課真的有用，希望這門課能夠學習到一些真東西。掏心窩子的話應該比假大空實在些，而這正是我這一學期上課之后的個人想法。
感謝老師和助教辛苦的付出，十分感謝真的。勇于做出改變并經常聽取我們意見的張老師 我報以十分感謝！
構建之法這本書也不錯，是少有的能讀下來，并且很順暢不費力的書。買了一本全新的，以后上班再讀又是另一番感悟。
歡迎老師和我進行更進一步的交流！希望我們院的這門課可以越來越好。努力謙遜，不忘初心。E心E意，一心向前。
同學四：
這學期收獲真的很多，非常感謝所有的老師和助教們，同學們。這門課的形式也非常好，我能深切的體會每個學到的專業（軟件工程）相關的術語，考試的時候根本不需要翻書，我能深刻的體會到所列詞的實踐含義。我很開心，并且很享受這種過程，不斷地進步，不斷地豐富自己的知識。雖然每位同學都會有自己的體會，很多意見，各種疑慮，但是這至少說明大家都認真的參與其中了，有了自己的切身體會，有體會才會有發言權（確實是這樣），有體驗就一定會有收獲。我個人希望這種模式能堅持下去，并且能夠越來越好。同時希望其他的課程也更多的注重實踐，這樣我們學生才能收獲更多。
助教想說的話
關于結對的成績，有的同學認為結對也應該給貢獻分，我覺得是大家誤解了結對編程的意義。結對編程是兩個人共同討論編程的整體思想，確定下來后，在編程過程中不斷交換領航員與舵手的角色，共同完成一個項目。在這個過程中，因為編程思想已經統一，就不存在在項目的實施過程中誰做得多誰做得少的問題，兩個人其實是一個人的大腦和手，大腦只負責指導手。
關于團隊貢獻分，alpha階段結束后，各團隊貢獻分相差還算比較大，基本可以達到5，4，4，3，2這樣的分差，但進入beta階段，大家的團隊貢獻分就變了5，5，5，5，4這樣的分差，其實從一些組的coding提交和平時的博客中就可以看出大家的團隊貢獻并不是全員總動員的，所以助教們采用了映射為5-1這樣一個區間的方式。
關于需要大神帶領的同學，看來你已經意識到自己的不足，那么就請你自己行動起來，不希望以后拖大家后腿，那就自己成為能和別人比肩的大神。種一棵樹最好的時間一個是十年前，一個是現在。
關于映射分是我的一個失誤，其實在beta階段我就已經看出來前三名的同學和后面的同學分差有些巨大，但我并沒有意識到問題的嚴重性。以致到期末所有分數給出來后，全班爆發了大規模的抗議，也是我始料未及。鄒欣老師指導我，將超級學霸給滿分，其余的同學按照50-95映射。我和張敏老師討論后得出的結論，就是將班級同學的最高分也降幾分，區分出123名，然后按照實際分數映射到100-班級同學最低分這個區間上。因為1411班的同學普遍完成了beta階段所有的任務，而且演示效果好。而其它班級的有些團隊沒有完成beta階段的全部計劃任務，通過映射后也比這個班同學的分數高，所以采用了這樣的策略。
關于過于注重博客，這一點在我上一次做助教的時候也有同學提過，首先我覺得還是自己做得有問題，今后會更加關注同學們的代碼。其次，我還是要說，博客寫得好，分就高，這沒有什么錯誤。項目展示與項目編碼同等重要，在實際的工作中，我也深有體會，有時自己花了好幾天做了一個作品，但展示匯報PPT做得不好，最后也沒有獲得理想的成績。博客正是大家呈現自己的作品的地方，如果博客寫得不好，有三種原因，一是你沒做出來像樣的產品，二是你沒認真寫博客，三是你不屑于寫博客。對于哪一種同學，都不應該給高分。當然在以后擔當助教的過程中，我會更加關注同學們的代碼。其實助教將每位同學的代碼編譯運行這種可能性很低，因為大家所使用的語言，環境可能都不一樣，有些同學在自己的coding中連引用的包或庫文件都不上傳，只上傳了自己寫的那部分代碼，這讓助教很難通過運行后的程序好壞來評價全部的同學們，助教們用眼睛看是一定會出現問題的。有時候助教覺得一名同學的代碼寫得棒棒的，但有可能那棒棒的部分就是從哪個大神那copy來的，對于部分代碼的查重檢驗，說實話，助教的編程經驗也沒豐富到那種程度。所以一方面請同學們體諒，一方面助教自己增加修為。
希望教師可以做得改進
張敏教師真的已經非常認真了，每個作業都制定的非常詳細，也經常評論同學們的博客，經常在微信群中與老師們討論教學方法，與助教們討論教學實施，非常認真負責的老師，想為她點贊。但我也提幾點建議，以便今后的課程越來越好：）
- 作業內容部署的非常詳細，但是不是每個作業都留給同學一點自由發揮的空間。這與我們這些助教評分也有關，根據作業內容制定評分標準時，應該提高個人發揮部分的得分。
- 有的同學提到了alpha階段展示由于教師先給了分數，所以班級同學有些跟風，給了與教師差不多的分數。教師可以在所有團隊都展示過后，收齊其它團隊的分數再公布自己的分數，這樣可以就少一些導向的指引。
- 有的同學提到了beta了階段沒有課堂展示，希望教師能計劃好時間給同學們一個展示的機會，可能他們沖刺7天就在等這一刻的到來，可能他們上次alpha階段沒有展示好就等著Beta階段咸魚翻身，但是少了這樣一個展示的機會，他們可能真的會有些失望。
- 還有的同學提到了自己班同學評論自己班同學的作品會有人情分，是否可以2班評1班的，3班評2班的這樣交替評分，希望教師可以考慮。
- 有的同學希望早點開這門課，其實很多學校的同學都提到了這個問題，是否要早開課教師可以考慮。這門課需要大家有一定的編程語言基礎，對編程有了一點點經驗，上課效果會更好一些。
- 可以讓同學們加入代碼行數和PSP時間的統計。我看大家在團隊項目的時候就不再使用PSP了，其實PSP可以貫穿軟件工程的各個階段。
- 可以讓同學們一直修改個人作業中的四則運算，讓同學不斷完善自己的程序，不斷迭代。這樣可以給一些同學不斷增加附加分的機會，讓想進步的同學可以逐漸追上前面的同學。
對同學們的建議
我非常的喜歡這個班的同學，感覺上進的同學占絕大多數。雖然我們遠隔千里之外，但我知道他們在平時一定都是優秀的，因為我們有思想的交流。以下是我對同學們的建議，希望你們可以越來越好：
記得開學初龐同學好像就因為哪里的分數有些問題和我懟了一次，我覺得挺好，能站出來和你懟的都是用心的同學，他們覺得我努力了，但你沒有給我應有的回報。后續幾次的成績發布過程中，也相繼有同學懟我，我很高興，說明大家真的努力在做這件事了，所以才會向我要成績。我一直秉承我的老師的觀點，在班級范圍內，我們可以怎么懟都行，但一旦這件事確定下來了，就是雙方都達成了協議。
發布成績后24小時是一個時間邊界，過了24小時，其實大家就沒有申訴的權利了。這就相當于工程中的deadline，過了deadline，你做出一個多么完美的東西都是沒有用的，因為在deadline的時候你沒有響應我，那以后就再也不用響應了。之前大家一直遵守的都很好，但反而到了期末大家都不守規矩了。因為考試忙，這我很理解，但過了邊界再申訴真的不是一個好方案，所以我可能懟了有些同學，但我并不想表示歉意。
寫好博客很重要，博客是你展示你的思想，總結你的工作經驗的地方。只做不總結，會有進步，但速度會很慢。將你的思想展示出來，與這個世界進行思想的交流和碰撞，得到牛人的指點，你才會進步的更快。世界這么大，讓你的思想出來看看。。。
回復別人的話的很重要，不斷迭代才能做出完美的軟件。鄒欣老師說過：“從windows 1.0 到 windows10，我們將這個“點”去掉了，用了10年。”（大致意思哈，具體細節記不清了，歡迎鄒老師自己來澄清，但這樣的話一定說過）大牛們都一直這么努力的在迭代，我們怎么可以懈怠。
學習就向健身，非一朝一夕能成也。
個人總結
這學期終于結束了，我是開心的，我覺得我感受到了自己的進步。學期初制定的目標基本實現了，與教師經常溝通，印象深刻的溝通就有關于領騎杉什么時候發放、同學們的個人總結應該包含哪些內容啊等；與同學們的溝通也比之前多了很多，與每個團隊的隊長溝通、與意見不統一的同學溝通，雖然也有溝通后結果不如人意的，但我還是努力嘗試了，我覺得這就是自己的進步。在制定評分標準上，我覺得自己還是很用心的，雖然在出差階段評分標準是大史和西瓜來做的，但我覺得我在參與課程設計上還有發揮了一定的作用的。
但是雖然有以上優點，缺點也是不可忽視的（我也對自己來個漢堡點評法）。最后的成績大爆發給了我很深的教訓，這就是在課程中期沒有預見性，這個問題在課程中期就已經暴露出來了，但我沒有給予足夠的重視，最后導致了成績不合理事件，我要負主要責任，也給張老師帶來了很大麻煩。由于這學期期中我個人的工作較多，對同學們的博客評價也不及時，出差階段都是大史、西瓜制作的評分標準，在此再一次展開自我批評，制定評分標準不夠細致，這一點要向西瓜助教學習，細致、認真、考慮的周全。還有一點，自己在班級群聊天中還是少了點雞湯，好像每周除了發布成績就沒什么可說的了，其實如果多了解一下同學們就會知道同學們課業很忙，也幫助大家解決一些時間安排上的困惑。
通過成績大爆發事件，我也學習到了解決辦法，這也是一項不錯的收獲。同學們對這門課越批評，說明對這門課越熱愛，否則就會不愿意吐槽。大家對這門課的吐槽也很認真，說明大家真的在思考，是發自內心的想讓這門課變好，變得更加有意義。
在alpha階段與鄒欣老師不斷就分數計算方法問題進行討論，我不斷的對自己的分數計算方法進行迭代，我覺得這也是我的進步。
感謝的話
感謝鄒欣老師對我的信任，一學期以來鄒老師一直是我的精神領袖，無論任何時候，都能看到他在評論同學們的博客，我有時都覺得不可思議，怎么可以這樣堅持的做一件事，我真的發自內心的欽佩。
感謝周老師，飛龍博士，讓我成為了一個更積極的人，遇事逃避的毛病雖然還存在，但好像比以前要改進不少，與同學的溝通與變多了，自己這學期還寫了幾篇闡述型的博客。鍛煉身體也堅持下來了，感謝周老師送的書和啞鈴，我很愛它們。
感謝張敏老師，這么認真的老師，我要向您學習，孜孜不倦，兢兢業業。
感謝這些同學們，是你們讓我進步，希望通過這門課你們真的有所收獲，如果能找到自己未來想要努力的方向就更好了。
最后還是感謝我的老師楊貴福老師，是他帶我走進了構建之法。
寫了三天終于寫完了，其實很理解同學們的心情，上一天課了，回來還要進行軟件工程，要討論，要寫博客，要寫代碼，但就是壓力才使人進步啊。回首看看這一學期，是不是自己最忙的時候，反而是收獲最大的時候。
文章列表
留言列表
