軟工團隊 - 預則立&&他山之石

軟工團隊 - 預則立&&他山之石

團隊任務計劃

時間	人員	任務
10.23-10.29	張昭錫	初擬Android代碼規範
	李永盛	初擬PHP代碼規範
	劉晨瑤	初擬Git代碼規範
	劉晨瑤	組織對規範文檔的討論、修改完善規範文檔肯定終板
	李永盛	服務器測試、框架搭建
	蘇偉鵬	學習項目的PHP框架
	陳龍江	學習Android測試工具的使用
	張昭錫、熊立強、陳龍江、胡俊欽、駱景昭	學習Android MVP模式、對照項目需求和原型界面學習Android控件
	李永盛、張昭錫、劉晨瑤	初步架構設計
	劉晨瑤	需求規格說明書終板
	劉晨瑤	完善原型設計
10.30-11.05	劉晨瑤	Alpha終板原型
	劉晨瑤	組織討論和修改架構設計
	陳龍江	編寫測試計劃
	李永盛、劉晨瑤	接口設計文檔
	李永盛、蘇偉鵬、劉晨瑤	數據庫設計
11.06-11.16	劉晨瑤	組織每日站立式會議、把控項目進度
	張昭錫	Android MVP模式框架搭建
	張昭錫、熊立強、胡俊欽、駱景昭	Android客戶端編碼
	陳龍江	客戶端測試
	李永盛、蘇偉鵬	服務器端編碼
	李永盛	服務器端測試
11.17-11.19	李永盛、張昭錫、熊立強、駱景昭、蘇偉鵬、胡俊欽	項目完善
	張昭錫、熊立強、胡俊欽、駱景昭	學習和初步實現推薦文章算法
	李永盛、蘇偉鵬	學習垃圾過濾算法
	劉晨瑤	收集用戶試用反饋，造成總結和改進方案
	陳龍江、劉晨瑤	測試計劃改進
	劉晨瑤	Alpha階段總結
11.20-11.26	劉晨瑤	組織每日站立式會議、把控項目進度
	張昭錫、熊立強、胡俊欽、駱景昭	完善客戶端編碼、加入推薦算法
	陳龍江	客戶端測試
	李永盛、蘇偉鵬	完善服務器端編碼、加入垃圾過濾算法
	李永盛	服務器端測試
11.27-12.03	張昭錫、李永盛、駱景昭、蘇偉鵬、熊立強、胡俊欽	正式版本完善
	陳龍江	同時在線人數等壓力測試
	劉晨瑤、張昭錫、胡俊欽	撰寫用戶手冊
12.04-12.10	劉晨瑤、胡俊欽	撰寫宣傳文案和推廣
	劉晨瑤	發佈正式版本、做出開發總結

細化後的issue：https://github.com/StardustProject/Stardust/issues

他山之石採訪記錄

採訪是的「一不當心就火了」隊，隊長逸超學長和咱們團隊的個別成員認識，交流起來也至關的輕鬆愉快~

項目開發經驗

• Q： 咱們有看到其餘學長寫到，項目的開啓能夠由一個比較有經驗的人把項目的架構寫好，而後再由其餘人進行填充，可是負責安卓端的開發人員都沒有項目經驗，如何開啓一個項目？
  A：咱們當時是寫着寫着就寫起來了，就我本身來講，安卓的話，到目前爲止，整個項目的結構大概就是activity，adapter，請求代碼工具包之類的。具體的話，能夠學一下MVP模式，嘗試一下。用這種方式的話，整個工程結構、層次確定比較清晰，可是初期可能會碰壁，遇到不少坑。或者說大家也能夠用本身的一套規定。​

• Q： 關於接口方面，有什麼建議，須要團隊一塊兒制定嗎？
  A：接口的話，至因而不是一塊兒定義，若是其餘人都不熟悉的話，由熟悉的人一我的來定義也是能夠的。另外，接口文檔要寫好，記錄工具的話就不要再用word了，咱們本身的經驗就是後期文檔太亂，多使用協同工具，apizza能夠嘗試使用一下。

• Q： Android客戶端和後臺PHP端有使用什麼框架嗎？
  A： Android端的話好像沒有。可是大家Android不是要作圖片，通常不本身寫，能夠用glide，網絡請求庫的話，如今比較流行的是Retrofit+RxJava。PHP端咱們當時用的是ThinkPHP的框架，固然作接口開發的話，也有不少輕量級框架能夠用：Lumen、Slim。大家已經搭好的Laravel，比較傾向於全棧方向，屬於比較集成的，固然這些框架的選擇，只要大家以爲OK，均可以。

