第一次迭代心得

一，設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

①解決的問題：咱們的軟件是一款基於聯邦型知識圖譜的關鍵詞搜索引擎。目前，聯邦RDF 系統由許多自治的SPARQL 端點組成，SPARQL 端點只提供查詢接口而用戶不能經過此接口遠程下載數據集來創建全局倒排索引，所以，關鍵字檢索難度很大。咱們基於一種在聯邦RDF 系統上進行關鍵字搜索的方法，經過SPARQL 端點上下文檢索把關鍵字映射到子圖結構中，而後經過子圖生成SPARQL 查詢來查詢Endpoints 上的數據集，而不須要在不一樣SPARQL Endpoints 上創建全局倒排索引。爲了提升查詢性能，咱們設計了多重查詢優化策略來重寫查詢語句，普遍的實驗證實咱們的技術仍是有效的。

②典型用戶及典型場景：咱們這個項目定位不屬於商業應用型項目，而是一個算法研究型項目，因此典型用戶不是咱們這些平常的搜索引擎的使用者，而是專門的程序員或者RDF技術研究者，典型場景也偏向於研究而不是商業應用，更傾向於爲專門的研究者服務，爲算法研究提供前端界面並保存下大量中間結果及查詢日誌以方便研究者進一步改進算法。

2. 咱們達到目標了麼（原計劃的功能作到了幾個？  按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

咱們基本達到了第一次迭代的計劃於目標，咱們原計劃的功能包括要實現用戶登陸，註冊，郵箱激活，權限管理，搜索算法實現，結果展現等六大功能，最終咱們按照進度如期完成了原計劃的迭代。可是在頁面美化尤爲是結果頁的處理上還須要在第二次迭代時進一步優化。

3. 和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

與以前一階段相比，咱們團隊的工程質量提升了不少包括

①軟件架構層面的優化：咱們組以前的代碼基本沒有思考軟件架構的優化，因此先後端混在一塊兒，全部事物基本都使用代碼實現，而且每次數據操做均須要頻繁開關鏈接，因此代碼拓展性和可維護性極差，可是如今咱們組將前端，數據庫，業務邏輯徹底剝離，而且使用了不少配置文件來避免「硬編碼」，還使用了鏈接池來專門管理鏈接，整個工程分爲了若干模塊，代碼拓展性和可維護性都大大提升。

②代碼的複用性的改良：咱們組以前在寫代碼時不少函數直接寫死了並且數據粒度比較大使得代碼複用性比較差，在此次迭代中咱們注意了這個問題，一些函數採用了接口的形式，而且下降了不少函數的數據粒度來加強代碼的複用性。

③編碼習慣的改良：咱們組以前的代碼在變量命名上比較隨意而且基本不註釋，因此代碼可讀性比較差，通過了一個階段的修正咱們組如今在編碼時就比較注意變量命名規範性以及增長必要的註釋。

4. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

用戶量及用戶的接受程度基本符合預期，由於目前咱們的系統是一個研究型項目，面向的主要是專門的代碼研究人員，用來方便他們的算法研究因此與不懂電腦的普通人相比，咱們的用戶做爲比較專業的程序員對於咱們的系統比較容易上手。

5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

 對於典型用戶與典型場景必定要明確清晰，若是重來咱們會發揚此次的經驗，在項目開始時儘快肯定項目的用戶及場景。

 

二，計劃

1. 是否有充足的時間來作計劃?  

咱們組比較嚴格地按照邊老師的要求，在每週日晚會討論決定小組的周計劃，以後我的再根據小組進度安排本身的周計劃。

2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

咱們組在計劃階段小組內部確實產生了不少不一樣意見，咱們是先一塊兒評估一下爭議點的工程量及咱們的能力最後討論肯定最終的計劃的。

3. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

第一次迭代的原計劃的工做基本都完成了，關於頁面美化尤爲是結果頁的處理上還須要在第二次迭代時進一步優化。

4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?

有不少，好比一些其餘架構的探索以及使用socket通訊時一開始採用了txt文件來過渡等等，不過感受這些雖然最後沒有使用在最終的工程裏可是對於技術探索仍是有益的。

