我的項目管理經歷
    項目管理經歷記錄了按照項目為單位的相關管理上的問題，包括管理思想、管理方法、
管理實踐等相關的內容。（為了保密原因其中的名稱均是化名，但并不影響真實性）

1. 新網絡管理系統項目（2005/7——2007/4）
    該項目是在xxxxx公司從事的MSTP系列通訊網絡的管理系統，用于管理公司自行研發生
產的MSTP設備和運營網絡。在該項目的開發周期內同時也有一些公司其他的項目的網絡管理
系統的開發工作（如：RPR等），所以此處以MSTP網管系統的開發作為一個項目的代表。
    MSTP項目是我所管理的第一個軟件開發項目，主要工作包括團隊的建設、項目管理和軟
件開發的具體工作。同時也是第一次引入了敏捷軟件開發——極限編程方法，在引入該開發方
法時并沒有全面的按照XP方法的內容進行開發，而是采用了根據當時情況的需要而認為較為
符合團隊實際情況的實踐內容，主要是結對編程、代碼公有制、單元測試、版本管理、持續
交付這幾個方面的方法。由于我所接手的開發小組原來并沒有形成明顯的團隊觀念，所以在
整個開發過程中為了能夠培養和組建一支高績效的團隊采用了我所認為的實踐和方法，主要
是生日慶祝制度、項目階段獎勵制度、員工等級晉級制度、每周開發會議制度、榮譽責任制
度、輪值領隊制度、為人師表制度、階段性過程改進制度、共產主義制度、共榮共辱制度、
遠景規劃等相關的方法和體制。對于具體的軟件開發活動則采用以身作則為人師表的方式給
每一個項目成員提供榜樣和參考，對于需要在團隊中采取的任何措施必須自己先身體力行，
我們遵循這樣的格言：
                   “己所不欲，勿施于人。唯己所欲，勿施于人。”
                   
    我們在項目的過程中采用了如下的階段工作安排：
    *項目初期階段
       a. 首先確定了團隊名稱、團隊宣言、團隊目標和參考的開發方法體系，然后確立了
          項目的章程與遠景目標;
       b. 接下來就是所要開發的軟件的總體架構的設計和討論工作，確保每一個團隊成員
          都能夠參與和理解所開發的軟件架構，以圍繞著架構進行工作（一個非常有效的
          工作方式）;
       c. 在確保每一個人都明確了開發的軟件總體圖景之后，需要就開發所采用的環境、
          工具和技術進行了必要的探索、準備和培訓工作，并使得每一個開發人員都能夠
          對開發的環境有一定的熟悉程度（不可能在開始前做到非常的精通，要不斷地摸
          索和學習），其中包括了開發IDE環境、操作系統、第三方工具和庫、項目工程
          目錄結構規則等等一系列的開發約束;
       注：項目的需求建立在每一個開發人員都在以前的項目開發活動中了解了項目的真
           實需求，并且網管軟件與被管系統之間的接口也已經事先定義完成。
    *項目進行階段：
       d. 確定了開發活動中風險最大的部分，然后對其該部分的子結構模型進行了抽象設
          計，并就每一個人充分的了解該部分的模型結構；
       e. 根據模型結構的劃分，將任務劃分成為幾個關鍵的組成模塊，采用結對認購任務
          和開發人員自行估算的方法進行開發任務的下發方法；
       f. 在本次迭代開發過程中，由于有些開發人員沒有全面深入的理解所開發的模塊的
          結構導致了我必須和他們重新編寫該部分的代碼，但是還是在3個月的時間內完
          成了工作并進行了第一次成果演示；
       g. 后續的開發活動則按照每一個開發人員對軟件不同部分的熟悉程度進行人物的安
          排，沒有再采用自行認領的制度，但是在全部的開發過程中均極為嚴格的要求每
          一個模塊在編寫時必須同步編寫單元測試代碼；
       h. 模塊的持續集成工作，我們在完成模塊的開發后馬上進行模塊之間的集成工作，
          雖然沒有采用嚴格的接口設計和約束，但是我們通過無阻礙的溝通和交流以及榮
          譽責任制度，保證了在所有的模塊進行集成時從未遇到任何集成問題；
       i. 對集成了的模塊進行了單獨的集成測試的編寫工作，采用代碼編寫者與測試者共
          同編寫集成測試代碼的方式保證了測試過程的順利進行，同時亦保證模塊會被更
          多的人理解和學習；
       j. 在開發過程中我們不斷地修正工程目錄結構、不斷的從遇到的問題和陷阱中提煉
          出開發規范，并在下一個階段積極的實施，做到持續的改進過程；
    *項目發布階段：
       k. 在發布階段我們最遺憾的是沒有采用項目自動化的方法保證每天都能夠進行項目
          的自動編譯和測試工作，但是我們通過共榮共辱制度使得每一個人在項目的發布
          階段不斷的保證項目的健康狀況，把項目當作自己的責任看待；
       l. 后來進行了幾次release后發現確有必要編寫一個發布腳本來完成該工作，遂通
          過最為簡單的bash腳本完成了上述的工作（雖然很粗燥）；
       m. 在完成軟件第一次完整發布后，我們組織團隊成員進行了一次天柱山之旅，大家
          興趣高昂，第一次看到了volcano團隊的真正形成；
    *項目維護階段：
       n. 根據我公司現場調試人員的反饋進行了必要的修正和再發布工作；
       o. 此時RPR項目被下達給了我們團隊，根據通訊網絡管理系統的相似性，我們第一
          次萌生了重用MSTP基礎代碼模塊的想法；
       p. 由于MSTP網管代碼并不是為了可重用的框架編寫的，所以在開發RPR項目的過程中，
          我們對MSTP網管的基礎架構代碼進行了較大的重構，由于我們開發配有單元測試和集
          成測試，所以該重構過程變得非常的順利和平滑，很快完成了該工作；
       q. 在公共基礎上進行RPR項目的開發工作，我們僅僅只花費了50天的時間就完成了
          代碼的設計、編寫和全部的測試工作，是我們從未有過的歷史；
       r. 我們在開發RPR項目的過程中，引入了MSTP項目的開發模式和全部的開發實踐及
          規范，又一次的證明了上述開發策略的有效性，同時我們形成了一個真正團結一致的
          開發團隊；
   
    最遺憾的是我沒有能夠得到公司領導的大力支持，由于公司領導采用了他自己的一套管理和開發
方法（瀑布模型），他的方法在我看來不太適合小規模的團隊，由于無法達成一致的認識，為了能夠
不在錯誤（我認為的）的開發方法上浪費時間，我選擇了離開，告別了我的團隊。現在他們回到了從
前，團隊也不復存在。經過了這樣的開發經歷，我深刻的認識到了任何工作都不是單純性質的工作，
軟件開發也不僅僅需要面臨和解決軟件開發活動中的問題，還有與所在企業文化息息相關的內容，所
以選擇開展工作的形式和方法需要充分的考慮到企業的認知和氛圍，如果不能完成你的愿望，最好選
擇離開。我認為在某些時候、經過了種種努力：
                                         “離開才是最好的選擇。”