1. 程式人生 > >團隊作業9--事後分析

團隊作業9--事後分析

階段 nbsp border ref cells ria 模板 是什麽 order

事後諸葛亮分析

四則運算 項目Postmortem 模板

整理:林國梽

設想和目標

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

  解決老師和家長的負擔,讓小學生能自主更高效的進步。想實現的功能還有點差強人意。

2. 我們達到目標了麽(原計劃的功能做到了幾個? 按照原計劃交付時間交付了麽? 原計劃達到的用戶數量達到了麽?)

  原計劃計劃的功能基本做到,按時交付,原計劃用戶數量未達到。

3. 和上一個階段相比,團隊軟件工程的質量提高了麽? 在什麽地方有提高,具體提高了多少,如何衡量的?

  質量提高了,在各自的默契程度上有了相當的提高,想表達的意思原來需要幾句話來描述,現在只需一句話,對方就能心領神會。

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

  沒有用戶,所以也就沒有用戶的接受程度情況。

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

  如果歷史能再重來一次,我們會增加推廣,爭取找到用戶來使用我們的app。

計劃

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

  有較為充足的時間來做計劃。

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

  對於計劃的不同意見,采用投票形式來解決。

3. 你原計劃的工作是否最後都做完了? 如果有沒做完的,為什麽?

  原計劃的工作差不多都做完,沒做完的有一些的界面美化,因為工作量有點大。

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

  沒有。

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

  我們覺得是的,但在別人看來可能還差了點吧。

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

  項目過程很順利,並沒有什麽太大的意外風險。

7. 在計劃中有沒有留下緩沖區,緩沖區有作用麽?

  有留下緩沖區,主要是為了優化。

8. 將來的計劃會做什麽修改?(例如:緩沖區的定義,加班)

  將來計劃更加明確緩沖區要做的任務,細分任務。

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

  計劃很重要,一定要好好的規劃。

資源

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

  沒有用戶。

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

  根據自身的能力來預估,精度還行。

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

  資源不太足夠,工作量還是有點大。

4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?

  測試讓別人來做可能更有效率,我就稍微粗心點,耐心差一點。

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

  準備好大量的資源,這樣下次肯定能事半功倍。

變更管理

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

  同一宿舍,消息絕對同步。

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

  投票決定。

3. 項目的出口條件(Exit Criteria – 什麽叫“做好了”)有清晰的定義麽?

  一開始就沒有讓項目出口的想法。

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

  應該不會計劃,有變更就直接處理。

5. 員工是否能夠有效地處理意料之外的工作請求?

  沒有經過意料之外的請求。

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

設計/實現

1. 設計工作在什麽時候,由誰來完成的?是合適的時間,合適的人麽?

  由組長完成,是合適的時間,合適的人。

2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?

  沒有這種情況。

3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效麽? 比較項目開始的 UML 文檔和現在的狀態有什麽區別?這些區別如何產生的?是否要更新 UML 文檔?

  運用了單元測試,發現更加的高效。

4. 什麽功能產生的Bug最多,為什麽?在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?

  錯題本的bug較多,因為每個人的錯題本記錄都不一樣,要做各自的保存。

5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規範?

  小隊成員之間輪流進行。

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

測試/發布

1. 團隊是否有一個測試計劃?為什麽沒有?

  有。

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

  正確。

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

  沒有用到測試工具。

4. 在發布的過程中發現了哪些意外問題?

  都是一些小問題,比如換個電腦,重新運行就會出現一些有的沒的bug。這應該是數據庫的連接沒搞好。

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

  對於要發布的項目,測試還是很重要的,之後我們會更加認真的對待測試。

團隊的角色,管理,合作

1. 團隊的每個角色是如何確定的,是不是人盡其才?

  根據對方的意願來整合分配,人盡其才可能還差點。

2. 團隊成員之間有互相幫助麽?

  互相幫助是有的,經常集思廣益,討論問題。

3. 當出現項目管理、合作方面的問題時,團隊成員如何解決問題?

  基本沒遇到什麽問題,相互之間合作的很愉快。

  

每個成員明確公開地表示對成員幫助的感謝 :

我感謝 ____小隊各個成員_____對我的幫助, 因為某個具體的事情: _____每個人都或多或少的對我有幫助,盡力盡力的幫我討論分析問題___。

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

  眾人拾柴火焰高。

總結:

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段? 你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進? 你覺得目前最需要改進的一個方面是什麽?

  還處於萌芽的階段,對於上一個裏程碑來說可是質的飛躍,從無到有的可怕進展。最需要改進的就是要做好充分的計劃。

全組討論的照片

技術分享圖片

團隊成員在Beta階段的角色和具體貢獻:
名字 角色 團隊貢獻分 可驗證的貢獻
張洪濱 PM 21 整合了項目
林國梽 Dev 19 註釋
唐壺海 Test 20.5 bug被修復了
黃興 Desiger 20 設計各個界面
陳敬軒 Test 19.5 bug被修復了

團隊作業9--事後分析