1. 程式人生 > >第一次迭代開發有感

第一次迭代開發有感

前言:時光飛逝!第一次迭代開發已經過去大概一週的時間了,有必要來個小結了。

   下面我就參考老師給出的模板,來對我們組第一次迭代開發做一個小結。

 

設想和目標

 

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

  • 我們的專案是要做一個創新課程管理系統。根據指導老師的要求,就是做一個適用於本門(軟體工程導論)課程的一個管理系統,web端應用程式。具體點來說,就是類似於我們大二上資料結構課使用的超星系統。(而在超星系統中,我們僅僅充當的是學生的角色,上傳作業,接收老師發的通知等等。但是我們組要做的是一個完整的課程管理系統,參加課程的學生、助教、老師、學校和系統管理員都要使用的一個系統)
  • 需求還是定義的比較清晰的。
  • 典型使用者:學生、助教、老師、學校管理員、系統管理員
  • 典型場景:
  1. 課程初期學生選擇隊員組成結對程式設計和團隊專案的團隊、課程初期學生選擇批改結對程式設計和團隊專案作業的助教、組隊完畢後團隊專案的小組選擇老師釋出的專案、學生接收老師傳送的通知、學生檢視本門課程老師上傳的資料、學生提交自己的個人程式設計、結對程式設計和團隊程式設計(比如每週的周計劃、周總結等等)的作業、學生檢視作業的分數……
  2. 助教批改自己負責的學生的作業,並打分、助教接收老師傳送的通知、助教檢視未按時交作業的學生,並負責傳送通知……
  3. 教師上傳學生資訊表和助教資訊表向系統匯入學生角色和助教角色的使用者、教師釋出作業、教師傳送通知、教師釋出團隊專案供小組選擇、教師檢視系統推薦的資料、教師上傳自己的課程資料並設定許可權、教師檢視助教批改作業的情況並可以修改分數……
  4. 學校管理員匯入本校使用系統的教師資訊、學校管理員傳送通知……
  5. 系統管理員匯入使用系統的學校和學校管理員的相應資訊、系統管理員設定各種不同角色(如學生、助教和教師)的許可權……

 

2. 我們達到目標了麼(原計劃的功能做到了幾個?  按照原計劃交付時間交付了麼? 原計劃達到的使用者數量達到了麼?)

  • 整體上來說達到了第一次迭代版本的目標,但是過程十分狼狽,在此就不一一贅述了……
  • 原計劃:實現教師的課程資料和個人資料的增刪改查以及上傳功能,人員管理中助教和學生表的增刪改查功能,以及每個角色的賬號管理,伺服器搭建等等。
  • 已按照原計劃時間上交檢查。
  • 由於是第一次迭代的alpha版本,所以目前還沒有使用者數量,只是開發人員在瀏覽器上測試。

 

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

  • 這是專案開發的第一次迭代,所以這個問題留待下次回答。

 

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

 

  •  目前沒有使用者,所以這個問題留待下次回答。

 

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

 

  •  開發工作不能拖延,一拖再拖的結果只能是最後不能完成任務。平時就要分出任務然後認真學習,儘量在規定時間內落實完成自己的任務。由於我們組開發用的是指導老師要求的guns框架,所以前期會有很多不懂的地方,比如springboot、maven、mybatis-plus等等很多知識。但是不能畏難,要大膽去開發,實現,實在遇到不懂的地方再有針對性地去學習,而不能像第一次迭代那樣打著學習guns框架的幌子而停滯不前。總之開發的過程中遇到難以解決的bug是很常見的事情,我們不能過於畏懼而失去了對專案的熱情。只有在錯誤中才能成長。

 

計劃

 

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

  • 有很充足的時間做計劃。我們組專案的功能很繁雜,所以前期在需求分析階段花費了很多很多的時間,但是也導致了一個問題就是我們的開發時間更少了。然後到了後期,由於需求太多,有一些小的細節都有所遺忘。

 

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

  • 當有不同的意見時,我們會很認真地進行討論,從複雜程度、將來開發的難易程度、對使用者是否足夠友好等很多方面進行討論,最終選擇一個更好的方案。

 

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

  • 並沒有。原計劃的上傳檔案以及批量讀入資料工作本來也想寫進alpha版本的,但是後期發現程式碼一直有bug,而且bug沒有得到解決,最後就沒有做出這個功能。是技術方面的原因,對guns框架的瞭解程度不夠,然後寫自己的業務程式碼時就會一直報錯,試了很多辦法也沒有解決。

 

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

  • 前期對專案原型的設計花費了不少時間。由於我們專案的功能比較多,原型方面要做的頁面比較多也比較複雜,所以就花費了很大的精力來設計原型,後來我們決定用框架時,發現原型沒有多大幫助,之前的精力都浪費掉了。

 

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

  • 是的。前期我們的任務是按角色劃分,每個人負責一個角色,然後做響應角色的功能分析、頁面設計等等。後期開發也是按功能點劃分,比如檔案的上傳下載、Excel的匯入、功能選單的實現等等。

 

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

  • 專案確實是按照老師規定的計劃進行。但是在開發階段,框架的難度和複雜度是我們沒有料到的,因為它涉及很多我們沒有學過的知識,比如springboot、maven、mybatis-plus、jquery、shiro等等很多知識,如果不瞭解這些知識,就讀不懂它的程式碼。如果沒有讀懂它的一些程式碼,我們開發過程出現bug就很難解決了,另外,開發也有難度。

 

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

  • 沒有。

 

8. 將來的計劃會做什麼修改?(例如:緩衝區的定義,加班)

 

  •  

 

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

 

 

 

 

 

資源

 

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

 

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

 

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

 

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

 

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

 

 

 

變更管理

 

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

 

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

 

3. 專案的出口條件(Exit Criteria – 什麼叫“做好了”)有清晰的定義麼?

 

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

 

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

 

 

 

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

 

 

 

設計/實現

 

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

 

2. 設計工作有沒有碰到模稜兩可的情況,團隊是如何解決的?

 

3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效麼? 比較專案開始的 UML 文件和現在的狀態有什麼區別?這些區別如何產生的?是否要更新 UML 文件?

 

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

 

5. 程式碼複審(Code Review)是如何進行的,是否嚴格執行了程式碼規範?

 

 

 

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

 

 

 

測試/釋出

 

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

 

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

 

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

 

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

 

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

 

 

 

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

 

 

 

 

 

團隊的角色,管理,合作

 

    1. 團隊的每個角色是如何確定的,是不是人盡其才?

 

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

 

    3. 當出現專案管理、合作方面的問題時,團隊成員如何解決問題?

 

    每個成員明確公開地表示對成員幫助的感謝 (並且寫在各自的部落格裡):

 

    我感謝  _______<姓名>______對我的幫助,  因為某個具體的事情: _____________________。

 

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

 

 

 

總結:

 

      你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
      你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
      你覺得團隊在這個里程碑相比前一個里程碑有什麼改進? 
      你覺得目前最需要改進的一個方面是什麼?

 

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

部落格要附上全組討論的照片。