• Q： 咱們對項目測試尚未一個清晰的概念，學長能說說要如何測試及制定測試計劃嗎？其中要注意一些什麼嗎？測試是手動測試仍是自動測試，若是是自動測試用的什麼工具？
  A：當時的軟工項目上，咱們沒有主要的項目測試人員，項目基本上沒有什麼測試，寫過一個自動化測試測試過登陸界面，主要是對接口進行一些測試。大家要作的話，能夠寫一些單元測試、自動化測試，對每個功能函數進行測試。對於服務端接口的測試，經過堆棧發起請求去請求接口，進行壓力測試。目前暫時能夠不考慮高併發問題，項目後期，對於這個問題，能夠考慮限制流量方式來解決。

• Q: 看《構建之法》裏面說到測試驅動功能，我在結對做業中使用的是測試先行的方式，結果編碼量和編碼時間都指數爆炸。學長是傾向於測試驅動功能呢仍是先寫功能再測試？
  A: 通常我寫是先寫完再測試，好像無論是公司裏面仍是其餘團隊都是這個樣子。

• Q: 整個Alpha階段只有10天，編碼時間相對緊。在這麼短的時間內發佈一個release版本，是一個什麼概念？
  A: 建議的話就是，大家在作以前要把各自的工做給作好，分工要明確。由於咱們以前作的話，最開始分工不明確，並且當時相比咱們上一屆，4我的，他們人數更少。這種編碼的工做不是人越多寫得越快，由於大家還要解決各類衝突，包括代碼的衝突，還有隊員交流這些。因此這個就須要組長好好協調。

• Q: 團隊成員基本沒有項目經驗，學長有沒有什麼建議？
  A: 這纔是鍛鍊啊！Android端，個人建議就是，learning by doing，就是你要這個功能，就去找，以後想深刻了解的話，再去擴展。大家如今作的東西都是會去用而已，好比大家要去實現什麼功能，就去把這個控件學一下怎麼用，然後面若是要深挖的話，就不是隻是會用的程度了，要去了解底層是怎麼實現的。因此大家這個階段沒作過什麼是不要緊的，就是基本上要去學會怎麼用，若是有興趣的話再去深挖。你要寫這個東西的話，最要看的就是，他整個邏輯是怎麼傳遞的，若是你搞清楚了的話，順着那條路慢慢寫，最後確定寫的出來。

團隊成員協做

• Q： 有出現團隊裏某個隊友進度落後全團隊都在等的狀況嗎？這時候怎麼辦？
  A： 咱們當時的服務端的接口都已經完成了，可是其實咱們是在Alpha階段最後一天纔開始對接口的。致使這個的緣由主要也是分工不明確。分工模糊，咱們那時候項目有四個端，不少東西是重複，好比查看結果是同樣的，後面對於重複的界面要用誰的，就炸了，誰也不服誰。

• Q： 學長們都說好基友千萬不要在一個團隊是爲何？是後期衝刺常常鬧矛盾嗎（我的能力致使代碼沒法交付亦或是由於以爲他人寫的代碼「過醜」）？團隊情緒如何把控？
  A： 寫代碼就會有衝突嘛，主要你們要相互理解。咱們當時Alpha階段，安卓端的開發人員就有三人發生衝突。每一個人能力不同，掌握的技能也不同，走在前面的人可能須要等待剛開始起步的同伴，這時候就要耐心一點，固然，每一個人手頭上有可能各類事情，在這種時候要表現出足夠的耐心也是比較難的。另外，各類規範要制定清楚，也能減小一些衝突的發生。對於團隊成員中代碼不優雅的狀況（好比四個for），現階段對於大家團隊的狀況可能比較次要，先把要作的功能作出來，保證功能能正常使用，標記tag，後期來進行產品的優化，由於大家團隊現階段最首要的任務就是如何在這麼短的時間把大家的產品比較完整的作出來。

時間週期安排

• Q： 離第一次的Alpha版本發佈只有一個月左右，學長們是怎麼解決在這麼緊的時間完成大部分的功能的？
  A： 其實大家不要太過緊張，完備規範，明確分工，註釋清晰（註釋必定要寫清楚！！），這樣就能夠了。

• Q： 是否有發生在某一環項目的實際進度趕不上計劃的狀況，應該如何調整？
  A： 熬夜啊。
  Q：？？？

其餘

