軟件工程 ：方法與實踐 第五次讀書筆記

此次學習的最後一個關於敏捷與精益的時實踐例子是結合了敏捷和精益於一體的「看板方法」

這是一個在敏捷軟件開發的精益方法，因此二者都有，但更側重於精益，一樣和精益的概念來自於豐田生產系統。它的定義是一種增量式的，演進的改變技術開發和組織運做的方法。看板經過限制WIP（Work-in-Progress）的數量，造成了一個以拉動系統爲核心的機制，暴露系統中的問題，激發協做來改善系統。以前也看到了，豐田生產系統對於浪費的定義極其的嚴格，只要是沒有帶來經濟效益就是浪費（雖然說感受太利益化，可是對於一個公司來講是一個很好的標準，能夠助其成長），雖然說當時列出了常見的6種浪費可是在理解上確定不夠，今天又學到了：WIP（在製品）由於它不是可交付的產品，還不能帶來效益因此這個東西也是一種浪費！！難以置信，可是比較一下平常生活中在常常緩存視頻的時候，常常會有修改默認最大每次緩存視頻數目，即便軟件沒有這樣的設定咱們在下載速度捉急的時候也會不自覺的暫停過多的視頻緩存進度，「專心一意」緩存最想看的那一兩個，做爲用戶的心理就是想要儘快的拿到可交付的產品。綜上本身的實際例子分析，確實WIP就是一種短期還不能帶來效益的浪費，必定有必要控制其數目。

「看板」來源於日語，意爲「可視化的卡片」，用於在生產中發佈指令，尤爲是在一個過程必須等待另外一個過程結束才能開始時，用看板方法能夠實時看管項目的各部分進度，好隨時發現開發過程當中的不足，這樣來持續的改善系統。能夠理解到見解方法有以下原則：

1·從組織的現狀開始：在看板時能夠實時發現下降效率的問題所在，可是因爲其實時性，其關注的的部分就必定是局部的不能關注到將來的問題，和其他部分的問題那麼分析問題的過程就會是以組織現狀爲基礎進行局部的改善；

2·造成以漸進的、演化的方式來改善系統的共識：由以上所說，改善的局部性，咱們只能及時的作到一步一步的改進系統，同時也就決定了它必定是持續的，不斷地發現各個地方的問題，不斷的改善進步咱們的系統。這樣就像咱們寫完程序以後會持續一段時間的debug，一次一次的在不一樣問題發現本身程序的不足點，一次一次的更改這一點問題，一次一次的將程序推向完美，誰也不會寫完程序就能夠用大局觀來知道怎麼改動它；

3·看板方法尊重當前的過程定義、角色、職責、或頭銜：就像1點所說的，咱們都是以現狀出發，從如今的組織開始改善系統，那麼必定有合理的理由尊重現狀的一切定義、角色、職責等等，作到步步修改，每步小改，這樣纔不會落到想重頭再來的風險。同時，這裏說的是尊重，不表明必定不會改變，就像我的做業那樣一味的堅持不會有太大的改善，尊重它也得有勇氣改變它，惟有變化才能進步，那怕是很重要的部分到了該改變的時候也會充滿敬意的選擇更好的那個部分。