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

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:// xueba.nlsde.buaa.edu.cn

0x01：設想與目標概述

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

 

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

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

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

 

Alpha階段BugPhobia團隊基本定位	Beta階段BugPhobia團隊基本定位
完善？搜索引擎架構？	組間協做！重構兼容！繼續的開發迭代！
完善的用戶個性化管理、完備的問答資源爬取、完善的搜索引擎架構，咱們將用戶精肯定位於計算機系的「對專業課程、概念和軟件使用有着大量需求」的學生羣體，和非計算機專業的「對計算機相關概念和理解有着問答需求」的學生羣體	組間協做：Alpha階段開發過程當中，學霸項目各團隊均忽視了組間協做的高昂成本，各自模塊的完成不等於對接成功！所以，即使在Beta階段的溝經過程長達2周，BugPhobia團隊、Dream團隊、PowerTeam團隊之間協商後端開發接口、SOLR字段開發文檔、SOLR配置和解決方案文檔等，後期的組間協做也初步完善
	重構兼容：Alpha階段，團隊僅考慮自己的實現效果；而Beta階段爲保證其餘協做組的開發進度，團隊從前端的React單頁應用到後端的JSON數據定義完成了所有代碼的重構
	繼續的迭代開發：Beta階段，在後續的開發過程當中考慮到重構、溝通的高昂成本，所以團隊儘量保證技術棧的優先搭建；不管是共用後端（Django）、FLUX單頁開發模式均徹底搭建成功；同時，團隊不只保存開發過程的必要文檔，也留下Semantic UI、Django部分的開發文檔和心得，保證後續的迭代開發可以順利開展； 數據處理能力的可擴展性： n  SOLR自己具有分佈式支持的特性 n  單頁應用模式對於服務器的計算壓力較小，前端對CDN加速的技術適應性較強

BugPhobia團隊在Beta階段的基本需求和定位同Alpha迭代相比有着較大的功能上的差別：

n  Beta階段團隊共用後端的接口搭建成功，且單元測試覆蓋率根據Django Unit Test的計算達到91.7%，基本覆蓋了其接口測試的主要分支，其正確性在網站的發佈時的測試也基本獲得驗證

n  Beta階段重構工做和歷史遷移工做基本完成，按照功能上的劃分，能夠綜合評價總體的需求和實現方面的映射關係：

l  用戶模塊的設計：Alpha階段需求分析映射的用戶管理功能基本完成，但用戶的積分制度（Profile頁面）和用戶的消息機制（Message頁面）還沒有搭建完成，此部分功能能夠做爲用戶管理模塊的擴展功能繼續開發

l  問答模塊的設計：Beta階段BugPhobia團隊重點完成問答模塊的搭建工做，後端的接口已經搭建完成，但因爲工做時間的壓縮，編輯刪除問題等操做還沒有與後端接口完成對接；這裏請翻閱團隊的技術文檔，在先後端同期維護的技術文檔中能夠進行翻閱（https://team.oschina.net/Bugphobia/document）

l  課程模塊的設計：Beta階段此部分功能未進行任何處理，因爲數據組和爬蟲組未提供此方面的數據，所以其頁面仍爲Alpha階段的展現功能頁面

l  Phobia助手的設計：Beta階段此部分功能未進行任何處理，但後期的開發團隊能夠考慮經過基礎知識庫的搭建完成個性化AI的設計和搭建工做。

 

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

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

基本項目說明	燃盡狀況描述
高昂學習成本的消化曲線	但從issues的角度分析，團隊共添加5個issues節點任務用以完成高昂學習成本的消化（Semantic UI、ReactJS、Django框架的審查和學習成本消化）；所以，在初期的燃盡階段，直線段的燃盡曲線主要做用域高昂學習成本的消化
任務分工粒度縮減	考慮到Alpha階段的燃盡圖生成，幾乎徹底依據前端頁面和後端功能進行任務和issues的劃分，所以在Beta階段，團隊儘量將任務劃分爲多節點的子任務從而使得開發工做的任務粒度較爲細緻，可以加快後續的Scrum燃盡效率
團隊成員的責任明確化	事實上，在這次issues的統計中，近一個半月的開發時間，團隊共提供50個issues記錄和31次commits記錄；而issues則明確了基本的標籤和直接的責任人，在commit時會連接到相應的issues記錄，方便後續查看時能直接依據issues記錄找到負責的團隊成員

 

