第01組 Alpha過後諸葛亮

1、組長連接

http://www.javashuo.com/article/p-aisjazzk-du.html

2、現代軟件工程 項目Postmortem

設想和目標

1.咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

咱們的軟件要解決的問題是對福大校內各個任務羣、拼車羣的資源整合，方便校內學生以更高的效率拼到車或發佈任務。另外還有一個板塊用來給你們討論。定義得清楚。有。

2.咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?

目標達到了。功能都完成了，也按計劃交付了，可是還沒有對外開放。

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

用戶對重要功能的接受程度和咱們事先的預想一致。咱們離目標更近了。

4.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

好比須要更早的開啓項目，不然後面會比較趕時間。

計劃

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

有充足的時間來作計劃。

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

經過集體討論、投票解決同事們對於計劃的不一樣意見。

3.你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

作完了。

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

沒有發現你作了一些過後看來不必或沒多大價值的事。

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

是。

6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

都按計劃進行。

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

否。緩衝區爲整個項目的按計劃完成增長了保障。

8.未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

在每一步計劃中留下緩衝區。

9.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學到了關於微信小程序開發的整個流程。再來一遍，咱們會增長計劃的預留時間等等……

資源

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

有。

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

根據困難程度估計。精度大體符合預期。

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

足夠。低估了。

4.你有沒有感到你作的事情可讓別人來作（更有效率）?

有。

5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

作任何事情前要更加了解項目後再入手。

變動管理

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

知道。

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

小組討論。

3.項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

能夠完整實現某項功能的時候算作好了。

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

能夠。

5.員工是否可以有效地處理意料以外的工做請求？

能。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們學到了當功能變動的時候須要讓其餘人員即便了解方便他人手頭上的工做。

設計/實現

1.設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

做業發佈初期黃皓同窗和孫庭鑫同窗就開始進行產品的原型設計，是合適的時間和合適的人。

2.設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

有，有些界面彷佛可存在又不必，最後又團隊內討論決定的最終方案。

3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

是，頗有效。

4.比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

如今的uml更加詳盡也更加貼近實際需求。這些區別是在產品的開發過程當中漸漸對原來的設計有了更實際的改動後產生。

5.什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

都挺多的。由於做業太難了。發佈後沒有什麼重要的bug。由於你們都是第一次作這種類型的做業因此沒有經驗因而沒有想到這麼多狀況。

6.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

一個模塊一個模塊，一個組件一個組件的來熟悉，掌握。實現一個比較大的功能，儘可能嚴格遵循規範。

7.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

遇到困難，不要懼怕，微笑地面對它。消除恐懼的最好方法就是直面恐懼。堅持纔是勝利。加油，奧裏給。若是歷史重來一次，咱們必定會節省不少嘗試地時間。

測試/發佈

1.團隊是否有一個測試計劃？爲何沒有？

沒有，開發時間不是很充足。

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

是，完成後第一時間進行了測試。

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

無。

4.團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

沒有測量跟蹤。

5.在發佈的過程當中發現了哪些意外問題？

帳號鏈接有些問題。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

再來一遍，咱們遇到什麼困難，也不懼怕,微笑着面對它，消除恐懼的最好辦法就是面對恐懼，堅持纔是勝利,加油，奧裏給！

團隊的角色，管理，合做

1.團隊的每一個角色是如何肯定的，是否是人盡其才？

你們報名完成，是的。

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

團隊成爲之間經常互相幫助。

3當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

沒有這方面的問題。

4.每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

我感謝 ______一組的全部成員______對個人幫助， 由於某個具體的事情:______你們都積極完成做業。_______________。

5.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

還來，咱們遇到什麼困難，也不懼怕,微笑着面對它，消除恐懼的最好辦法就是面對恐懼，堅持纔是勝利,加油，奧裏給！

總結:

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

CMMI一級，完成級.

2.你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

團隊目前處於磨合階段。

3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

這個里程碑挺好的。比上次做業人更多了，合做更順利了。

4.你以爲目前最須要改進的一個方面是什麼?

代碼編寫能力。

5.對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談這一原則。當出現交互上的問題時，組員們能快速的互相交換信息解決問題。

3、答辯總結

團隊貢獻

成員	分工	貢獻比例
孫庭鑫	原型設計	9.8%
黃皓	原型設計	9.8%
張澤宇	產品經理	10.3%
李至恆	後端編寫	10.3%
林易豐	後端編寫	10.3%
江斯強	後端編寫	9.8%
楊藍宇	後端編寫	9.8%
沈鴻驍	前端編寫	9.8%
蔡嘉懿	前端編寫	9.8%
劉偉楠	前端編寫	10.3%

本組現場答辯得分

26

無人對本組提出問題

4、PSP與學習進度條

PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	20	15
· Estimate	· 估計這個任務須要多少時間	5	5
Development	開發	480	420
· Analysis	· 需求分析 (包括學習新技術)	60	60
· Design Spec	· 生成設計文檔	20	30
· Design Review	· 設計複審	10	10
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	60	120
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	30	45
Reporting	報告	0	0
· Test Report	· 測試報告	0	0
· Size Measurement	· 計算工做量	10	10
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	20	25
	· 合計	715	740

5、全組討論的照片