BugPhobia回顧篇章：團隊Alpha階段工做分析

0x00：序言

1 universe, 9 planets,

204 countries,809 islands, 7 seas,

and i had the privilege to meet you.

To the searching tags, you may well fall in love with http:// 10.2.26.67

 

0x01 ：敏捷開發原則評估

0x0100：敏捷開發的基本原則

（1）儘早並持續地交付有價值的軟件以知足顧客需求。 （2）敏捷流程歡迎需求的變化, 並利用這種變化來提升用戶的競爭優點。 （3）常常發佈可用的軟件，發佈間隔能夠從幾周到幾個月，能短則短。 （4）業務人員和開發人員在項目開發過程當中應該天天共同工做。 （5）不管團隊內外，面對面的交流始終是最有效的溝通方式 （6）以有進取心的人爲項目核心，充分支持信任他們 （7）可用的軟件是衡量項目進展的主要指標 （8）敏捷流程應能保持可持續的發展。 領導, 團隊和用戶應該能按照目前步調持續合做下去。 （9）只有不斷關注技術和設計才能愈來愈敏捷. （10）保持簡明 - 儘量簡化工做量的技藝 - 極爲重要。 （11）只有能自我管理的團隊才能創造優秀的架構, 需求和設計. （12）時時總結如何提升團隊效率, 並付諸行動。

 

0x0104：敏捷開發的團隊評估

從基本的論述方案中，BugPhobia團隊通過嚴謹論述，分析認爲對於如下三方面的原則，團隊在敏捷開發階段感覺最爲深入：

（5）不管團隊內外，面對面的交流始終是最有效的溝通方式 （9）只有不斷關注技術和設計才能愈來愈敏捷. （12）時時總結如何提升團隊效率, 並付諸行動。

實際在學霸在線系統Alaph階段的開發工做中，不妨首先去借用《構建之法》中總結的敏捷原則，去印證團隊在軟件開發過程當中對效率和討論的專一調研。

在團隊敏捷開發的實踐過程當中，團隊自己時刻總結有利於提升咱們團隊效率的方法，而且切實實踐，咱們在提高效率的過程當中密切關注技術和設計，以使得咱們的開發流程總體敏捷效率較高，並呈現穩步上升的趨勢。所謂「磨刀不誤砍柴工」，基於集市方案的配置，團隊架構師致力於嘗試新的技術和工具，而且在面對面的交流之中將其推廣給團隊的全部的開發人員，雖然前期的學習成本不容忽視，甚至因爲團隊管理疏忽而沒有正視高昂的學習成本，使得在軟件開發的前期階段一度陷入「力不能及」的消極工做狀態，但儘管萬事開頭難，一段實踐與磨合後開發人員與架構技術獲得了很好地融合，從而能夠將工具的性能極大地發揮出來。正如《構建之法》中強調的觀點，「創造和使用工具是人類和普通動物的最大差異」。咱們由於關注技術和設計，勇於嘗試新的符合咱們需求的技術和工具，咱們的團隊在開發的過程當中愈來愈能感覺獲得強大的技術架構帶給開發人員的生產力的大解放，而在遭遇Scrum Meeting事件危機後，團隊自己迅速機動處理，採用了組內結對編程的方式，進一步提高了效率。

 

圖 1 BugPhobia團隊在Alaph階段結束的過渡期間的「反思與展望「聚餐（捂臉）

 

在總體的開發流程中，正如「不管團隊內外，面對面的交流始終是最有效的溝通方式「所言，經過真正例會的反思和總結，團隊自己可以從架構、設計、開發、測試的方向依次評估，從不一樣角度把握進度自己的影響，儘量保證此前設計的」流水線「工做方案可以穩定而高效的執行（關於流水線方案的執行效果，詳情分析請參閱0x04：設計與實現工做評價），而不一樣方面的評估，才能依據各流水線的執行情況，不只能夠解決當下的問題，並且也能讓組員瞭解下一步要完成的任務對項目自己的意義所在。這在很大的程度上提高了咱們的效率。

暫且拋開書上總結的敏捷原則，Martin Fowler總結的敏捷方法的兩個特徵在咱們組上都有明顯的體現：

首先是適應性優於預測性。衆所周知，咱們的團隊的產品是「爬蟲—數據處理—在線系統「這條開發流的最末端，按照預測，咱們應該是順着這條「完美無缺」的流程華麗地完成咱們的既定任務的，可是很遺憾因爲組間協調的部分問題，團隊自己並無及時得到相應的數據，可是咱們能夠迅速應變緊急制定出一套自主提供數據的框架方案，在既定路線未正常執行的狀況下，可以迅速變動需求，緊急完成Solr和Nutch框架的總體部署和開發，完成獨立的數據提供模塊，雖未完美，卻也心安理得。