所以，在Beta階段，團隊自己消耗大量的時間成本針對Alpha階段的團隊溝通問題，同Dream團隊、PowerTeam團隊之間完成了諸如協商後端開發接口、SOLR字段開發文檔、SOLR配置和解決方案文檔等團隊溝通工做，並從底層的架構中給出了基本的解決方案，重構了學霸的WEB先後端工做，保證了組間銜接工做的正確性和高效性。

最終解決方案	能夠選取的解決方案
l  ReactJS的數據單向流動框架/開發模式 l  JSON數據封裝而非Django模板渲染 l  Solr平臺的數據插入	l  搭建中間層，兼容數據組數據庫，直接根據數據庫的SELECT查詢操做完成封裝

而在此階段，架構師也選用了JSON格式封裝的新的數據傳輸格式以及新的前端框架，從而將先後端解耦，使得學霸WEB組可以同窗霸APP組共同使用團隊搭建的後端接口，且數據處理組也可以快速完成數據的採集和插入工做，最終將學霸項目徹底對接起來。

最終，依賴全棧工程師兼架構師的GNU_Linuxer驅動，依賴獨立後端開發成員Fizhero（http://www.cnblogs.com/Fengzr）的驅動，團隊依舊處於高速的運轉之中，而在後期近三天的對接工做，幾乎承擔了絕大多數的工做，最終團隊完成了基本的重構工做：

n  架構的可擴展性、可維護性相對較高，技術棧總體較易適應於分佈式等方面的加速

n  學霸APP組和學霸WEB組可以完成共用後端的操做，且通過團隊的測試，後端接口單元測試徹底經過，而測試時也並未發現較大的異常

n  代碼可讀性和複用性大幅提升，且文檔齊全幷包含部分用於上手的的學習文檔

 

0x0108：Beta階段用戶註冊和訪問量說明

用戶實際註冊數	訪問流量統計	活躍用戶量
——	——	——
這裏BugPhobia團隊爲您的支持表示感謝，但經歷了溝經過程的高昂成本消化後，後期實際開發過程當中，即使學霸項目四組間最終完成了項目的對接工做，但從用戶的角度，Beta階段迭代後的產品版本沒法面向用戶，部分功能受到數據組數據類型的限制、後期開發時間的嚴重縮減，致使重構後的產品只能把必要的技術棧填充。 所以，考慮到繼續迭代開發的過程，團隊Beta階段的項目並不面向最終用戶，而面向了繼續迭代和開發的人員；所以，僅從團隊自己的意向出發，團隊此階段的工做已所有順利完成；後續的開發人員可以從三方面入手： n  共用後端的接口擴充：其可擴展性較強，數據庫和後端接口的相關文檔也所有保留（建議添加課程部分） n  適用於CDN加速：FLUX單頁模式即ReactJS的開發模式，因爲其架構自己和SOLR的架構自己均支持分佈式的搭建，特別地對於CDN加速的搭建也有很大的幫助 n  FLUX單頁開發模式：在ReactJS的單頁應用開發架構下，團隊自己預留了充足的學習文檔和開發文檔能夠提供給後續的開發人員繼續迭代

 

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

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

 

0x0200：計劃完成狀況

在1月1日的Scrum Meeting記錄中，團隊Beta階段的項目的對接和發佈尚處於微妙的狀態：

ü  前端ReactJS頁面已經由「舉步維艱」的摒棄jQuery機制，遷移大量CSS和JS/JSX的過程，過渡到基本完工的工做狀態

ü  後端Django的基本接口書寫完成，但因爲數據庫的完整性約束條件的限制，正處於緊張的單元測試和錯誤排查階段

ü  先後端的基本對接工做，從理論上，因爲此前協商的定義應當不存在任何問題，但因爲後端的測試過程所以還沒有進入成功對接的階段

ü  文檔方面，因爲此前工做的部分延誤，大量的文檔積累在complete文件夾，未徹底排版和整理

