Posted on 2008-08-01 16:05
帥子 閱讀(194)
評論(0) 編輯 收藏 所屬分類:
J2EE技術專區
11.你們的進度表是否反映最新開發進展情況？
??????
?????? 應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用于其它的Spec。Baseline是變更管理里面的一個重要手段。
??????
?????? 12.你們的工作量是先由每個人自己估算的么？
??????
?????? 應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
??????
?????? 13.你們的開發人員從項目一開始就加班么？
??????
?????? 不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬于剝削的范疇。
??????
?????? 14.你們的項目計劃中Buffer Time是加在每個小任務后面的么？
??????
?????? 不要。Buffer Time加在每個小任務后面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。
??????
?????? 15.值得再多花一些時間，從95%做到100%好值得，非常值得。
??????
?????? 尤其當項目后期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
??????
?????? 16.登記新缺陷時，是否寫清了重現步驟？
??????
?????? 要。這屬于Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。
??????
?????? 17.寫新代碼前會把已知缺陷解決么？
??????
?????? 要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。
??????
?????? 18.你們對缺陷的輕重緩急有事先的約定么？
??????
?????? 必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。
??????
?????? 19.你們對意見不一的缺陷有三國會議么？
??????
?????? 必須要有。要有一個明確的決策過程。這類似于CCB(Change Control Board)的概念。
??????
?????? 20.所有的缺陷都是由登記的人最后關閉的么？
??????
?????? Bug應該由Opener關閉。Dev不能私自關閉Bug。