我對軟工有話說
經歷了一學期的軟件工程課程實踐，先給個自己在這門課中學到的東西打個分：
- 編碼能力：★★★
- 代碼質量：★★★★
- 團隊管理：★★★★★
- 風險控制：★★★★
- 解決問題的能力：★★★★★
下面也不寫總結了，想寫的話太多，都融入了團隊總結里，但不會對這門課有太多幫助。下面就我而言談談感受比較深的幾點和建議，希望可以通過自己的努力把這門課改得更好。
1、個人項目的題目設計
個人項目的設計上，建議從一些難解問題里面進行挑選，主要目的是開擴思路與解決問題的能力的培養上，不要是一個簡簡單單的程序題。我覺得今年的個人項目其實就挺不錯的。
這方面最近還在想...
2、團隊項目
2.1 新的團隊組隊模式
我認為，對於一個團隊，必不可失的核心人物是兩個：項目經理與架構師。如果說項目經理是在過程中探索需求與確立開發方向、進度安排、開會研討的角色，那么技術顧問在整個團隊起步時就應當有團隊項目的技術架構設想——包括使用什么技術，學習什么語言，最好可以粗略估算一個功能的實現需要的時長，還能給出一定的引導教程。技術棧的確定有關學習成本，會間接影響項目的進展程度，所以我以為，技術顧問最好是之前有過相關開發經驗或者有過豐富的項目實踐經驗的同學，這樣可以大大減少團隊因缺失經驗而出現停滯的概率。
按照今年我了解到的團隊項目來看，我發現有技術顧問或者叫技術骨干的團隊，最后都做出了相對較好的產品，沒有出現短期或長期停工的不可控情況。
但結合今年的團隊情況來看，矛盾點出現在技術骨干在各個團隊中比例不一 上。項目經理既有全能的技術，又能管理與協調團隊的情況很少，所以一支隊伍至少需要一個項目經理與一個技術骨干。為了協調各個隊中能夠盡可能達到這一點，我認為應當對純自由組隊的制度加以部分限制。至少不應讓很多強力選手扎堆聚集在一個項目中，強者扎堆的團隊可能做出非常驚艷的產品。愚以為，軟工課的初衷是讓每個同學——無差別對待地——都完整體驗一遍類實際生產環境中的軟件開發流程，從而對各個環節的知識有一個結合實踐的新認知。強者的聚集是對其他團隊資源的剝奪，違背了軟工課的初衷——讓每個同學都在實踐中出真知。一個團隊項目如果缺乏帶給大家信心的技術骨干，又沒有嚴格監督控制進度的項目經理，到最后大家水一水完成，演示也不認真准備，那么開發與不開發其實沒有什么區別。
我有幾個想法，但是不太成熟，不知道是否可以對上述情況有所改變：
從個人項目初步評價一個人的能力
從個人項目和結對項目中的個人博客其實可以看出每個同學對一個問題思考的深度、廣度與對待軟工實踐的積極性。個人博客寫得認真負責有水平的人，相信也會當好一個項目經理（從今年的情況來看是這樣的）。
提前放出項目計划與要求，確定項目經理
將在個人項目中個人博客表現較為突出的8位同學作為種子選手，這8名同學將作為第一輪迭代項目的項目經理。同時，為了給予其他同學機會，保留4個項目經理的位置留給剩下的同學，出4名非種子選手作為項目經理。這12位同學通過黃金點游戲進行優先級排序，在課上選擇自選或者給定的項目。
項目策划書與計划安排
這12位項目經理應當在個人項目結束一周后寫一個小小的項目策划書，項目策划書不要求篇幅很長（大約500~1000字左右即可），內容包括但不限於：
- 面向的用戶群體
- web/APP/其他形式
- 擬定使用的語言/工具/開源項目
- 項目期待的角色構成與需求的相關領域知識
項目策划展示
按照個人的想法，希望可以設計一個類似於現場招募的環節來招募到志同道合的隊友。在項目策划結束后，老師將每個小組的項目策划鏈接放在一個博客中，然后要求其余同學對項目進行簡單了解，並寫出自己最想去的三個項目組以及自己適應該項目所會的基礎技能或者以前的開發經驗，寫上自己想應聘的身份：UI/Test/Dev/Product等（三張紙，每張紙上寫上自己的權重比，三個項目的權重比和應當為100）。在第一節課上課期間，助教按照項目組將意向表區分開，第一節課結束后，將每個項目組的意向表分發給各個項目經理。
現場招募
我個人所設想如下：每個項目經理通過自己手里的成員資料意向表自定一個招募隊員的優先級，然后進行現場招募。招募的環節類似於下面的場景：
- 招募分幾輪進行，第1輪，先按照黃金點游戲排名的次序，首先1號項目經理進行邀請。
- 每個項目經理1輪可以挑選1名成員，當1輪結束后，按照和上次挑選的次序相反的順序。比如第2輪，首先應該是12號項目經理進行邀請。
- 某個隊員同意加入某個項目組的話，則成為該項目組的一員，並且不能再被其他項目經理邀請。
- 如果被挑選到的隊員還未有組，並且在邀請項目組的意向表中，且給出的傾向權重大於30，則不得以任何理由拒絕項目經理的邀請；如果被邀請的隊員不在該項目組的意向表中，則可以拒絕該項目經理的邀請，且該項目經理挑選其他成員的機會順延到本輪最后一個。
- 一個團隊最低人數為4人，最高人數為6人。
- 如果一個項目團隊最終招募到的人數達不到最低要求，將拆分合並到其他組中。
2.2 團隊項目第一周
個人覺得很多團隊團隊項目的第一周有一點荒廢，我覺得只有項目經理在寫需求分析等，會讓整個團隊的學習成本轉移到scrum meeting開始后，這樣是不好的。與其這樣，不如在第一周在項目經理寫其他文檔的同時，讓其他同學也做點東西。
更合理的項目起步
為了不荒廢其他隊員的時間，我覺得可以每個隊員在第一周起始時接受項目經理關於學習語言/框架/工具等方面的安排，個人參考建議如下：
- 前端通過modao/mockplus/sketch等進行界面原型的設計，並上傳到Git/TFS上
- 架構師選定某個框架進行學習，並與項目經理一起設計API文檔，並上傳到Git/TFS上
- 開發/測試人員通過學習項目經理給定的任務，將自己做過的demo和實際體驗的心得寫成一篇個人博客。
以上是我的一些初步想法，不成熟的地方還請多多包涵~
之后如果有更好更新的想法會及時更新的！