一、團隊采訪概況
- 1、采訪團隊：《一起買》開發團隊
- 2、采訪形式： 團隊-團隊
- 3、采訪內容的提煉
- 4、部分提問及采訪心得
二、團隊采訪內容提煉
針對項目選題
- 游戲更側重游戲的策划以及PS的美工，這兩個項目決定了游戲質量的好壞，而編碼部分需要的內容並不太多。
針對開發經驗
- 學長們的團隊和我們是很相似的，因為我們的團隊都沒有開發經驗，面對沒有開發經驗的團隊，我們要明確團隊內部的模塊划分，每個模塊內部的人員要以一個內容，貫穿始終，而不是簡單地去按功能划分，這樣會導致每個人要做的內容都有交集，而沒有經驗的情況下，就會加大團隊的學習內容。
針對團隊的組織方式
- 與開發經驗類似，團隊的組織要求分工明確具體，每一個人都需要有自己負責的內容和學習的工作。
針對成員協作
- 需要一個詳細的接口文檔，將每一個部分作為銜接，要確保每一個內容雙方都根據接口文檔進行交接，對於命名規范，有詳細的規定。在協作同時，團隊內部要多交流，盡量能夠在一起開發，規避不一致帶來的問題和風險。
針對時間安排
- 在學習階段，目前的籌備階段，盡量能去做就去做，能多學一些內容就趕着學一些內容，方便在項目的沖刺階段可以直接拿起來用，減少時間的浪費。提高效率。
- 在項目的沖刺階段，將編碼任務盡量多的提前，之后節約出的時間，安排給單元測試和其他重要的測試。
針對GitHub管理
- 希望有一個人來專精，通過GitHub管理來進行分支的操作，如合並等等。
針對技術的實現
- 如數據庫的管理，數據庫的部署，跟隨學長做了一些經驗的交流。同時對於邊學邊做，寫一個Demo的學習方式將會加快我們的學習速度。
重點需要去把握的問題
- 1、git的分支合並
- 2、接口文檔問題
- 3、需求的修改問題
三、團隊成員的部分提問+心得體會 （摘要）
問題1：學長你們開發中不同模塊間如何協調，比如像界面和數據庫，在界面沒有寫好之前沒辦法去寫數據庫函數去綁定按鈕啊。
- 學長答：我們界面和數據庫是同步進行，兩者間的協調是通過——接口文檔。在文檔中詳細到函數接口，函數的命名，乃至按鈕的id，都是統一的，這樣的話，兩組人員只要完全按照文檔的要求來寫，后期合並后就可以實現交互了。
問題2：你們團隊間的交流呢，是組長統一協調分派任務，各自在宿舍完成自己的任務，還是團隊待在一起寫代碼。
- 學長答：因為我們宿舍都在隔壁間，就沒有特意找個活動室一起做。倒是交流的話，我們在項目后半階段是每一都開一次會，大家相互匯報進度和問題，這個你們老師之后也會跟你們強調的。
問題3：你們之前強調說項目的開發都是完全依照文檔進行的，那么你們是否有修改過文檔，例如像某個技術上的難題，很難解決，所以減低要求，修改文檔
- 學長答：文檔修改肯定是有的，你在進行開發之前是不會預料到會遇到哪些那題，開發過程中也會有很多想法去改進。所以我們的建議是你們初期最好圍繞核心需求，盡量的簡單。
-
收獲：通過本次的采訪，再次讓我認識到了文檔的重要性。團隊開發中每個人都有自己的任務，要高效率的開發項目顯然是不能用你寫完了我再寫的方式來，而如果同步的話那就必須確立統一規范。在本次的采訪中，學長除了回答我們的問題外，也向我們講了他們開發過程中遇到的坑和經驗。隊員間一定要互幫互助，不能只盯着自己的任務做，做完了就不管了，哪位同學的工作量比較大，就應該去幫助負擔一下。
-
通過學長的建議，意識到合理分配任務以及團隊協作是非常重要的，由於隊員都是沒有開發經驗的，而且安排過多過雜的任務會導致每個人的學習任務過重，因此按照所需要學習的內容將每個人的任務獨立開來是個不錯的辦法。另外定期安排會議，促進隊友間的交流也是必不可少的。
- 按照不同的模塊去安排成員的學習任務，專門學會學好某一個要用的技能。學習新知識的時候，不要光看書，動手去做做樣例，邊做邊學。成員之間要多多交流，也要寫好文檔，做好不同模塊間的銜接工作。此外，最好有專人負責github的分支合並等工作，做好團隊協作工作。
四、采(mian)訪(ji)現場
