一.   項目基本狀況

1.      作業時間2008年7月9日– 2008年10月7日

2.      作業范圍詳細設計，編碼，PT測試。

3.      人員結構 PM1人+PJL1人+Member5人+支援1人

二.   這是一個什么樣的項目

項目本身很正常，卻無法正常去做。

最根本的原因，就是時間不足。

基本狀況就是，一個需要六天的任務，只有三天的時間去完成，這種狀況普遍存在。

所以，這個項目從一開始，對我們的PM，PJL來說，就是一種挑戰。

三.   這是一個什么樣的問題

時間問題。說到時間問題，每個人都會有不同的主觀想法。Member會覺得是工作量過大，領導會覺得是客戶太XXXX，客戶會覺得是我們的能力不足。

客觀的說，就是，以我們現有的水平無法在預定時間內完成計劃中的任務。

不管是什么原因造成的，就是這個問題，從項目開始就出現了。

四.   對策

1.      加班。從項目開始一直持續到最后。

2.      加人。先后加了兩個人。

3.      以降低質量來換取進度。這一點不是領導說的，是我說的。領導一直在強調，不管進度如何，一定要保證質量。但是誰心里都明白，既要保證質量，又要保證進度，那是不可能的。

五.   對我的影響

式樣理解階段：沒有。被擠到DD設計的時間里了。

DD設計階段：式樣沒理解透就開始DD，結果質量不好，做的也吃力。達不到指導編碼的效果。（項目的最后兩天，重新修改DD，若要完全修改的話，我的修改量可達80%）

PG階段：只能說是寫完。無法保證質量，PG結束后，對自己的代碼仍沒有信心。

PT階段：很多PG的問題殘留到PT，導致修改量大。很需要二次PT。

交叉測試階段：我被發現的問題有很多。對我來說，是最重要的5天。

六.   我的流水賬

7月9日

項目啟動的第一天，大部分時間在開會，了解一下項目的基本狀況，以及項目組成立后的注意事項，比如，任務安排，職責安排，作業方式，共通內容等等。

7月10日

按照大工程表的劃分，今天開始作業，內容是XXX機能的詳細設計，共4天。我自己在小工程表中劃了兩天的時間作為式樣理解。

7月14日

第一個延遲。

延遲原因：

1. 式樣理解不足。

2. 沒有詳細設計模板。

對策：

加班、調整工程表。

從這一天，我的延遲生活開始了，并基本上一直保持到最后。

從這一天，我們項目組的加班生活也開始了，每天9：30，周六加班，周日看情況。

7月15日

關于DD，PG的先后。

做這個項目前，我一直認為，對于我現在的水平，合理的做法應該是先PG，再DD。結果被領導否了，領導說，先PG再DD會限制住一個人的設計思路。我開始嘗試不編碼，直接DD，結果感覺很好。

7月17日

對DD的認識，發現兩點很重要：

1. 自查時，一定要打印出來，校對格式。

2. DD內容的準則，就是，找一個傻瓜過來，也能看懂你的設計思路。

7月21日

第二個延遲。

延遲原因：

1.  作業量大。

工程表上三天的任務，我在加班的狀況下，實際用了八天的時間。

2.       不穩定作業。

開會頻繁，無確定時間，作業經常被打斷，且占用時間長。

3.       過多的計劃外的事。

很多工程表之外的事情需要對應。如WT實施，WT對應，共通類實現等等。

    對策：

    加班、調整工程表。

    7月24日

    領導心情很差，很煩躁，作業氣氛開始壓抑。

    我決定給領導打起，因為我覺得，無論遇到什么困難，領導在手下面前都應該是自信滿滿的樣子，即使心里極度煩躁。

    7月25日

    一個人嚴重的問題暴露了，member的問題。

    當前項目組5人在作業，由于技術原因，只有一人能夠正常DD作業，就是leader。

    其余四人技術上的情況如下：

    Member1：無XX框架經驗。沒做過前臺jsp。

Member2，無XX框架經驗，自學過一陣子。

Member3，無XX框架經驗。

Member4，就是我，了解XX框架，但我的作業只用java，和XX框架沒有關系。且java部分無框架。

由于XX框架的特殊性，對DD的要求很高，不懂XX框架的話，DD會很吃力。

    7月26日

    領導的狀態恢復了。

    針對項目組的作業狀況（普遍延遲），領導的對策是，加一個人。很明智。

    7月27日

    領導的又一個明智的決定，讓Member1和Member3提前進入PG階段。

在另一個項目的case study中，也聽到了這樣的經驗，對技術不熟的人，很實用。

    這樣能夠讓這二人，更直接的熟悉框架，提高后期的作業質量，減少風險。

    7月28日

    我們犯了一個錯誤。

    框架設計和DD設計應該是分開的，而且，框架設計應該在DD設計之前完成。

