組長博客

軟件工程項目總結思考

設想和目標

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

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

我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？)

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

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

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

計劃

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

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

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

對于計劃的不同意見我們通過討論的方式尋求最優的解決方式。

你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?

原計劃的工作未能全部完成，主要原因是時間太趕而且恰逢其他科目有考試，導致原定計劃未能全部實現。

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

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

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

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

在計劃中有沒有留下緩沖區，緩沖區有作用么?

沒有留下緩沖區，主要原因在于時間較少且要花時間去學習新知識，同時還要處理其他科目的學業，已無時間留下緩沖區。

將來的計劃會做什么修改？

1、設置緩沖區 2、制定合理的計劃 3、明確任務指標。

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

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

資源

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

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

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

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

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

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

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

大家都在學習新的知識，所以沒有這種想法。

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

測試的時間需要提高，如果歷史重來一遍，我們會多注重測試部分的時間，同時盡可能多地尋找需要的資源。

變更管理

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

對于變更的消息我們會及時在群里通知，由于宿舍的緣故也會直接告知負責的人。

我們采用了什么辦法決定“推遲”和“必須實現”的功能?

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

項目的出口條件（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開發