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

第一次叠代開發有感

人員管理 浪費 課程 view cnblogs 我們 bsp 效能 失去

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

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

設想和目標

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 中的哪個檔次?
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
你覺得目前最需要改進的一個方面是什麽?

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

博客要附上全組討論的照片。

第一次叠代開發有感