其次是以人爲本。說起以人爲本，這裏按照大衆的思路應該都是將「人「設定爲」用戶「，然而在敏捷開發的階段，這裏Martin Fowler所總結的人，更主要關注的是」開發者「。在總體的開發模式中，團隊始終採用集市式的方式進行團隊項目的基本管理和開發，由於首先咱們的項目是有一個基礎原型的（雖然遺留的代碼框架被推翻重構，但基本的創意和功能定位仍能體現於具體的代碼中），其次咱們一直採用集市式的方式進行咱們的團隊項目，大多數任務幾乎都是本身主動要來的。團隊內部的大部分人都很積極，任務也大多數都有明確的人真正去負責，每一個人選擇其本身感興趣的任務去進行。咱們順利地採用集市式的模式完成了幾份高質量的做品。一我的初稿、一我的複審迭代更新、一我的再度審覈排版等等，每一個人都出於我的的責任、榮譽以及興趣等複雜情感，深刻地參與到了整個過程當中。雖然沒有很是明確的安排，可是你們都主動承擔了某一部分的任務。咱們用集市搭建起了一座教堂，團隊開發人員的熱情很是高，團隊的關係很是融洽，你們一塊兒工做鬥志十足，效率很高，每個成員都能在這個團隊的協做過程當中得到充分的價值體現和歸屬感。

 

圖 2  BugPhobia團隊在Alaph階段的集市式開發剪影

 

對於集市式的開發，更爲具體的反思與思考同時也能夠關注團隊內部成員博客反思的展現：

GNU_Linuxer：http://www.cnblogs.com/fzyz999/p/4963681.html

Fihezro：http://www.cnblogs.com/Fengzr/p/4963514.html

PocketPanacea：http://www.cnblogs.com/panacea/p/4966144.html

Whenever：http://www.cnblogs.com/whenever/p/4963109.html

-OwO-：http://www.cnblogs.com/-OwO-/p/4961662.html

Someonefighting：http://www.cnblogs.com/someonefighting/p/4963118.html

SummerMTY：http://www.cnblogs.com/summerMTY/p/4965973.html

 

0x02 ：設想與目標概述

ü  咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？ ü  是否有充足的時間來作計劃? ü  團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？ ü  用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

 

0x0200：團隊需求與實現評價

在此階段，BugPhobia團隊自己再次引用此前的團隊需求和分析表格：

網站基本定位	面向CS/EE領域的垂直搜索引擎
網站創新形式	首先，按照《構建之法》中創新類型的劃分，在創新的類型上，咱們的產品是改良型的創新，而非顛覆性的創新
用戶基本定位	計算機及相關專業學生，其中以大學生羣體爲最主要的用戶羣
用戶的知識層次	用戶具有基本的編程基礎，並具有使用通用搜索引擎（百度、谷歌等）的能力
網站的基本功能	網站可以採集專業化社區中的問答數據、高質量課程資源、專業技術文檔中的內容，爲使用者提供一體化的、精準的、高質量的搜索內容 同時，用戶可以經過網站直接參與到上游社區的討論中

從網站的基礎功能上，參照此前學長搭建的網站功能（http://www.cnblogs.com/ourteam/p/4225596.html），簡單概述而言，完善的用戶個性化管理、完備的問答資源爬取、完善的搜索引擎架構已經基本搭建完成，而與此前搭建網站的Beta版本相比，基本功能的實現已經達到50%左右，而目前主要的需求和實現集中於：「學霸後端數據組的數據規範化」（25%的工做量，但在溝通成本上會很是嚴重，因此這裏採起前端兩組聯誼共同開發後端的方式，而後訂製統一的數據接口，以下降此前其餘組所說起的工做量），「課程、問答的具體展現頁面優化」（25%的工做量，此部分工做比較「泛化」，主要是將此前的模塊從新佈局，保證符合用戶體驗），而在此基礎上，團隊還額外完成了外部搜索引擎的搭建工做、Phobia助手的交互工做、流媒體的播放預覽功能等方面。

所以，綜合評價總體的需求和實現方向的映射關係：

ü  用戶模塊部分的設計：用戶模塊缺少概念模型的基本構建，但對於已經說起的基本屬性已經覆蓋；Beta階段將依據溝通文檔（詳情請翻閱0x07：溝通工做的進度評價），對這一部分的數據進行json的結構化處理，從而展現與前端的單頁應用中

ü  問答模塊的設計：基礎功能基本搭建完成，從後續的溝通文檔中回顧，此部分的設計模型基本符合預期，目前只須要完成Semantic UI向ReactJS的代碼遷移工做便可，此部分截至筆者撰寫此文時，遷移工做已完成30%左右

