程序設計團隊項目
團隊作業（一）：團隊展示
參考鄒欣老師的博客《現代軟件工程講義 4 團隊和流程》和《現代軟件工程講義 5 團隊合作的階段》，在接下來的時間里，我們將嘗試以團隊為單位完成一些任務。
任務一：團隊組建
- 3-5人一組，建立團隊
- 認真選擇你的隊友，不必限於同一個寢室/班級
- 組建團隊后，選出一名隊長，並確定隊名
- 每個團隊新建一個博客園賬號，之后將以團隊為單位，撰寫並提交博客
任務二：團隊展示
使用團隊博客園賬號，每隊發表一篇隨筆，內容包括：
- 隊員姓名與學號（標記組長）
- 隊名：要求有亮點與個性
- 隊員風采：介紹每一位隊員的風格、擅長的技術、編程的興趣、希望的軟工角色、一句話宣言等
- 團隊的首次合照：有圖有真相，合照風格可以發揮創意
- 團隊的特色描述，主要描述有別於其他所有團隊的特點或核心競爭力，言簡意賅
- 可參考福州大學團隊展示作業，如：【軟件工程實踐 · 團隊項目】 第一次作業，充分發揮本小組成員的創意.
其他
- 本次作業提交截止時間為本周日23:59
- 隊長或隊員在自己的博客中附上團隊博客的鏈接，並在此處提交
- 每隊提交一份即可
團隊作業（二）：項目選題
任務一：團隊選題
參考『Java程序設計』課程 團隊項目備選題目 ，確定本小組的項目題目。
【注意】：原則上各小組選題不能重復，如有重復，請小組之間協商確定。
- 初步熟悉團隊git的協作方式。項目后續的代碼、文檔都要通過github增量式管理。實現文檔的版本化和增量式管理。
- 初步確立團隊任務計划，將團隊的任務計划添加到github的團隊項目issues里。后續根據時間進度，在每個階段統計open/closed的統計情況，同時通過工具自動生成燃盡圖。（ 生成燃盡圖的方式可參考使用Github生成燃盡圖）
- 采訪老師或有開發經驗的學長，訪談他們關於項目開發經驗、團隊組織方式、團隊成員協作、時間周期安排等包括但不限於上述內容的采訪。采訪前，准備好相應的提綱，做好功課。
任務二：需求分析
- 參考藍墨雲班課中資源，撰寫本項目的《需求規格說明書》，並提交至碼雲。
- 各小組發表一篇隨筆，內容為：撰寫《需求規格說明書》的工作流程、組員分工和組員工作量比例。
- 在隨筆中附《需求規格說明書》的Git鏈接（markdown文件及pdf文件，tip：pdf可由markdown轉pdf工具得到）。
《需求規格說明書》要求：
- 參考《軟件需求規格說明書》國標規范文本，撰寫對應項目的軟件需求規格說明書。
- 除形式上滿足規范文本要求外，整體內容必須圍繞項目實質展開，對所要開發的項目確保盡力做到清晰完整准確。
- 采用分層形式描述，隨着“層”的深入，描述的內容細節越具體。
- 使用一致的圖形符號和文字描述內容。
- 所有的縮寫須事先定義。
- 圖文並茂，通篇文檔有一個統一的樣式風格（對於該md文件，要求團隊內每個人都需進行相應的commit，作為團隊開發的第一次嘗試）。
- 將自己置於讀者的立場——如果對軟件項目不熟悉的人員，通過閱讀這份文檔，能否完全讀懂軟件要做什么。
- 訪問軟件項目的真實用戶，確保軟件真正體現用戶的需求，為軟件最終可用奠定基礎。
- 需求規格說明書里描述的細分功能、邊界范圍等，限定於本學期期末驗收時能達到的功能，最終答辯驗收將對照需求規格說明書進行。 亮點以及未來預期完成的功能，可在需求規格說明書里獨立專章描述。
- 團隊協作，加強分工，需要描述每個成員的具體分工及占整個文檔任務的工作量比例。
- Checklist:
- 引言(5 ')
- 用戶場景（15 '）
- 類圖（10 '）
- 界面原型（15 '）,建議使用墨刀
- 功能描述（20 '）
- 驗收驗證標准（20 '）
- 文檔的圖表、文字、樣式統一且符合規范（15 '）
其他
- 本次作業提交截止時間為本周日23:59
- 組長或組員在自己的博客中附上團隊博客的鏈接，並在此處提交
- 每隊提交一份即可，在博客中注明本次博客撰寫人
團隊作業（三）：確定分工
-
修改完善上周提交的需求規格說明書，並在博客中描述：上次的《需求規格說明書》初稿有哪些不足？修改需同時體現在Github的MarkDown文件與PDF中。（提示：功能考慮不全或需求文檔描述缺少的地方。）（5'）
-
討論制定團隊的編碼規范，討論之前和討論之后，隊員閱讀《構建之法》第四章內容，並討論總結。將代碼規范和編碼原則發布在隨筆上，並說說你們這么選擇的理由。（5'）
-
通過Powerdesigner完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖。(10')
-
進行項目的后端架構設計，要與需求規格說明書中的界面原型設計相對應。（15'）
-
確定團隊分工。請參考"分而治之(WBS - Work Breakdown Structure)"，提供下述內容：（15'）
- 利用象限法確定各個核心需求的優先級，依據需求優先級確定團隊Alpha 版本需要實現的功能，在博客中敘述並給出相應的WBS圖。
- 在團隊管理軟件中（比如Github的Issue，Leangoo等）將各個葉子結點的功能加入，並確定每個子功能的工作量，在博客中給出分配后的截圖。值得注意的是，與學習技術相關的任務也需要考慮在工作量中，開發需要檢驗產出，學習同樣要有結果。PM可以用小Demo演示或學習心得博客作為學習任務的檢驗。
- 給出團隊各個成員（用學號代替姓名）認領的工作，列出當前團隊的TODOList，並在最后給出燃盡圖。
-
描述組員在上述任務中的分工和工作量比例。
-
以上內容發表成一篇隨筆，Alpha 版本的發布時間安排在5月下旬，請各個團隊注意時間結點，盡快開始開發。
-
附錄
團隊作業（四）：描述設計
同學們已經做了需求的分析，也做了詳細的系統設計，畫過了一些小小的類圖/用例圖，對自己要做什么應該有比較清晰的認識了。接下來，我們要怎么做便成了問題。有同學會說，我大概已經知道怎么做了，在腦海里比划着，很多東西都有大致的想法，45度仰頭思考片刻，有了一張宏偉的藍圖，感覺差不多可以施工了。
等等！好像不是自己一個人干，旁邊還有幾個身手不錯的搭檔，況且這對一個人來說，工作量還是很大的，那就大伙分工合作吧，給大家講講自己的藍圖，然后開始分工：
- 張三做前端
- 李四做后端
- 王五來搞數據庫
- ...
大家熱火朝天地干起了屬於自己的活，若干天后，某些部分功能做得差不多了，感覺可以試試，說我們來整合聯調一下：
- 接口怎么是這樣的？跟我想的不一樣啊
- 不是應該有個XXX類嗎？
- 這里不是應該用多態嗎？
- 不對，你的調用順序錯了！
- 我要的數據沒有啊！
- ...
哪里出問題了呢？很顯然是溝通問題，一個人的想法和理解，即使自己覺得很完整，很美好，但是能讓別人理解一致嗎？不見得，同一件事情，如果不溝通清楚，兩個人的理解可能是千差萬別的，所以需要有充分的溝通，盡可能減少歧義的溝通。
溝通要借助工具，我們日常使用自然語言溝通，也是一種工具，只是這種工具常常存在歧義，那么我們用什么能更加准確地描述自己的設計呢？這里推薦UML給大家。
至於UML的基礎知識，課上我們講過了。這里個人理解：把UML作為一種溝通工具來使用。溝通什么呢？溝通設計思想。
問題既然拋出來了，一個團隊如何去描述討論結果，並且確認大家理解一致，我們可能需要用到：
- 用例圖
- 時序圖
- 狀態圖
- 活動圖
要做什么？
- 大家准備如何分工合作
- 找到自己負責部分的核心（或最復雜）模塊做UML練習
博客模板
- 團隊分工（5分）
描述團隊的每個成員分別完成了UML圖的哪些部分，可以選擇多種方式呈現，推薦泳道圖。
- UML（需求規格說明書里已經練習過了整個系統的UML設計，這里不需要對整個系統建模，只需要每個團隊成員找到自己負責部分的核心或最復雜模塊做UML練習）（20分）
- 用例圖（必選）
- 類圖（必選）
- 活動圖（必選）
- 狀態圖（必選）
注：對於每個圖，需描述對應的是系統哪部分、這部分面臨什么樣的問題、這樣的設計解決了哪些問題？
- 工具選擇（大家可以共享經驗，相互推薦，談談為什么選擇這個工具）（5分）
- 最快的可以手畫在紙上，拍照上傳，后面再電子化
- 推薦用上課講過的WhiteStarUML
- Visio
- ROSE
- 搜索選擇其它工具（包括一些在線工具）...
因為一個團隊為完成一個項目，為了信息完整，須將每個人的成果匯集到一篇博客中，由組長提交到作業中。
團隊作業（五）：沖刺總結
沖刺（7次 Scrum）
團隊在日期區間[13-15周]內，任選7天進行沖刺，沖刺當天發布一篇隨筆，共7篇。具體的博文規范如下：
- 第 1 篇 Scrum 沖刺博客對整個沖刺階段起到領航作用，應該主要包含四個部分的內容：
- 各個成員在 Alpha 階段認領的任務
- 明日各個成員的任務安排
- 整個項目預期的任務量（使用整數表示，與項目預估的總工作小時數一致。比如項目A預估需120小時才能完成，則任務量為120。）
- 團隊成員貢獻值的計算規則
- 第 2-6篇 Scrum 沖刺博客是沖刺階段的主要產出，主要包含四個部分的內容：
- 各個成員今日完成的任務（如果完成的任務為開發或測試任務，需給出對應的Github代碼簽入記錄截圖；如果完成的任務為調研任務，需給出對應的調研總結博客鏈接；如果完成的任務為學習技術任務，需給出學習總結博客鏈接）
- 各個成員遇到的問題
- 明日各個成員的任務安排
- 各個成員今日對項目的貢獻量（使用整數表示，如無產出則為0，整個沖刺階段所有成員的貢獻量總和應與項目預期任務量相近）
- 第 7篇 Scrum 沖刺是對沖刺階段的總結，主要包含兩個部分的內容：
- 各個成員今日完成的任務（要求同上）
- 項目的發布說明，主要包含：本版本的新功能，軟件對運行環境的要求，系統已知的問題和限制，軟件的發布方式以及發布地址。
除上述博客內容外，每次 Scrum 沖刺博客都需要提供當天站立式會議照片一張，發布項目燃盡圖，並描述項目整體的進展情況。
參考博客：
http://www.cnblogs.com/ruangong3165/p/6048364.html
http://www.cnblogs.com/CSLaker/p/6079765.html
團隊項目列表
基本要求
- 平台Java、Java Web，Android或iOS平台
- 內容
- 游戲
- 工具
- 自定義
- ...
- 代碼量不要低於2500行
參考項目
歡迎關注“rocedu”微信公眾號(手機上長按二維碼)
做中教，做中學，實踐中共同進步！
-
版權聲明：自由轉載-非商用-非衍生-保持署名| Creative Commons BY-NC-ND 3.0
如果你覺得本文對你有幫助，請點一下左下角的“好文要頂”和“收藏該文”