團隊任務：撰寫《需求規格說明書》

• 團隊組長：袁逸灝
  本次編輯：劉偉康

流程、分工、比例

（比例按照任務的費時、難度和完成情況估算）

• 流程

  確定任務 → 分配任務 → 完成各自任務 → 審核修改 → 匯總整理

• 分工及比例

需求規格說明書

【markdown 鏈接】

【pdf 鏈接】

【注】pdf 版本可以通過點擊“下載”預覽文件：

Git團隊協作初步嘗試

• 本次Git我們并沒有撰寫詳細的 commit 信息，但是都嘗試了一下：

交互總結

考慮到各個小組之間的交流問題，我們團隊的 莫禮鐘 主動提出對接其他小組的任務請求，他主要詢問了一些小組的一些 明星成員，有的同學非常配合小編在此表示感謝，莫禮鐘也針對他的采訪做出了以下總結：

關于第三周團隊采訪的一點小小感想：

• 當團隊作業進行到第三周時，婁老師給我們安排了一項任務： 采訪老師或有開發經驗的學長，訪談他們關于項目開發經驗、團隊組織方式、團隊成員協作、時間周期安排等包括但不限于上述內容的采訪。采訪前，準備好相應的提綱，做好功課。

• 由于同學們都沒有經歷過合作開發項目的經驗，所以大家問的問題都差不多是幾個點：

1.如何分工
2.時間上的安排
3.小組凝聚力

• 我也去詢問過各個小組的成員，關于他們小組的時間分配和遇到的難題。我得到的反饋是有些同學擔心小組內代碼水平參差不齊，可能會有較大的代碼任務分配到自己的身上。但他們暫時也沒有想到好的辦法。

• 而關于這個問題，有些被采訪的老師和學長學姐們意識到了，他們給出的回答有以下幾個方面：

1.全組成員一起敲代碼。
2.選取組員的時候要選取踏實能干事的組員。
3.發揮各個組員的專長，給他們分配最理想的工作。

• 對于以上方面，我覺得第三點實現起來比較容易，第一第二點實現的困難程度依次遞減。為什么呢？

• 關于第一點的全體組員一起敲代碼，依照我們小組的打醬油成員（沒錯就是我）來說，大家一起敲代碼確實是能快速提高我自身的代碼水平，但很有可能出現的問題就是：我基礎太弱導致代碼敲不出來，嚴重影響了團隊項目的進度。那么對于我這種情況的解決方案是什么呢，我要求小組給我分配更多的關于代碼外的任務：問題討論、博客思路、對于推廣的想法。但敲代碼也不能落下，所以我跟劉偉康討論的結果是：盡可能的分配代碼任務讓我編寫，或者是組員們一起討論編寫，如果我的代碼水平能夠在一段時間內趕上他們，那么就讓他們把更多的代碼任務分配給我。總的來說就是水平差的人多搞搞后勤，代碼任務可以少分配一點，跟在其他組員的身后多學習提高水平，等水平提上去了就可以獲得一樣的工作量。

• 關于第二點的選取組員，只能說小組如果凝聚力足夠，組員各司其職，其實不用在團隊組建之前就商量好要和誰抱團，大家都想把項目弄好，有這份心再加上行動，誰都是一個好苗子。（莫禮鐘）

小編感想

　　兩周的任務量其實和之前一周的任務量差不多，雖然也感覺有點多，但是對于凝聚力強的團隊來說不足掛齒。我們本次撰寫的說明書，由于具體頁面和一些功能需求還沒有設計出來，所以在需求規格說明書中我們只能盡可能詳細地描述這些部分，之后的版本還會有修改補充。我們這次的流程分工仍然需要加強，一個組員，如果對于流程不夠了解或者分工不夠明確，必然會對團隊整體造成一定影響，這就導致了團隊效率的下降。我們小組仍然在不斷積累經驗，不知道以后還會有什么挑戰呢？
　　作為一個團隊博客撰寫人員，可能這是個“苦差事”，我認為主要苦在等其他組員完成各自任務之后才能進行完整的總結，才能提交博客。為此就需要在 DeadLine 之前不斷督促一些組員，但是也有一些組員做得很好，每次作業都可以在整體完成階段的中期提交，這樣下來如果檢查時缺少了哪部分內容還可以及時補全，達到預想的效果，這也是一個團隊凝聚力和 敏捷流程 的體現，我希望能夠有更多組員積極配合團隊一起進步。
　　可能每次任務都會有一兩個組員承擔略多的任務，你們多承擔一點，責任就會重一點，但是團隊的瓶頸就會少一點，同時也能鍛煉的自己的能力，你們毫無怨言地接收任務就應該得到表揚。（編輯：劉偉康）

最后吐槽一下吧：一些網站或者編輯器上都會有 markdown 格式，但是碼云上的 markdown 兼容格式真心不太滿意，然而再轉 pdf 時又需要使用另外一種格式，我為此消耗了大量時間。

參考資料匯總

• 軟工團隊 - 需求規格說明書

• 報課系統軟件需求規格說明書

• “一起買APP“需求規格說明書

• ”報課系統“需求規格說明書