ü  課程模塊的設計：基本的展現功能搭建完成，但對於具體的數據類型尚無良好的數據結構，所以，此部分須要根據溝通文檔對前端方面進行必定程度佈局的修改，而非「新功能模塊」的開發

ü  Phobia助手的設計：基本功能遷移完成，基礎的知識庫考慮搭建；若溝通進度進展緊張，此部份內容將維持現狀

 

0x0204：時間計劃安排和執行狀況

 

燃盡圖具體數聽說明

系列1：預約目標（藍色直線），是指代預期目標 系列2：實際日均（橙色直線），按照團隊自己的實際開發天數，天天應該作到的量 系列3：實際完成（灰色直線），實際完成的工做量

從燃盡圖的安排中，團隊自己對這次的總體任務分配狀況進行了必定程度的闡釋：

        高昂學習成本的低估

在項目開展初期，項目自己並未忽視高昂學習成本，但卻嚴重低估了各框架自己的學習成本，Solr、Nutch、Django、Semantic UI框架自己的配置和學習佔用了大量的開發時間；而對應到開發階段，沒有很好地把握學習成本和進展之間的平衡，致使開發前期出現了「先後端脫節」「代碼複審質量下降」等問題；所以，在Beta階段，已經開始將學習任務落實到團隊的各個成員的工做上，如ReactJS、Semantic UI等框架的學習工做（分別給出3~5天的學習成本用以中和後期的開發工做）。

        任務分工粒度龐大

在這次的燃盡圖中，任務按照開發的模塊進行劃分，例如此前說起的「主頁面 —— 用戶頁面 —— 搜索頁面」等方式的模塊。但從分工的角度，此階段的分工粒度較大，致使前期因爲數據的匱乏，總體的項目進展緩慢，甚至致使環境配置所有完成後，任務粒度劃分較大。所以，在Beta階段，這次任務分工採用協商的方式，由開發人員完成學習任務的Demo後，給出必定的時間參考，而所有任務排列後，再和具體的負責人協商時間的延長或縮短；進度耽擱後，將嚴格按照績效管理進行處理，同時將部分工做量進行轉移，保證團隊總體進度可以基本按照預期進行燃盡。

        學霸總體系統的流水線需求溝通缺失

今後次的學霸總體組別展現效果，因爲缺少必定的協商和溝通，或者說在和另外兩組幾番討論後仍未肯定數據的基本結構，團隊總體的開發陷入了尷尬的停滯階段（具體細節能夠參閱0x0404：流水線開發的冒險與暫停），而此階段中，團隊出於展現效果和嚴峻的開發週期，最終額外而獨立完成了展現數據的結構化爬取和設計。同時，此問題也出現於開發「學霸APP」的Dream組中，根據數據組的基本抱怨，「因爲缺少溝通，咱們和APP組的數據定義相差太多」，而致使數據組「愛莫能助」。所以，在Beta階段，團隊自己將嚴重重視溝通這一問題，在Alpha階段向Beta的過渡期（2015/11/17~2015/11/24），團隊自己和Dream團隊也已經進行了大幅度的溝通工做，從而保證前端組之間可以定義完成的數據接口，並共同同一套後端，以此來充分整合前端兩組的工做量，從而保證數據組和爬蟲組在數據的格式化和爬取上，下降壓力，從而實現團隊共贏。

而對於爬蟲組、數據組，因爲在展現和溝通時，存在「團隊自己不提供需求」的誤解，這次團隊將在近期內發佈統一的先後端數據接口，並將需求真正定位到數據層次，再作進一步的討論。帶接口調研完成後，預計於2015/12/1往後開展數據組的溝通工做，此部分溝通工做中，項目經理將全程進行文檔備案，並充分保證溝通的高效執行。

        團隊成員的責任明確化

在這次的團隊分工工做中，因爲團隊總體處理基礎的磨合期，致使團隊成員對於責任的制度不清晰，在某些事件上（例如經典的BugPhobia’s Scrum Meetings事件），團隊成員的對於責任制不存在清晰的定位，致使大量已經完成的Scrum Meeting文檔草稿沒有按時發佈。所以，考慮到集市式自己的弊端，在Beta階段，項目經理將特別明確任務的警惕時間和基本負責人，一旦這一段時間內的工做進度並沒有轉機，將額外選定有足夠能力、且適合完成這一任務的人，進行責任的明確化，從而避免集市式模式失效後直接的崩盤。

 

0x03 ：團隊協做與計劃覈定

