團隊作業第六次—事后諸葛亮


易校園項目Postmortem結果

歸屬班級 →2019秋福大軟件工程實踐Z班
作業要求 →團隊作業第六次—事后諸葛亮
團隊名稱 未來之光
這個作業的目標 總結
作業正文 →Light of future-團隊作業第六次—事后諸葛亮
其他參考文獻

設想和目標

  1. 我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?

    答:在一定程度上便利在校師生的日常生活中兼職,代取快遞,順風車等問題,定義清晰,也有清楚描述具體在需求文檔。
    
  2. 是否有充足的時間來做計划?

    答:有時間,但是大部分人並不知道如何利用這一段時間來做計划。
    
  3. 團隊在計划階段是如何解決同事們對於計划的不同意見的?

    答:主要通過站立式會議,每個人發表各自看法,通過投票贏取大部分人同意,從而解決問題。
    

計划

  1. 你原計划的工作是否最后都做完了? 如果有沒做完的,為什么?

    答:我們已經完成絕大部分工作,剩余部分由於我們各自有其他事情要做,沒有時間繼續完善。
    
  2. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?

    答:沒有。 
    
  3. 是否每一項任務都有清楚定義和衡量的交付件?

    答:大部分都有,因為我們有嚴格的驗收標准,但是有些任務,我們並沒有考慮清楚等原因,而導致沒有嚴格驗收。
    
  4. 是否項目的整個過程都按照計划進行?

    答:基本上,因為組長的“光環”,大家大部分情況下都聽他的。
    
  5. 在計划中有沒有留下緩沖區,緩沖區有作用么?

    答:沒有。
    
  6. 將來的計划會做什么修改?(例如:緩沖區的定義,加班)

    答:如果將來有時間我們會繼續完善,並且考慮緩沖區問題。
    

資源

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

    答:我們有足夠的人力資源和學習資源支撐我們完成項目相應的目標。 
    
  2. 各項任務所需的時間和其他資源是如何估計的,精度如何?

    答:參考往屆學長學姐的項目經驗以及一些開源項目的項目安排。
    
    精度較為准確。
    
  3. 用戶測試的時間,人力和軟件/硬件資源是否足夠?

    答:足夠。
    
  4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?

    答: 組內較強的組員,可以稍微留出一些比較輕松任務交給能力較弱一些的組員,這樣可以共同進步也不耽誤項目進度。
    

變更管理

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

    答:可以,因為我們有微信群以及各自聯系方式,加上住的也比較近,所以消息流通比較方便。
    
  2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?

    答:根據我們的項目進度,與項目密切相關的功能優先實現,一些聯系沒有那么高的功能如果時間不足可以稍微延后。 
    
  3. 項目的出口條件(Exit Criteria)是否得到清晰的定義?

    答:我們項目並沒有使用到這個條件,所以沒有比較清晰的定義。 
    
  4. 對於可能的變更是否能制定應急計划?

    答:基本沒有。
    
  5. 員工是否能夠有效地處理意料之外的工作請求?

    答:我們的所有意料之外的工作請求都轉到我們的技術總監,通過他進行人員調動。 
    

設計/實現

  1. 設計工作在什么時候,由誰來完成的?是合適的時間,合適的人么?

    答:在需求分析與原型設計階段進行,由小吳和小鄒完成,非常合適。 
    
  2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?

    答:主要通過站立式會議,每個人發表各自看法,通過投票贏取大部分人同意,從而解決問題。
    
  3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么?

    答:運用了單元測試的組員,整體來看Bug不多。TDD 要求PM要清楚地確定功能說明(spec),我們目前還做不到這一點。
    
  4. 什么功能產生的Bug最多,為什么?

    答:個人中心的個人訂單查詢產生的bug比較多,因為牽涉到頁面的動態交互導致功能實現在邏輯上看起來很復雜。
    
  5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規范?

    答:起初代碼量較少的時候沒有進行代碼復審,但隨着項目的進展,BUG逐漸增多導致我們分出一位人手去進行代碼復審。根據復審人員說:基本有執行代碼規范。 
    

測試/發布

  1. 團隊是否有一個測試計划?為什么沒有?

    答:我們有測試計划,也通過這個測試計划解決了一些之前未發現的問題。 
    
  2. 是否進行了正式的驗收測試?

    答:目前還沒有,還未完成正式的驗收。
    
  3. 團隊是否有測試工具來幫助測試?

    答:否,但是有進行相關的代碼功能測試和人工測試。
    
  4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?

    答:通過項目項目人員參與功能測試,在個人的測試過程中會發現相應的輸入BUG和字符編碼BUG,從運行的實際結果看,這些測試工作幫助我們完善項目的功能,改進的話,應該利用現有大家認可的測試工具來完成比較妥善。
    
  5. 在發布的過程中發現了哪些意外問題?

    答:該項目目前只在本地進行發布,發現在手機端會出現屏幕不適配得問題,以及在其他計算機上可能因為沒有完整配置好環境出現一些運行上的問題。
    

團隊的角色,管理,合作

  1. 團隊的每個角色是如何確定的,是不是人盡其才?
角色是當初在進隊伍后大家自己選擇的。人盡其才的話,由於我們組組長是比較有代碼能力的,在后端工作上很大依賴於他,要是當時把任務多分派下去,感覺人力資源能得到更大的利用。
  1. 團隊成員之間有互相幫助么?
有,主要是在前端彼此和后端彼此,然后組長給了我們很多幫助。
  1. 當出現項目管理、合作方面的問題時,團隊成員如何解決問題?
項目管理方面的問題主要通過開會討論解決,合作方面一般是由合作雙方自行商討。

總結

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

    我們認為目前團隊還處於CMMI一級,執行級的檔次。
    
  2. 你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?

    我覺得團隊目前處於規范階段。
    
  3. 你覺得團隊在這個里程碑相比前一個里程碑有什么改進?

    相較於之前,前期的需求分析更周到,設計更詳細,團隊成員的配合更緊密,技術方面也進步了不少。
    
  4. 你覺得目前最需要改進的一個方面是什么?

    我覺得目前最需要改進的方面是團隊成員間的溝通,了解大家的長處和短處,充分發揮團隊協作的力量
    

每名成員的貢獻比

組員 工作量比例
黃檳鴻 10%
林國欽 9%
吳姍姍 10%
鄒旖 8%
胡成宇 12%
王星雨 10.5%
張啟榮 10.5%
葉艷玲 10.5%
邱煒旭 10.5%
溫俊欣 9%

團隊照片


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM