未讀完整本書，到最後還是堅持不下去了，對我來講收穫太小了。
基本上這本書已經的核心就是評估敏捷方法和傳統軟體工程方法的優劣，並找出彼此的相同和不同，然後相互取長補短，形成最有效的方法和過程。不過我還是無法找到想要的答案，或者是很明確的方法。其實大家早知道一定要找到適合自己的方法，不能空談什麼rup，xp，cmm或cmmi之類。但講到實踐的層面，還是xp更實際一些，更貼近我們的工作內容。
最近工作上也常遇到類似的問題，pm或再高層的經理總是說大家要提高開發速度，大家要提高修bug的速度，等等。聽得人犯睏，完全是念經，更像喊口號。提高工作效率不是光喊喊就能做的，要花很多時間和精力作為前提。光是發個郵件，會議上提一下就能達到這個目的，簡直就是痴人說夢。不過多數的管理層不相信，或是不願意相信這一點，而是指望下次真的會提高開發速度。然後再這麼迴圈下去。其實道理很明白，但真要提高開發效率，首先要找到問題所在，到底是什麼使效率如此之低，各個方面的原因都找出來，包括人、過程、產品、時間。
然後乙個乙個想辦法解決，逐漸提高個體的效率和質量，整個團隊的效率也就出來了，然後再專門對團隊進行分析，找出需要提高的地方以改進。這是只一條路，能不能達到終點還要依賴於其它因素，但始終是在朝正確的方向走著。這個很重要。
在這裡作者提供了兩種方式，使用計畫擴充套件xp的應用規模和在傳統方法中使用xp實踐。此外還提到了採用敏捷方法的缺陷，雖然我不認為那是真的。總之，如果採用xp，你會獲取更多的好處，儘管它的難度更大。首先要選擇能勝任的人，實踐xp，這中間對人的要求很高。反而是傳統的方法或cmm對人的要求沒那麼高，更注重的是過程本身。
不過，這本書也體現了它的價值，當你需要從敏捷方法和傳統方法中找到乙個折衷點，它會給你提供基本的原則和方法，以及一些有趣的實踐，當然，前提是你的頭腦要保持清醒，知道自己需要什麼。
敏捷開發下平衡質量和進度
敏捷軟體開發團隊必須確保他們開發出來的產品質量能夠滿足要求，管理團隊也經常希望開發團隊能夠提高速度以實現為客戶提供更多的功能。本篇文章中多個作者 了質量和速度之間的關係，並提出了一些既能提高質量也能加快進度的方法。bob galen曾今在他的部落格中發表了讀懂我的唇語 敏捷並不快速的文章，在其中寫到...
讀敏捷過程有感
在閱讀敏捷開發過程中，發現乙個很有意思的地方，就是敏捷提倡程式設計師開始預估自己的開發速度，再後來的迭代中得到乙個真實的速度，那麼下次的迭代計畫則根據上次迭代的得到的速度數值來計畫。這樣就可以使計畫始終按照最真實的開發速度來制定。敏捷開發通過這麼乙個簡單的方法就實現了cmmi5的不斷優化。我就將這種...
讀《老子》看「敏捷宣言」
quote 敏捷宣言 我們通過身體力行和幫助他人來揭示更好的軟體開發方式。經由這項工作，我們形成了如下價值觀 個體與互動 重於 過程和工具 可用的軟體 重於 完備的文件 客戶協作 重於 合同談判 響應變化 重於 遵循計畫 在每對比對中，後者並非全無價值，但我們更看重前者。quote 引用於 url ...