在幾年前，我就對軟體的敏捷開發有著很高的興趣的。一直覺得，程式設計師應該是最自由，最輕鬆的一種職業！而且我也一直在向這個方向努力！
我們應該如何做呢？一說到程式設計師，大家就公認的是腦力民工！為什麼？在程式設計師自己報怨開發環境不好，工作量大，任務重，壓力大的同時，有沒有想過，有些問題其實是程式設計師自己的原因造成的呢？
我們來看乙個流程的例子：
從乙個問題單開始，你要解決這個問題，首先得申請問題單的檢視許可權，花5分鐘填寫乙個許可權申請電子流，然後等1到2個小時生效。當然，如果你一次申請乙個長久有的效的許可權，第二次在解決問題單時就不須要了。
然後閱讀問題單，重現問題，如果有不清楚的，可能還會諮詢測試人員。假設你在1個小時以內了解清楚了問題。
然後準備修改問題，得先申請**許可權。填寫電子流也就幾分鐘，然後等待審批，可能得1到2上小時。如果幸運的話，是這樣的。
然後是**的checkin與checkout，以及修改！
然後是編譯，驗證。最後出版本！
ok，這是乙個比較簡單的流程，我們看看，其實有很多因素可能導致我們的開發流程是效率很低的。例如，在許可權申請的等待過程！問題確認過程！電腦檔案開啟等待過程！網路開啟等待過程！等，一些不產生value的過程，都是精益開發中應該減少的。
我們並不能指望效率會有多高（豐田的效率也只有40%左右，效率就是把乙個流程中，產生value的時間除以整個流程的總時間），但在精益開發中，就是要在各個環節中找到影響效率的點，然後盡力的去減少它！
例如，上面的例子中，當開發人員要確認問題時，應該直接找到測試人員，面對面的把問題搞清楚。而不是在郵件，或者**中詢問題！再如，給開發人員配置更快的電腦，以減少開啟檔案的等待時間。當然，開發人員也應該自己優化自己的開發電腦。公司優化網路等。
當然，在整個流程中，要分清楚哪些工作是有效的，哪些是沒有效的，並不是件容易的事！一些非常明顯的事，如前面提到的等待，就不用說了。
對於以下一些事件，哪些是有效的，哪些是無效的呢？
需求分析
需求設計
編寫設計文件
測試設計
編寫測試文件
編碼測試
修改bug
技能提公升
呵呵，感覺全部是有效的工作！其實不是！
從使用者角度來看，只有編碼一修改bug是有效的，其它的一律無效！
當然，這是從使用者角度來看。從我們開發人員來看，上面的也並不是全部有效的！
例如：設計文件，測試
而技能提公升是有效的。
這裡不去細緻的討論哪些有效哪些無效，只要記住精益的思想：
盡量發現開發流程中的無效工作，並儘量減少它！
當然，精益開發也給我們提供了一些簡單的方法來判定有效工作與無效工作！
這就是精益開發的第一條原則！而後面的所有原則就都是由它產生的！
敏捷（Agile）與精益（Lean）對比
消除浪費 eliminate waste 嵌入質量 build quality in 創造知識 create knowledage 延遲決策 defer commitment 快速交付 deliver fast 尊重他人 respect people 整體優化 optimize whole 目標都是...
瀑布 敏捷 精益 devops
敏捷 分工角色 大專案分小專案 每個節點時間設定里程碑 scrum實施的核心可以概括為 化繁為簡 從幾個維度解釋下 團隊角色的定義，將團隊人員定義為三個角色，scrum master 主要負責消除障礙，帶領團隊運作 product owner 主要負責描繪產品遠景，定義優先順序 scrum team...
敏捷開發 Scrum與精益相得益彰
摘要 瀑布模型是軟體工程中最初的經典模型。這種方法對於那些在初期需求就很完整清晰，並且在開發過程中不會有太多變化的專案非常適用。但是，大多數情況下在 軟體開發過程中需求會不斷變化，而瀑布式開發很難適應這種變化。針對瀑布模型的這一不足，隨後湧現了許多開發模式，比如螺旋模型和統一過程開發 rup 模型。...