ü  你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何? ü  有沒有發現你作了一些過後看來不必或沒多大價值的事? ü  是否每一項任務都有清楚定義和衡量的交付件? ü  是否項目的整個過程都按照計劃進行，有什麼風險是當時沒有估計到的，爲何沒有估計到? ü  在計劃中有沒有留下緩衝區，緩衝區有做用麼? ü  未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

 

0x0300：團隊集市式管理評價

集市式管理方式積極端

高效且積極的開發效率 ü  初期根據高昂的學習成本，制定了架構師和團隊其餘成員的結對編程方案，同時立會時特別依據各人的疑問和困惑進行解答，保證了團隊在重構輪子的初期不會由於高昂的學習成本而嚴重拖延進度； ü  中期根據他組的協商結果，制定了依據「必定原則」的儘量獨立效率編程，雖然說在最終的耦合結果並不理想，但這次嘗試也基本確立了團隊各成員的基本開發方向，開發溝通渠道的思路； ü  後期，根據敏捷開發的剩餘需求，採用先後端對接方式的結對編程，極其高效地完成了各部分的收尾工做。         管理方式靈活高效 ü  自主申請任務，確保思路靈活，開發高度積極 ü  各任務均存在必要負責人

 

集市式管理方式弊端

缺少高度的責任制管理 ü  每日立會、每日例會、每宿舍例會均是正常進行，不管是初期的結對編程「培訓」或是中後期的數據對接上，此方面的立會均能有效保證先後端的高效對接，在必定程度上彌補了中期任務分配失衡的錯誤；但最核心的問題，就是負責人的指定，也就是責任的單一化！所以，手中積累了大量的鬆散記錄和項目草圖，卻一直未能有效整合；同時，負責維護的少年也對內容審覈過於嚴苛，致使文檔發佈拖延形成了嚴重的後果。如今回顧，若當初可以將責任高度單一化，並確保能力足夠，可能進展會更爲順利         用集市搭建了教堂，卻忽視了「興趣」和「責任」的非等價關係 ü  咱們順利地採用集市式的模式完成了幾份高質量的做品。一我的初稿、一我的複審迭代更新、一我的再度審覈排版等等，每一個人都出於我的的責任、榮譽以及興趣等複雜情感，深刻地參與到了整個過程當中。雖然沒有很是明確的安排，可是你們都主動承擔了某一部分的任務。咱們用集市搭建起了一座教堂。 ü  以前的成功使得咱們沒能認清楚上面所敘述的一些本質性的東西，從而致使了後面的問題。我認爲其中最主要的是第一條：項目必須首先是你感興趣的，最終對其餘人有用的。以前構築的一系列文檔，源自團隊中對於文字有執着追求的青年的努力，也源自團隊自身開發設計的需求，所以，你們參與得較爲深刻。特別是一些每一個成員都可以用到的文檔，好比設計文檔、需求分析等等。然而，咱們沒有認識到'每日立會'的會議記錄的做用，於是也沒有人對其感興趣。你們都以爲，這個東西彷佛沒那麼重要，沒有給予太多的重視。如今回想起來，我以爲這確實是違背了上面的第一條條件：項目必須首先是本身感興趣的。沒有人願意關注的東西，天然難以採用集市式的方式進行。因而，在這一次，集市沒有起到任何做用，咱們一直所倚靠的集市式成了低質量的罪魁禍首。

 

在經歷了這樣許多以後，我認爲，咱們依舊須要堅持咱們所一直依賴的集市式模式，它是咱們成功的基石。但在此之上，咱們必須另想辦法解決那些不適用於它的情景。在我看來，一個適合咱們團隊狀況的開發模式是這樣的：對於每個任務或者需求，首先應當儘可能採用集市式的思路去完成它。但同時，咱們應當設置一個警惕時間。若是超過這個時間依舊沒有任何轉機，那麼就說明集市模式已經再也不適用於這個任務或需求了。咱們應當綜合各方面意見，選定一個特定的，有足夠能力的且適合完成這個任務的人。讓他爲此事負責，這樣才能產生足夠的質量。從而避免集市式模式失效後直接崩盤的慘痛結果。

 

0x0304：前端AND 後端

前端—後端對接

「半獨立開發」形成冗雜交流 ü  從項目自己的架構出發，Seamantic UI的前端框架和Django框架相比，學習成本相對較低，所以不可避免遇到設計—前端的組合進度提早於後端進度；所以，在經過必定的協商規則，讓設計—前端組合優先整理需求，並反饋給後端調研可行性，但也致使後期，先後端對接過程兩方均作出了必定的修改，同時對接也更加依賴「全棧工程師」協調；