而在最後一週的短暫開發時間中，此前疑慮的「先後端對接可能會浪費大量時間」因爲單元測試的完備，此部分時間被大量節省，所以在開發後期，團隊可以專一完成此前預計的各方面工做，雖然與此前Beta階段初期預想的最終結果有所差距，即因爲開發時間的急劇壓縮，數據量的積累程度未達到預期。

項目說明	Alpha階段功能展現	Beta階段功能添加
用戶管理	用戶信息查看	用戶信息查看（保持不變）
	用戶信息修改	用戶信息修改（保持不變）
	用戶標籤管理：添加、刪除（無）	用戶標籤管理：添加、刪除（新增）
	用戶查看推薦標籤（無）	用戶查看推薦標籤（新增）
搜索單元	基於TAGS雲的搜索	基於TAGS雲的搜索（刪除）
	基於TAGS標籤棧的搜索（無）	基於TAGS標籤棧的搜索（新增+完善）
	輸入框關鍵字搜索	輸入框關鍵字搜索（保持不變）
課程單元	課程視頻展現	課程視頻展現（保持不變）
	課程PDF展現	課程PDF展現（保持不變）
Phobia助手	聊天查詢	聊天查詢（保持不變）
問答	查看問題（無）	查看問題（新增）
	添加問題（無）	添加問題（新增）

 

n  附註：有沒有發現你作了一些過後看來不必或沒多大價值的事?

n  事實上，在Beta階段，團隊的開發進程基本處於穩定的狀態，因爲團隊成員之間的協調與配合，所以此部分工做相對較少，這裏僅就Alpha階段和Beta階段的部分對比給出說明

UI細節優化說明	UI優化前劣勢設計
修復了TAGS雲和右側標籤欄重複的UI展現效果，同時爲右側標籤欄增長分頁功能，保證多標籤的正常瀏覽效果	增長TAGS雲以動態刷新標籤供用戶選取
修復了用戶管理頁面對問題、標籤的下拉欄過長問題，採起分頁的JS代碼機制保證多條瀏覽記錄的快速分頁	將用戶的問題、關注的標籤等細節所有展現了用戶自主頁面，下拉pusher便可發現平鋪於頁面的具體信息
修復了搜索結果展現的UI優化，保證搜索結果的提示信息更爲人性化	將搜索結果的URL直接展現於用戶

 

0x0204：任務的定義和交付衡量

 

u  團隊在Beta階段將完成使用Team@OSC進行任務的管理（https://team.oschina.net/Bugphobia）和Github自己的Issues進行關聯

u  任務具體的發佈流程 ◦團隊所有成員均可以發佈任務，但必須保證任務標籤、任務說明均完備，在發佈後任務將自動進入待辦中狀態

u  全部預約任務均會在兩天前發佈任務，團隊成員在完成任務時應當首先將任務狀態更改成進行中狀態，而任務完成後可自行將任務狀態更改成已完成（或者在Scrum Meeting上說明情況，由其餘人歸爲「已完成」狀態）

u  狀態進入「已完成後」，任務管理將進入「審閱階段」，此階段將由項目經理審閱後更改成「已驗收」狀態，此後項目經理將同期發佈代碼複審工做

u  而任務的審查或出口條件爲：子任務模塊已被代碼複審人員確認爲符合規範、任務所關聯的文件已具有完整的註釋和相應issues的維護文檔、commit記錄已與issues進行了關聯和綁定操做

 

0x0208：風險評估與分析

時間	困難描述
12月13日	n  關於ReactJS和Semantic UI的javascript衝突情況 n  關於Solr自己的配置和插入問題 n  關於對接的終稿交付說明
12月16日	n  溝通問題的協商和解決 n  學霸爬蟲組與需求的不對稱
12月23日	n  關於Solr的數據插入的解決方案 n  關於Seamantic UI自己的BUG解決方案
備註	這裏僅給出部分苦難的描述，對於詳情的分析，請翻閱BugPhobia團隊的Scrum Meeting篇章進行查看和翻閱

