先敏捷再規範，先做到再寫到，先短期利益再長遠利益，先實效再完備。
這個策略源於實踐。因為一步到位直接採用規範的方法，阻力比較大，效果難以持久，很可能事倍功半，敏捷方法以其短期內可以見效、對已有的開發過程調整幅度小等特點易於開發人員接受，所以可以先敏捷再規範，將敏捷作為通向規範的乙個階段。
芸芸眾生，大都是凡人。凡人都是注重短期利益的。只有那些領袖、那些思想家才是目光如炬，站的高看的遠。過程改進要從凡人做起，凡人是體系的執行者，所以首先要滿足凡人的需求，讓凡人看到好處，否則，群眾的力量是無窮的，這力量可以建設的力量也可以破壞的力量。
敏捷的方法是適應變化的一種方法，因時、因勢、因事調整計畫，它可以處理近期內即將發生或已經發生的變化，它不贊成去為未來的變化太多花費時間，變化會導致近期計畫的調整，也使長期的計畫難以預期。
採用敏捷的方法並不意味著沒有規矩，沒有文件、沒有計畫、沒有跟蹤與控制並不意味著就是敏捷。敏捷方法在落實其規矩時和重量級的方法有所不同：
1 敏捷方法減少了中間結果的記錄、減少了管理與支援類的文件；
敏捷方法中最常見的是3
種角色：教練、客戶、程式設計師。教練起到了專案經理和過程指導者的作用，客戶實時執行確認與驗證的動作，程式設計師去實現產品。敏捷方法減少了管理與支援文件的工作量，但並不意味著沒有做管理，只是做的少、文件也少。比如敏捷方法也要做計畫、也要估算專案的工作量、也要和專案組的成員溝通計畫的可能性、也要獲得專案組成員的承諾，只是這些管理活動可能只有最終的計畫書，而沒有中間結果的記錄。在敏捷方法中很少看到關於質量保證活動、度量分析活動的系統要求。
2 敏捷方法強調通過面對面的口頭交流減少書面的文字交流；
文件是溝通的一種方式，口頭交流也是一種溝通的方式。在重量級的管理方法中強調了文件的重要性，而敏捷方法並非沒有文件，只是它認為口頭交流更重要，口頭交流效率更高，因此可以編寫簡單的設計文件，設計的思想可以通過口頭交流進行評審，用口頭交流彌補文件簡化的不足，因為文件簡單，將來的變化也就少，維護的工作量也相應減少。
3 敏捷方法強調最終的交付物而忽略了中間產物。
關注最終交付物的質量而不是中間結果的質量，採用諸如單元測試、結對程式設計、**重構、持續整合、**規範等手段確保源程式的質量，採用迭代的方法盡早進入程式設計，在過程中通過溝通進行設計的實**審、**的實**審，以便於盡早發現交付**的缺陷，盡早修復缺陷。作為開發過程的中間產物需求與設計等文件則進行了簡化。**是必須交付的，所以要採用一切手段規範之，既然要交付，就要保證其質量。而需求與設計文件並非是必須交付的，而需求和設計也是經常變化的，既然不交付，既然始終變化，乾脆就不去花時間去寫。
4 高效的人比規範的過程更重要。
一群精英如果能配合默契的合作，則不需要去監督他們是否按照標準規範去執行了，這個團隊是自我管理的，大家有著共同的價值觀，彼此能快速協同，互補合作，最終走向成功。是英雄創造了歷史，還是人民群眾創造了歷史？結論不言而喻，但是如果沒有英雄呢？如果各位都是英雄呢？
以上種種思想，反應了敏捷方法的實用主義哲學。如果一家企業的專案大都在10人以下的開發團隊完全可以從敏捷方法開始著手進行過程改進。但是，軟體開發是一種非規模經濟的現象，隨著團隊規模的增加，上述的手段可能很快就失效，還要回到重量級方法上來。
先敏捷再規範
先敏捷再規範，先做到再寫到，先短期利益再長遠利益，先實效再完備。這個策略源於實踐。因為一步到位直接採用規範的方法，阻力比較大，效果難以持久，很可能事倍功半，敏捷方法以其短期內可以見效 對已有的開發過程調整幅度小等特點易於開發人員接受，所以可以先敏捷再規範，將敏捷作為通向規範的乙個階段。芸芸眾生，大都...
再理解敏捷
2009年1月24日 2008年春，專案做的對敏捷有了點興趣，花了兩個晚上瀏覽了 敏捷迭代開發 管理者指南 理念式的書，看起來比較輕鬆，摘錄一些自己的體會。有些需求在開始的時候是提不出來的，或者說沒法細化的，強行的過渡需求分析是浪費時間的行為，到後來多半還是要改。瀑布 其實royce大大提出的瀑布模...
先ORDER BY再GROUP BY問題
我需要實現標識最小的顯示出來，並且binglihao沒有重複 以張三00為例，張三00有兩條資料，一條標識是50，另一條是56 語句 select from select h.xingming as xingming,h.binglihao as binglihao,j.biaoshi as bia...