所以，在第二輪迭代的過程當中，團隊將優先保證設計層次的對接。擴展來說，先後端將優先以相似「E-R圖」的方式進行邏輯層次的設計，同時，儘量採起階段性的結對編程，實時完成需求變動的編碼實現，具體

 

0x0308：NOT 任務責任集中/他組協商工做

NOT 任務責任集中

詳情可翻閱0x0300：教堂OR集市模式

 

NOT 他組協商工做

考慮中間層的搭建工做（鑑於第一輪迭代的Nutch插件開發思路未被採納）         優先整合另外兩組原有的接口         協商額外需求的特性         及早進行接口、功能方面的溝通和整合         經過交換人員來創建更有效的溝通渠道

 

0x04 ：設計與實現工做評價

ü  設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？ ü  設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？ ü  團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ ü  什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況? ü  代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

 

0x0400：團隊原定的開發流程

在Alpha階段的團隊開發流程中，團隊自己爲了減小溝通交流成本，制定了一個流水線式的開發流程：

設計：由團隊中的原型設計人員梳理需求邏輯，利用Pencil原型工具製做出簡易的原型。這個原型圖主要展示出頁面佈局，各個控件、內容的佈局，以及總體的頁面邏輯。

前端：原型設計圖完成後，交付前端人員實現。前端人員把原型圖製成靜態頁面。用Semantic UI框架來實現原型圖中的各處設計。

後端：頁面完成後交付後端人員。後端人員實現後端的功能，而後將靜態頁面整理成Django模版，並最終讓頁面「動起來」。

測試：「動起來」後的頁面交由測試人員負責測試（蘊含的單元測試天然由開發人員首先覆蓋完成）

這樣的一套開發流程最主要的意圖有兩個：減小溝通次數，下降學習成本。

在這種流水線式的開發流程中，前端人員能夠徹底不用接觸動態網頁部分的知識，只需真正實現清楚的靜態頁面；然後端人員只須要看着前端人員的頁面，將全部的部分整理爲Django模版，並在後端實現對應功能便可，無需再和前端人員作太多溝通。同時，利用流水線式的開發讓你們的工做盡可能能夠並行地進行，提供人力資源的利用率。

 

0x0404：流水線開發的冒險與暫停

什麼是流水線的冒險和暫停：在計算機組成中，流水線CPU設計式，先後兩條指令若是都使用了某個寄存器，則可能致使數據冒險。遇到這種狀況，CPU就不得不暫停，即在流水線中插入空指令以規避冒險。

團隊自己設計的流水線式開發流程也遇到了如同定義所描述的相似問題，然而，在團隊開發的初期，因爲缺乏必定的處理，致使了此流程的流水線被迫陷入流水線的暫停工做。

首先將團隊問題映射到「頁面設計「階段，在最初的開發階段中，因爲流水線式開發的核心理念沒有傳達得太明確，設計人員試圖作出一份至關完整的界面設計，甚至將配色和模塊精確到像素級別。然而，咱們約定使用的Pencil原型繪製軟件是絕對作不出相似效果的，並且也並不須要作出那樣。因爲這樣一個傳達上的失誤，致使了大約半天的拖延。而在此後的設計階段，團隊自己的流水線缺少了必定的交互，致使設計圖自己出的也較慢，這裏最重要的交互在於」前端技術實現「和」設計理想實現「的差別，設計人員自己不瞭解Semantic UI具體的特性和效果，致使前端人員和設計這裏很難接洽。所以，在最初的開發階段，前端人員連同設計的工做一同承擔，是流程自己的第一處問題。

然而，團隊流程進一步的問題集中到「數據來源「的問題，團隊自己並不瞭解其餘兩組如何將數據反饋給咱們。而通過和另外兩組幾番討論，這件事仍舊未能肯定下來。致使了整個後端處於徹底的停滯狀態。咱們的流水線開發流程暫停了大量的時間（數天），最後才決心採用本身的數據和框架結構來推進開發穩定實現。而團隊自己設計數據和規範數據部分的內容，團隊開發才繼續執行，而此時距離開發的結束期限已然很少。

總覽而言，用最通俗的話語去解釋，Alpha階段開發初期最大的問題就在於數據供給這一部分的停滯。因爲和其餘組溝通帶來的問題，團隊的開發節奏略微自亂陣腳。部分同窗不知道該去作什麼，部分同窗想作些事情又迫不得已。

 

0x0408：結對編程：流水線開發的起色

當開發時間急劇縮短時，流水線開發自己的模式已經難以適應具體的開發工做，所以，考慮到問題自己在於先後端的交流和數據依賴相對缺失，所以，開發流程總體趨向於「結對編程「的方式進行調整。在此階段，因爲團隊自己的的Solr和StackExchange自己爬取的數據已經基本到位，而且可以知足開發和展現的部分需求，此時，阻礙後端進展的最大問題已經被妥善解決，進一步所需的工做，就是以最快的速度解決完全部的問題。

