alpha階段問題總結随筆

這個作業屬于哪個課程	2020春|S班（福州大學）
這個作業要求在哪裡	團隊作業第六次——beta沖刺+事後諸葛亮
團隊名稱	軟工實踐互動評價小組
這個作業的目标	beta沖刺
作業正文
其他參考文獻

一、設想和目标

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

   我們的項目是《軟體工程實踐》互動評價系統，要解決的是《軟體工程實踐》這門課程送出評分表的這個問題。典型使用者和典型場景還是很清晰的。(因為我們就是)

2. 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)

   基本達到目标。

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

   提高了。組員們對git工具的使用更加熟練了。

4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?

   一緻，更近了。

5. 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

   如果能重來的話，會把必要功能和拓展功能定義得更加清楚。

二、計劃

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

   有

2. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？

   如果有隊員對計劃有不同的安排，我們都會提出來，看看那個更加合理或者更加符合我們的項目程序，但其實這種情況挺少的。

3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

   基本做完了。

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

   如果說做了什麼事後看來沒有多大價值的事或者說意外的話，那可能還是展現在某些部分的設計上。比如當時看到mysql有json格式就拍案決定使用以及時間使用date格式，還有json格式嵌套的問題，都給我們帶來了很多麻煩。後來我們進行了重新設計，優化了json結構，使用時間戳代替date，花了較短時間就完成了本來的任務，這其實很大程度都是經驗上的問題，如果能有重來的話，一開始選擇正确的道路又能節省很多時間。

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

   否

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

   否，意外如上題。

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

   有預留一定的緩沖時間，但開發基本在計劃時間之内完成了，預留的時間做了一些結構上的優化。

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

   之前緩沖區穿插在沖刺周期之間，以後應該會集中一點。

9. 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?

   如果曆史重來一遍，計劃的制定可能會實際一點。

三、資源

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

   基本有，如果學校報帳伺服器就好了。

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

   各項任務大概是通過難度和經驗進行評估，精度不是很高，每個人的學習進度不一緻，而且會遇到無法預期的錯誤。

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

   測試的資源不夠。都是測試就是人工測試接口了，看到這份表格才知道有一些其他方式，還是經驗上的不足。對于一些非程式設計資源還是有一些低估了，甚至對前端也低估了。

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

   也許有，但是本次實踐重在讓大家得到提升，而不是效率高的人把事情全做了。

5. 如果能重來的話會使用一些測試工具來幫助測試。

四、變更管理

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

   有。

2. 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?

   取決于實作難度以及時間是否充裕。

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

   能夠完成核心功能流程。

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

   能，事實上有一些内容确實變更過。

5. 員工是否能夠有效地處理意料之外的工作請求？

   能。

6. 變更最重要的是能夠及時通知到所有人，我們通知其實挺及時的。

五、設計/實作

1. 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？

   設計就是在之前的作業安排的時候做的，我負責整體的設計，蔡鴻輝負責資料庫設計，張增燊負責類圖設計，然後我根據原型列出了需要的接口和一些設計規約，各組員完成自己負責的接口部分。設計之前有一些課程内容還沒有接觸到，是以不一定是合适的時間合适的人。

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

   設計會有遇到模棱兩可的時候，比如用哪種資料結構好，接口傳回的格式應該怎麼好，尖銳一點的問題我們就當場讨論了，其他問題我們一般會進行集中讨論，看哪種解決方案比較可行。

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

   一開始的設計文檔和現在有一定差別，差別産生的原因是因為一開始經驗上的不足，設計時不夠實際，也比較不清楚一些現在比較主流的解決方案。

4. 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

   我們小組項目有一個核心功能，就是定時任務，系統會在評分表截止時間到的時候自動統算每個小組和每個人的分數，這個功能産生的BUG最多，因為我們當初認為springboot架構好像有自帶定時任務功能，事實上這個功能并不好用，後來我們使用了另一個架構來完成這個任務。釋出後沒有什麼重大BUG。設計/開發的時候沒想到是因為經驗不足。

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

   代碼複審使用阿裡的代碼規範插件。

6. 如果曆史重來一遍的話，在一些功能設計上會一開始就使用一些主流的解決方案。