前端的風險在初期並無被正確地認識和估計，設想是將HTML經過ReactJS自己的約束和限制模板將其更新爲JS/JSX風格的代碼；但實際操做室，因爲須要封裝純粹的JS而非jQuery代碼段，所以Semantic UI自己封裝的大量的jQuery均處於停滯狀態，大量當時直接引用的庫函數或方法難以繼承了JS/JSX代碼段中，所以前端的開發過程耗費了開發人員大部分的精力。而談及後端的接口可用性測試，在數據的存儲方式和調用方式之間存在着不一樣，使用時須要轉變，這個風險一樣是沒有預料到的。再者就是當初的後端數據庫裏面有不少的與數據處理組不相關得當初測試用的文件，有時會被當成搜索結果返回，違反了調用的正確性，致使了不可預料的錯誤，這個也是一個沒有預料到的風險。

挑戰	n  須要和APP組公用後端 n  前端須要支持經過JSON與後端交互 n  單頁應用技術較新，之前從未接觸過 n  須要對幾乎全部代碼進行重構
機遇	n  優化Alpha階段的細節 n  重構不合理的頁面 n  拋棄在Alpha階段結尾寫成泥球的代碼 n  將代碼組件化，增長代碼重用，整理代碼結構

 

0x020c：其餘問題的簡要說明

 

問題	回答
在計劃中有沒有留下緩衝區，緩衝區有做用麼?	因爲開發時間和溝通時間均被大幅度壓縮，所以在緩衝區上未設置開發過程當中的緩衝區；但一樣，在開發階段考慮到編譯原理課程設計的衝突狀況，團隊在開發過程當中嵌入了大量的緩衝區，用以保證工做進度不至於單向阻塞而難以繼續執行
未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）	在未來的計劃中，重點仍在與文檔的描述與備案；由於學霸項目是不斷迭代的過程，做爲遵照職業道德的攻城獅，必須保證後續接手的團隊可以快速完成項目的搭建工做
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?	在Alpha階段，團隊就能堅持Beta階段的架構設計，經過一系列的接口實現組間的互聯互用，從而避開Beta階段繁忙的大做業衝刺時間；合理利用時間，是BugPhobia團隊對下一屆接受咱們項目的團隊最大的希冀

 

0x03  資源

ü  咱們有足夠的資源來完成各項任務麼? ü  各項任務所需的時間和其餘資源是如何估計的，精度如何? ü  測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度? ü  你有沒有感到你作的事情可讓別人來作（更有效率）? ü  有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

 

0x0300：集市管理的資源制度分配

集市管理的重要責任	具體執行方案說明
合理組間協做溝通負責人	在開發過程當中，遇到組間協做的部分，儘量經過某一架構完成兩方面團隊工做的協做；而團隊建議在此部分架構上安排特定的某一人，去解決這一部分對接工做的所有問題，去直接和下游的團隊進行對接，儘量下降組間溝通消耗的成本
開發的直接負責人	實際上，在開發過程當中必須確保每一部分工做的質量均由特定的人進行管理，遇到變動時再優先和負責人討論後做出妥協或決定
時間節點的設置	各任務必須給出預算的時間節點，供項目經理搭建出流水方式的工做進度管理
依賴關係的重視	確保架構上的依賴關係，進度上的時間依賴關係有足夠的容錯能力，保證在後續的調整過程當中，不會出現集市的空檔期

 

所以，基於集市管理的基本方法，在團隊總體的項目管理中採用「局部流水處理」和「總體並行處理」的方式進行管理，其基本的貢獻和資源分配狀況能夠以下圖所示，這裏作出必定的說明：

n  圓點的面積表明任務的燃盡狀況，同總任務的比率；而此圖以3天爲時間粒度進行劃分，展現每3天的團隊開發進程

n  其中面積較大的點：此階段處於局部流水區域；後端開發、前端開發、先後端對接工做積累至模塊對接階段，此部分工做主要涉及子任務的對接，先後端的代碼複審，所以此部分任務量相對較大

n  其中面積較小的點：此階段處於局部並行區域：因爲三部分開發工做可以分割爲獨立的開發工做，所以此階段工做處於局部的並行區域

 

0x0304：團隊開發模式評估