而我們卻是在DD設計的同時各自設計各自的框架，當WT之后才開始統一。

    7月29日

    總結一下這個階段從領導身上學到的：

1.      在緊張的階段，要時刻鼓勵大家，而不是督促大家。

2.      不懷疑手下的工作方式和工作效率，要相信他。即使不放心，也要私下里說。

3.      不輕易在會議上直接批評別人，也不在別人面前說自己組員的不是。

4.      懂得自我批評。

    8月2日

    總結一下這個階段學到的開會的學問：

1.      定時。

對于每天的例會，時間上要規定好，這樣可以讓member避免自己的作業被突來的會議打斷，而且還可以讓member事先對會議有準備。對于一些臨時的會議，也要盡可能的提前通知，不要隨叫隨開。

2.      效率。

開會人提前做好準備，要說哪些事，要統計哪些事。完事立馬散會，不要把會議的內容拿到會議上去想。

3.      語言精煉

一共有哪幾件事，需要大家知道什么，需要大家做什么，怎么做。

Member只關心一件事，需要我做什么，怎么做。至于這個問題你是怎么發現的，怎么思考的，怎么設計的，我們不關心，我們關心的只是你最后的決定。

4.      能用郵件說明的，盡量用郵件。

節省時間，還能有所保留。   

    8月3日

    正對目前的作業狀況，日方提出方案，改變項目作業方式。

    以機能為單位，分別進行DD->PG->PT。而且，每周按機能向客戶提交成果物。還好我當時的DD已結束，接下來要做的就是機能1的PG,PT，然后進行機能2的PG,PT。…….

    這樣的好處：可以提前發現一些PT的問題，進而在下一個PG中避免。

    這樣的壞處：頻繁的修改和維護文檔。PG,PT的質量會有影響。

    8月5日

    關于review的問題。

    據說第一次review都要全員參加。

    我們review的方式完全是在模仿日本的review方式：會議室全員review。

    結果不是很理想，因為項目組的大部分人技術和經驗都沒有達到能夠直接review的水平。

    這件事讓我意識到一個問題，不能盲目的模仿日本的作業方式，應該結合我們自身的實際水平，用適合我們自己的方式。個人覺得，我們項目組的方式應該是這樣的：

1.      針對某一個機能，在review前，安排2-3人（或者全員）在自己的機器上review，時間由review者在當天自由安排。

2.      review者將review結果直接告訴給被review者。

3.      review者將共通的問題，以mail的形式全員通知大家（或者利用早會）。

4.      有需要的話，可以在大家都review之后，再去會議室集體review，內容為大家陳述自己的指摘內容，而不是大眼兒瞪小眼兒的在那兒看。

5.      多多鼓勵大家主動review，自己寫完了，主動找別人幫看一下大概。

6.      參考別人代碼的時候，也隨時幫別人指摘。比如一些類似的地方，無所謂誰對誰錯，只要大家做法統一就好。

總之，我們目前的水平，還不能靠經驗來review，只能憑借剛剛做過的內容，再看到別人犯同樣的錯誤時，就能夠指摘出來。

8月6日

Review工作改為一對一的方式。由PM和PJL擔任，分別review我們的各個機能。

這樣，PM和PJL的工作任務又重了，由于時間的緊迫，使得一些機能無法得到及時的review。增加了一些不必要的修改時間。

這里讓我想起某項目的一條經驗，就是對每一個擔當的第一個成果物要做到100%review。大概就是這個意思，這就是兩個項目的差距，他們有式樣理解的時間，有WT，CR的時間，而我們，這些內容，只能自己擠時間來做。

這樣的情況下：

談質量？談方法？

8月7日

總監請項目組全員吃飯。

慰問餐。

    8月12日

    測試開始，整理幾個問題：

1.      一定要發布到一個專門的服務器上，在服務器上測試。特別是在這種PG,PT交替進行的作業方式的情況下。

2.      測試的過程中，不要使用個人相關或者公司相關的數據作為測試數據，特別是截圖。

3.      養成每晚下班前，checkin自己的代碼的習慣。

4.      checkin之前，先取得服務器的最新版本，保證代碼編譯正確。

Java工程中，即使個別文件有編譯錯誤，其它文件依然可以正常編譯，但是有些語言的工程是需要全部文件編譯無誤后，才可以正常編譯的。

5.      eclipse中由一個Checked Out Files的View，可以一覽所有已checkout的文件。

6.      每天早上來了之后，先取得最新的代碼，保證大家代碼一致。

8月14日

式樣變更的問題讓人頭疼。

這次讓我頭疼的不是變更的內容本身，而是在對應變更上。

1.      全員開會討論，如何對應變更。

這樣做沒有必要，領導內部討論完，給member一個方案就成了。

2.      對于某個變更，花了很長時間在全員會議上講，為什么這樣對應，還讓大家去想領導的這種方式好不好。

