2017-2018-1 Java演繹法 小組會議及交互匯總（不定期更新）
第一周會議
今天我們小組開展了第一次團隊例會活動。我們小組將《構建之法》分為了六個部分並由六位成員先分別學習並向組長上傳學習收獲，這次的活動內容便是 交流前兩周小組成員學習閱讀《構建之法》的收獲。
在各位成員的交流中我們將自己所讀的這部分內容的總結與其他人的進行交換，從而對自己還沒有讀到的內容有一個大致的了解。其中組員劉偉康提到的我們要形成 “交響樂隊模式” 的團隊是這次團隊例會中大家共同贊成的觀點，他提出要避免 “明星模式” 失控時一家獨大的狀態，讓每個人都有明確的分工和職責，同時在某位成員工作暫時受到阻礙時，要有其他成員能夠有能力及時補上他的工作。這樣可以讓團隊中的每個人都最大化與格式化自己的力量，不會出現一個人幹活一人偷懶的局面。同時我們也對尚未完成自己閱讀項目的莫禮鐘同學進行了鼓勵，希望他能努力學習，在下一次交流中展現自己的學習成果。
【此次交流總結由 馬軍 記錄】
【2017.10.11晚】
第二周會議
今天（10.18）我們小組開展了第二次團隊例會活動。我們小組主要討論了前兩周我們組的優缺點以及第三周團隊任務的分工等問題。
我們首先確定了第三周團隊任務的大致分工，其中組員劉先潤自薦修圖。在選取遊戲的討論上，我們組意見出現分歧，組長袁逸灝及組員馬軍覺得闖關類遊戲比較容易推銷，莫禮鐘想要新意多一點的RPG養成類遊戲，並且以社交為主，但是我認為開發社交類遊戲消耗的人月太多，所以我們還需要進一步討論選取。
當我詢問到組員們對於團隊特色的描述以及關於團隊前兩周表現的優缺點時，一種自豪之感油然而生。雖然我們團隊剛剛組建，還沒有開發項目、合作的一些經驗，但是我們前兩周一直按照老師的要求執行任務，也參考了《構建之法》上的部分內容改進，我們小組每個人每周都為團隊花費了一些時間，每周例會上暢所欲言的感覺真是不錯，從軟件工程的角度講，我們團隊要爭取做一個?交響樂隊模式的敏捷團隊，相比起其他團隊，我們的交流次數較多。劉誠昊還說，第二周我們小組成員選的遊戲都比較新穎，這樣一種默契和自信是正是我們團隊的特色和優點。大多數組員甚至認為我們組沒有“缺點”，我覺得我們組還是缺少一些磨合，在交作業上也要加強督促力度，不然會耽誤每周團隊總結博客的發表時間。相信在組員們的持續配合下，我們團隊能夠表現得更出色。
【此次交流總結由 劉偉康 記錄】
【2017.10.18晚】
第三周會議
第八周我們小組舉行了會議討論，會議圍繞以下內容進行了討論：
1.上周的采訪後我們形成的結論有哪些？後面如何工作？
2.討論一下馬軍制定的計劃表合不合理？不合理及時修改。
3.（重要）參考QQ群中的用戶需求文件，看看每種軟件的介紹背景，目的，驗收標準，明確並且討論一下我們要做的軟件的相關內容及具體需求。
4.前三周相比起其他組，我們有沒有什麽值得借鑒的地方
對於第一個問題：袁逸灝認為需要將人力主要集中在代碼方面，工作效率要有保證，團隊的開發要做到先苦後甜。除了袁逸灝發表見解，劉偉康同學進行了補充。他認為日後的工作中，要註意寫工作文檔來說明情況，尤其在代碼方面，代碼中要用註釋來寫明代碼的運行邏輯，並註意產品代碼要加入文檔說明，說明內容：類對於用戶的作用，時間記錄，剩余時間預估。劉誠昊作為測試代碼負責人員，他補充以後的工作他們測試代碼這一板塊需要提前將測試項目定好。他認為，測試項目其實就是用戶的需求，這一方面很重要，因此這一項要提前做好。
對於第二個問題：大多同學都沒有異議，馬軍同學認為自己做的計劃表仍然太泛。他認為的問題集中在代碼方面，他期望近期能將需求說明書，界面討論出來。
對於第三個問題：由於該周任務重，而且用戶需求文件篇幅較寬，因此大多同學都沒看完。
【此次交流總結由 袁逸灝 記錄】
【2017.10.26晚】
第四五周交互
當團隊作業進行到第三周時，婁老師給我們安排了一項任務： 采訪老師或有開發經驗的學長，訪談他們關於項目開發經驗、團隊組織方式、團隊成員協作、時間周期安排等包括但不限於上述內容的采訪。采訪前，準備好相應的提綱，做好功課。
由於同學們都沒有經歷過合作開發項目的經驗，所以大家問的問題都差不多是幾個點：
1.如何分工
2.時間上的安排
3.小組凝聚力我也去詢問過各個小組的成員，關於他們小組的時間分配和遇到的難題。我得到的反饋是有些同學擔心小組內代碼水平參差不齊，可能會有較大的代碼任務分配到自己的身上。但他們暫時也沒有想到好的辦法。
而關於這個問題，有些被采訪的老師和學長學姐們意識到了，他們給出的回答有以下幾個方面：
1.全組成員一起敲代碼。
2.選取組員的時候要選取踏實能幹事的組員。
3.發揮各個組員的專長，給他們分配最理想的工作。對於以上方面，我覺得第三點實現起來比較容易，第一第二點實現的困難程度依次遞減。為什麽呢？
- 關於第一點的全體組員一起敲代碼，依照我們小組的打醬油成員（沒錯就是我）來說，大家一起敲代碼確實是能快速提高我自身的代碼水平，但很有可能出現的問題就是：我基礎太弱導致代碼敲不出來，嚴重影響了團隊項目的進度。那麽對於我這種情況的解決方案是什麽呢，我要求小組給我分配更多的關於代碼外的任務：問題討論、博客思路、對於推廣的想法。但敲代碼也不能落下，所以我跟劉偉康討論的結果是：盡可能的分配代碼任務讓我編寫，或者是組員們一起討論編寫，如果我的代碼水平能夠在一段時間內趕上他們，那麽就讓他們把更多的代碼任務分配給我。總的來說就是水平差的人多搞搞後勤，代碼任務可以少分配一點，跟在其他組員的身後多學習提高水平，等水平提上去了就可以獲得一樣的工作量。
關於第二點的選取組員，只能說小組如果凝聚力足夠，組員各司其職，其實不用在團隊組建之前就商量好要和誰抱團，大家都想把項目弄好，有這份心再加上行動，誰都是一個好苗子。
【此次交互任務由 莫禮鐘 完成】
【2017.11.02晚】
第六七周交互
團隊任務已經進行到第六第七周，從開始的規格說明書如何編寫，到現在根據《構建之法》第四章內容討論編碼規範，各個小組已經進入到了開始代碼構架的階段。
為此，我繼續進行著我的交互任務，對各個小組做了一些簡單的問答。bug終結者小組說：他們的需求規格說明書還沒有做到他們滿意的效果，所以他們關於團隊任務的安排是：讓小組成員們對需求規格說明書的任意一章（自選）進行修改，並且在此任務的基礎上讓小組成員們尋找關於APP的素材，並開始對APP的構架。
JaWorld小組說：他們遇到的困難是，會遇到有不懂的代碼，而且擔心趕不上開發進度。
剩下的兩個小組我得到的信息大概與上面兩個小組相同，對於遇到的問題都是一些開發上面的問題。交互反思：
覺得這次和上次的交互比起來太草率而且太不嚴謹了，許多小組都對於我（莫禮鐘）的來意表示疑惑，並且我對他們的提問總是一成不變的：遇到什麽問題？打算怎麽解決？怎麽分工？這些能在團隊博客裏呈現的內容。
交互改進（下一次團隊作業時）：
我會準備一個問題模版並針對當前我們小組遇到的開發問題與其他小組進行探討，讓交互不再是簡單的你問我答環節，而是對於各個小組遇到的問題能互相溝通提出建議或改進，學習其他小組的先進內容。
【此次交互任務由 莫禮鐘 完成】
【2017.11.19晚】
第八周會議
- 期待 劉先潤 的總結！
2017-2018-1 Java演繹法 小組會議及交互匯總（不定期更新）