Postmortem of SendsLab

設想和目標

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

  我們的項目解決的問題是校園內部大量學生開發的成果沒有發佈的地方,無法讓更多的同學能夠方便的使用到它,同時又有大量的學生在使用校園網內部資源的時候由於信息的匱乏,難以找的自己所需使用的工具的矛盾。
  我們的項目的定義是一個適宜學生的項目開發生命週期管理與協作平臺以及創新產品集中發佈平臺。
  對於典型的用戶場景我們在項目早期便進行了充分的描述

 

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

  我們在需求調查和項目計劃的過程花費了大量的時間。做了很充分的準備

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

  在計劃階段,我們主要採取的是通過定期會議討論協商不同意見的處理。每次會議結束都會對提出的問題確定決議。


計劃

1. 你原計劃的工作是否最後都做完了? 如果有沒做完的,爲什麼?

  一直到計劃階段的工作中,除了項目設計文檔只完成了初稿之外其他幾乎都完成了。沒能完成項目設計文檔的主要原因有兩個。其一,設計方面在即將開發的時候開發者仍然提出了大量技術選擇的變動。而開發者聲稱用舊技術“沒有激情”致使不得不在此有所妥協。其二,本項目開發者相比文檔,更喜歡用EMail來解決問題,因此沒有完成該設計文檔。

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

  有,本次項目在技術選擇上變化太大,現在看來,初期的技術變化完全沒有必要,在這一方面作爲PM,當時正確的選擇是預留一段時間予以思考,並且在確定之後強硬的貫徹。 

3. 每一項任務都有清楚定義的和衡量的交付件?
  
  對於每一項任務,有着清楚的定義,但是存在的問題是,作爲一個第一次合作的團隊,我們之間的磨合往往缺乏一些認識層次上的匹配,致使往往在一位要求某種任務定義的時候,令我一位給予的定義是過於抽象層次或者過於具體層次的。
  而衡量的交付件方面做的不好,沒能每次都定義好交付結果 

4. 在項目的整個過程都按照計劃進行?
  
  項目的需求分析和計劃階段發生太多意外情況導致幾乎拖延了一個半月。而項目的開發階段,幾乎是徹底的失敗。

5. 在計劃中有沒有留下緩衝區,緩衝區有作用麼?

  預留了緩衝區,但是不夠用。而緩衝區的時間是合理的。所以證明是項目過程管理的失敗。

6. 將來的計劃會什麼修改? (例如: 緩衝區的定義,加班)?

  幾乎是由PM提出問題,之後召集衆人討論。這一方面有疑惑,肯定有好的多的解決方案。

 
資源

1. 我們有足夠的資源來完成各項任務麼?
  
  結果證明開發者是極度匱乏的。而在需求分析方面的人員正好,並且適度的通過各種手段調用校內能夠利用的人力資源。

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

  PM提出當前任務,對各人進行分工,由個人自行估計時間長短,最後PM約定一個交付時間。精度往往偏差較大。 

3. 用戶測試的時間,人力和軟件/硬件資源是否足夠?

  空

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

  有,我認爲我可以把其中的一部分工作完全交付,但是自己沒能充分發揮好隊員的特長。

 
變更管理

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

  是的 

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

  在需求階段有每週定期會議討論決定,開發階段使用eMail聯繫。

 

3. 項目的出口條件 (Exit Criteria)是否得到清晰的定義? 到底什麼叫 “做好了”?

  沒有清晰的定義。做好了的標準由PM判定能夠使用爲準。此處是一個漏洞。

 

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

  需求分析階段雖然效率不高,但是很好的處理了變更。
 

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

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

  設計工作是在需求調查的基礎上完成的。由PM負責,理論上這是不合適的,應該由架構負責,但是對於我們小團隊來說PM同時負責架構是可以的。

2. 設計工作有沒有碰到模棱兩可的情況,團隊如何解決的?
  
  設計方面存在太大的疑問,主要源於開發者和架構對於各個層次的定義的預期不同。 

3. 團隊是否運用單元測試(unit test), 測試驅動的開發(TDD), UML, 或者其他工具來幫助設計和實現?這些工具有效麼?

  沒有,開發未完成

4. 什麼功能產生的bug 最多,爲什麼?

  沒有,開發未完成

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

  沒有,開發未完成
 
測試/發佈

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

  有一個很粗略的用戶黑盒測試。

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

  沒有
 

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

  準備好了使用一些常用的壓力測試工具。
 

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

  沒有 

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

  沒有,開發未完成

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章