Alpha階段過後分析

Alpha階段過後分析

1. 設想和目標

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

咱們要實現一個課程資源共享平臺，爲同窗們獲取資源、分享資源提供便利。對於要解決的問題咱們小組定義得比較明確，對典型用戶和典型場景也有較爲詳細的描述。

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

原計劃實現的資源上傳/下載功能都已經在Alpha階段實現了，只是一些比較細緻的功能，如資源收藏、評價等，尚未實現。咱們的原計劃是發佈一週內用戶量達到300， 實際結果爲230左右。

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

目前只是實現了資源上傳和下載的功能，目前接到的反饋有打開資源界面的時候太慢，這一點實際上咱們已經在發佈前注意到了，只是沒有時間去修復了。在發佈以後咱們經過資源的分頁顯示優化了資源顯示過慢的問題，目前使用體驗較好。

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

感受沒有抓住用戶的痛點，下載資源的步驟感受仍是繁瑣了點，應該在Alpha階段實現一個「搜索資源」的功能會好一點，這部分咱們在Beta階段實現。

---

2. 計劃

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

Alpha階段共四周，其中第一週的時間主要都用於作計劃上了，時間感受比較充足。咱們在第一週大體設計了網站的原型，並對數據庫結構和一些接口進行了定義，但儘管作了不少計劃，依然還有不少沒有考慮周全的地方，好比數據庫和接口在實際開發中作了不少修改。

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

好像在實際開發中出現意見對立的狀況不是不少……通常採起的作法是PM將全部不一樣的意見彙總，綜合利弊得出結論。

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

本來計劃是把資源收藏等小功能也給實現了，但資源上傳下載這部分比想象中難很多，尤爲是如何下載用戶上傳的文件是個問題，在這一部分花費的時間超出了預期。

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

我的中心在Alpha階段徹底沒用上，不過這也是爲資源收藏等功能作鋪墊，並且也沒有耗費太多時間。

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

感受並無，PM只是說要實現一個什麼樣的功能，卻沒有說這個功能實現以後要達到一個怎樣的標準，一個模棱兩可的功能實現，最終也能夠被交付。

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

並非，好比在爬取課程信息的時候一開始沒有獲取到課程類別和開課院系等信息，這樣子就沒辦法篩選課程了，只能先把Beta階段的課程搜索功能先實現了。還有一個意外就是以前提到的，咱們的資源分爲兩種，一種是爬取的資源，其實就是引用一個課程中心的連接；另一種是用戶上傳的，和課程中心上的是徹底不一樣的原理，下載用戶上傳的資源咱們費了很多時間。

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

計劃中沒有緩衝區，都是從issue堆裏直接分配的（逃

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

工做重心轉移到後端，比起趕着實現博文功能，不如先把資源功能儘量完善，把較少的功能作到極致。

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

開發感受缺少計劃性，儘管最終目標很明確，可是實際開發時是走一步算一步。我感受計劃方面要向NewTeam團隊學習，他們在Alpha階段代碼編寫以前就已經將任務細化到每人、天天上，這一點比咱們強太多……

---

3. 資源

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

咱們是一人測試，四人開發，兩人前端，兩人後端，資源算是很充足了，並且組員們能力都很優秀，遇到的不少坑在你們的努力下都一一踩實了。

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

以小時爲單位記錄任務時間，估計的時候首先對任務進行一個大體瞭解，而後經過商議、查找資料等途徑判斷其難度。

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

咱們有一名成員專門負責測試，資源還算充足，只是在進行壓力測試的時候機器要一直開幾天，感受有些吃不消……咱們團隊沒有美工設計和文案，只有碼代碼的程序員。

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

有時候網站功能出現問題了會幫忙debug，但須要本身先熟悉一下代碼，這樣效率感受就有點低了（其實仍是本身比較菜）。

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

仍是感受分工出現問題，每一個人只負責職責內的工做是最好的。要是能重來，我做爲一個PM首先要保證文檔是隨着代碼進度不斷更新的，這樣可以提升成員交流的效率，其實能節省下來很多時間。在實際開發過程當中，不少bug也是由於沒有定義清楚接口和功能致使的，感受浪費了很多時間……

---

4. 變動管理

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

感受並無，有些私下決定的事並沒能及時通知你們，這一點PM須要反省。

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

核心的功能必須實現（如資源的下載和上傳），圍繞着核心功能的小功能能夠先放放（如資源的收藏和評論）。

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

並無，差很少能跑了就算出口了……

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

感受並無針對變動制定應急計劃，這一點在計劃中已經反省了，遇到變動的時候只有應急，沒有計劃。

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

中途有臨時給一些成員添加過任務，他們都接受了而且完成得很漂亮，可是我以爲意料以外的工做請求仍是應當越少越好。

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

因爲計劃性不是很強，因此對於變動也沒有概念，這實際上是個很危險的事情。另外若是出現了變動，PM要明肯定義出「什麼東西變了，什麼東西沒變」，這樣成員們大概也有個底。

---

5. 設計/實現

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

設計是在Alpha階段第一週由PM完成的，軟工團隊項目是和結對項目無縫銜接的，所以時間還算合適。

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

