第06組 Alpha過後諸葛亮

1、組長博客：

http://www.javashuo.com/article/p-ajwstqul-dv.html

2、Postmortem模板

設想和目標

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

設計一款簡潔實用、功能齊全、爲福大學子們量身定作的基於移動設備的線上任務交易平臺APP——「福大幫幫」。在平臺上，福大校園裏的同窗能夠發佈任務及酬勞，能提供幫助的同窗能夠領取任務給與幫助，這不只幫助任務發佈者以高效方便地尋求幫助並解決問題，也讓任務領取者在幫助了他人的同時也獲取相應酬勞，一箭雙鵰；同時在平臺上，同窗間也可進行二手物件交易，尤爲是二手書交易。

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

達到了一部分的目標並按照計劃時間交付，但還未達到原計劃的用戶數量。

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

軟件還未開放公測，小範圍內測中。用戶對重要功能的接受程度和咱們事先的預想基本一致，離目標愈來愈近了。

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

經驗教訓：想作的東西太多，但時間和準備上的不充足，讓咱們不得不放棄許多功能。若是歷史重來一遍，咱們會從新分析需求，細化任務分配，挑選最重要的功能來作。

計劃

一、咱們是否有充足的時間來作計劃？

有充足的時間來作計劃，在組完隊後咱們就找時間討論要作的產品。

二、團隊在計劃階段怎麼解決同事們對於計劃的不一樣意見？

在這個階段中，咱們進行了討論，提出本身的見解，有的人提出應該實現什麼功能，在這個過程當中是否會出現什麼問題等等，對於不一樣的意見，使用少數服從多數的方式來解決分歧。

三、你原計劃的工做是否最後都作完了？若是沒有爲何？

原計劃的工做大部分都完成了，包括完成登陸註冊模塊、 二手商品的發佈等。剩餘的部分好比任務發佈尚未作完，主要是由於臨近期末，你們都有一些考試，時間上不太好協調。

四、有沒有發現你作了一些過後看起來不必活沒有多大的事？

確定是有的，在剛開始作的時候，並無很明確的思路，作了很多無用功。

五、是否每一項任務都有清楚的定義和交付件？

是，每一次Alpha衝刺的代碼都有上傳到Github。

六、是否項目的整個過程都按計劃進行，項目出了什麼意外？有沒有什麼風險當時沒有估計到？

並無徹底按照計劃進行，好比前端和後端之間的接口尚未徹底肯定下來，整個項目在相互聯繫方面並無一個明確的規範，不一樣人完成的任務會有必定程度上的差別，須要統一，這個狀況歸結到底仍是計劃不夠細緻和溝通問題。風險的話是安全性方面作得不夠，軟件安全係數低，後期時間足夠的話會考慮服務器安所有分增強安全性的途徑，以及數據庫部分沒有用戶認證。

七、在計劃中有沒有留下緩衝區，有什麼做用？

有的，緩衝區的做用就是能夠幫助咱們更好地發現問題和更高效地解決問題，進行交流彌補溝通不足和不明確各部分任務完成狀況的缺陷。

八、未來的計劃會作什麼修改？

基本上沒有什麼修改，只須要花時間把整個軟件的功能作完。

九、咱們學到了什麼？若是重來一遍，咱們會作什麼改進？

完善計劃和定製計劃一樣重要。原計劃的實施狀況已經符合咱們的預期，可是在過程當中總會有一些意想不到的突發狀況，所以及時的微調計劃對於整個項目的實行起到了很重要的做用。若是能重來一次，我但願在制定計劃時可以留下更多的緩衝時間。

資源

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

相對來講有足夠的資源來完成各項任務 ，咱們組有不少大佬！

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

根據任務須要學習的內容難易程度還有開發難度，給與適當的時間；根據實現功能實現須要什麼來肯定資源，精度通常 。

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

軟硬件，人力基本足夠，時間資源略有不足。關於美工設計與文案確實有所低估，所需資源分配不夠充足。

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

沒有。組長在分配任務的時候就考慮了每一個人的能力。

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

經驗教訓仍是時間估計的有點錯誤，和考試衝突的太頻繁了，若是再來一次的話，咱們必定會更加合理的安排好時間，。

變動管理

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

是的。

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

根據實際狀況決定。

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

有，基本完成核心功能，無明顯bug，根據實際使用狀況和用戶反饋來定義。

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

暫時沒有制定應急計劃，對於（將來）可能出現的變動，咱們會對相關成員進行積極的溝通。

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

鑑於咱們組會議時分工明確，且基本沒有負擔太多的工做，意料以外的工做請求比較少，所以對於突發狀況仍是可以接受的。

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