這樣做也沒有必要，不是自己的機能自己也聽不懂。對于member，我承認，需要有自己的主見，但是在那種情況下，member需要的，就是結論。

    8月19日

    我生日。其實很期盼領導跟我說一句，過生日，今天就別加班了，結果一直等到9：30也沒聽到，可苦了在家等我的那幫兄弟們。

    8月24日

    延遲白熱化。

    延遲原因：

1.      作業量大。

以Member1為例，一個機能，三天寫了4000行代碼，沒寫完，最后用了9天多，寫了20幾個類，凈代碼6000多行，還包括幾個共通的類。

這樣的結果是，他在例會上被領導狠批了一頓，因為延遲。

2.      延遲。

因為延遲，所以延遲。就是這樣。我的體會就是，一直處于延遲狀態，影響我的作業質量和作業效率。

    對策：

    加班、調整工程表、找人分擔剩余作業任務。

    我覺得，PG階段，我們的代碼質量可以做的更好，但是，這樣的原因，導致，自己編碼之后，對自己的代碼一點信心都沒有。因為我幾乎沒有認真的從頭到尾看一遍自己的代碼。

    8月25日

    部長，PM，PJL安排項目組聚餐。

    得以小釋。

    8月29日

    關于編碼。

    我習慣上是先寫代碼，待代碼調通之后，再從頭整理代碼（格式，補注釋以及代碼優化）。每個人的習慣都不同，但這次，很吃虧。由于代碼邏輯比較復雜，代碼量也比較大（幾千行），等我調試之后，再回頭整理的時候，真的很頭疼。

以后決定，編碼的同時，寫簡單注釋。

    9月4日

    項目開始走入正軌。主要表現在：

1.      大家對作業內容和作業方式都基本熟悉了。

2.      領導加人和調整工程表后，延遲逐漸向0發展。

3.      領導心情變好了。

這一個月，雖然依然在加班，但是比前兩個月好多了。

9月7日

發現兩個領導的一個共同優點，隨和，不擺領導架子。值得推廣。

9月9日

關于匯報進度。

從項目啟動開始，每天都要匯報進度，直到現在才認識到一些問題：

1.      項目組要事先定義好進度的標準。

對于一個機能的DD,PG或者PT來說，什么樣算100%，什么樣算90%，什么樣算80%。定義好，會節省很多不必要的再質問的時間。

2.      匯報內容要詳細

有人認為這很浪費時間，我覺得很有用，也很值得。

既能整理自己的思路，又能讓領導及時準確的了解你的作業狀況。

主要說明這樣幾件事：

1.      今天計劃做的內容。（工程表中要完成的）

2.      今天實際做了哪些內容。

3.      延遲情況（是否有延遲，有的話說明原因）

4.      對策（基本上就是加班，說明自己什么時候能過挽回延遲）

5.      遇到的問題。（包括一些橫展開的注意點，以及一些無法解決的困難）

6.      PT的話，要說明，測試機能名，預計測多少點，實際測多少點，產生多少bug，對應狀況等等。

總之一句話，盡可能的說明白。

這個項目，基本上都在例會上匯報進度。個人感覺，不如改用郵件的方式更好一些。

9月14日

劃工程表的一個小失誤，沒有考慮到節假日。（端午節休息）

9月16日

寫郵件時，被領導指摘了。一定要寫有意義的title。

9月27日

加班生活結束。

10月4日

提交最終代碼。

10月6日

修改DD。

再回頭看自己兩個多月前做過的DD時，發現做的真的很爛。

1. 缺少框架的概念。

2. 欠缺共通的思想。

3. 關于異常，Log等細節考慮的不全面。

以后需要注意。

七.   項目之后，談談心情

從心里來說，其實從不覺得這個項目累，比起曾經，這樣的加班不算什么。但是，這個項目做起來，沒有做上一個項目舒服。

做上一個項目的時候，自己一直被領導和身邊的人肯定著，我付出的越多，越能幫助大家解決更多的問題，所以，雖然每天加班到很晚，但是做的很開心。

做這個項目的時候，從一開始我就處于延遲狀態，每天加班的目的只有一個，就是挽回自己的延遲。別說幫別人分擔作業了，連自己的作業都無法完成。這樣的加班，不可能是開心，只能讓我更加急躁。最煩的時候，甚至開始抵觸加班。

那段日子，不只我煩，包括領導，大家都煩。雖然心情會影響到一部分工作，但大家還是一起挺過來了。

我覺得我們是成功的，因為我們都堅持到了最后。

無論遇到什么事，只要堅持住，相信一切都會好起來的。

歡迎來訪！^.^!
本BLOG僅用于個人學習交流!
目的在于記錄個人成長.
所有文字均屬于個人理解.
如有錯誤，望多多指教！不勝感激！