再談了需求（甚至可以說是complains）之後，就可以切入正體了，並且我將以我的乙個專案經驗來闡述敏捷開發？
事實上我對這其中的許多方法學感受不深，不過我下面會談到我參與過的乙個算是用了半個敏捷開發的專案吧。不過我首先想提出的做為乙個程式設計師，如果要開發乙個專案，你第一件事想到的是什麼？是設計嗎？不，是**！想馬上寫一段**試試看？這在傳統軟體工程學中，是要被bs的。但敏捷開發不同，以人為本嗎。事實上仔細想想，你實際上是在用**做設計，而不是傳統軟體工程學中所說的編碼過程！以人為本，所以這裡不需要你有嚴格規範的設計文件，不一定非要用建模工具，但是有一點還是需要的，你寫的**，或者說你設計的框架，別人一定要看懂！怎麼看懂？隨你了，你可以用uml建模工具將**做成uml模型（事實上我認為uml真正的用途在於程式設計師之間的交流，而非建模本身），可以寫簡單的設計文件，甚至，真正優秀的**只通過注釋就可以在程式設計師之間進行沒有任何障礙的交流。當然了，這是需要用極高的**質量保證的。袁紅崗就說，他從不用任何建模工具，他就是考**建模的，如果有任何人讀不懂他的**，就說明沒寫好，就要重寫！
下面要說的是測試驅動（tdd），什麼是測試驅動？就是現有測試，再有**！這聽起來覺得匪夷所思，但如果你是從客戶的角度取考慮問題，那自然是理所當然的了。你最終要呈現給客戶或者說是其他呼叫你的**模組的東西就是，一些輸入和期望的輸出，而就進有無期望的輸出就是通過測試完成的！於是這又是乙個以人為本的體現！再者，事實上tdd能盡量的把測試工作再編碼階段就完成，這樣做的莫大好處在於補救bug的代價變小了，在軟體工程學中有這樣乙個說法就是，bug發現的越完，補救的代價越大？如果你完全的依靠傳統軟體工程學中的測試步驟，以及測試人員的話，那補救bug的代價將會非常之大，開發人員甚至已經忘了這段**的作用了。而如果採用測試驅動的方法學，將大大的縮短最終的整合測試的時間，使盡量多的bug在編碼階段就已經得到了解決！
所有網上的文章都在描述敏捷開發所帶來的效率和以人為本。不過我想在中國敏捷開發能夠未我們帶來的最重要的東西卻是真正對程式設計師的尊重！敏捷開發的方法學是要開發人員以對開發工作的熱情和開發人員之間的協作，良性競爭為基礎的。這在中國目前的以外包業為主的軟體業中是很少見的，我們目前的軟體業所需要的似乎只是循規蹈矩的按照傳統工程學的工序一步步走下來的，編寫無數重複**的廉價勞動力！而中國卻還一直在叫囂缺乏高階軟體人才！事實上正是所謂的有了高階，低階，軟體藍領，軟體白領之分，才導致了優秀人才的缺乏！正是由於這些對程式設計師的不尊重，才導致了中國軟體業落後的局面！程式設計師就是程式設計師，既不是做簡單重複腦動的所謂軟體藍領，也不是制定一些往往事與願違的開發計畫，管理管理手下的經理人員。那是什麼呢？程式設計師是能夠改變世界的工程師！是把現實問題，轉換成計算機描述並加以解決的技術人員！是為這個世界變得更簡單而出力的勞動者！最重要的是，他們是在感受世界的人！
最後還是用這句話來結束這篇blog：開發以人為本！
敏捷開發 我的經驗（二）資源計算 以人為本
在整個sprint開發過程中要做到資源合理和充分利用，並給予st預留閒置時間。1.每天工作時間為8小時，可充分利用時間為80 90 即8 80 8 90 6.4 7.2小時之間。一般的，如果整個團隊配合時間較長，可以考慮資源利用率在90 如果是新團隊或者專案剛給啟動，建議資源利用率80 在團隊成長過...
軟體開發管理，以人為本，還是以流程為本
正方觀點 軟體開發可以通過不斷細分的工序化流程來減弱開發人員個人對於專案的影響，只需要少部分人的創造性思維，而大部分開發者則嚴格按照工序流程進行開發 反方觀點 流程管理只能一定程度上控制專案進度和質量，專案的完成情況關鍵靠個人能力和素質。辯論前提 這裡的軟體開發不是指領先技術的開發，例如搜尋引擎，3...
手機軟體開發還是要以人為本
手機軟體開發還是要以人為本 近日來，一款名為 來福找小工 的移動應用，以它獨特的角度和非常大的實用性，正在成都百姓和打工者中迅速走紅。使用者輕按手機就能找到相應的生活服務，從開鎖換鎖 電腦維修，到家電維修 門窗安裝一應俱全。這款手機軟體開發的成功和走俏，說明它的開發者是真正體會到了移動開發的本質 以...