項目	Alpha階段開發模式	Beta階段開發模式
面向羣體	面向用戶的開發模式	面向開發人員的開發模式
架構開發	Semantic UI前端和Django後端結合	Semantic+ReactJS前端和Django共用後端結合
車禍係數(單核心依賴係數)	在Alpha階段，團隊出於基礎的磨合階段，所以在必定程度上，由Alpha團隊內的組內協做可知： n  團隊技術棧是以架構和後端做爲驅動的開發模式，所以團隊內的協做是以架構師GNU_Linuxer爲基礎，所以極可能因爲架構師傳遞信息的「不肯定性」，致使項目車禍發生 n  團隊先後端對接工做徹底依賴後端人員對前端代碼的理解，所以二者須要必定時間進行結對編程，致使二者之間的耦合相對較差	在Beta階段，經歷Alpha階段的開發，團隊成員自己對項目和架構的認知相對較深，所以團隊的分工呈現多層次的遞歸發展： n  團隊技術棧開發分離，SOLR架構、前端ReactJS、後端Django開發組均能正確獨立地完成相應模塊的開發，所以對接成本下降 n  團隊先後端的對接工做相互獨立，後端人員完成相應接口的設計後，只需經過Django自己的單元測試框架便可完成正確性的驗證；而前端人員能夠直接根據接口文檔完成調用，無需理解具體的原理過程
流水線開發模式	n  在Alpha階段，團隊總體的開發呈現基礎的流水線工做，設計、前端、後端、測試、複審、驗證的流水機制高速運轉，其總體的開發模型符合瀑布模型的流水工做，總體的代碼嚴謹性較強 n  但同時，流水線的阻塞也是開發過程不可避免的階段，部分工做的延誤將有可能致使其餘人員的進度延誤	Beta階段，考慮到流水線機制自己的問題，團隊的開發呈現局部流水、總體並行的開發機制： n  在局部上，項目自己將各功能模塊進行分割操做從而保證了局部的開發模塊可以以流水的形式繼續開發，即前端和後端的對接，測試的驗收等部分工做；而結對編程也一樣發揮了應有的做用 n  在總體上，項目自己處於總體併發的開發機制，一旦某一開發人員開發陷入阻塞態，其餘成員可以依據自身的並行開發序列繼續開發，從而避免總體開發進度阻塞的問題
文檔管理	Alpha階段未強調文檔的基本管理	Beta階段，團隊制定了完整的文檔管理計劃（更多細節能夠瀏覽github的文檔版本）： n  團隊內的文檔儘量使用Markdown文本編輯，容許使用擴展的Markdown語法，但必須保證GIT@OSC或MarkdownPad可以支持相應的擴展語法 n  對於部分必要的新技術，必須同時維護一份技術入門文檔
測試說明	Alpha階段未強調單元測試和部分性能測試的問題	Beta階段制定了完成的測試方案和計劃說明（更多細節能夠瀏覽github的文檔版本和測試報告） n  腳本型功能測試 n  手工測試 n  腳本型安全性測試及性能測試
責任明確	Alpha階段，團隊總體處於集市的開發模式，團隊自己未強調相關任務責任的明確化和細緻化	Beta階段制定了明確的責任分工制度（更多細節能夠瀏覽github的文檔版本和測試報告）

 

0x0308：團隊基本分工職責

王鹿鳴	n  完成Semantic UI框架向ReactJS的代碼遷移工做 n  完成其餘模塊的具體頁面的前端實現 n  架構團隊總體的開發流程	u  前端開發 u  全棧溝通、架構、前端
錢林琛	n  完成功能規格說明書、技術規格說明書、績效管理的整理和維護工做 n  Scrum Meeting期間完成Scrum Meeting的記錄和更新，要求必須包含：我的的Work Issue的ID關聯（已完成、計劃完成、工做中的困難記錄），燃盡圖，照片，代碼/文檔的簽入記錄說明 n  與團隊成員交流後規劃各個開發時間，進行監督和「干預」 n  必須與爬蟲組、數據組、APP前端組進行溝通	u  項目經理 u  功能溝通，管理
馮志睿	n  調研第三方登錄的基本環境，並在Beta階段進一步支持第三方登錄 n  根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析	u  後端開發 u  全棧溝通、後端、結對編程
王文基	n  根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析	u  後端開發 u  後端、結對編程
趙庶宏	n  根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析	u  後端開發 u  後端、結對編程
李雲濤	n  Javascript和DOM的學習進度規劃 n  從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」 n  直接以ReactJS的view渲染開始新頁面的編碼和設計	u  前端開發 u  全棧溝通、前端、結對編程、測試
李入雲	n  Javascript和DOM的學習進度規劃 n  從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」 n  直接以ReactJS的view渲染開始新頁面的編碼和設計	u  前端開發 u  結對編程、前端
金東禾	n  整理已知的Django框架、Semantic UI框架的入門教程，經過Markdown或LaTex整理爲可讀性較強的文檔，留做爲接任此項目的團隊的學習文檔	u  文檔整理 u  學習文檔整理、技術平臺整理

 