此時，咱們採用告終對編程這種方案。而在功能的定位和劃分上也儘量經過面對面的交流和文檔傳遞的方式進行解決，同時對於新功能，也採起團隊Scrum Meeting協商開發時間和需求定位進行平衡，所以，在敏捷開發階段，學霸在線系統的基本功能穩步開發和上傳，同時，新功能的提議和開發也穩步部署於服務器端和系統端。在此階段，敏捷開發的效能真正的體現出來了，積蓄已久的「開發勢能」，恰到好處地迸發出來。此前，總體的前端頁面已經徹底準備就緒，而僅僅缺乏後端對頁面的「動態化「處理，而結對編程頗有效地發揮了咱們積蓄已久的積極性。

通過了長達幾周的磨合，團隊成員間相互也很是熟悉了。同時，對於需求的理解也基本達成一致。所以，現實的壓力又迫使咱們高效地完成餘下的任務。結對編程正好有了用武之地。其結對編程效率呈現高度的高效性真正地體現出來，以致於測試人員在這一階段感慨「敏捷到測試都沒法徹底執行「

 

0x040c：Alpha階段的總結概述

過後總結起來，Alpha階段最主要的問題還在於先後端耦合度過高，先後端人員無法單獨進行開發。咱們試圖讓後端人員接收前端中和後端相關的部分。結果後端開發工做的問題顯得十分明顯。後端進行不下去的時候，前端只能寫寫靜態頁面，而無法幫忙製做Django模版。先後端的分離很差。何況Alpha階段的最後，團隊迫於項目壓力，進行了一輪「大躍進」式的開發。結對編程高效是高效，但代碼質量着實通常。這輪開發達成的成果是顯著的，但與此同時，粗放式的開發也爲Beta階段遺留了必定的問題

 

0x0410：Beta階段的過渡與重生

在Alpha階段，團隊對敏捷開發過程的主要問題進行了基本的梳理工做：

ü  VIEWS代碼存在重複，不少函數用於渲染模版的字典是類似的 ü  DJHTML的代碼有大量重複，主要是不少模版都很是類似 ü  JS代碼混亂，CSS和JS缺少有效整理 ü  先後端開發都沒有留下相對有效的接口文檔 ü  須要其餘組統一接口，數據以及APP組都須要可以接到一塊兒 ü  部分UI效果須要重寫

所以，在基於以上的代碼「歷史問題「，團隊權衡後也給出了必定的解決之道：

首先回顧數據組的基本抱怨：「因爲缺少溝通，咱們和APP組的數據定義相差太多「，所以數據組認爲目前想支持都很是困難。而學霸APP組自己也在困擾數據的類型和結構等問題。所以，在Beta階段，如何有效銜接成爲了擺在咱們這四個組面前的最大問題。所以，基於數據溝通的問題，在過渡階段，團隊自己首先選擇了和APP組進行溝通，力圖統一咱們兩組的接口。而統一必然要帶來必定的重構。 如何下降重構成本，以及如何溝通，都成爲了擺在咱們面前的大問題。最終，咱們提出了一個相對合理的方案，而且獲得了APP組的承認。 雙方正在就具體細節進行進一步的溝通。Beta階段咱們的設計方案是這樣的，咱們能夠將整個項目理解爲這樣：APP和網頁所有是學霸項目的一種前端，也就是說，咱們能夠作一個統一的後端，而後，前端只負責展示以及處理必要的用戶邏輯。這樣，APP和WEB頁面都經過URL調用統一的後端，咱們不但接口可以統一 ，並且還可以實現完美的互操做 。那麼先後端之間如何溝通呢？回憶起老師當初說起的XML，咱們聯想到了如今不少網站都在使用的JSON。 前端應用和後端之間採用JSON進行交互，前端的全部功能均經過調用後端API來實現。同時，這裏特別回顧社團平臺的「WoWoTou「團隊，他們採起了先後端分離的設計方案，從最終展現效果觀望，這樣的開發總體效果很理想，團隊的組織頗有序。先後端的開發工做就能夠實現解耦。同時，因爲咱們團隊自己和Dream組共同開發後端，雙方共享了一部分開發力量，因此後端總體的開發成本會下降不少， 能夠實現共贏。

所以，基於以上基本狀況的鋪墊，目前總體的開發流程可以接近於Flux的開發思路。

首先回顧以前的方案，若仍然沿用現有的結構，將前端理解爲經過AJAX向後端請求數據的單頁應用，頗有可能致使項目崩潰，而頁面也堆疊爲由各類JS和CSS混雜的大泥球。