5. 是否每一項任務都有清楚定義和衡量的交付件?

咱們組在需求文檔和第一次迭代開發文檔裏對每一項任務都有清楚定義和衡量的交付件。

6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

項目整個過程基本是按照計劃進行，固然中途也出現了些意外，在驗收前五天時項目組的服務器意外宕機了，致使當時項目組進度被停滯，這一點是以前沒考慮到的，主要是想以前沒有提早思考硬件故障的問題（尤爲是騰訊這種大廠居然說出問題也出問題。。。）

7. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

此次咱們製做計劃時沒有留下緩衝區，致使最後幾天頻繁刷夜（整個週末感受比高三時還拼╥﹏╥...），緩衝區能夠爲一些意外事件提早留出解決的時間。

8. 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

未來計劃咱們必定要提早考慮到各類意外出現的可能性，留足緩衝區時間，避免最後幾天刷夜（實在肝不起了）

9.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

 咱們學到了在計劃中要留下緩衝區，若是重來一遍咱們會提早考慮到各類意外出現的可能性，留足緩衝區時間

 

三，資源

1. 咱們有足夠的資源來完成各項任務麼?

①硬件方面咱們組有本身的一臺服務器和老師的一臺服務器基本知足需求

②軟件方面咱們組均爲一個專業的，空閒時間比較集中，編程能力上你們自學能力也都比較強，因此基本能夠完成任務。

2. 各項任務所需的時間和其餘資源是如何估計的，精度如何?

咱們組是根據任務的工程量，要作到的精細程度和咱們自身的編碼能力來評估所需時間和資源的，精度比較準確。

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度? 

前期估計比較準確，因此在測試階段資源基本足夠，對於不須要編程的資源好比文案及UML圖等咱們小組都是一塊兒解決的，因此並無低估難度。

4. 你有沒有感到你作的事情可讓別人來作（更有效率）?

基本沒有過，小組分工還算合理，我比較擅長數據庫及先後端聯繫，軟件架構層面，最終分配任務也是承擔的這方面的任務。

5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

儘管小組分工比較合理，但仍是不夠細化，小組開發時仍是不少時候出現了交叉甚至每一個人慢慢地都快變成了「全棧工程師」，固然這主要是由於咱們仍是在一些基礎技術上掌握得不是很熟練，不少技術架構都是直接現學現用致使很容易碰到問題因此小組只能是每一個人每一個地方都會些，一我的出現問題了可能全組人一塊兒幫助解決。若是重來一遍，一個team仍是要儘可能避免這種交叉編程的。

 

四，變動管理

1. 每一個相關的員工都及時知道了變動的消息?

項目組有專門的羣用來討論以及變動的通知。

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

咱們組通常會根據任務的工程量，功能是不是核心功能以及咱們自身的編碼能力先討論決定「推遲」和「必須實現」的功能，固然若是意見遲遲不能統一就投票決定或是向指導老師請教。

3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

咱們組在需求文檔及項目原型中對項目的出口條件進行了清晰的定義。

4. 對於可能的變動是否能制定應急計劃?

咱們組沒有在項目開始時事先制定應急計劃，但此次迭代中發生變動時咱們組都會抽時間一塊兒討論來快速制定應急計劃。

5. 員工是否可以有效地處理意料以外的工做請求？

咱們會進行動態的任務分配，一些意料以外的任務可能會動態的分配給一些編程能力較強的人。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學到了 對於項目的出口條件，應急計劃等必定要提早計劃好，若是重來一遍，咱們會在項目開始時事先制定下大概的應急計劃。

 

五，設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

咱們的設計工做是第七週左右開始的，而且採起了全組一塊兒完成的方式（全組均爲開發人員），時間節點上比較合理，人員分配基本合理。

2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

團隊通常會討論最後表決肯定最終的設計

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

①咱們組使用了starUML來製做UML圖以及powerdesigner來製做數據庫的E-R圖，可能咱們的工程與真實企業項目仍是有差距，這些工具備做用能夠幫助咱們明晰需求及項目設計但用處不是很是大