0x030c：團隊部分問答解釋說明

問題描述	回答說明
咱們有足夠的資源來完成各項任務麼?	從基本的資源分配中能夠看出，經歷兩輪迭代和技術棧更新的團隊，在開發效率幾乎與Alpha階段相比有着較高的提高。以12月11日左右Semantic UI中期考覈任務結束做爲分界線，團隊總體完成了技術棧的更新和學習，然後期開發工做基本以連續開發時間做爲主要的影響因素。 n  若需求定位於後續迭代的技術棧維護，時間資源可以達到預期目標，而學習成本資源和人員安排也符合預期安排 n  若需求定位於面向用戶版本的更新，時間資源基本不足以完成預期目標，然後端的資源分配基本充裕，但前端的開發資源相對匱乏
各項任務所需的時間和其餘資源是如何估計的，精度如何?	n  在Alpha階段~Beta階段的過渡階段，團隊總體完成了技術棧的試驗遷移工做，在此階段，團隊針對JSON的遷移工做、ReactJS的遷移工做作出了基本的demo n  在Beta階段，後端的開發時間相對充裕，所以時間成本基本按照前端的開發進程進行估計，後端任務劃分爲：後端開發、單元測試、代碼複審、對接審覈、接口文檔歸檔的部分，在前端相對部分開發時須要保證前兩子任務優先完成 n  Beta階段，前端任務相對緊張，所以，此部分工做基本由團隊的開發人員開發一週後自行給出進度報告，並和後端協商後完成最終進度的確立
你有沒有感到你作的事情可讓別人來作（更有效率）?	由「0x0308：團隊基本分工職責」的表格中能夠發現，團隊基本保證，各任務幾乎保證了專人專任制度，根據Alpha階段的開發方向進行歸類，在總體上保證了效率的最大化
有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?	n  對接工做由Alpha階段必須開展 n  對接工做由Alpha階段必須開展 n  對接工做由Alpha階段必須開展

 

0x04 ：變動管理

ü  每一個相關的員工都及時知道了變動的消息? ü  咱們採用了什麼辦法決定「推遲」和「必須實現」的功能? ü  項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼? ü  對於可能的變動是否能制定應急計劃? ü  員工是否可以有效地處理意料以外的工做請求？

 

0x0400：消息傳遞機制

 

消息傳遞機制	具體說明
Scrum Meeting會議	n  團隊每1~2天完成Scrum Meeting會議的基本討論，主要探討基本的進度問題、設計時的衝突問題、技術棧的新BUG解決方案等問題
Team@OSC團隊管理	n  團隊在Beta階段將完成使用Team@OSC進行任務的管理（https://team.oschina.net/Bugphobia）和Github自己的Issues進行關聯 n  任務具體的發佈流程 ◦團隊所有成員均可以發佈任務，但必須保證任務標籤、任務說明均完備，在發佈後任務將自動進入待辦中狀態
文檔溝通方式	n  此部分溝通方式主要應用於先後端的開發方面，而此時commit記錄必須與前端文檔的維護情況相對應，一旦後端接口出現變動後馬上對commit記錄進行查看並進行小範圍的修改和維護

 

0x0404：緊急計劃和變動說明

