現代軟件工程 做業 團隊第一個做業

這是現代軟件工程做業系列的一部分

 

1. 團隊成員介紹

介紹每一個成員（照片，主頁，技術特長，在團隊中擔任的角色）。 建議拍一張有創意的合影。 在介紹的時候，能夠採用藝術照等形式， 保護同窗的隱私，不想說明真實姓名的也能夠用暱稱。 

若是投入熱情和努力，這個團隊做業會是你一輩子的精彩回憶（福州大學團隊1，2，北航1， 2）。

 

2. 如何決定我的貢獻分，  如何決定 alpha 階段後換組

團隊項目通常有 alpha 和 beta 階段， 每一個階段都要評 「我的貢獻分」。 在alpha 階段後，咱們要求每一個小組選出一名同窗，他/她自行尋找下一個接納他的團隊。 請和每一個小組成員商量好方式並寫成文字。 

請看《構建之法》 17章關於績效的部分， 小組決定如何決定每一個成員的貢獻分（分數是如何構成， 貢獻分參考連接）

在這門課中,  大部分學生要作」真實的項目」 – 有真正用戶的軟件。  那些 「經典」 的項目, 例如圖書館管理系統, 學生學籍管理系統等,  若是沒有大量模擬用戶，不練習一些實戰的功能，是不符合要求的。  項目要有活的用戶, 只有活的用戶纔有活的需求, 纔有活的場景, 活的測試用例。 只有活的用戶才決定同窗們寫的軟件是否值得使用, 有些團隊寫的小軟件很好用,  在合適的用戶羣中引發共鳴, 短短期內, 就會有幾千到幾萬個用戶, 也有的團隊費了老鼻子勁, 寫出來的東西用戶量小於10, 本身團隊成員包括在內。 這些不一樣的用戶數量會迫使項目團隊反思當初在需求分析, 設計上的問題。 另外這門課並非算法競賽, 或者代碼集中營, 你們比的不是如何快速敲打出某個算法, 而是如何在有限的時間內交付有價值的軟件給特定的用戶。 「真實」這一條件也促使你們作 「現實」的項目和項目管理。 不少學生有宏大的夢想,  可是在短短的 8 周團隊項目時間內, 他們宏大的構想每每由於非技術的因素而轟然倒地，團隊也做鳥獸散。 

既然真實，就會有人員流動的問題，由於：

- 有人想去作更好的項目

- 有人願意去嘗試別的項目和角色

- 有人離開公司（退課）

- 有人和團隊中的人合不來

- 有人以爲本身應該獲得更多報酬 （分數，錢，股票），不肯意在原來的團隊幹了

- 有人作得不好，團隊以爲沒有他更好... 

人員流動致使「可維護性」成爲一個痛點, 不然項目無法生存超過半個學期。 因此，咱們在團隊項目的 alpha 階段後，強制全部團隊必須有一我的離開。 這我的要本身找能接納本身的團隊（不是原團隊），通過新團隊的贊成，雙方談好了 責任/權利/義務/報酬，就能夠在一個團隊工做了。 詳細分析在這裏。

3.  從前人的經驗中學習

採訪本課程的往屆同窗(含外校和畢業生)。現代軟件工程這門課已經上了好幾年了，之前有不少學生作過團隊項目（說不定包括本校的學生），請大家找一個之前的團隊採訪並整理：

• 這個項目叫什麼？項目網頁在哪裏？用多少時間，多少人力開發出來的？發佈時有多少用戶，給了用戶什麼價值？ 如今還有人用嗎?  爲什麼沒有人用了？
• 使用一下這個軟件（若是還有可能的話），稍微評價一下優勢和缺點。
• 調查他們的軟件工程質量指標（參見《構建之法》14章 關於 「軟件工程質量」的描述），例如

  • 源代碼/文檔還有麼？測試用例的數量、測試自動化的程度、每日構建的速度、自動部署系統的效率、代碼覆蓋率、文檔的質量，等等。

• 這個項目可否給咱們團隊繼續開發，源代碼/文檔還有麼?  若是沒有，爲什麼源代碼/文檔沒有保存？
• 項目開發有什麼經驗和教訓？ 爲什麼當時沒有能解決這些問題？若是你要接手開發這個軟件，你會怎麼作？
• 關於學好軟件工程，他們對學弟學妹有什麼具體的、能夠實施的建議。 （不是空泛的套話）