這是現(xiàn)代軟件工程作業(yè)系列的一部分

1. 團隊成員介紹

介紹每個成員(照片，主頁，技術特長，在團隊中擔任的角色)。 建議拍一張有創(chuàng)意的合影。?在介紹的時候，可以采用藝術照等形式， 保護同學的隱私，不想說明真實姓名的也可以用昵稱。?

如果投入熱情和努力，這個團隊作業(yè)會是你一生的精彩回憶(福州大學團隊1，2，北航1， 2)。

2. 如何決定個人貢獻分，??如何決定 alpha 階段后換組

團隊項目一般有 alpha 和 beta 階段， 每個階段都要評 “個人貢獻分”。 在alpha 階段后，我們要求每個小組選出一名同學，他/她自行尋找下一個接納他的團隊。 請和每個小組成員商量好方式并寫成文字。?

請看《構建之法》 17章關于績效的部分， 小組決定如何決定每個成員的貢獻分(分數(shù)是如何構成， 貢獻分參考鏈接)

在這門課中,? 大部分學生要做”真實的項目” – 有真正用戶的軟件。? 那些 “經(jīng)典” 的項目, 例如圖書館管理系統(tǒng), 學生學籍管理系統(tǒng)等,? 如果沒有大量模擬用戶，不練習一些實戰(zhàn)的功能，是不符合要求的。? 項目要有活的用戶, 只有活的用戶才有活的需求, 才有活的場景, 活的測試用例。 只有活的用戶才決定同學們寫的軟件是否值得使用, 有些團隊寫的小軟件很好用,? 在合適的用戶群中引起共鳴, 短短時間內(nèi), 就會有幾千到幾萬個用戶, 也有的團隊費了老鼻子勁, 寫出來的東西用戶量小于10, 自己團隊成員包括在內(nèi)。 這些不同的用戶數(shù)量會迫使項目團隊反思當初在需求分析, 設計上的問題。 另外這門課并不是算法競賽, 或者代碼集中營, 大家比的不是如何快速敲打出某個算法, 而是如何在有限的時間內(nèi)交付有價值的軟件給特定的用戶。 “真實”這一條件也促使大家做 “現(xiàn)實”的項目和項目管理。 很多學生有宏大的夢想,? 但是在短短的 8 周團隊項目時間內(nèi), 他們宏大的構想往往因為非技術的因素而轟然倒地，團隊也作鳥獸散。?

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

- 有人想去做更好的項目

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

- 有人離開公司(退課)

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

- 有人覺得自己應該得到更多報酬 (分數(shù)，錢，股票)，不愿意在原來的團隊干了

- 有人做得很差，團隊覺得沒有他更好...?

人員流動導致“可維護性”成為一個痛點, 否則項目沒法生存超過半個學期。 所以，我們在團隊項目的 alpha 階段后，強制所有團隊必須有一個人離開。 這個人要自己找能接納自己的團隊(不是原團隊)，經(jīng)過新團隊的同意，雙方談好了 責任/權利/義務/報酬，就可以在一個團隊工作了。 詳細分析在這里。

3.? 從前人的經(jīng)驗中學習

采訪本課程的往屆同學(含外校和畢業(yè)生)。現(xiàn)代軟件工程這門課已經(jīng)上了好幾年了，以前有很多學生做過團隊項目(說不定包括本校的學生)，請你們找一個以前的團隊采訪并整理：

• 這個項目叫什么？項目網(wǎng)頁在哪里？用多少時間，多少人力開發(fā)出來的？發(fā)布時有多少用戶，給了用戶什么價值？ 現(xiàn)在還有人用嗎?? 為何沒有人用了？
• 使用一下這個軟件(如果還有可能的話)，稍微評價一下優(yōu)點和缺點。
• 調(diào)查他們的軟件工程質量指標(參見《構建之法》14章 關于 “軟件工程質量”的描述)，例如

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

• 這個項目能否給我們團隊繼續(xù)開發(fā)，源代碼/文檔還有么?? 如果沒有，為何源代碼/文檔沒有保存？
• 項目開發(fā)有什么經(jīng)驗和教訓？ 為何當時沒有能解決這些問題？如果你要接手開發(fā)這個軟件，你會怎么做？
• 關于學好軟件工程，他們對學弟學妹有什么具體的、可以實施的建議。 (不是空泛的套話)

總結

以上是生活随笔為你收集整理的现代软件工程 作业 团队第一个作业的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。