職能說明	具體工做評估
團隊項目進度協調	「無論是開源仍是商業化，都必需要有一我的對整個項目負責。不是兩我的，不是三我的，而是一我的「，這裏筆者通過兩輪迭代的開發暫時不予支持這一觀點。這裏負責的概念，筆者從技術和進度上給出負責的定義： l  技術負責：團隊可以依據目前的開發情況，更新技術棧，並穩定基礎架構，針對不一樣狀況給出不一樣的解決方案 l  進度負責：團隊可以根據目前的進度情況和預期計劃，更新進度日程和先後端對接進度，保證開發模式和進度呈現穩定發展 所以，筆者所處的團隊基本處於兩人的負責的階段，技術負責交付架構師，進度負責交付筆者，而平臺的對接溝通工做交付平臺對接人員，三方面對團隊進行負責，最終保證Beta階段團隊項目可以穩步進行，完成最後的預期開發
團隊項目進度的干預	團隊的所有成員自己從態度和能力上都很是靠譜，交付的任務和挑戰都能盡力完成且交付的版本都幾乎和最終歸檔的版本相差不大。但團隊一樣會經歷部分任務的「卡殼「階段。       在開發中期，團隊的前端頁面的遷移工做一度陷入遲滯，因爲前端遷移人員糾結在主頁面的標籤雲遷移工做，而正常的工做難以繼續開展；所以此時項目經理須要適時干預進度，將此部分任務標籤後移，並提供不一樣的解決方案供技術負責參考，並完成進度的遷移

 

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

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

 

0x0500：設計工做安排

 

王鹿鳴	n  完成Semantic UI框架向ReactJS的代碼遷移工做 n  完成其餘模塊的具體頁面的前端實現 n  架構團隊總體的開發流程	u  前端開發 u  全棧溝通、架構、前端
李雲濤	n  Javascript和DOM的學習進度規劃 n  從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」 n  直接以ReactJS的view渲染開始新頁面的編碼和設計	u  前端開發 u  全棧溝通、前端、結對編程、測試
李入雲	n  Javascript和DOM的學習進度規劃 n  從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」 n  直接以ReactJS的view渲染開始新頁面的編碼和設計	u  前端開發 u  結對編程、前端

 

0x0504：測試部分以及bug修復

n  用戶管理模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
正常註冊	——	——
正常登錄	——	——
重複註冊	提示信息出現錯誤，此BUG經調研涉及Semantic UI框架自己標記的BUG	已修復
錯誤信息登錄	後端驗證中提示信息出現錯誤，此BUG提供網頁前端驗證的解決方案	已修復
非法信息註冊	——	——
資料查看	可能出現部分資料屬性返回空值的狀況，經調研此問題涉及部分POST機制，交付Exception模塊處理便可	已修復
資料修改	——	——

 

n  標籤搜索模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
搜索存在的標籤	搜索結果未進行分頁，頁面顯示過長	已修復；前端開發人員從新設計佈局並使用分頁佈局JS和CSS完成BUG的校服
搜索不存在的標籤	爲搜索到返回結果，無提示信息；特別說明，此BUG屬於後期測試時用戶提供的BUG標籤，所以在Beta階段完成此BUG的修復工做	已修復
對搜索框進行注入	——	——
直接點擊Tag進行搜索	——	——

 

n  問答模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
問題搜索	——	——
回答展現	此部分展現效果根據用戶的反饋，其UI美化相對較差，所以可能須要從新佈局和排版	未修復
問題提出	——	——
相關問題推薦	——	——

 

0x0508：團隊Beta階段的架構反思說明

Beta階段咱們的設計方案是這樣的，咱們能夠將整個項目理解爲這樣：APP和網頁所有是學霸項目的一種前端， 也就是說，咱們能夠作一個統一的後端，而後，前端只負責展示以及處理必要的用戶邏輯。 這樣，APP和WEB頁面都經過URL調用統一的後端，咱們不但接口可以統一 ，並且還可以實現完美的互操做。那麼先後端之間如何溝通呢？回憶起老師當初說起的XML，咱們聯想到了如今不少網站都在使用的JSON。 前端應用和後端之間採用JSON進行交互，前端的全部功能均經過調用後端API來實現。同時，這裏特別回顧Alpha階段社團平臺的「WoWoTou「團隊，他們採起了先後端分離的設計方案，從最終展現效果觀望，這樣的開發總體效果很理想，團隊的組織頗有序。先後端的開發工做就能夠實現解耦。同時，因爲咱們團隊自己和Dream組共同開發後端，雙方共享了一部分開發力量，因此後端總體的開發成本會下降不少， 能夠實現共贏。

