程序設計團隊項目

目錄

• 程序設計團隊項目
  • 團隊做業（一）：團隊展現
    • 任務一：團隊組建
    • 任務二：團隊展現
    • 其餘
  • 團隊做業（二）：項目選題
    • 任務一：團隊選題
    • 任務二：需求分析
    • 其餘
  • 團隊做業（三）：肯定分工
  • 團隊做業（四）：描述設計
    • 博客模板
  • 團隊做業（五）：衝刺總結
  • 團隊項目列表
    • 基本要求
    • 參考項目

程序設計團隊項目

團隊做業（一）：團隊展現

參考鄒欣老師的博客《現代軟件工程講義 4 團隊和流程》和《現代軟件工程講義 5 團隊合做的階段》，在接下來的時間裏，咱們將嘗試以團隊爲單位完成一些任務。

任務一：團隊組建

• 3-5人一組，創建團隊
• 認真選擇你的隊友，沒必要限於同一個寢室/班級
• 組建團隊後，選出一名隊長，並肯定隊名
• 每一個團隊新建一個博客園帳號，以後將以團隊爲單位，撰寫並提交博客

任務二：團隊展現

使用團隊博客園帳號，每隊發表一篇隨筆，內容包括：

• 隊員姓名與學號（標記組長）
• 隊名：要求有亮點與個性
• 隊員風采：介紹每一位隊員的風格、擅長的技術、編程的興趣、但願的軟工角色、一句話宣言等
• 團隊的首次合照：有圖有真相，合照風格能夠發揮創意
• 團隊的特點描述，主要描述有別於其餘全部團隊的特色或核心競爭力，言簡意賅
• 可參考福州大學團隊展現做業，如：【軟件工程實踐 · 團隊項目】 第一次做業，充分發揮本小組成員的創意.

其餘

• 本次做業提交截止時間爲本週日23:59
• 隊長或隊員在本身的博客中附上團隊博客的連接，並在此處提交
• 每隊提交一份便可

團隊做業（二）：項目選題

任務一：團隊選題

參考『Java程序設計』課程 團隊項目備選題目 ，肯定本小組的項目題目。

【注意】：原則上各小組選題不能重複，若有重複，請小組之間協商肯定。

• 初步熟悉團隊git的協做方式。項目後續的代碼、文檔都要經過github增量式管理。實現文檔的版本化和增量式管理。
• 初步確立團隊任務計劃，將團隊的任務計劃添加到github的團隊項目issues裏。後續根據時間進度，在每一個階段統計open/closed的統計狀況，同時經過工具自動生成燃盡圖。（ 生成燃盡圖的方式可參考使用Github生成燃盡圖）
  
• 採訪老師或有開發經驗的學長，訪談他們關於項目開發經驗、團隊組織方式、團隊成員協做、時間週期安排等包括但不限於上述內容的採訪。採訪前，準備好相應的提綱，作好功課。

任務二：需求分析

• 參考藍墨雲班課中資源，撰寫本項目的《需求規格說明書》，並提交至碼雲。
• 各小組發表一篇隨筆，內容爲：撰寫《需求規格說明書》的工做流程、組員分工和組員工做量比例。
• 在隨筆中附《需求規格說明書》的Git連接（markdown文件及pdf文件，tip：pdf可由markdown轉pdf工具獲得）。

《需求規格說明書》要求：

1. 參考《軟件需求規格說明書》國標規範文本，撰寫對應項目的軟件需求規格說明書。
2. 除形式上知足規範文本要求外，總體內容必須圍繞項目實質展開，對所要開發的項目確保盡力作到清晰完整準確。
3. 採用分層形式描述，隨着「層」的深刻，描述的內容細節越具體。
4. 使用一致的圖形符號和文字描述內容。
5. 全部的縮寫須事先定義。
6. 圖文並茂，通篇文檔有一個統一的樣式風格（對於該md文件，要求團隊內每一個人都需進行相應的commit，做爲團隊開發的第一次嘗試）。
7. 將本身置於讀者的立場——若是對軟件項目不熟悉的人員，經過閱讀這份文檔，可否徹底讀懂軟件要作什麼。
8. 訪問軟件項目的真實用戶，確保軟件真正體現用戶的需求，爲軟件最終可用奠基基礎。
9. 需求規格說明書裏描述的細分功能、邊界範圍等，限定於本學期期末驗收時能達到的功能，最終答辯驗收將對照需求規格說明書進行。 亮點以及將來預期完成的功能，可在需求規格說明書裏獨立專章描述。
10. 團隊協做，增強分工，須要描述每一個成員的具體分工及佔整個文檔任務的工做量比例。
11. Checklist:
    