所以，咱們將前端進一步工程化、專業化。引入更現代的前端開發技術：Webpack和ReactJS，而將頁面設計爲Flux架構的單頁應用。

Webpack用於處理各個模塊間的依賴關係，處理ReactJS、ES6等，並最終將其編譯爲能夠使用的靜態資源；ReactJS是目前咱們所能找到的最強力的用於構建數據變化頻繁的應用的框架，上手容易，設計簡潔；在前端工程化並轉換爲單頁應用後，咱們能夠得到額外的一些好處：

ü  先後端開發耦合性下降，相互間更爲獨立

ü  混亂的JS代碼能夠被整合起來了

ü  後端的代碼重複能夠獲得必定程度的解決（由於後端的重複主要是爲了渲染模版。如今前端主動從後端得到數據了，相應問題獲得解決）

ü  開發效率提升

Flux架構的思路較爲清晰，能夠很簡單地理清現有前端代碼混亂的思路。由官方網站能夠看到，Flux架構是對MVC模式的一種創造性的改進。Action由全局惟一的Dispatcher分發到各個Store。 Store負責處理業務邏輯，並更新其所維護的數據。數據的改變最終流向View。View獲取到用戶輸入後觸發Action。整個數據流沿着單一的方向流動，程序邏輯十分簡潔清晰。

 

 

圖 3 Flux框架的基本思路和流程圖

（特別鳴謝來源：http://facebook.github.io/flux/img/flux-simple-f8-diagram-with-client-action-1300w.png）

 

0x05 ：測試工做計劃評價

ü  團隊是否有一個測試計劃？爲何沒有？ ü  是否進行了正式的驗收測試？ ü  團隊是否有測試工具來幫助測試？ ü  團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？ ü  在發佈的過程當中發現了哪些意外問題？

 

0x0500：基本測試計劃

 

功能測試	模擬用戶的使用方式進行的測試，屬於黑盒測試。在這一階段的測試中，不經過閱讀代碼的方式反覆嘗試全部用戶可能的使用方式，探索可能出現的問題。在M1階段，全員參與到了這一階段的測試中。測試的項目包括但不限於：全部輸入框的輸入、頁面之間的跳轉關係是否正常、資料修改的結果可否保存、Tag雲可否進行有效點擊、對於通常錯誤請求可否給出響應等。除此以外，咱們還使用修改過的爬蟲對網站進行整站連接的訪問，確保每個連接都指向了有效的地址。 測試中出現了一些Bug，其中影響主要功能的均已修復完成，但依然有少許非功能性bug尚待修復。
安全性測試	安全性測試主要進行的是注入測試和csrf攻擊測試。在M1階段，網站存在的主要注入點是輸入框（登陸註冊框和用戶資料框）和頁面跳轉連接。注入測試主要使用了功能全面的Sqlmap和BSQL Hacker，在手工注入階段使用Burp進行抓包並修改。首先嚐試對數據庫進行盲注入，探測數據庫類型及存在的表，均得不到結果。隨後，嘗試使用部分信息注入的方式，發現存在有效注入點，反饋給後端人員進行修改。對於csrf攻擊，因爲django的框架自身存在反攻擊措施，均未成功。
白盒測試	在進行完功能測試和安全性測試後，我開始了白盒測試。前段實現採用了Sementic-UI的響應式佈局，測試時着重測試了響應式佈局的實現是否正確。經過閱讀代碼不難發現，實現的方式確實知足響應式的方式，可是一些細節的控制還欠缺問題，如Text的寬度可能超過一個grid，致使在響應式生效時可能超出區域，顯示出現問題。後端實現使用django框架，功能實現基本正確，可是缺乏一些基本的安全防禦措施，如對於用戶輸入的限制只在前段進行，後端不作檢查。多數問題在後期反饋後已修復。
服務器壓力測試	使用Pylot進行服務器的壓力測試。pylot能夠指定鏈接到服務器的客戶端數量以及持續的運行時間，能夠獲得在一段時間內的請求數以及服務器的平均相應時間、各比例的相應時間和無響應數。使用LoadRunner模擬用戶的請求，進行連續訪問，獲得測試結果圖。 在所有服務遷移至新的服務器以前，咱們使用的阿里雲的性能太低，不足以支撐咱們須要的功能，所以缺失率極高（保持在50%左右）。在切換至新的服務器後，能夠確保知足200用戶的併發訪問，基本不會出現拒絕服務的狀況。

 

0x0504：測試流程反饋的問題