所以，基於以上基本狀況的鋪墊，目前總體的開發流程可以接近於Flux的開發思路。首先回顧以前的方案，若仍然沿用現有的結構，將前端理解爲經過AJAX向後端請求數據的單頁應用，頗有可能致使項目崩潰，而頁面也堆疊爲由各類JS和CSS混雜的大泥球。所以，咱們將前端進一步工程化、專業化。引入更現代的前端開發技術：Webpack和ReactJS，而將頁面設計爲Flux架構的單頁應用。Webpack用於處理各個模塊間的依賴關係，處理ReactJS、ES6等，並最終將其編譯爲可使用的靜態資源；ReactJS是目前咱們所能找到的最強力的用於構建數據變化頻繁的應用的框架，上手容易，設計簡潔；在前端工程化並轉換爲單頁應用後，咱們能夠得到額外的一些好處：

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

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

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

ü  開發效率提升

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

 

 

 

0x05 ：測試工做計劃評價

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

 

0x0500：團隊部分問題說明

問題描述	回答說明
團隊是否有一個測試計劃？ 是否進行了正式的驗收測試？	此部份內容具體能夠翻閱團隊的測試報告，這裏給出詳細的連接： http://www.cnblogs.com/bugphobia/p/5117731.html
團隊是否有測試工具來幫助測試？ 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？	n  團隊的測試代碼通過協商，其關於壓力測試、安全測試等方面的腳本均爲閉源代碼，此部分工做沿用Alpha階段的工做繼續進行 n  團隊的網站的相關測試直接經過手動測試完成了相關內容，具體的信息仍翻閱團隊測試報告便可（http://www.cnblogs.com/bugphobia/p/5117731.html）
在發佈的過程當中發現了哪些意外問題？咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?	n  開發前期總體進度較慢，及所以有充足的時間進行代碼複審，代碼完成的質量也比較高。而進入後期的最終衝刺階段後，功能更新速度提高，天天都會有不少新的代碼，所以複審的工做便落後於代碼編寫的進度，這直接致使了一部分代碼未通過複審就上線發佈。然而問題是，這些直接發佈的代碼質量廣泛誤差，可擴充性很差，不知足後期開發的需求。所以，這一段代碼咱們將在整理階段進行刪減和部分重構。 n  同時，在Beta階段的開發中，單元模塊測試明顯不足，大量的測試不足以覆蓋模塊中的全部代碼。後期也存在了一部分沒有通過單元模塊測試就遷入的代碼，這都將對應用的穩定性形成很大影響。

 

0x06：總結

問題描述	回答說明
你以爲團隊目前的狀態屬於CMM/CMMI 中的哪一個檔次?	筆者觀點，團隊處於其中的最多能夠算上管理級，在Alpha階段咱們的團隊用行動證明了咱們能夠實現完成級的突破，在本次的Beta階段咱們認爲咱們的團隊實現了明確任務，細化責任的工做，經過結對編程咱們將成員的任務具體化、明確化。每個模塊都有專門的成員負責完成。所以，筆者認爲這個能夠算上是處於管理級的。
你以爲團隊目前處於 萌芽/磨合/規範/創造階段的哪個階段?	總體團隊目前是處於規範的階段，由於在Beta階段正是經過一系列的規範的制定才實現了最終的4個組之間的銜接
你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?	總體團隊更加懂得分享和合做了，在這個階段咱們經過組間的合做將之前孤立的系統進行了融合咱們擯棄了咱們以前爬取的全部的數據將數據處理組的數據做爲咱們後臺數據的所有，成員之間也更加熟悉，相互的孤立使得彼此能在「惡劣」的大做業紛飛的環境下依然爲軟工盡心竭力。
你以爲目前最須要改進的一個方面是什麼?	時間規劃是咱們一開始的劣勢，若是有可能的話咱們但願咱們如今的Beta階段成爲咱們當初的Alpha階段，而後在如今的基礎上進行更深刻的開發。因此咱們但願留下儘量多的文檔和資料讓後來的開發者可以儘快達到咱們如今的層次從而在此基礎上進行開發和創新。