在經過了長達4個月的敏捷管理體驗後，最近才剛剛琢磨出一點道理，雖然很膚淺，但是確實是切身體會。
從開發的全程角度上看，從規範到落地，感覺最重要的部分就是需求與溝通，而其次才則是tdd和短週期交付；在開發之初，需求就好像乙個精彩電影的緒章，我們雖然可以了解到這個電影的主題是什麼，但是很難深入了解到其中的精要環節。只有隨著時間不斷的迫近交付期，我們的客戶才會在不斷的磨合中暴露出其真實的想法，此時在cmmi的週期定型情況下，往往已是架構定型，已經產出大半，為時以晚了。而敏捷的管理方式就好比把這條流水線分割開來，並不斷的請客戶來確認當前生產的東西到底是不是他想要的東西。哪怕是產品的乙個區域性工藝。
而溝通所能體現出的則是一種近似於激情式的開發方式，我們可能往往乙個團隊只有在一起吃飯時候才會將想要說的想法暴露出來，原因就是平時在工作中溝通太少了。對於技術的交流、進度的溝通都會被無意思的阻隔掉，這樣往往當生產過程進入尾聲時候，才會將各種問題保留出來，ok，現在的敏捷則盡可能能的將溝通也放在了日程的前端，我們不得不每天都開會、談心，不斷的將客戶需求、測試案例、開發風險從我們每個人的各個角度爆發出來，將最後風險爆發的可能性降至最低。
也許敏捷的開發理念還有很多有待挖掘，但是目前這冰山一角已經很有效的將風險和成本降低了下來，確實是一種讓人感覺很「爽」的方式。
關於敏捷的一些想法
敏捷軟體開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過遵循計畫 今天看了robert martin的ppp一書的第一部分，敏捷開發 回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。這些公司中不乏奉過程開發為寶典...
關於敏捷開發的一些事情
說的敏捷開發不得不提之前一直流行的 瀑布式 開發，所謂瀑布式開發 就是所有的專案開發過程都是按部就班的進行，先要需求調研有需求文件然後設計文件再後就是開發文件等等，之後就是 的編寫 測試上線，所有的整個過程都是按照一定的先後順序來進行的。瀑布式開發的好處在於管理人員可以對整個專案進行很好的掌控，專案...
關於最近使用stl的一些感受
最近用stl重寫來原來的乙個處理xml資料的類，感覺效率很高，比原來用mfc實現的簡單了很多，特別是一些關於記憶體的處理，以前用mfc的時候，需要自己處理好記憶體的管理，如果不小心的話，那麼就會出問題，而這些東西在stl裡面都是很好處理的，使 用標準的容器，將這些工作都交給模板去處理，大大減少了工作...