敏捷: 分工角色 大專案分小專案 每個節點時間設定里程碑
scrum實施的核心可以概括為「化繁為簡」，從幾個維度解釋下：
團隊角色的定義，將團隊人員定義為三個角色，scrum master（主要負責消除障礙，帶領團隊運作）、product owner（主要負責描繪產品遠景，定義優先順序）、scrum team（主要負責實現產品）
工作任務的拆分，將產品需求拆分成小的使用者故事，並評估優先順序
時間的拆分，將專案週期拆分成固定時長的迭代週期，每個迭代交付一部分可驗收的功能，通常迭代長度為1到4周
精益:
原則1:消除八大浪費
企業中普遍存在的八大浪費涉及：過量生產、等待時間、運輸、庫存、過程（工序）、動作、產品缺陷以及忽視員工創造力。
原則2:關注流程，提高總體效益
管理大師戴明說過："員工只須對15%的問題負責，另外85%歸咎於制度流程".什麼樣的流程就產生什麼樣的績效。改進流程要注意目標是提高總體效益，而不是提高區域性的部門的效益，為了企業的總體效益即使犧牲區域性的部門的效益也在所不惜。
原則3:建立無間斷流程以快速應變
建立無間斷流程，將流程中不增值的無效時間盡可能壓縮以縮短整個流程的時間，從而快速應變顧客的需要。
原則4:降低庫存
需指出的是，降低庫存只是精益生產的其中乙個手段，目的是為了解決問題和降低成本，而且低庫存需要高效的流程、穩定可靠的品質來保證。很多企業在實施精益生產時，以為精益生產就是零庫存，不先去改造流程、提高品質，就一味要求下面降低庫存，結果可想而知，成本不但沒降低反而急劇上公升，於是就得出結論，精益生產不適合我的行業、我的企業。這種誤解是需要極力避免的。
原則5:全過程的高質量，一次做對
假如，團隊整體的分工模式是錯誤的，那 devops 還是沒辦法消除團隊內不同角色間的甩鍋與填坑的；能為團隊設計出正確的分工模式，是團隊能開始協作的關鍵的第一步。
在 devops 的世界裡，所犯下的最大的錯誤是：整天只知講些文化、協作, 卻完全將最重要、最關鍵，儲存在 svn, git⋯內的開發人員的 「行為資料」 視而不見。在 devops 的世界裡犯下這樣的錯誤，將使得團隊白白的耗費大量的人力、時間，只是照著 「 devops 的課本」 在演出一場 「devops 的行動劇」罷了；團隊對於如何的持續改善團隊成員的開發效率、產品的質量，還是茫然無知的。
不論團隊是要匯入 devops 、scrum、safe、less、kanban, 都應該要從 「團隊的現況」 與 「開發人員的行為資料」 開始。
所以，身為 devops, safe, scrum, less, kanban 的教練、顧問, 都不應該背離了 「程式設計」，更不該對 「人類的行為模式」 是茫然無知的。
我們總是聽到，devops 能提公升效率、質量。
我們總是聽到，不做 devops 就會面臨被淘汰的命運。
但是，為何當我們每個人都認為 devops 是必要的同時，卻很少有人會去懷疑，團隊在 devops 的 value stream 中的整合測試，其實是不可信的？
就宛如我們總是聽到，因為健康檢查，而有多少人能及早發現、**了癌症；我們每個人也都認為每年的健康健查是必要的。
但，卻很少有人會去關注，有多少比例的癌症病人當中，其實，是每年都有在做健康檢查的？！
我們往往都太急於想在急速變化的it 產業當中，去抓住一塊 「浮木」 來獲得安全感、專業感；其實，這塊浮木，往往是連我們自己都感到茫然、感到陌生的。
為何在 google, amazon, netflix 的內部永遠都只專注在：人、架構、**、自動化工具，而沒跟風的去搞所謂的 devops, safe, scrum, kanban⋯卻仍然能使得產品擁有質量、價值與競爭力？！
我並不是說 devops, safe, scrum, kanban⋯是沒有用的。
我只是想建議，我們應該要 「顛倒」 下我們理解的思路；不要急著將在 devops, safe, scrum, kanban 中所學到的 「答案」，就直接的套在我們日常的軟體開發當中。
相反的，應該是從我們日常的軟體開發當中，去引導、去設計出我們所真正需要的 devops, safe, scrum, kanban⋯
敏捷之看板 精益生產
精益生產最重要的兩個理念就是準時化和自働化，由看板為實踐工具，最終能夠達到高質量 低成本及快速響應。首先擺在大家面前的就有乙個問題，什麼是看板，它和看板牆又是什麼關係？之所以把這個問題一開始就丟擲來是因為看板的 板 字，很容易讓人產生困惑。既然是個板子，那因該就是我們平常所說的物理卡牆，就是因為這點...
精益與敏捷開發（隨筆）
在幾年前，我就對軟體的敏捷開發有著很高的興趣的。一直覺得，程式設計師應該是最自由，最輕鬆的一種職業！而且我也一直在向這個方向努力！我們應該如何做呢？一說到程式設計師，大家就公認的是腦力民工！為什麼？在程式設計師自己報怨開發環境不好，工作量大，任務重，壓力大的同時，有沒有想過，有些問題其實是程式設計師...
精益敏捷採購的外包
u0026 xd u0026 xd u0026 xd u0026 xd 採購流程是組織在運營中變敏捷的最後一道障礙。在最近的agilia會議上,mirko kleiner就精益敏捷採購提出了一種服務合同談判的方法，該方法涉及採購專家 it團隊和 商，它能夠大幅縮短合同談判的時間，並將你爭我奪的態度轉...