這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ |
---|---|
這個作業要求在哪里 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ/homework/10151 |
這個作業的目標 | 組織事后諸葛亮會議並發布隨筆 |
設想和目標
- 我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
答:我們的軟件主要解決的是目前福州大學里沒有一個校內自己的BBS軟件的問題,對典型用戶(學生)有比較清晰的描述,相當於一個福大校內版的貼吧。
- 我們達到目標了么(原計划的功能做到了幾個? 按照原計划交付時間交付了么? 原計划達到的用戶數量達到了么?)
答:我們可能正處於達到目標的中途,目前的前端頁面實現了大部分,但是由於后端的搭建除了一些意外,導致目前的項目沒有辦法把后端功能實現,現在都是靜態的頁面,數據保存在本地。
- 和上一個階段相比,團隊軟件工程的質量提高了么? 在什么地方有提高,具體提高了多少,如何衡量的?
答:和上一階段相比,質量可以算是有所提高吧,畢竟大家都在學習,一路摸爬滾打過來,主要體現在編碼效率和團隊溝通上,不過如何衡量我們還沒有一個標准。
- 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
答:因為暫無上線,后端功能的一些欠缺,導致我們的項目還不是很完整,所以這方面沒有什么進展。不過我們從這次項目中還是學到了很多。正如上一次總結中提出來的,我們團隊溝通和一些細節方面還需要很大的改進,如果項目重來的話,可能會先選好開發語言,在留出足夠的時間去學習,最后項目再加強溝通,編碼之類的事情。
計划
-
是否有充足的時間來做計划?
答:計划階段一開始沒有花上太多時間,所以在項目過程中出現了很多問題,這也是我們團隊的 一個問題。
-
團隊在計划階段是如何解決同事們對於計划的不同意見的?
答:因為這是我提議做的項目,所以我作為組長腦海里有比較完善的一個框架,同學的問題我有些是去考慮過的,沒有想到的問題,也就是不同意見出現的時候我們還是會小討論,力求把這個問題解決。
-
你原計划的工作是否最后都做完了? 如果有沒做完的,為什么?
答:原計划的工作只做了一般吧,也就是目前已經實現的前端頁面,后端沒有做完也就是上面提到的,一是對於后端語言以及開發的學習的欠缺,二是團隊整體積極性不高,后面的情況就是有在做,但整體積極性不高。
-
有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
答:沒有多大必要的話就是在后端語言選擇的情況下,因為不太清楚后端的開發,大家都比較懵,本來想用Java,但不熟悉,無疾而終,后面想用JavaScript,也是遇到一些困難,到最后是選擇了Python的Flask框架,在其他方向上花的時間算是沒有價值吧。
-
是否每一項任務都有清楚定義和衡量的交付件?
答:不是每一個任務都有比較清楚的定義,我們是先闡述功能,再去讓同學自己根據功能和自己的想法去實現,實現了以后再規范整體風格。
-
是否項目的整個過程都按照計划進行,項目出了什么意外?有什么風險是當時沒有估計到的,為什么沒有估計到?
答:整體上是在按照計划進行,中途小意外其實也是蠻多的,首先是對Vue的不熟悉,對Uni-app的開發的不熟悉,再到后端的語言不會,不會開發環境,各個部分不知道怎么連接,相應接口實現不了,這都是沒有想到的。
-
在計划中有沒有留下緩沖區,緩沖區有作用么?
答:有留緩沖區,但是在緩沖區里沒有監督組員的進程以及進度,所以緩沖區沒有起到很大的作用,作為組長我也應該反思。
-
將來的計划會做什么修改?(例如:緩沖區的定義,加班)
答:將來的計划暫無了吧,考完之后如果有機會可能會再堅持一下。
資源
-
我們有足夠的資源來完成各項任務么?
與其他團相比隊,我們團隊個人的能力資源不是很足夠。團隊總共八個人,只有兩個人有項目經驗。我們團隊中有所有成員在編程代碼方面的能力不是很強,是導致開發大部分項目的任務需要團隊集體合作。
-
各項任務所需的時間和其他資源是如何估計的,精度如何?
各項任務所需的時間一般是按照任務的難度進行估計安排的代碼能力差所欲相對的時間就會長一點,設計ui較簡單時間充裕。測試的時間根據代碼提交完成然后進行測試,並找出BUG。 -
測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試的時間緊湊,畢竟我們代碼開發的人力資源不夠。有時不能按預期完成,沒有完成的話測試就沒辦法進行。否,代碼能力雖然不強,但其他工作必須要認真對待,來補充我們的能力資源的不足。 -
你有沒有感到你做的事情可以讓別人來做(更有效率)?
有,有時候自己工作多了遇到問題的時候就會堵在一個地方覺得很煩倦,有時候別人的思路會很清晰,旁觀者清,當局者迷。
變更管理
- 每個相關的員工都及時知道變更的消息嗎?
每次變更管理的時候,我們都會在群里發布通知開會,並且全員到齊。每位成員都會及時收到通知及時了解。 - 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
我們采用的方法是從用戶的角度出發,來決定哪些功能是軟件內必備的,哪些是附加功能,哪些是可有可無的,因此排出軟件開發功能的優先級,來決定哪些是必須在第一次沖刺Alpha階段完成的功能,哪些又是可以推遲到第二次沖刺beta階段完成。 - 項目的出口條件 (什么叫做好了)有清晰的定義嗎?
有,我們的開發的軟件項目基本能滿足用戶體驗的需求,包含論壇的發帖,點贊等基本功能都能使用。 - 對於可能的變更是否能制定應急計划?
可以的,我們團隊已經准備並制定了應急計划。在第二次沖刺過程中,我們團隊代碼環境運行出現問題,以至於我們團隊耽誤了幾天。最后通過隊員以及外界的幫助,我們在期限內完成了我們的項目。 - 員工是否能夠有效地處理意料之外的工作請求?
大部分員工是的可以處理工作之外的工作請求的。只有及個別員工,因為自身原因和自己能力沒有辦法處理。團隊內部可以理解。
##設想和目標
1. 我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
答:我們的軟件主要解決的是目前福州大學里沒有一個校內自己的BBS軟件的問題,對典型用戶(學生)有比較清晰的描述,相當於一個福大校內版的貼吧。
2. 我們達到目標了么(原計划的功能做到了幾個? 按照原計划交付時間交付了么? 原計划達到的用戶數量達到了么?)
答:我們可能正處於達到目標的中途,目前的前端頁面實現了大部分,但是由於后端的搭建除了一些意外,導致目前的項目沒有辦法把后端功能實現,現在都是靜態的頁面,數據保存在本地。
**3. 和上一個階段相比,團隊軟件工程的質量提高了么? 在什么地方有提高,具體提高了多少,如何衡量的?**
答:和上一階段相比,質量可以算是有所提高吧,畢竟大家都在學習,一路摸爬滾打過來,主要體現在編碼效率和團隊溝通上,不過如何衡量我們還沒有一個標准。
4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
答:因為暫無上線,后端功能的一些欠缺,導致我們的項目還不是很完整,所以這方面沒有什么進展。不過我們從這次項目中還是學到了很多。正如上一次總結中提出來的,我們團隊溝通和一些細節方面還需要很大的改進,如果項目重來的話,可能會先選好開發語言,在留出足夠的時間去學習,最后項目再加強溝通,編碼之類的事情。
計划
1. 是否有充足的時間來做計划?
答:計划階段一開始沒有花上太多時間,所以在項目過程中出現了很多問題,這也是我們團隊的 一個問題。
**2. 團隊在計划階段是如何解決同事們對於計划的不同意見的?**
> 答:因為這是我提議做的項目,所以我作為組長腦海里有比較完善的一個框架,同學的問題我有些是去考慮過的,沒有想到的問題,也就是不同意見出現的時候我們還是會小討論,力求把這個問題解決。
**3. 你原計划的工作是否最后都做完了? 如果有沒做完的,為什么?**
> 答:原計划的工作只做了一般吧,也就是目前已經實現的前端頁面,后端沒有做完也就是上面提到的,一是對於后端語言以及開發的學習的欠缺,二是團隊整體積極性不高,后面的情況就是有在做,但整體積極性不高。
**4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?**
> 答:沒有多大必要的話就是在后端語言選擇的情況下,因為不太清楚后端的開發,大家都比較懵,本來想用Java,但不熟悉,無疾而終,后面想用JavaScript,也是遇到一些困難,到最后是選擇了Python的Flask框架,在其他方向上花的時間算是沒有價值吧。
**5. 是否每一項任務都有清楚定義和衡量的交付件?
** > 答:不是每一個任務都有比較清楚的定義,我們是先闡述功能,再去讓同學自己根據功能和自己的想法去實現,實現了以后再規范整體風格。
**6. 是否項目的整個過程都按照計划進行,項目出了什么意外?有什么風險是當時沒有估計到的,為什么沒有估計到?
** >答:整體上是在按照計划進行,中途小意外其實也是蠻多的,首先是對Vue的不熟悉,對Uni-app的開發的不熟悉,再到后端的語言不會,不會開發環境,各個部分不知道怎么連接,相應接口實現不了,這都是沒有想到的。
**7. 在計划中有沒有留下緩沖區,緩沖區有作用么?
** > 答:有留緩沖區,但是在緩沖區里沒有監督組員的進程以及進度,所以緩沖區沒有起到很大的作用,作為組長我也應該反思。
**8. 將來的計划會做什么修改?(例如:緩沖區的定義,加班)
** > 答:將來的計划暫無了吧,考完之后如果有機會可能會再堅持一下。
資源
1. 我們有足夠的資源來完成各項任務么?
與其他團相比隊,我們團隊個人的能力資源不是很足夠。團隊總共八個人,只有兩個人有項目經驗。我們團隊中有所有成員在編程代碼方面的能力不是很強,是導致開發大部分項目的任務需要團隊集體合作。
2. 各項任務所需的時間和其他資源是如何估計的,精度如何?
各項任務所需的時間一般是按照任務的難度進行估計安排的代碼能力差所欲相對的時間就會長一點,設計ui較簡單時間充裕。測試的時間根據代碼提交完成然后進行測試,並找出BUG。
3. 測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試的時間緊湊,畢竟我們代碼開發的人力資源不夠。有時不能按預期完成,沒有完成的話測試就沒辦法進行。否,代碼能力雖然不強,但其他工作必須要認真對待,來補充我們的能力資源的不足。
4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?
有,有時候自己工作多了遇到問題的時候就會堵在一個地方覺得很煩倦,有時候別人的思路會很清晰,旁觀者清,當局者迷。
變更管理
1. 每個相關的員工都及時知道變更的消息嗎?
每次變更管理的時候,我們都會在群里發布通知開會,並且全員到齊。每位成員都會及時收到通知及時了解。
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
我們采用的方法是從用戶的角度出發,來決定哪些功能是軟件內必備的,哪些是附加功能,哪些是可有可無的,因此排出軟件開發功能的優先級,來決定哪些是必須在第一次沖刺Alpha階段完成的功能,哪些又是可以推遲到第二次沖刺beta階段完成。
3. 項目的出口條件 (什么叫做好了)有清晰的定義嗎?
有,我們的開發的軟件項目基本能滿足用戶體驗的需求,包含論壇的發帖,點贊等基本功能都能使用。
4. 對於可能的變更是否能制定應急計划?
可以的,我們團隊已經准備並制定了應急計划。在第二次沖刺過程中,我們團隊代碼環境運行出現問題,以至於我們團隊耽誤了幾天。最后通過隊員以及外界的幫助,我們在期限內完成了我們的項目。
5. 員工是否能夠有效地處理意料之外的工作請求?
大部分員工是的可以處理工作之外的工作請求的。只有及個別員工,因為自身原因和自己能力沒有辦法處理。團隊內部可以理解。
##設計/實現 **1. 設計工作在什么時候,由誰來完成的?是合適的時間,合適的人么?**
答:設計在項目開始初期,由組長完成。
2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?
答:有,通過討論決定。
3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么? 比較項目開始的 UML 文檔和現在的狀態有什么區別?這些區別如何產生的?是否要更新 UML 文檔?
答:有運用unit test,UML等工具。
有效。
與開似乎的比較區別不大。
需要更新UML文檔。
4. 什么功能產生的Bug最多,為什么?在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
答:帖子發布這個功能Bug最多。
未發布
一開始沒有想到。
5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規范?
答:未能嚴格執行了代碼規范。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
答:軟件開發從設計、實現到測試,每一步都要非常的嚴謹,要考慮的十分周全。
##測試/發布 **1. 團隊是否有一個測試計划?為什么沒有?**
答:沒有,因為一開始沒想到這個。
2. 是否進行了正式的驗收測試?
答:不算正式。
3. 團隊是否有測試工具來幫助測試?
答:沒有。
4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?
答:並未正式量並跟蹤軟件的效能。
5. 在發布的過程中發現了哪些意外問題?
答:還有很多功能未能實現,后端也沒有做出來。
我們學到了什么? 如果重來一遍, 我們會做什么改進?
答:最后結果不是很好,也是意料之中,如果重來,相信大家會更努力地去做。
##團隊的角色,管理,合作 ** 1. 團隊的每個角色是如何確定的,是不是人盡其才?**
答:由成員自己決定,看個人興趣。
** 2. 團隊成員之間有互相幫助么? **
答:有的。
3. 當出現項目管理、合作方面的問題時,團隊成員如何解決問題?
答:大家不會有什么矛盾,有問題說出來協調一下就解決了。
##總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
答:我們認為目前團隊還處於CMMI一級,執行級的檔次。因為大部分同學是第一次接觸,還是只能奔着實現項目需求出發。
你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
答:磨合階段。
**你覺得團隊在這個里程碑相比前一個里程碑有什么改進? **
答:沒有太多改進。還需努力。
你覺得目前最需要改進的一個方面是什么?
答:個人編程能力開發能力是最需要改進的。
占比
031702145 | 馬連政 | 13% |
---|---|---|
031702125 | 胡慶壽 | 11% |
031702349 | 吳斯桓 | 11% |
031702129 | 劉清宏 | 13% |
031702248 | 王振雄 | 11% |
031702132 | 江家舟 | 13% |
031702243 | 楊成錦 | 17% |
031702131 | 蔡劭凡 | 11% |