六、測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？

   我們小組開發的時候有一份接口開發測試情況表，上面有接口清單，以及每個接口的負責人，每個人完成和測試後要在文檔上進行登記。然後前端進行連接配接測試，測試到接口出現問題的時候直接根據文檔找接口的負責人進行改進。

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

   根據作業要求完成了測試報告。

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

   後端用了postman進行接口測試。

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

   暫無

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

   無，有預演過。

6. 我們學到了什麼? 如果重來一遍, 我們會做什麼改進?

   重來的話會使用一些測試工具。

七、團隊的角色，管理，合作

1. 團隊的每個角色是如何确定的，是不是人盡其才？

   每個人的角色是自己選的，不一定人盡其才。

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

   我們小組成員之間交流的還是挺積極的。遇到問題也都有在群裡讨論，大家也會互相幫助。

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

   有問題在群裡提出來，大家互相幫助，一起解決。

4. 每個成員明确公開地表示對成員幫助的感謝：

• 許家誠：首先感謝所有組員們的積極配合，感謝蔡鴻輝為我分擔了一部分工作壓力，感謝陳茜幫我做答辯PPT。
• 陳 茜 ：感謝所有組員們的配合，每次及時将自己的部落格部分發給我。感謝許家誠找的vue.js教程，對學習vue.js有很大幫助。
• 陳家祯：我感謝蔡俊對我的幫助，因為他幫助我學會了從前端接收body格式的資料并插入資料庫的方法。
• 肖玮昊：我感謝許家誠、張增燊、蔡鴻輝對我的幫助，因為他幫助我在Json格式下提取資料。
• 張增燊：我感謝許家誠對我的幫助，因為我經常在群裡提出一些對程式的疑問他都能耐心地回答，是一個很好的組長。
• 蔡 俊 ：感謝陳家祯，因為他在我對架構某些細節某些注釋了解不夠清楚的時候抽出時間為我解答，一起共同進步。
• 蔡鴻輝：感謝許家誠同學對我的幫助，因為他教了我如何運用定時任務架構quartz。
• 傅少華：我感謝許家誠對我的幫助，因為：因缺少vue開發的經驗，寫代碼會覺得無從下手。通過借鑒項目中家誠同學在前端實作注冊功能的代碼，完成了學生管理、助教管理等頁面的主要功能的實作。

八、總結：

1. 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?

   可重複級(Repeatable)

2. 你覺得團隊目前處于萌芽/磨合/規範/創造階段的哪一個階段?

   規範階段，目前大家已經可以根據文檔來完成各自的開發任務了，但是實作上還存在一些差異的地方，需要進一步規範。

3. 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?

   技術有長進。

4. 你覺得目前最需要改進的一個方面是什麼?

   測試上有一定不足。

5. 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

   可用的軟體是衡量進度的主要名額，我們測試的一個主要名額就是軟體是否可用，而不是某個子產品的完好。

   要做到簡潔，盡可能減少不必要的工作，這是一門藝術。我們主要開發核心功能，避免做成大雜燴。

九、正如我們前面提到的，軟體的品質 = 程式的品質 + 軟體工程的品質，那團隊在下一階段應該如何提高軟體工程的品質呢？

1. 代碼管理的品質具體應該如何提高？代碼複審和代碼規範的品質應該如何提高？

   我們之前代碼管理品質其實還行。我們一開始讓所有成員加入協作者，這樣commit就不用頻繁地去合并，然後大家直接在項目倉庫部署本地項目，規定了commit之前要先fetch，然後有更新的話要在群裡通知其他組員，然後每個人負責的檔案比較少有交叉，通過這些方式來避免沖突。

2. 整個程式的架構如何具體提高？如何通過重構等方法提高品質，如何衡量品質的提高？

   我對我們目前的程式架構還算滿意，不需要做什麼大的改動。降低耦合度。

3. 其它軟體工具的應用，應該如何提高？

   看情況。

4. 項目管理有哪些具體的提高？

   暫無。

5. 項目跟蹤使用者資料方面，計劃要提高什麼地方？例如你們是如何知道每日/周活躍使用者等資料的？

   學習一些工具的使用。根據背景管理系統來判斷。

6. 項目文檔的品質如何提高？

   多吸取教訓。

7. 對于人的上司和管理，有什麼具體可以改進的地方？

   給一些任務設一個ddl，偶爾催一下進度。

8. 對于軟體工程的理論，規律有什麼心得體會或不同意見？