第6組 Beta衝刺 總結

2022-08-09 20:45:13 字數 4805 閱讀 8648

目錄3. 敏捷開發

姓名工作量

郝雷明8%

方梓涵12%

杜筱10%

鮑凌函10%

董翔雲10%

黃少丹10%

詹鑫冰11%

曾麗莉9%

曹蘭英9%

吳沅靜11%

2.1. 設想和目標

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

a: 解決的問題:為考研學子提供乙個交流經驗和提供題庫資源的平台;

定義:小程式功能定位清澈

有典型使用者和典型場景的描述:

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

a: 原計畫功能:全部做到(雖然有些不是特別符合要求)

但是根據老師的要求,是乙個「粗糙」的小程式,不能通過

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

a: 由於小程式還沒通過審核,使用者量暫且未知,

之後會補充

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

a: 不要低估了任何乙個專案的開發難度和工作量

改進:每個成員之間溝通更加緊密;

2. 計畫

是否有充足的時間來做計畫?

a: 有足夠的時間準備,團隊分工還是較為明確的,完善專案後還是剩餘一些時間

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

a: 通過線下線上討論的方式,及時溝通,互相理解這個很重要!

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

a: 按照原定的目標和要求,團隊每乙個成員基本完成都完成了

但是現在還要繼續修改,可能需要增加功能;

我們一開始沒有決定要做乙個刷題的小程式

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

a:姓名

反思郝雷明

有學到一些不一樣的,都是可以的

方梓涵沒有,都是需要完成的任務

杜筱沒有,為完成那些功能實現,做的事都是必要的

鮑凌函有,走了一些彎路,最終選擇了最合適的雲開發完成功能實現

董翔雲沒有,做的事都有用,有的是現在,有的是以後

黃少丹沒有,踩的坑都能讓我懂得如何更好地避開未來的坑,總結經驗

詹鑫冰沒有,做的都是需要的

曾麗莉沒有,目前做的都很有必要

曹蘭英雖然現在有些事現在看起來沒必要,但是以後總有乙個時刻會覺得有用吧

吳沅靜beta階段沒有

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

a: 是,分工將任務已經具體化,beta階段小組配合很順利,每個人各司其職

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

a: 基本是按照計畫進行;

專案出現的意外:小程式上線審核未通過,老師評定太差了;

風險:新的新增的模組可能做不出來,

原因:準備緩衝區了,小組分工相較於alpha也更加清晰,

專案最初的設想可能沒有闡明清楚,

沒有發布過小程式,未通過的具體原因還不清楚;

在計畫中有沒有留下緩衝區,緩衝區有作用麼?

a: beta階段一開始設留緩衝區

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

a: 向已經上線小程式的小組請教:如何通過審核

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

a: 有效的團隊合作會使專案事半功倍;

改進:無

3. 資源

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

a:之前有,人力肯定不缺,因為做的是小程式,其他資源,像時間也不是特別緊張

但是現在和以後可能時間不夠了,因為要改很多東西

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

a: 估計:根據alpha的時候每個人負責的部分,不斷優化;

小組內成員先單獨嘗試優化;

當實在沒有辦法解決,小組內進行討論,得到可行的方案;

同時也有專門的負責人催促;

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

a: 測試的時間,人力和軟體/硬體資源足夠

不需要程式設計的資源 (美工設計/文案)也沒有低估難度

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

a: 應該沒有吧

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

a: 有效的團隊合作會使專案事半功倍;

時間的分配合理促使專案更加順利進行;

改進:無

4. 變更管理

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

a: 在beta階段,基本上是每個相關的員工都及時知道了變更的訊息。

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

a: 根據實際優化情況和小組討論的結果,來決定「推遲」和「必須實現」的功能,

專案的出口條件(exit criteria – 什麼叫「做好了」)有清晰的定義麼?

a: 我們團隊一致認為:小程式功能實現作為出口條件

對於可能的變更是否能制定應急計畫?

a: 仍然沒有遇到特別緊急變化;

如果十萬火急,應該會立即開會並指定口頭上的急需計畫。

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

a: 有員工能力較強,可以意料之外的工作請求;

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

a: 有效的團隊合作會使專案事半功倍;

改進:無

5. 設計/實現

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

a: 有,協商討論一同解決。

