項目管理之事後諸葛
設想和目标
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型
場景有清晰的描述？
(1)、首先我們想擴充傳統記事軟體輸入、設定時間、記錄的方式，以軟體自
動記事，圖檔資訊記事和手動記事來代替傳統的記事方式。其次我們想擴充到
點提示的傳統記事軟體使用的方式，以一種更加智能方式像使用者推薦有什麼事
需要去做。
(2)、√
(3)、√
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間交
付了麼？ 原計劃達到的使用者數量達到了麼?)?
Alphe先實作了一個簡陋版軟體，需要在Beta進行重構和優化
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目
标更近了麼?
暫無使用者量，是以接受程度暫時無法預測，等課程結束我們會再來回答。
是的，我們離目标更近了，我們每天都在犯錯誤，但是毋庸置疑我們每天都再
一點點接近目标。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
計劃
是否有充足的時間來做計劃?
√
團隊在計劃階段是如何解決同學們對于計劃的不同意見的？
我們會及時交流想法，最後會通過某種合理方式達成一緻。
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
我們本來想能自動分類使用者手寫輸入的資訊，是以我們把使用者的輸入推送到服
務器端，然後在伺服器用自然語言處理包去處理這段文字，回報一個分類；但
是我們高估了現在自然語言處理的能力，我們得到的分類往往是錯誤的，反而
使得前端顯示出現了混亂，是以現在已經暫時摒棄這方面的功能，還是采用用
戶手寫輸入、不處理直接記錄的方式。
是否每一項任務都有清楚定義和衡量的傳遞件?
我們小組比較尴尬的地方是沒有專門研究前端或者android端的同學。是以我
們選擇了可以以java語言編寫大部分代碼的安卓app。但是受限于安卓本身的
架構限制，無法做到完全解耦，是以不是每一項任務都有清楚的定義。
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是
當時沒有估計到的，為什麼沒有估計到?
在計劃中有沒有留下緩沖區，緩沖區有作用麼?
√，作用是為了解決發生的意外
将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
暫時還不會做修改，之前這個模式做的不錯，如果以後覺得這種模式不适合我
們會再做修改。
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
在小組人員分工方面，一定要對選擇做技術的同學先進行一些小測試，以防小
組成員低估了某項任務的難度而導緻後期無法完成任務
資源
我們有足夠的資源來完成各項任務麼?
各項任務所需的時間和其他資源是如何估計的，精度如何?
盡量做到各任務完全解耦然後配置設定到個人，考慮到每個人空閑時間和對任務熟
悉程度不同以一個版本作為完成時限。
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資
源 (美工設計/文案)是否低估難度?
（1）測試範圍暫時無法做到多人人肉測試，應該會采用編寫Junit代碼進行測
試。
（2）×，美工和文案都有專人負責
你有沒有感到你做的事情可以讓别人來做（更有效率）?
輪子真好用
資源方面沒有
變更管理
每個相關的員工都及時知道了變更的消息?
我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
每次答辯後的修改
項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義
麼?
對于可能的變更是否能制定應急計劃?
×
員工是否能夠有效地處理意料之外的工作請求？
程式員不能蒙頭寫代碼，要花很多時間在溝通時間上
設計/實作
設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在項目開始的時候開始設計，是合适的時間，合适的人
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
√，繼續溝通
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML,
或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文
檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為
什麼我們在設計/開發的時候沒有想到這些情況?
手寫輸入，高估了現在自然語言處理的能力
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審不是Alpha的事
加強溝通
測試/釋出
是否進行了正式的驗收測試？
團隊是否有測試工具來幫助測試？
團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些
測試工作有用麼？應該有哪些改進？
不是Alpha的事
在釋出的過程中發現了哪些意外問題？
alpha版暫時不涉及
團隊的角色，管理，合作
團隊的每個角色是如何确定的，是不是人盡其才？
是根據我們擅長和感興趣的方向确定的，√
團隊成員之間有互相幫助麼？
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
基本是誰負責的子產品誰負責，如果個人實在解決不了，我們會一起解決
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）
：我感謝吳曉輝的幫助， 因為我覺得他做到了他能為這個小組做到的一切，
是我們組的主心骨，而且正是在他的督促下我才能及時的完成自己的任務。
總結:
你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
level2
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
比需求分析階段作品的得分好了很多
你覺得目前最需要改進的一個方面是什麼?
個人覺得目前各方面都還行，不過團隊溝通應該加強
部落格要附上全組讨論的照片
不存在的