對於業務邏輯和產品細節要求應該一開始儘量的肯定，且充分考慮其可行性，預估可能遇到的困難，才能減少變動發生的可能性 。

設計/實現

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

設計工做在選題報告的時候就開始了 ，由組長梅恆權完成，是合適的時間和合適的人。

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

設計過程當中的確有一兩個地方模棱兩可，是由具體設計的成員提出，而後先在UI設計師內部交流出一個方案，再來詢問其餘開發人員意見。

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

使用了unit test的TDD工具，它很好的幫助將需求和系統的體系架構轉化成代碼和可視化。

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

主體部分與項目開始的UML文檔一脈相承，一些小邊幅的修改須要更新UML文檔。

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

搜索二手商品時產生的Bug最多，有時候會搜索不出來。 發佈後還沒有發現什麼重大的bug 。

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

採用結對編程的方法，由另外一位同窗去審查代碼尋找問題，嚴格執行了代碼規範。

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

掌握了不斷學習新技能的能力和各方面的基礎知識。 若是再來一次，會花更多的時間在討論需求上，同時作好代碼規範。

測試/發佈

一、團隊是否有一個測試計劃？是否進行了正式的驗收測試？

有測試計劃。未進行正式驗收測試。

二、團隊是否有測試工具來幫助測試？

直接在手機上安裝咱們的軟件進行使用來測試。

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

查看各個函數耗時、內存佔用、CPU佔用率等，找出性能瓶頸；以及在實際訪問頁面時頁面排版、頁面跳轉是否出現Bug。在數據庫測試中，測試查找最佔用時間、最佔用系統資源的查詢語句，檢測是否存在死鎖等。測試過程當中找到的大部分問題已經進行改善優化。

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

產品暫時尚未發佈，先進行本地的測試。

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

學到了HTML、JS、CSS等Web前端開發的必備知識；數據庫的設計和實現，數據庫軟件的使用；以及先後端的交互過程，網頁的運做過程，對整個Web開發的流程有了更加深刻的瞭解。若是歷史重來一遍，會更加合理安排時間，安排計劃，增強隊員之間的交流。

團隊的角色，管理，合做

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

是根據你們學習意願，本身選擇前端或者後端學習。還算是人盡其才，你們都盡力作好本身的部分工做。

二、團隊成員之間有互相幫助麼？

這是確定有的，總有學得快的或是以前有小部分經驗的人存在，互相詢問和互相討論也是咱們團隊學習技術的方式之一。

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

不論什麼類型的問題，咱們團隊的解決方法第一步都是團隊討論，而後進行集思廣益解決問題。

四、我的感謝部分。

感謝小組的每個人！你們在一塊兒努力衝刺，作好本身的任務，沒有人想要划水。

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

咱們在團隊合做方面，可以及時溝通解決，沒有出現大的問題，在這一方面咱們是比較優秀的。

總結：

一、你以爲團隊目前的狀態屬於CMM/CMMI中的哪一個階段？

我以爲團隊目前的狀態屬於CMM/CMMI中的可重複級。

二、你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段？

我認爲咱們團隊目前處於規範階段。

三、你以爲團隊在這個里程碑相比前一個里程碑有什麼改進？

在團隊的分工以及協做能力上大大提高。

四、你以爲目前最須要改進的一個方面是什麼？

目前項目的功能比較少，所以我認爲豐富功能纔是應該改進的。

全組討論的照片

3、答辯總結

一、貢獻比例

隊員姓名	分工	貢獻比
梅恆權	團隊項目管理員 （隊長）	10%
王瑞卿	產品經理	9%
楊歡	前端工程師	11%
汪倍民	前端工程師	11%
關文濤	後端工程師	11%
黃益頌	後端工程師	10%
陳夢雪	美工	10%
朱慶章	美工	10%
黃宇航	數據測試	9%
胡康	數據測試	9%

二、現場答辯得分

• 平均得分：91.5
• 總分（乘以60%）：54.9

三、提問回答

很遺憾沒有其餘小組對咱們進行提問：）

四、PSP與學習進度條

我的PSP

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

我的學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	0	0	10	10	學會markdown寫博客
2	500	500	26	36	學會json格式使用 使用request庫調用API
3	0	0	21	57	使用Axure進行原型設計 設計十三水原型
4	600	1100	16	73	進行UI設計 設計十三水UI
5	0	1100	10	88	學會軟件的選題分析
6	0	1100	13	101	學會軟件的需求分析
7	1200	2300	12	113	學會對爬取數據進行 處理並分析利用
8	0	2300	10	123	學習MySQL
9	100	2400	10	133	學習django
10	1000	3400	20	153	Alpha衝刺