一、駐足當下
1. 課程期望對比
開學初的課程期望——軟件工程的實踐項目課程的自我目標
- 對項目的整個開發流程有一個全面專業的了解
- 掌握《構建之法》的精髓，懂得如何管理一個開發團隊
- 代碼能力以及代碼規范得到進一步的提升
- 做出一個具有網站端又有移動端的項目
- 項目能在各類比賽中大放異彩，並進一步商業化開發，投入市場
- 實踐課保持依舊的魔鬼強度，又有所新的創新，讓我們在敲代碼的時候享受到快樂
課程期望履行情況
從實際項目的最終Beta版本可以看出，現實和期望基本還是挺吻合的：
- 軟工實踐整個過程，作為團隊的PM，在經歷過多次團隊摩擦、意見不合之后，學會了如何處理組員之間的溝通，更加合理高效得管理一個團隊，並通過一系列的任務計划與開會討論，讓整個團隊的編碼階段有條不紊得進行中，讓組員在編碼時有着一個輕松愉快的氛圍
- 我們團隊開發了一個Web端的畢設導師互選系統，而這個系統的安卓版同時也有另外一個小組在開發。
- 因為系統的完成程度較高，所以很可能在下學期系統便會在學院內部上線運行，而后再嘗試着將系統推行到其他學院甚至其他高校，進一步進行商業化的開發，投入使用
- 整個軟工實踐過程中，因為團隊協作和課程需要，我扮演的基本都是一個PM的角色，負責項目進度的把控以及博文的撰寫，所以期望中代碼能力並沒有得到顯著的提升，這也是我整個軟工實踐過程中最大的遺憾，當然，團隊要走得更前，必須有人做出犧牲，雖然說得好像有點假惺惺了，但確實挺可惜的。
2. 自我提升
新軟件
-
Typora：MarkDown編輯軟件
-
XMind：思維導圖的設計
-
Axure RP：原型設計軟件
-
Sublime：高效的代碼編輯器
-
PowerDesigner：數據庫設計軟件
-
ShadowsocksR：翻牆神器，順暢瀏覽github
-
GifCam：動態圖制作神器！無需安裝！只有1.5M！
新工具
- Git的使用
- JUnit單元測試框架的使用
- Wampserver64：Web項目的開發環境
- SourceTree的Github上的項目進行管理控制
- 利用燃盡圖對項目進度進行把控
新語言
- 對PHP、JS、CSS、HTML都有了進一步的了解，但因為充當的不是程序猿的角色，對語言的掌握能力並沒有顯著的提升
新平台
- 全程使用Github平台進行項目的托管，包括Project管理面板的利用、issues的溝通、里程碑的使用等，有效得提高團隊協作開發的效率
- 博客園。一開始讓我寫博文其實我是拒絕的，但是隨着博文越寫越多，才懂得寫好一篇博文也是一門藝術。一開始接觸MD時，內心除了吐槽還是吐槽，標題大小、縮進、排版等等都是一個頭疼的問題，但隨着不停得百度和查閱資料，對MD的使用日益熟練，也養成了屬於自己的博文風格，而且博客作業也多次收到助教們的好評，證明自己的努力還是有收獲的。
新方法
- 撰寫博文的習慣。如今項目開發過程遇到什么問題，都會習慣性得在博客里面記錄下來，這對自己的學習和以后的回顧都是有着一個很好的幫助。
- 通過issues進行項目粒度的划分以及完成度把控。團隊整個開發過程中基本沒有在群里互傳過資料，都是通過issues全員可視化的形式進行管理，包括每一次的總結以及每個任務的完成情況，這樣組員看得到彼此的進度，對自己也有着一個很好的督促作用。
代碼完成量
- 又說到這個尷尬的點了，因為充當PM的角色，在團隊開發過程中基本都是對組員完成的最后情況進行項目的審核，偶爾也會根據commit記錄審核下代碼，但次數較少，因為自己的精力大都是放在整體項目進度的推進以及博文的撰寫，所以在代碼上花費的精力較少。
其他提升
- 團隊協作管理能力
- 良好的溝通能力以及采納意見
- 文檔編寫能力
- 全局觀念以及項目粒度的划分
- 物盡其長，能夠合理得根據組員的擅長進行任務的分配
從團隊的角度來看，整個軟工實踐課還是非常成功的，小組的項目完成度高，組員的分數基本也都是在前十，小組目前也已經有兩名成員獲得了黃色領騎衫（估計還能領一件），這些都離不開每一個組員辛勤的付出。
二、人月神話
1. 項目經驗總結以及例證分析
在整個軟工實踐過程中，我所負責的基本都是項目管理方面的工作，所以我從PM的角度出發，講一下項目的經驗總結。
-
團隊溝通：作為PM，最關鍵最重要的點就是處理好和隊員之間的溝通！一個良好的團隊氛圍是成功的一半。在軟工實踐課剛開始時，我們團隊其實因為選題原因出現過不少的矛盾和摩擦，隊員們都很有自己的想法，我們的選題也因此換了三次，此外在對作業的要求上我可能比較嚴格，很多細節方面都是精益求精，導致團隊初期隊員們的反應較為強烈。我其實一開始挺擔心團隊是否能夠順利得走下去的，但是之后團隊開了多次的會議，經過大家的溝通以及協商，才逐漸確定了彼此的分工和職責，而我自身也把精力放在全局項目的推進上，對於細節方面改成沖刺最后再完善，此外還買了幾次夜宵給隊員，軟工實踐課結束后大家也一起聚餐，整個團隊的氛圍可謂說是越來越好，才造就了我們高效的開發進度。 -
任務分配：要做好一個PM，要學會如何第一時間從布置的任務中提取關鍵信息，並細化粒度分配到各個組員。同樣的，在團隊初期，因為對隊員的擅長了解不多，導致了前幾次團隊作業一兩個組員的任務量十分大，任務分配不均勻。但是隨着團隊的配合，逐漸發現了各個組員的擅長點，比如揚濤的的審美、齊民的盡責、偉煒的強大編碼能力以及妹紙們的心細，並據此分配好各個任務，盡量讓每個組員的任務量盡可能得平均，物盡其長。比如在軟工實踐的隨堂小測上，我在和老師理清了作業的需求之后，便根據每個人的擅長點進行了任務分配。我們有四個人會JAVA，每個人負責一個功能模塊，剩下三個人一個文檔、一個測試、一個圖表制作，在短短的一個上午里便完成了高質量的作業。此外還嚴格要求每個編碼的組員都按照注釋規范給代碼加上注釋，以保證作業的完成質量。 -
團隊結構：我們團隊 的結構屬於1 + 3 + 3模式，即一個PM加3個后台加3個前端，PM負責統籌全局項目推進，然后3個后台前端兩兩配合、結對編程，負責對應的功能模塊。此外團隊博客的撰寫全部由我負責，數據庫的設計由齊民負責，原型的改進由許玲玲負責，算法的編寫以及文檔晚上、圖標設計上面由楊濤負責，此外齊民和偉煒由於出色的編碼能力，團隊的技術指導基本由他們兩個負責，當然因為我們團隊的前端方面不是特別出色，我們又是也會請前端大神——立昊來當我們的技術顧問（感謝立昊(^__^) ）。因此，良好的團隊結構才造就了我們出色的配合默契。 -
項目管理:項目管理是一個PM的主要職責，我們團隊和其他團隊主要不同的地方在於我們的項目管理基本都是在github上面完成的，包括github上project和issues的利用，團隊群里基本沒有互傳過文件。無論是博客里每個組員的心得體會，亦或任務的分配以及項目進度的審核，都是在github完成。這樣做的好處是把團隊的所有工作記錄集中在唯一的一個地方，當組員在查看issues時也可以順便看到代碼的commit記錄，還可以在project看到整個項目的完成度，這樣能加深每個人對項目進展的了解度。 -
issues的利用：issues的利用我想單獨當作一個點來講，因為issues確實是項目管理的一個很好的輔助工具。先說說以往我們是如何進行團隊合作的：任務分配都在群里或則群公告發布，然后定期根據commit記錄審核項目，對未完成的點QQ私聊組員通知，心得體會也是群文件或則郵箱收集，這樣的團隊模式會導致文件太過雜亂或則消息過多，組員可能會遺漏到自己的任務點。反觀依照老師的建議后，我們全程采用issues進行項目的管理，根據項目的功能模塊，發布對應的issues，並注明標簽分配到每個人，被分配到issues的組員github會自動郵件通知，確保了每個人都能及時了解到自己的任務。而在issues的開頭我還會注明這個issues具體的任務要求是如何，每當組員完成對應的任務點時，便把完成情況提交到對應的issues下（文件/演示動態圖/界面截圖等），然后我會把項目拉下來，根據實際的運行對完成情況進行審核，如果有做的不好的地方，我便會在issues里面繼續注明。此外，issues的一個關鍵作用是組員可以看到彼此之間的任務進展，當組員看到其他人的issues一個接一個得關閉，無形之中對自己也有着一種督促作用，畢竟若是issues都是自己的未關閉issues，站立式會議時自己肯定也免不了尷尬。 -
結隊編碼：在Alpha階段和Beta階段時，我們小組經常在活動室一起敲代碼，項目要求上疑惑的點PM可以當場解答，技術上的難點團隊的技術大牛們也能幫忙，整個團隊互幫互助，互相督促，整個開發的效率簡直高得可怕！在第一次活動室結隊編碼之后，組員便一直反應說希望多些這樣的編碼方式，而在Beta階段我們便在活動室一起編碼了好幾次，大大促進了項目的進展。眾人拾柴火焰高，以后的團隊合作里，還會多多采用這樣的編碼環境。 -
沖刺時間的安排：軟工實踐課的強大確實是挺大的，這導致了挺多小組頻繁出現通宵熬夜的情況。作為一名程序猿，雖然說熬夜是基本的技能，但是頻繁得通宵熬夜可能還會適得其反。我們小組在整個軟工沖刺里，就熬過一次夜(Alpha版本驗收的前一個晚上，因為項目合並出現的一些沖突導致了熬夜)，很明顯的我可以感受到在那次唯一的一次熬夜里，隊員們包括我的情緒都變得煩躁了起來，開發效率大大降低，因此之后的話我便再也沒有把沖刺時間段放到晚上。Beta版本的沖刺我們基本都是在白天，晚上最遲10點就結束沖刺，這樣的話也能讓組員有時間休息（畢竟妹紙最多的組，妹紙們還是需要美容養顏覺的），雖然沒有熬夜，但是開發效率卻逐步加快，使得我們團隊在驗收前的一個禮拜左右就基本完成了Beta版本。
三、經驗建議
1. 對下一屆實踐的建議
- 作業分值的處理上盡量合理點，有很多團隊作業的強度和工作量明顯不同，但是最后的分值還都是15分。建議采用加權處理，根據預估的工作量分配分值權重；
- 可以增加一個技術問題記錄的作業，博客這種東西，說實話沒有作業的督促，很少有人會自己花時間去寫技術問題的記錄博客。下屆實踐課可以讓每個學生都養成寫技術記錄博客的好習慣，這樣幾十個人的經驗彼此分享，是一個非常寶貴的知識庫！
- 聽聞下屆軟工實踐可能采取跳槽的新玩法？想法是很好，但現實很殘酷。大學的課堂還是和公司很不一樣的，同學之間沒有那么多的利益爭紛，若采取跳槽的這種制度，是否有考慮到被投票出局的同學的心理感受？因為一個軟工課破壞了彼此間的友誼，我想這是所有人都不想預見的。所以依我看來，跳槽這種制度絕不可取！否則這將會成為軟工實踐課被黑得最慘最厲害的一個里程碑！
2. 對后來人的期許
- 選了軟工實踐課，就要做好付出無數時間精力的准備。軟工實踐課的收獲在分數上是遠遠體現不出來了，它是公司里團隊合作的一個縮影，對我們之后的職業生涯都是有着極大的幫助。
- 組建團隊時一定要考慮周全，團隊里最好至少有一個有項目精力的技術大牛，此外隊員們的積極性的話也得充分調動，不然讓每個人對作業都養成一種隨便敷衍了事的態度，這對團隊而言是一個惡循環。
- 在團隊組建后的初期，要做好團隊之間的溝通，明確好彼此的分工，這對之后每一次的團隊合作都是至關重要的准備工作。
四、團隊分析
《構建之法》里面提到的關於團隊發展的階段共有四個，分別是：萌芽階段、磨合階段、規范階段、創造階段。
萌芽階段：在實踐課初期，考慮到團隊的人員配置以及項目的可發展性，我們經歷了多次選題變更，最終才確定了“畢設導師互選系統”這個項目，並由Android端轉型為Web端。根據系統的特殊性（每個學生大學只用一次），我們確定了我們的項目是基於Web端的，目標用戶是學院的院負責人、系負責人、導師、學生等用戶，並且當項目在學院試用情況良好后，可能還會向其他學院進行推廣。
磨合階段：確立了選題之后，我們根據用戶給定的需求以及自身的實際經驗，進行了項目的思維導圖、數據庫以及原型的設計，並定稿的項目的《軟件需求規格說明書》，在文檔里面對項目的主要功能模塊進行了詳細得介紹，並確定了項目的驗收標准，以保證之后的開發都能嚴格按照驗收標准進行。此外，我們團隊構建了Github的團隊協同環境，確定了編碼規范以及開發工具版本的統一，以避免在團隊開發中出現的代碼沖突。我們還確定了項目的體系結構，采用MVC設計模式以及ThinkPHP框架進行開發，確保項目的完成效率。
附：需求規格說明書
規范階段：在整個軟工實踐過程中，我們團隊經歷過兩次重要的里程碑——Alpha版本和Beta版本。在Alpha版本里，我們團隊完成了畢設選導的主要核心功能模塊，並在驗收時成功演示了整個選導過程；而在Beta版本時，我們主要的工作是修復Alpha版本時出現的BUG以及完善系統剩余的功能模塊，此外因為Beta版本臨時產生的需求變更，導致我們的系統部分界面需要重新設計。但是因為Alpha階段的完成度較高，使得我們Beta版本總體而言的工作量並不會特別大，在驗收前的一個禮拜左右基本就完成了Beta版本的所有功能模塊。
創造階段：在Beta版本完成之后，我們團隊的主要的工作重點便是放在所有模塊細節方面的完善，比如Logo的設計，提示的規范化，界面排版布局的美化等等。此外因為我們的系統很可能會在今后上線使用，我們對實際用戶進行了充分的調研，包括學生用戶、系負責人用戶以及院負責人用戶，並根據用戶的反饋意見對系統進行修補完善。我們還采用了真實數據對系統進行了模擬測試。
經過上述的團隊分析，顯然我們的團隊最后應該達到了創造階段，並很好得完成了項目。
五、文獻筆記
論文 ：《Code quality analysis in open source software development》
摘要 ：開放源碼軟件開發的支持者認為，與傳統的封閉模型相比，使用這種模型產生更好的軟件。然而，很少有經驗證據支持這些要求。在本文中，我們提出的試點案例研究的結果，目的是：（一）了解結構質量的影響；（二）計算出的結構質量分析的代碼由開源風格開發交付的好處。為此，我們測量了100個應用程序編寫的Linux的質量特性，使用的軟件測量工具，並與工業標准，該工具所提出的結果進行了比較。本案例研究的另一個目標是調查的問題，在開源的模塊化，這種特性被認為是至關重要的開源這種軟件開發類型的支持者。我們有經驗評估的應用程序組件的大小和交付的質量通過用戶滿意度測量之間的關系。我們已經確定，在一定程度上，應用程序的平均組件大小與此應用程序的用戶滿意度呈負相關。
在大一時最開始寫代碼時，自己的代碼質量簡直是慘不忍睹，變量的定義都是隨隨便便什么abcd，縮進什么的也都沒有考慮，導致后來回頭再審視自己的代碼時，都不知道自己在寫什么。之后大一的暑假，根據《馬士兵的JAVA教學視頻》自學了JAVA，更重要的是對代碼質量第一次有了全新的認識，學會了大小駝峰命名法、注釋的規范寫法以及接口的抽象和面向對象設計的思想，整個代碼質量有了一個突飛猛進的變化。自己現在日常在寫代碼時，都有着屬於自己的編碼風格，並會習慣性得加上注釋，方便日后可能的再利用。
如何審核代碼質量關鍵有一下幾點：1. 代碼注釋；2. 編碼規范（各種命名）3. 代碼的可擴展性和可移植性
六、項目分析
1. 研發出符合用戶需求的軟件
我們的項目定位比較明確——畢設導師互選系統。整個項目的開發都是基於用戶（棟哥）所給定的需求，而對於需求變更也進行了相應的處理，以保證最終的產品完美得符合用的需求。此外，因為項目的性質比較特殊，若當學院采用了我們的系統進行畢設選導，那么用戶量基本不成問題，政策要求的話，所有老師和每一級的學生都會成為我們的用戶，而且當系統試用情況不錯之后，我們還會向其他學院甚至其他高校推廣我們的系統，以進一步得擴大用戶群體。
2. 能在預計時間內發布“足夠好的軟件”
從上述的團隊分析里可以看出，我們團隊有着完整規划性的開發流程，從項目規划=>需求=>設計=>實現=>發布都依次經歷過，但是系統因為還未上線，所以維護階段暫時沒有精力。我們團隊采用github進行項目的托管以及團隊的協同開發，並利用每次沖刺會議里展示燃盡圖以及項目的進度，而在項目的issues里面也可以看到每一個任務點對應的完成時間點以及完成情況，這充分表明了我們團隊能在規定的期限里很好得完成項目的開發。
- Alpha版本燃盡圖
- Beta版本燃盡圖
- 項目Beta版本的部分issues
3. 軟件的可維護性和可發展性
整個系統項目托管在開源的github平台上面，以便后來者可以在我們項目的基礎之上進行發展和開發。此外，項目相關的文檔也均匯總在github項目下的doc文件夾里面，項目使用者可以根據文檔內容對整個系統有着一個充分全面的了解。我們團隊在項目開發過程中，后台部分采用了接口的設計，增加了項目的可移植性的靈活性，利於之后的維護和進一步的發展。
此外，我們團隊還推出了系統的官方網站，這樣用戶是需要一個網址，便可以在官網上面可以了解到這個系統的大概功能以及運行流程，也可以看到關於我們團隊的相關信息。用戶若是對系統感興趣，可以通過官網上面的聯系方式直接聯系到我們團隊。
七、自我風采
031402304 陳燊
愛代碼，愛運動、愛美食、愛生活，江湖人稱燊哥哥
我叫陳燊（shen 第一聲！），來自於“我說的都隊”團隊，是團隊的PM兼職業軟文寫手。因為身為組長的原因，我在實踐課上“拋頭露面”的次數比較多，所以感覺同學們和老師應該得記得我（至少知道我名字怎么念！）我是一個“完美主義者”，組員們的眼里的“強迫症患者”（其實是認真！負責！嚴謹！好嗎！），無論任何事情都要盡可能得做到最好，最直觀得體現就是所寫的博客上面即使多一行少一行空格我都感覺不舒服，一定得讓整個版式規整統一！雖然“完美主義”確實耗費了我不少的時間精力，但是也直接保證了我們團隊每一次的作業 完成質量！
再者呢，就像我個性簽名說說的那樣，我這個人呢，比較矛盾，喜歡宅在宿舍敲代碼卻又向往健身和打球，喜歡各種美食卻迫於某些原因不得克制自己的吃貨欲望，喜歡音樂舞蹈卻天生五音不全（不過幸好高中時有在晚會上跳舞唱過歌，也沒留下什么遺憾了）。
總而言之，很幸運遇上軟工實踐，很幸運遇到你們，很幸運遇到“我說的都隊”，人生不說再見，青春永不謝幕。往后的日子，我一直都在！
"我說的都隊"——拍攝於文樓，一群要搞事的程序猿