• Q: 學長的項目分工的時候，爲何沒有一個負責測試的同窗呢？
  A: 由於咱們那個選導系統功能複雜項目太大，任務作不完，後面測試都比較水。接口是有測的，Android端這邊雖然測也是有測，可是單元測試作的就比較少，作了一個登錄界面的單元測試、自動化測試。測試這一塊，後面整合系統的時候也沒有怎麼測。並且中間有個隊友去比賽了種種緣由，後面分工要磨合很困難。並且有些人不熟，人手也不足，因此就沒有作很系統的測試。

• Q: 逸超學長是團隊的PM，可是在Alpha階段也參與了不少編碼工做，爲何？
  A: 其實貫穿整個過程，個人編碼工做仍是挺多的。也是由於這個，致使後面整個組的分工也比較不明確。並且Alpha階段和Beta階段是不一樣人在管，後面磨合也出現一點問題。因此我給大家的建議就是，組長就不要參與編碼，專門管控整個項目就行了。你要的是別人完成得怎麼樣，而不是你也直接參與。

• Q: 那所說的分工不明確是什麼樣，好比說只分了誰去寫服務端，誰去寫客戶端，而沒有分具體誰到某一個模塊這種程度？
  A: 對。由於兩我的作不一樣模塊，後面協調起來，衝突會比較少一點。若是兩我的作同一個模塊，一來代碼會衝突，二來兩我的之間也要互相詢問對方的代碼。

• Q: 我看到有個學長的博客說到AS的git功能很好用，但後面他又說圖形化的界面雖然能提升效率，但根本的仍是命令行，以爲命令行更好。git只是一個工具，若是用圖形界面開發效率更高的話，爲何要執着於命令行？
  A: 那些圖形界面，本質的話用到的仍是命令行。但對於大家現階段的話，爲了追求效率，爲了完成做業，仍是推薦使用圖形界面，就是AS自帶的git功能。可是大家學到後面的話，其實仍是命令行比較好用。由於你選擇命令行的形式的話，你確定對git瞭解更多更深，對於回退、合併、切換分支，你能知道他們具體的命令是什麼樣子的。而後圖形界面的話，有個優勢的話就是，你能夠看到那條分支線，合併操做的話也很簡單。因此二者各有優勢，若是你會用命令行的話，你用圖形界面也確定很好上手。最根本的仍是命令行。

• Q: 我看到當時學長們軟工的commit註釋有相似「整合上屆代碼，氣煞我也，在裏面發現了錯誤」、「隊友須要，改了返回數據格式」、「寫的快奔潰了，感謝產品不殺之恩Orz」，爲何長這樣的pull request也讓過了呢？學長們如今在公司作項目是否有一套固定的git規範？對於commit的註釋須要甚至詳細到操做了哪一個類的什麼函數嗎？
  A: 學長A：你回答，學長B：你是PM你回答，學長A：當時咱們對於git基本沒有制定必定的規範，因此才致使了這個問題。對於git，能夠給大家說說我最近的使用經歷。最開始確定是提交一個最初的master， 而後從master拉出一個dev的分支，按照dev分支這條線，開發人員根據實際拉出一條feature分支，對於feature的命名規範 「版本_開發人員名字_功能描述」，測試好了，再merge到dev分支。

任務分配比例

劉晨瑤	李永盛	蘇偉鵬	張昭錫	駱景釗	胡俊欽	熊立強	陳龍江
20%	20%	5%	20%	10%	5%	5%	15%

反思&總結

在採訪學長以前，把他們隊伍的博客從第一篇起一直看到了最後一篇。看到每日站立式會議照片裏的學長們從薄薄的短袖T恤一直到後來厚厚的羽絨服（其中一個學長正搓着手取暖），忽然間即便還沒開始這段旅程就已經感慨萬分。固然，其中也看到了學長們博客中體現出來的一些問題，都帶有疑慮的在採訪中問了這些不算太正兒八經的不解之處。好比爲何任務分配中沒有測試人員、爲何commit註釋千奇百怪、爲何Alpha階段結束後54張issue卡片還剩下多達12張...雖然問題自己看起來有點不是太友好qwq，但正是經過這些得知了一些很是真實的感覺和真實的狀況，包括後來還問了很多技術上的問題，太多很細緻的問題就沒有一一在上文列出，總之受益不淺。

以及一些本身的反思。問了本身不少次，爲何全部任務不管多早開始，都會在deadline的最後一秒甚至後一秒後兩秒後三秒完成？這個千古難題其實以前在線下就問了學長，學長的回答是安啦，都是常態。可是多次如此，仍是以爲有點難受。

---

據說逸超學長去了美團，然而接受採訪的時候身上穿的仍是美圖的文化衫 （逃