比較專案開始的 uml 文件和現在的狀態有什麼區別?這些區別如何產生的?是否要更新 uml 文件?

a: 狀態仍然有很大區別的;

原因是專案開始時的文件是基於我們的空想完成的,實際開發過程中不斷地在調整。當然需要更新(事實上我們也確實在做這件事)

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

a: 社群功能,因為功能更加複雜;

小程式未發布,現在真機除錯,已經優化完成

**複審(code review)是如何進行的,是否嚴格執行了**規範?

a: 目前複審的準則:功能是否可以正常使用,沒有特別嚴格執行**規範

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

a: 有效的團隊合作會使專案事半功倍;

改進:適當的文字記錄會議內容。

6. 測試/發布

團隊是否有乙個測試計畫?為什麼沒有?

a: 有

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

a: 正在完成,預估beta階段結束後,測試文件將定稿了

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

a: 有

在發布的過程中發現了哪些意外問題?

a: 還沒有發布(現在未知)

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

a: 測試是乙個很難的事情,並沒有想象的簡單;

前期要盡可能考慮測試實施的可行性,測試計畫改了很多次

7. 團隊的角色,管理,合作

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

a: 根據每個人的偏好和團隊需要進行分配;是人盡其才

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

a: 有

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

a: 線下會議討論

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

8. 總結

你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?

a: 可重複級

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?

a: 規範階段

你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?

a: 分工更加明確

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

a: 暫時沒有了專案基本完成了

1-我們的最高目標是通過盡早和持續第交付有價值的軟體來滿足客戶;

舉例:這是我們團隊的共識,小程式是先將整個框架做好後,

通過不斷的除錯bug,達到產品基本可用之後,我們再進一步優化產品

2-歡迎對需求提出變更 - 即使在專案開發後期,要善於利用需求變更,幫助客戶獲得競爭優勢;

3-要不斷交付可用的軟體,週期從幾周到幾個月不等,越短越好

4-專案過程中,業務人員與開發人員必須在一起

舉例:團隊每乙個人既是開發者也是業務人員!

5-要善於激勵專案人員,給他們以所需要的環境和支援,並相信他們能夠完成任務

6-無論是團隊內還是團隊間,最有效的溝通方法是面對面的交談

舉例:我們通過線下的會議,由專門的負責人一步步指導,以確保任務可以順利進行!

7-可用的軟體是衡量進度的主要指標

8-敏捷過程提倡可持續的開發,專案方,開發人員和使用者應該能夠保持恆久穩定的進展速度

舉例:整個專案都是連貫的,

因為後端與前端是連在一起的,beta優化的時候,需要相互協調!

後端做完後,測試也已經開始了

9-對技術的精益求精以及對設計的不斷完善將提公升敏捷性

10-要做到簡潔,盡可能減少不必要的工作,這是一門藝術

11-最佳的架構,需求和設計出自於自組織的團隊

12-團隊要定期反省如何能夠做到更有效,並相應調整團隊的行為。

舉例:每次部落格編寫前都有組內都會舉行會議,討論每乙個人的接下來的任務內容。

第6組 Beta衝刺 總結

目錄3.敏捷開發 姓名工作量 郝雷明8 方梓涵15 杜筱12 鮑凌函11 董翔雲11 黃少丹9 詹鑫冰7 曾麗莉9 曹蘭英9 吳沅靜9 2.1.設想和目標 我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?a 解決的問題 為考研學子提供乙個交流經驗和提供題庫資源的平...

6組 Beta衝刺 總結

現場答辯總結 各部分功能基本完成,尤其是beta衝刺預定的推送和日曆功能也已經完成。在接下來的時間裡,我們會根據實際情況對老師和其他同學提出的建議進行產品的繼續優化,盡最大可能完善產品。全組討論的 評估團隊中每個人對本次作業的貢獻比例,描述為本次作業的工作流程 組員分工 組員工作量比例 姓名負責任務...

第01組 Beta衝刺總結

總體過程非常順利,展示了大家整個beta衝刺的乙個結果,柯老闆也為我們提出了建設性意見,後續的final版本也改為web端功能的持續完善 姓名第一輪 第二輪第三輪 第四輪第五輪 答辯與總結 貢獻分比例評定 蘇藝淞 組長 alpha衝刺總結beta衝刺規劃 雲函式debug 雲函式debug 進度跟進...