②由於項目需求文檔最後進行了必定的修改，項目開始的 UML 文檔也進行了相應的更新

4. 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

搜索這個核心功能bug最多，由於它牽涉核心算法，數據庫操做與socket通訊等多個模塊，在發佈前進行了大量測試發現了數據庫鏈接空指針報錯，鏈接服務器超時，socket通訊空指針錯誤等多個bug但都在發佈前解決了。

5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

代碼審查咱們是依據邊老師以前發的阿里編程規範文檔中的要求結合網上一些案例進行的，總體上比較嚴格地執行了代碼規範。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學到了不少，包括各類工具的使用以及編碼規範等，若是重來一遍，咱們會在迭代時學習使用單元測試等工具及github或工蜂等代碼託管平臺的使用來避免咱們串聯工程時一遍遍地import工程。

 

六，測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

項目最後事先留了一成天來進行各子模塊及整個工程的測試。

2. 是否進行了正式的驗收測試？

項目進行了正式的驗收測試

3. 團隊是否有測試工具來幫助測試？

此次團隊沒有使用專門的測試工具來幫助測試

4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

團隊是交叉測量對方負責模塊的效能的，這些測試工做幫助咱們找到了不少bug使咱們在發佈前解決了軟件的bug

5. 在發佈的過程當中發現了哪些意外問題？

在發佈前進行了大量測試發現了數據庫鏈接空指針報錯，鏈接服務器超時，socket通訊空指針錯誤等多個bug但都在發佈前解決了。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

 咱們學會了要提早留出測試的時間並作好測試的計劃，若是重來一遍，咱們還會學習下專門的測試工具來幫助測試。

 

七，團隊的角色，管理，合做

1. 團隊的每一個角色是如何肯定的，是否是人盡其才？

團隊是根據成員的編程能力來肯定角色的，基本算是人盡其才，但分工能夠進一步細化

2. 團隊成員之間有互相幫助麼？ 

團隊採起了先我的編程搭好框架，再團隊一塊兒編程遇到問題一塊兒解決的方式（圖書館二樓基本快被軟工16級佔沒了。。）

3. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

小組通常會討論最後表決肯定最終的設計

4.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學會了什麼纔是一個team（話說最後一個週末仍是第一次五我的從早到晚連吃飯都在一塊兒連續待了兩天半）若是歷史重來，咱們會進一步細化分工，避免小組成員全變成「全棧工程師」的趨勢。

 

八，總結:

1.你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

嗯，以爲大致在第二等級到第三等級上（咱們沒第一等級辣麼差，嗯，也沒第四第五等級那麼好）

2.你以爲團隊目前處於萌芽/磨合/規範/創造階段的哪個階段?

團隊合做的話處於規範這一階段（嗯，謙虛點）
3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進? 

①軟件架構層面的優化：咱們組以前的代碼基本沒有思考軟件架構的優化，因此先後端混在一塊兒，全部事物基本都使用代碼實現，而且每次數據操做均須要頻繁開關鏈接，因此代碼拓展性和可維護性極差，可是如今咱們組將前端，數據庫，業務邏輯徹底剝離，而且使用了不少配置文件來避免「硬編碼」，還使用了鏈接池來專門管理鏈接，整個工程分爲了若干模塊，代碼拓展性和可維護性都大大提升。

②代碼的複用性的改良：咱們組以前在寫代碼時不少函數直接寫死了並且數據粒度比較大使得代碼複用性比較差，在此次迭代中咱們注意了這個問題，一些函數採用了接口的形式，而且下降了不少函數的數據粒度來加強代碼的複用性。

③編碼習慣的改良：咱們組以前的代碼在變量命名上比較隨意而且基本不註釋，因此代碼可讀性比較差，通過了一個階段的修正咱們組如今在編碼時就比較注意變量命名規範性以及增長必要的註釋。

4.你以爲目前最須要改進的一個方面是什麼?

具體設計上結果頁的處理及美化是當前最須要改進的

 

最後但願咱們的第二次迭代也能圓滿結束，不然都對不起咱們組的咖啡錢和夜晚裏掉落的頭髮（ヾ(´∀`o)+）