Alpha過後諸葛亮

組長博客

軟件工程項目總結思考

設想和目標

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

咱們的軟件爲了解決用戶對拼單的需求，解決用戶沒有拼單途徑的問題，定義得比較清楚。

咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？)

原計劃的功能作到了3個，未完成的部分爲舉報機制及發帖的部分，咱們在交付時間內完成了這個軟件，但有些功能尚未實現，整體而言完成了Alpha階段的計劃內容。

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

得到的經驗教訓就是必定要注重配合，若是歷史重來一遍，咱們會制定更爲詳細的計劃目標，讓項目更完美地達成預計的目標，在下一階段咱們須要對目前組員的實力進行從新評估，已制定更好的計劃以進行Beta階段。

計劃

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

對於計劃咱們用的時間較少，有必定的計劃，但不夠充分，在計劃時未考慮具體進度和學習新知識的時間，計劃不夠詳細現實。

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

對於計劃的不一樣意見咱們經過討論的方式尋求最優的解決方式。

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

原計劃的工做未能所有完成，主要緣由是時間太趕並且恰逢其餘科目有考試，致使原定計劃未能所有實現。

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

對於分配給每一個組員的每一項任務都有明確的定義，但沒有明確的衡量指標。

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

整個項目整體上都在按照計劃進行，沒出什麼意外。

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

沒有留下緩衝區，主要緣由在於時間較少且要花時間去學習新知識，同時還要處理其餘科目的學業，已無時間留下緩衝區。

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

一、設置緩衝區 二、制定合理的計劃 三、明確任務指標。

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

咱們學到了軟件開發的相關知識，並懂得了團隊的重要性，若是歷史重來一遍，咱們會多花些時間來制定一個合理的計劃。

資源

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

缺乏有過開發經驗的成員是咱們的一大問題。

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

各項任務所需的時間和其餘資源主要以該任務涉及的知識領域以及代碼量進行估計，精度不高。

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

因爲時間較少，測試的時間不夠，對於美工這類資源沒有低估其難度。

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

你們都在學習新的知識，因此沒有這種想法。

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

測試的時間須要提升，若是歷史重來一遍，咱們會多注重測試部分的時間，同時儘量多地尋找須要的資源。

變動管理

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

對於變動的消息咱們會及時在羣裏通知，因爲宿舍的緣故也會直接告知負責的人。

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

主要以可能花費的時間和學習成原本衡量，對於耗時大、學習成本高的推遲實現，比較容易實現的必須完成。

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

咱們的定義爲全部計劃中的功能所有實現且能運行即爲項目出口條件。

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

對於部分變動制定應急計劃，如服務器的搭建未能成功時就採起直連數據庫的方式。

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

若是是與負責的部分相關的意料以外的工做請求可以有效地處理，而涉及不是負責部分外的工做請求可能須要學習新的知識，並不能頗有效地處理。

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

學到了臨時變動發生時須要如何處理，若是歷史重來一遍，咱們會在計劃中對每一部分可能發生的變動制定一個應急計劃。

設計/實現

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

設計工做在項目開始初期，由組長來完成，是合適的時間，合適的人。

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

咱們會在羣中反饋工做中遇到的疑問，而設計人員會及時地參與討論，避免模棱兩可的狀況發生。

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

因爲開發經驗缺失，沒有用到這些工具，這也是須要改進的地方。

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

在登陸註冊功能上產生的BUG最多，可能的緣由是與數據庫的鏈接存在問題，發佈後發現軟件在退出後臺從新開啓時須要從新登陸，不能自動登陸上一次的賬號，目前緣由尚不明確。

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

代碼複審由各個部分負責的人自行復審，嚴格執行了代碼規範。

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

咱們學到了項目的設計與實現的通常步驟，若是歷史重來一遍，咱們會在計劃中運用單元測試等工具來幫助設計和實現的過程。

測試/發佈

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

因爲時間的關係及其餘科目的考試，咱們沒有測試計劃。

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

目前尚未測試工具來幫助測試。

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

咱們目前尚未一個有效的測試跟蹤效能的方法，這也是咱們下一個階段須要重點考慮的方面之一。

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

一些手機的系統沒法支持軟件的安裝。

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

咱們學到了對測試是一個很重要的部分，測試是一個發現問題的很重要的途徑，若是歷史重來一遍，咱們會在各個功能實現之後進行相應的測試以消除潛在的BUG。

團隊的角色，管理，合做

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

團隊的每一個角色都是本身挑選想負責的部分，可能並非人盡其才。

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

團隊成員間遇到問題都會互相尋求幫助，互相學習。

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

咱們會在羣中進行討論，必要時線下開會探討，互相交流意見，互相學習，及時處理疑惑和問題。

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

咱們學到了在一個項目開發的過程當中，一個團隊是很是重要的，若是歷史重來一遍，咱們會按照我的能力進行評估，給不一樣的人分配更適合的任務。

我感謝徐俊傑對個人幫助，由於他幫我解決了數據庫的鏈接問題。

總結

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

咱們團隊目前的狀態屬於CMM/CMMI中的可重複級。

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

咱們團隊目前處於磨合向規範過渡的階段。

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

團隊內交流更加頻繁，開發效率更高，對於出現的問題可以共同解決。

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

目前最須要改進的是測試方面的工做，因爲時間的緣由咱們未能制定測試計劃，這是咱們下一個階段須要進行改進的。

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

咱們小組作的最好的是原則4和原則7，對於原則4，咱們的組員在編寫代碼時都是共同工做，有問題互相幫助互相學習，而對於原則7，咱們一開始就以製做出一個可用的軟件爲衡量項目的主要指標。

全組討論的照片

答辯總結

• 組員貢獻比例

組員	徐俊傑	範文輝	江列湫	李家涌	連振升	黃麗萍	楊文	朱雅珊	彭佳偉	李煒煒
貢獻比	15	15	6	9	10	8	15	7	7	8

• 現場答辯得分:

• 其餘組對本組提出的問題
  其餘組未對本組提出問題。

我的PSP

過程	預估耗時（分鐘）	實際耗時（分鐘）
計劃	10	20
估計任務時間	0	0
開發	0	0
需求分析 (包括學習新技術)	100	100
生成設計文檔	0	0
設計複審	0	0
代碼規範 (爲目前的開發制定合適的規範)	10	1 0
具體設計	400	500
具體編碼	0	0
代碼複審	0	0
測試（自我測試，修改代碼，提交修改）	0	0
報告	0	0
測試報告	0	0
計算工做量	0	0
過後總結, 並提出過程改進計劃	0	0
合計	500	610

學習進度條

第n周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
12	300	300	30	30	學習Android開發