• 引言(5 ')
• 用戶場景（15 '）
• 類圖（10 '）
• 界面原型（15 '）,建議使用墨刀
• 功能描述（20 '）
• 驗收驗證標準（20 '）
• 文檔的圖表、文字、樣式統一且符合規範（15 '）

其餘

• 本次做業提交截止時間爲本週日23:59
• 組長或組員在本身的博客中附上團隊博客的連接，並在此處提交
• 每隊提交一份便可，在博客中註明本次博客撰寫人

團隊做業（三）：肯定分工

1. 修改完善上週提交的需求規格說明書，並在博客中描述：上次的《需求規格說明書》初稿有哪些不足？修改需同時體如今Github的MarkDown文件與PDF中。（提示：功能考慮不全或需求文檔描述缺乏的地方。）（5'）

2. 討論制定團隊的編碼規範，討論以前和討論以後，隊員閱讀《構建之法》第四章內容，並討論總結。將代碼規範和編碼原則發佈在隨筆上，並說說大家這麼選擇的理由。（5'）

3. 經過Powerdesigner完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖。(10')

4. 進行項目的後端架構設計，要與需求規格說明書中的界面原型設計相對應。（15'）

5. 肯定團隊分工。請參考"分而治之(WBS - Work Breakdown Structure)"，提供下述內容：（15'）
   • 利用象限法肯定各個核心需求的優先級，依據需求優先級肯定團隊Alpha 版本須要實現的功能，在博客中敘述並給出相應的WBS圖。
   • 在團隊管理軟件中（好比Github的Issue，Leangoo等）將各個葉子結點的功能加入，並肯定每一個子功能的工做量，在博客中給出分配後的截圖。值得注意的是，與學習技術相關的任務也須要考慮在工做量中，開發須要檢驗產出，學習一樣要有結果。PM能夠用小Demo演示或學習心得博客做爲學習任務的檢驗。
   • 給出團隊各個成員（用學號代替姓名）認領的工做，列出當前團隊的TODOList，並在最後給出燃盡圖。
6. 描述組員在上述任務中的分工和工做量比例。
7. 以上內容發表成一篇隨筆，Alpha 版本的發佈時間安排在5月下旬，請各個團隊注意時間結點，儘快開始開發。
8. 附錄

• Github項目生成燃盡圖的方式

團隊做業（四）：描述設計

同窗們已經作了需求的分析，也作了詳細的系統設計，畫過了一些小小的類圖/用例圖，對本身要作什麼應該有比較清晰的認識了。接下來，咱們要怎麼作便成了問題。有同窗會說，我大概已經知道怎麼作了，在腦海裏比劃着，不少東西都有大體的想法，45度仰頭思考片刻，有了一張宏偉的藍圖，感受差很少能夠施工了。

等等！好像不是本身一我的幹，旁邊還有幾個身手不錯的搭檔，何況這對一我的來講，工做量仍是很大的，那就大夥分工合做吧，給你們講講本身的藍圖，而後開始分工：

• 張三作前端
• 李四作後端
• 王五來搞數據庫
• ...

你們熱火朝天地幹起了屬於本身的活，若干天后，某些部分功能作得差很少了，感受能夠試試，說咱們來整合聯調一下：

• 接口怎麼是這樣的？跟我想的不同啊
• 不是應該有個XXX類嗎？
• 這裏不是應該用多態嗎？
• 不對，你的調用順序錯了！
• 我要的數據沒有啊！
• ...

哪裏出問題了呢？很顯然是溝通問題，一我的的想法和理解，即便本身以爲很完整，很美好，可是能讓別人理解一致嗎？不見得，同一件事情，若是不溝通清楚，兩我的的理解多是千差萬別的，因此須要有充分的溝通，儘量減小歧義的溝通。

溝通要藉助工具，咱們平常使用天然語言溝通，也是一種工具，只是這種工具經常存在歧義，那麼咱們用什麼能更加準確地描述本身的設計呢？這裏推薦UML給你們。

至於UML的基礎知識，課上咱們講過了。這裏我的理解：把UML做爲一種溝通工具來使用。溝通什麼呢？溝通設計思想。

問題既然拋出來了，一個團隊如何去描述討論結果，而且確認你們理解一致，咱們可能須要用到：

• 用例圖
• 時序圖
• 狀態圖
• 活動圖

要作什麼？

• 你們準備如何分工合做
• 找到本身負責部分的核心（或最複雜）模塊作UML練習

博客模板

1. 團隊分工（5分）

描述團隊的每一個成員分別完成了UML圖的哪些部分，能夠選擇多種方式呈現，推薦泳道圖。

1. UML（需求規格說明書裏已經練習過了整個系統的UML設計，這裏不須要對整個系統建模，只須要每一個團隊成員找到本身負責部分的核心或最複雜模塊作UML練習）（20分）

• 用例圖（必選）
• 類圖（必選）
• 活動圖（必選）
• 狀態圖（必選）

注：對於每一個圖，需描述對應的是系統哪部分、這部分面臨什麼樣的問題、這樣的設計解決了哪些問題？

1. 工具選擇（你們能夠共享經驗，相互推薦，談談爲何選擇這個工具）（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」微信公衆號(手機上長按二維碼)

作中教，作中學，實踐中共同進步！

---

• 原文地址：http://www.javashuo.com/article/p-sooqepmu-eg.html

• 推薦網站：博客園、新浪微博、扇貝背單詞、DKY背單詞小組、有道雲筆記、豆瓣讀書

• 版權聲明：自由轉載-非商用-非衍生-保持署名| Creative Commons BY-NC-ND 3.0

---

若是你以爲本文對你有幫助，請點一下左下角的「好文要頂」和「收藏該文」