團隊作業9——事後分析(Beta版本)
設想和目標
1. 我們的軟件要解決什麽問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
單個系統的部分功能 是 是
2. 我們達到目標了麽(原計劃的功能做到了幾個? 按照原計劃交付時間交付了麽? 原計劃達到的用戶數量達到了麽?)
完成原計劃第一部分的需求
3. 和上一個階段相比,團隊軟件工程的質量提高了麽? 在什麽地方有提高,具體提高了多少,如何衡量的?
沒,都在忙其他事,沒心思在完成下一階段(關鍵功能沒能實現)
4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?
還沒正式上線,原系統未發布,在小範圍內部測試
有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
選個自己的題目,從頭做起,才好做下去。
計劃
1. 是否有充足的時間來做計劃?
有
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的?
統一管理,各自完成
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的,為什麽?
原定第一階段完成,後續都沒心思做了(原系統不是自己的,下階段需要的功能技術為實現,都忙自己的事去了)
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
在部分功能實現方式多樣的情況下,沒有就簡單實用完成。考慮太多(或許)
5. 是否每一項任務都有清楚定義和衡量的交付件?
否
6. 是否項目的整個過程都按照計劃進行,項目出了什麽意外?有什麽風險是當時沒有估計到的,為什麽沒有估計到?
整個流程還是找預定計劃完成的。在完成一個階段的任務後。後續的任務都定義為可有可無的狀態
7. 在計劃中有沒有留下緩沖區,緩沖區有作用麽?
有 有
8. 將來的計劃會做什麽修改?(例如:緩沖區的定義,加班)
技術人員有意向繼續,那就繼續
資源
1. 我們有足夠的資源來完成各項任務麽?
沒
2. 各項任務所需的時間和其他資源是如何估計的,精度如何?
按任務點估計,不計時
3. 測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
是 否
4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?
沒
變更管理
1. 每個相關的員工都及時知道了變更的消息?
是
2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
PM一言而定
3. 項目的出口條件(Exit Criteria – 什麽叫“做好了”)有清晰的定義麽?
有
4. 對於可能的變更是否能制定應急計劃?
是
5. 員工是否能夠有效地處理意料之外的工作請求?
否
設計/實現
1. 設計工作在什麽時候,由誰來完成的?是合適的時間,合適的人麽?
三人分工,設計由PM完成 時間夠,人選屬於矮個子裏挑高的
2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?
有 能完成就好,那個快選哪個
3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效麽? 比較項目開始的 UML 文檔和現在的狀態有什麽區別?這些區別如何產生的?是否要更新 UML 文檔?
有 簡單的UML圖能夠快速反映功能點的劃分 沒怎麽變化(第一階段)
4. 什麽功能產生的Bug最多,為什麽?在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
js腳本 瀏覽器版本兼容 沒
5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規範?
PM進行 算是
測試/發布
1. 團隊是否有一個測試計劃?為什麽沒有?
沒 沒有實際意義上的函數 無法進行單元測試
2. 是否進行了正式的驗收測試?
是
3. 團隊是否有測試工具來幫助測試?
否
4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用麽?應該有哪些改進?
沒進行
5. 在發布的過程中發現了哪些意外問題?
未發布
團隊的角色,管理,合作
1. 團隊的每個角色是如何確定的,是不是人盡其才?
不算,本團隊沒有前端人員
2. 團隊成員之間有互相幫助麽?
有
3. 當出現項目管理、合作方面的問題時,團隊成員如何解決問題?
PM統一解決
每個成員明確公開地表示對成員幫助的感謝 (並且寫在各自的博客裏):
總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
初始級
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
萌芽
你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
沒有
你覺得目前最需要改進的一個方面是什麽?
執行力
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
沒有
博客要附上全組討論的照片。
......
團隊作業9——事後分析(Beta版本)