現代軟件工程 項目Postmortem 模板
設想和目標
咱們的軟件要解決什麼問題?是否認義得很清楚?是否對典型用戶和典型場景有清晰的描述?android
.咱們的軟件是聚合多個平臺的音樂。主要仍是模仿以有的音樂軟件的進行設計的。編程
咱們達到目標了麼(原計劃的功能作到了幾個? 按照原計劃交付時間交付了麼? 原計劃達到的用戶數量達到了麼?)?服務器
目前只實現了原計劃的幾個界面。主要的好多功能都沒實現。沒有在deadline以前完成任務。app
用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?工具
目前尚未作推廣,因此沒有用戶。若是有完善的版本,咱們將考慮推廣。post
有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?單元測試
在最開始的時候就沒有定下很具體,可實現的計劃。組內成員的溝通也有很大的問題。我想作的最大的測試
改進就是能增強溝通,這樣對任務的完成具備很大的幫助。設計
計劃
是否有充足的時間來作計劃?代碼規範
有是有,可是制定的計劃不合理。
團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的?
無非是你們多討論,經過合理的假設來推斷計劃的可行性。
你原計劃的工做是否最後都作完了? 若是有沒作完的,爲何?
並無作完。第一次作,不免會有不熟悉的地方,所花費的時間多,也沒有他人幫助。
有沒有發現你作了一些過後看來不必或沒多大價值的事?
因爲沒有溝通好的緣由,會致使組員之間的工做有重複的地方。目標的不明確也會致使作了許多的無用功。
是否每一項任務都有清楚定義和衡量的交付件?
沒有,只有某些的任務具備清楚定義。
是否項目的整個過程都按照計劃進行,項目出了什麼意外?有什麼風險是當時沒有估計到的,爲何沒有估計到?
根本沒有按照計劃去實現,組員的積極性實在是不高。
在計劃中有沒有留下緩衝區,緩衝區有做用麼?
有計劃過留個緩衝區,緩衝區的做用是幫助你們整合所做的成果,以及制定下一步的計劃,這樣能更好的爲後面的工做作鋪墊。但好像反而加強了你們的惰性。
未來的計劃會作什麼修改?(例如:緩衝區的定義,加班)
每過一段時間咱們將會開一次會議,會議上將會討論一些問題,針對這些問題作出對未來計劃的改善。
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
軟工實踐確實是須要團隊成員之間互相協做才行的。若是從新再來一次,我以爲首先須要有一個值得信賴的團隊。
資源
咱們有足夠的資源來完成各項任務麼?
無,人力資源尤其不足,服務器負載較差。
各項任務所需的時間和其餘資源是如何估計的,精度如何?
根據之前的經驗來估計的,精度整體匹配良好,存在部分差別。
測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
人力徹底不夠,平常只有3我的在幹活。無,難度在範圍內。
你有沒有感到你作的事情可讓別人來作(更有效率)?
爬蟲方面交由隊員更爲合適。
有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
該花錢就花錢,該抱大腿就別孤芳自賞。
變動管理
每一個相關的員工都及時知道了變動的消息?
是的,變動消息咱們會優先在羣內發佈,以後會對無反應的人員再單獨聯繫
咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
作好計劃並保留接口
項目的出口條件(Exit Criteria – 什麼叫「作好了」)有清晰的定義麼?
夠達成項目發佈時的基礎目標,並經過了必定的測試,額外目標能夠先保留以後陸續測試和更新
對於可能的變動是否能制定應急計劃?
目前還在具體商榷等待後續公佈方案
員工是否可以有效地處理意料以外的工做請求?
能
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
對軟件的開發須要更嚴謹的協調,咱們會在團隊協做和任務進度規劃上進行改進
設計/實現
- 設計工做在何時,由誰來完成的?是合適的時間,合適的人麼?
- 設計工做有沒有碰到模棱兩可的狀況,團隊是如何解決的?
- 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其餘工具來幫助設計和實現?這些工具備效麼?
- 比較項目開始的 UML 文檔和如今的狀態有什麼區別?這些區別如何產生的?是否要更新 UML 文檔?
- 什麼功能產生的Bug最多,爲何?在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
- 代碼複審(Code Review)是如何進行的,是否嚴格執行了代碼規範?
- 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
測試/發佈
團隊是否有一個測試計劃?爲何沒有?
有的,但由於基礎性的開發並無完成,在後續會有一個測試。
是否進行了正式的驗收測試?
否
團隊是否有測試工具來幫助測試?
有,android studio自帶的虛擬機以及4個不一樣廠商(覆蓋Android5-9)的測試機
團隊是如何測量並跟蹤軟件的效能的?
虛擬機以及實體機測試。
在發佈的過程當中發現了哪些意外問題?
產品基礎性的開發並無完成,暫未發佈。
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
有一個合理的測試對項目的修改和完善有很大的幫助。
團隊的角色,管理,合做
團隊的每一個角色是如何肯定的,是否是人盡其才?
根據各自的意願,例如隊員自己對於某個方面的精通或是興趣,儘可能保證可以加快進度。
團隊成員之間有互相幫助麼?
有的,例如開發組在安裝android studio期間會進行交流、溝通、情感宣泄以及對於某404公司的感激之情。以及爬蟲組在爬取歌曲資源時與親密夥伴的肢體接觸,偶爾存在親密夥伴須要重啓的狀況。
當出現項目管理、合做方面的問題時,團隊成員如何解決問題?
冷戰
每一個成員明確公開地表示對成員幫助的感謝 (而且寫在各自的博客裏):
我感謝朱躍安對個人幫助, 由於他等了我好久。
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
學到了管理學的重要性。不偷懶,不不聞不問。
總結:
你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?
成熟度級別3 - 已定義
你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
磨合
你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
迴應比較整齊劃一
你以爲目前最須要改進的一個方面是什麼?
不不聞不問
傑 33
躍安 33
佳煒 18
淇 5
鬆 5
泓 3
裕翔 3
(72+40+52+72+45+53+55+50+61-72-40)/7=55.43
1. 是否針對組內分工不明的狀況提出相應辦法?
接下來pm計劃親自深刻整個項目,努力成爲全棧
2. 就目前的進度來看,小組在協做方面彷佛遇到了困難,是否考慮如何解決?
還在商討
1. Alpha版本完成了哪些內容可否有具體的展現?
已有的內容展示於ppt上
2. 大家認爲在beta衝刺結束前大概能完成大部分功能嗎?
暫時沒法給出答案
3. 大家組內是否擁有明確的分工?
有的,各小組的討論組都建好了呢
1. 就目前的進度而言,大家或許後續的工做量挺大,可否有一個合理的初步規劃,具體到目標時間內將要完成的成果。
基礎功能先進行完成
2. 在後續的進度裏大家打算怎樣去實現大家原先設定的功能,會有與以前指望相異的地方嗎?打算作那些變更?
有的,功能方面會進行精簡,保留主體功能。
3. 目前的瓶頸是什麼,致使組內進程緩慢的緣由有哪些?後續會怎麼調整呢?
一羣懶癌患者,工做人員不超過3人,調整會在近期完成
無問題
1. 目前遇到的最大的困難是什麼?
懶,溝通不暢
2. 成員的任務是否落實到位
否
3. 有沒有對接下來未完成的任務進行明確的計劃?
先保證主體功能的完成
1. 預計在多久時間內能結束?
遙遙無期
2. 預計時間內完成目標是什麼?
所有
3. 如何看待此次任務沒完成?
很是慚愧
1. 目前爲止組內的最大問題是什麼
漠不關心
2. 對不一樣平臺的音樂內容是否能有效爬取,爲何沒有展現出來,遇到了什麼問題
只完成了一個,不能算不一樣音樂平臺
3. 核心功能的實現可能性有多大
極大,可是須要漫長的時間
1. 對於團隊內成員不聞不問的態度,如何採起有效的方法push到每一個人?
方法即將出現
2. 在已經落後這麼多的狀況下,最終大家擬定要將app作成什麼樣子?
好看的樣子(大霧)
目前的計劃是先將主體功能完成。
3. 對於近期有什麼具體的規劃?
還在商討中。