開發前期總體進度較慢，及所以有充足的時間進行代碼複審，代碼完成的質量也比較高。而進入後期的最終衝刺階段後，功能更新速度提高，天天都會有不少新的代碼，所以複審的工做便落後於代碼編寫的進度，這直接致使了一部分代碼未通過複審就上線發佈。然而問題是，這些直接發佈的代碼質量廣泛誤差，可擴充性很差，不知足後期開發的需求。所以，這一段代碼咱們將在整理階段進行刪減和部分重構。

同時，在Alpha階段的開發中，單元模塊測試明顯不足，大量的測試不足以覆蓋模塊中的全部代碼。後期也存在了一部分沒有通過單元模塊測試就遷入的代碼，這都將對應用的穩定性形成很大影響。

 

0x06 ：Bug反饋機制與TDD模式評價

0x0600：Bug分類設定與處理標準

Bug	基本詮釋	解決方案
開發級Bug	我的開發和對接時遇到的BUG，其特色爲阻礙開發的進度。同時此類BUG因爲單元測試和架構自己，可以很快的發現，涉及的模塊較少	因爲咱們採用的集市化管理結對式開發，因此對於我的開發的過程當中遇到的bug就兩個開發人員想辦法解決就是了；而後在對接過程當中遇到的問題，你們都會聚到一塊兒來討論問題的所在，同時解決問題
測試級Bug	在測試人員進行測試時遇到的bug，其特色爲隱祕，更多的涉及到安全與性能的問題	這類問題，咱們一般都是測試人員在每日例會上面說明測試發現的bug，而後當場分析多是誰的模塊出了問題，而後相應的人員去進行修復
用戶級Bug	在發佈後用戶反饋的bug，其特色爲須要儘快的解決，同時在整個項目中涉及的模塊比較多	當接到用戶的反饋時，咱們第一時間讓架構師負責，由於咱們的架構師也是項目的全棧工程師，因此經過他的分析定位出bug的所在，而後再召集相關人員快速處理

 

0x0604：TDD模式反思與評價

BUG缺乏必定的記錄和備案	因爲咱們的bug解決起來仍是比較快速的，因此沒有去記錄遇到的bug，也不明確什麼程度的bug須要記錄在案。可是在下一個階段咱們會明確這個方面，增長bug的備案
BUG的解決上缺乏問責制度	雖然咱們可以將bug較快速的解決，可是這個主要緣由仍是在於咱們的全棧能力比較強。因此目前發現一個問題，因爲沒有明確BUG的責任人和強制的時間要求，因此不可以讓bug在獨立解決很流暢

這裏在評價上，給出必定的BUG解決樣例做爲反思的基礎：

ü  在問答展現模塊的開發過程就出現了一個BUG，因爲有一些VIEWS函數的URL映射是不一樣的成員開發的，當時出現了CRSF的異常，這是因爲幾個靜態頁面致使的，可是當時因爲這方面的溝通沒有進行好，致使這樣的小問題未在單元測試部分解決，而所以從新查找和確認

ü  在測試環節，測試人員進行安全和性能方面的測試後有發現一些問題，可是因爲沒有找到明確的負責人，從而致使問題最後拖延了一段時間。緣由是某些方面的BUG在分工初期是沒有可以很好的分工明確的，因此出現了一些BUG以後，而集市模式下的敏捷開發沒有很好地去負責

ü  發佈後獲得反饋的一些問題，其中有一次獲得的反饋是註冊登錄過程會存在不肯定性的失敗現象。那是咱們將不少問題歸到了服務器性能上面，雖然這是一部分的事實，可是還有很大的緣由是咱們各個隊員的當時在磨合狀況上確實還不是很好，因此有些模塊上人員不斷調動，最後在BUG的處理上形成了必定的不靈活性。還有就是發佈前的基礎功能測試沒能很好作到位。

 

0x07 ：溝通工做的進度評價           

在此前的0x01~0x06的工做進度中，都大量說起了溝通缺少這一嚴峻問題，所以，特別創建0x07模塊來特別強調BugPhobia團隊和其餘團隊的溝通情況，以此在Beta階段記錄項目總體的緊張，近期也會將溝通交流階段的Scrum Meeting（溝通階段長週期例會）發佈至博客中，做爲Beta篇章的啓程和重生。

時間節點記錄	溝通摘要	討論成果
2015/11/17~ 2015/11/24	l  BugPhobia團隊和Dream團隊決定共同後端進行開發，Dream團隊的趙庶宏和BugPhobia團隊的馮志睿、王文基將共同開展後端工做的「結對」編程工做 l  網站和APP整合開發需求，共同協商JSON的數據類型，同時將在概念模型完成後抽象爲JSON格式的數據接口，方便先後端的共同開發	https://github.com/bugphobia/XuebaOnline/ blob/master/需求分析和定位概念模型.md