有，好比課程id這一部分，到底是一個遞增的整數，仍是教務上的課程碼，這一點並沒能達成一致。後來id是按照整數算的，可是又加了一個code字段，用以和爬取的資源信息進行銜接。

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

並無用到這些工具，測試驅動的話感受時間不是很夠，UML感受用處也不是很大，不過單元測試在beta階段應當嘗試一下。

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

資源的上傳，由於這裏須要將文件從本地轉移至服務器上，在發佈以後出現的bug有「沒法下載上傳的文件」、「超過1M的文件上傳失敗」等bug。因爲時間較緊，咱們只進行了簡單的測試，沒有想到「上傳的文件也能夠下載」這個問題；咱們文件的上傳大小限制爲10M，咱們前後嘗試了上傳1M如下和10M以上的文件，前者成功後者失敗，覺得功能沒有bug，卻沒有考慮到1M~10M中間可能出現的問題。

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

團隊沒有統一進行代碼複審，只是PM在Alpha階段結束以後瀏覽了一遍核心的view.py和interface.py兩個文件。其中view.py中發現了未被調用的函數，這些有的是提早開發的Beta階段的功能，有的是Alpha階段廢掉的函數。
代碼規範較嚴格地遵照了，python部分大部分函數都在開頭用註釋標註了requires，modifies和effects，前端部分也遵照了npm的代碼規範（不然編譯都過不了……），只是沒有規定變量的命名方式，這一點沒有作到統一。

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

設計階段是軟件開發的地基，值得重視。要是能重來，除了增強代碼規範外，還要對設計進行充分的考慮，儘量完善接口和數據庫說明文檔。

---

6. 測試/發佈

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

PM並無制定測試計劃，由於當時PM認爲測試是要依賴於開發的，因此更多留意了開發部分而忽視了測試部分。

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

在驗收的時候，除了運行測試樣例外，還進行了負載&壓力測試，測試同窗還提供了一些優化建議。

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

功能測試使用java版本的selenium，負載測試採用jmeter和badboy實現。

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

咱們使用jmeter測試網站的性能，在alpha階段後期進行了一次耗時兩天的壓力測試，模擬100個用戶連續訪問，請求響應的錯誤率爲0，經過此次壓力測試，咱們瞭解了網站的承受能力，固然此次測試也有須要改進的地方：

1. 運行壓力測試時要封閉其餘用戶登陸，開放環境下壓力測試獲得的最大用戶量比網站是實際能承受的用戶量略小。

2. 只在alpha階段快結束時進行了一次壓力測試，測試的次數太少，鑑於兩天的時間比較長，測試期間網站不能更新版本，從此打算每次測一兩個小時，每週測一次，以追蹤網站效能。beta階段後期再進行一次較長時間的壓力測試。

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

nginx默認的文件上傳限制爲1M，後來經過修改配置文件解決了這個問題。

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

除了要制定開發的計劃，也要制定測試的計劃，並且要增長壓力測試的次數。

---

7. 團隊的角色，管理，合做

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

調查了一下各個同窗的意願，最終狀況是，前端是有過開發經驗的兩名同窗，測試是一名很細心、能力很強的同窗，然後端是對後端開發抱有極大興趣的兩名同窗。

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

互相幫助是常常的，好比前端的兩名同窗會常常討論一些技術問題，出了bug以後你們也會很積極地尋找緣由。以前Ajax出現問題的時候你們也都積極地思考解決方法，並在羣裏告知你們。

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

組裏關係很融洽，至今沒吵過架（捂臉）。有時候代碼銜接出現問題或是任務分配不當的時候，成員們都就事論事，沒有爭吵，而是共同尋找解決的辦法，這是令我很欣慰的。

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

要了解每一名成員，包括但不限於長處、短處、性格以及時間安排等等，分配給每一名同窗最適合它的工做是墜吼的，可是作到這一點很難很難……

---

8. 總結

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

我以爲處於第一檔次，由於沒有一個較爲完整的計劃，管理經驗不足，實際開發變動較多。

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

我認爲處於創造階段，團隊中全部人的努力都是爲了最終產品的質量，總體氛圍很和諧，爲了更好地達到預期的效果，小組成員會主動學一些技術，出現問題的時候羣裏也會有交流。

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

任務分配，Alpha階段任務分配太模糊了，組員不知道該作什麼，應當作成什麼樣，這是PM的責任。若是能處理好這一點，規劃好要實現什麼，交付的標準是什麼，明確了方向組員才能投入更多的精力在開發上，而不是在揣測「咱們要作什麼」上。

8.4 對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

• 不管團隊內外，面對面的交流始終是最有效的溝通方式：每晚召開的Scrum Meeting上，除了彙報進度外，還會對開發中遇到的問題進行討論，尋找解決方法。因爲全部成員都住在三公寓7樓，有時候遇到問題也會直接一塊兒商量，很方便。
• 可用的軟件是衡量項目進展的主要指標：在先後端銜接的時候，關閉issue的條件是對應功能可使用

---

9. 全組討論的照片