說的敏捷開發不得不提之前一直流行的「瀑布式」開發，所謂瀑布式開發：就是所有的專案開發過程都是按部就班的進行，先要需求調研有需求文件然後設計文件再後就是開發文件等等，之後就是**的編寫、測試上線，所有的整個過程都是按照一定的先後順序來進行的。
瀑布式開發的好處在於管理人員可以對整個專案進行很好的掌控，專案進行到哪個階段，進行到什麼程度可以很清晰的了解。開發人員也不必擔心自己的沒有事情可幹，或者自己的事情做不完，整個過程中的每個人都是很清楚的應該做的事情。
凡事有利就有弊，瀑布式開發的弊端同時也是它的優勢，專案管理過程不靈活，若有新的需求變化，需要重新制定整個或者區域性的過程，在此過程中開發人員需要等待流程走到自己的這部分時才可以進行開發，開發人員的主動性沒有很好的發揮出來，雖然開發人員可以更專注的進行編碼工作，但是由於對文件和專案的理解程度不同，造成實現的結果也會出現偏差。
敏捷開發強調的是迭代開發、增量開發，及時溝通及時修正，在時間和管理上更加的靈活，更加的有效和積極。
敏捷開發過程中
1.在開發過程中，要有積極主動的態度；
2.樂於分享自己在開發過程中遇到的問題以及解決方法；
3.不要在乙個問題上過於的糾纏，要懂得放棄；
4.要有不滿足於現狀的心態，對於自己不懂的東西要想辦法弄明白；
5.積極的與使用者進行溝通，把批評當做一種資訊，而不是錯誤；
6.理解業務需求、設計文件，把它作為指導但不是作為依賴；
7.使用自己學過的技術或者之前的技術要合理，不過度炫技；
8.提前配置好可以發布的環境；
9.不停的測試演示給客戶或者專案組的其他人看；
10.先完成在完善。先要完成核心功能然後在不停的完善其他次要的功能；
11.正確評估自己的開發進度；
12.**格式要規範，**要清晰，盡量不適用不常用的語法，以**清晰乾淨為榮；
13.程式最好的注釋就是**本身；
14.編寫必要的注釋，注意：是新增必要的；
15.保持簡單。簡單不失簡陋業餘也不是能力不足，而是大道至簡；
16.物件導向開發要保持每個類的內聚；
17.把乙個類中的修改功能和查詢功能分開；
18.要面向介面程式設計，隨時都由替換整個類的能力，而不同擔心出現問題；
19.把自己解決過的問題記錄下來，以便可以隨時查閱；
20.不要忽略警告資訊，在某些情況下，警告也是錯誤；
21.對於程式中的問題，要集中精力解決完成乙個之後再解決另外乙個；
22.對於使用者來說要提供給使用者有用的提示資訊，而不是似是而非的資訊；
23.團隊內部之間要經常性的溝通和交流；
24.專案的架構師也要寫**，深入了解專案的產生的過程，並且對**的質量要負責；
25.專案中成員要相互了解彼此的開發內容，可以隨時的切換；
26.分享自己的知識與經驗；
27.當成員提出問題時，先鼓勵對方自己自己想辦法或者給予提示；
28.專案中成員要及時匯報自己的工作進度。
關於專注，關於最近的一些事情
這是自己第一次寫非技術的部落格，但是不寫不行了。最近心情很沉重，因為自己又又又又又一次把事情搞砸了，47個人裡排倒數第二，當看到成績的時候心情真的很壓抑。不止一次開始認認真真的做一件事，然後到一半的時候注意力不夠集中，然後造成一系列的後果。學車的時候，各種公升學考試的時候，軟體設計師考試的時候，求職...
關於敏捷的一些想法
敏捷軟體開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過遵循計畫 今天看了robert martin的ppp一書的第一部分，敏捷開發 回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。這些公司中不乏奉過程開發為寶典...
關於《謀劃》一些事情
今天好多朋友詢問我，怎麼等了一天都沒有更新？首先謝謝您的關注！因為考慮到一些個人方面的因素，以及打算把 謀劃 寫的更好之後再給大家看，以後的 謀劃 只在周一至週六更新，週日就不再更新了，對於關注這部 的朋友說一聲抱歉！自從開始在部落格 這部 後，有不少朋友通過msn，站內郵件等方式聯絡我，有詢問接下...