相關博文目錄：
團隊信息
本頁點評團隊1-22，其他組見：http://www.cnblogs.com/xiaozhi_5638/p/4490764.html
| 團隊編號 | 博客園團隊博客 |
|---|---|
| 1 | FOR THE DREAM |
| 2 | 思甜雅 |
| 3 | 平常心 |
| 4 | 沉睡魔咒 |
| 5 | 藍色夢想 |
| 6 | 進擊的代碼 |
| 7 | 追夢人 |
| 8 | One Piece |
| 9 | 四傻大鬧齊工大 |
| 10 | 粉末 |
| 11 | Dream high |
| 12 | 軟件工程學習小組 |
| 13 | 躥吧 妮兒 |
| 14 | 代碼海洋 |
| 15 | KING |
| 16 | 奔跑的蝸牛 |
| 17 | 狩獵的時間到了 |
| 18 | 非常4+1 |
| 19 | 19 |
| 20 | 天天向上 |
| 21 | 翱翔的飛鷹 |
| 22 | 團隊博客206 |
NABCD點評
團隊項目里一下子要做的幾個都是比較抽象的東西：
- 協作與分工
- 立項（NABCD大法。。）
- 功能設計
- 用例圖、類圖、時序圖等
- 測試計划
前兩次作業分別是PSP和結對編程，上述幾個內容都沒有得到充分的有效訓練，導致同學們做這幾個環節整體流於形式。不能抓住重點。
簡單確定團隊成員之后，不應該直接就分工了。一般來說立項是第一位的，如果不能確定軟件要不要做，要做什么，分工有個屁用。而立項，根據《構建之法》，我們知道NABCD是一種有效的模型，大家稱為NABCD大法。不過我的角度看來，大家還只是在字面意義上去使用NABCD了，有NABCD和沒NABCD區別在哪？我認為以上的其他部分都可以圍繞NABCD的去做。
那好，我們就說用NABCD了:
N，我認為N一定要分析目標用戶群，搞清楚：誰是用戶，他們的需求是什么，現有的軟件解決了他們的什么問題，沒解決的問題是什么，然后，我們的Team才決定去做一個軟件解決這些用戶的需求。用戶可以是自己，也可以是班上的同學，也可以是網絡上的其他人，但一定要有用戶。沒人用，你做的都是無用功。一般來說，能搞明白面向的用戶是誰、能解決的核心問題，就是最基本的。需求也不是自己拍腦袋想出來的，多半你還是需要去和你的用戶溝通，做用戶需求分析，否則你想象出來的需求根本不存在，在整個項目周期內，需要反復從用戶哪里得到反饋。
A，這個地方你大可以針對N里的需求做分析、設計。分析的話可以做個基本需求分析、高級需求分析、擴展需求分析等。設計，才是你們需要用上用功能設計、用例圖、類圖、時序圖的地方。
B，好不容易做了分析、做了設計。總得說下如果要去實現的話，做好了這個軟件。用戶會不會被吸引去使用，怎樣才能被吸引？B要思考的就是我們的軟件經過A之后，會不會根本不夠吸引用戶去使用，如果是的話，那就要返回去思考N和A是否有問題。如果有問題，就一定要回歸分析、設計了。如果連自己都說服不了，不值得寫代碼。
C、如今早就是滿世界都是軟件了，你做一個一模一樣，完全功能都一樣，甚至更全的軟件估計都沒什么競爭價值了。那么問題來了，怎樣才有競爭力，競爭力意味着別人死活都比不過你。這個就要絞盡腦汁的。
D、請返回看你的N，如何讓他們用上軟件，解決他們的問題，並讓它們得到B，你的軟件他們會用多久呢？
以上幾個點，並非一次了事的事情，會貫穿整個軟件生命周期，需要隨時更新和調整。然后，就開始開工了，無論是瀑布模型還是敏捷開發，盡早往github上提交代碼啊。寫了一堆東西，一行代碼都沒看到呢？第一天就可以初始化項目目錄，工程文件，趕緊往github上提交唄。一個月時間不抓緊怎么能做出高質量的軟件。在經驗不夠的多的情況下，能一個team在一起協作多寫代碼才更真實吧，那些抽象的名詞也沒辦法不寫代碼只寫博客就能理解。盡早做出有人用的軟件才是真正的目標。
評分
7月8日更新，重要：
- 程序部分里的代碼提交部分單獨拆出評分，請還沒提交或者提交不完整的團隊，補交完整項目代碼，截止日期2015年7月15號。Fixed!
- 博客作業逾期（超過一周）未提及的，會直接倒扣分數。
| 團隊編號 | NABCD(10) | 程序(10) | 運行與總結（10） | 代碼提交(10) | github | 備注 | 總分（3:2:3:2） |
|---|---|---|---|---|---|---|---|
| 截止時間 | 5月24 | 6月14 | 6月21 | 6月21 | |||
| 19 | 8 | 8 | 8 | 8 | 完整 | 80 | |
| 4 | 6 | 8 | 7 | 8 | 完整 | 71 | |
| 2 | 6 | 8 | 7 | 8 | 完整 | 71 | |
| 3 | 7 | 6 | 7 | 7 | 完整 | 68 | |
| 7 | 7 | 7.5 | 7 | 5 | 完整（7月10號更新提交） | 67 | |
| 13 | 7 | 7.5 | 7 | 4 | 提交了單個文件，無后綴名 | 請提交完整項目工程 | 65 |
| 14 | 6 | 7.5 | 7 | 4 | 提交了一個txt文件 | 請提交完整項目工程 | 62 |
| 20 | 5 | 7.5 | 7 | 4 | 提交了一個Md文件 | 請提交完整項目工程 | 59 |
| 12 | 7 | 7.5 | 7 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 57 |
| 18 | 5 | 7.5 | 6 | 4 | 項目不完整 | 請提交完整項目工程 | 56 |
| 22 | 4 | 5 | 6 | 7 | 完整 | 54 | |
| 6 | 6 | 7.5 | 6 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 51 |
| 10 | 6 | 7.5 | 6 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 51 |
| 11 | 6 | 5 | 4 | 4 | 提交了單個文件，無后綴名 | 請提交完整項目工程 | 48 |
| 15 | 3 | 3 | 7 | 5 | 有未實現代碼 | 請提交完整項目工程 | 46 |
| 16 | 5 | 7.5 | 4 | 2 | 提交了單個文件，無后綴名（7月15號更新提交） | 命令行版變成GUI版？請提交完整項目工程；7月15更新：重寫了命令行版的總結。 | 46 |
| 9 | 6 | 7.5 | 4 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 45 |
| 17 | 4 | 2 | 5 | 5 | 完整（7月10號更新提交） | 41 | |
| 21 | 6 | 2 | 6 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 40 |
| 1 | 5 | 3 | 5 | 0 | 無，博客有代碼 | 請提交完整項目工程 | 36 |
| 5 | 5 | 4 | 2 | 3 | 提交了單個文件，無后綴名 | 命令行版變成GUI版？,請提交完整項目工程 | 35 |
| 8 | 7 | -5 | 2 | 2 | 提交了單個文件，無后綴名（7月10號更新提交） | 命令行版變成GUI版？,請提交完整項目工程,面向對象程序設計超過一周未提交 | 21 |
優：
- 總體上每個團隊還是堅持到了最后，完成了大部分必要的環節
- 一部分同學至少學會了完整提交github，如果能整個開發周期都在github上協作就更好了
- 項目的立項和分析，NABCD環節，總體上有了個初步的接觸，想必以后做其他項目的時候大家會想到這個大法
- 無論自己寫的還是基於已有代碼做的，都至少做了一些
劣：
- 老師布置的環節有的團隊沒做完整，比如面向對象程序設計，運行和總結
- 只要少數幾個團隊認真提交了github，一部分提交了單文件，另一部分沒提交，還有的沒看到代碼，也說明了團隊的程序開發並沒有全程使用github的版本化功能
- 有很多博客內容摘抄的痕跡明顯，其實如果是引用別人的文章，至少要加引用說明，可以引用，但是一定要有結合自己項目理解並認真寫的部分，列個參考資料也比直接抄強
- 整個團隊項目過程中，可能是由於期末同學們忙於各種考試的原因，體現出工程方法的比較少
- 團隊的博客里應該說明團隊里每個成員的實際做的事情，以及協作解決問題的過程中如何使用工程方法解決的，但很多團隊博客只寫了博主自己干了什么
- 團隊項目代碼做的質量並不如結對編程的代碼質量，可能是由於期末的原因吧，多人協作的項目至少要有足夠的代碼數量吧，很多太簡單了，還不如結對項目
- 如果是基於已有項目的代碼，至少應該說明下，本項目基於之前誰誰誰的哪個版本的代碼上開始做，自己做的部分主要添加了哪些東西，最重要的是，自己做的部分是什么
未來改進點
- 第一周個人項目的時候，一定要嚴格考核每個同學的Git使用能力。比如可以設置只有通過Git考核的才能進入下一個環節（結對編程）項目，而不進入下一個環節就不能得下一個環節的分數，這樣寧缺毋濫的要求下，必然不會出現到了團隊項目還不會正確使用Git以及在Github上協同開發。單元測試也要嚴格通過。
- 結對編程的時候，一定要嚴格考核每個小組的編碼規范能力，以及兩人協同開發的能力。如果一個班級都采用一種語言開發，比如Java，那么此時可以要求在教師指定的編碼規范里挑選一種並且嚴格執行。協同開發，在Github上必須有兩人協作開發的fork-pull-request記錄。
- 團隊項目的時候，必須一開始就說明團隊博客地址+團隊項目的Github倉庫地址。必須為團隊項目在第一天就建立團隊項目的Github倉庫，並且每個階段都必須有所有團隊成員的fork-pull-request提交記錄。
- 選題要說明是重新開發的項目還是在已有項目上開發，如果是在已有項目上開發，應該在NABCD里重點說明已有項目的背景，及其需要改進的點，或者哪些新需求，這樣才能有的放矢，在后續的環節里明確說明團隊改進和新增部分的內容，而不能用已有項目本身的代碼充數。
- 對於學生來說，還是應該圍繞可運行的項目代碼為核心，任何一個環節都應該保證Github上提交的代碼是當前可執行的。
- 可以的情況下，應該要求必須反饋助教或者老師的建議，不反饋者直接扣分，否則給出的建議都沒有跟進。