1）scrum和看板都是過程工具，它們講的是做哪些事情能夠在一定程度上幫助你提高工作效率。（工具= 用於完成任務或達成目的的任何東西；過程= 工作方式）
2）scrum和看板有乙個共同的思路：「少就是多」 。有疑慮的時候，先從少做起。
3）scrum簡述：用小團隊在短時間內做出小塊的東西來，在有規律的整合中組裝出全貌。
4）看板簡述：將流程視覺化（把工作拆分成小塊，一張卡片寫一件任務，再把卡片放到牆上；每一列都起乙個名字，顯示每件任務在流程中處於什麼位置。），限制wip（在製品，work inprogress ）；度量生產週期（完成一件任務的平均時間，又稱迴圈週期）。
5）看板是一種改變管理方針的途徑。看板的本質是乙個很樸素的思想：在製品（work-in -progress，wip）必須被限制。只有當前的某項工作被交付，或是有了來自於下游的拉動，新的工作才能開始。
6）看板所提倡的是漸進式演化，逐漸向敏捷和精益的價值觀靠攏。
7）實施看板的原則是把當前的工作作為起點，通過價值流分析來理解當前的流程，然後為每個環節中的在製品上限達成共識。讓看板訊號拉動著工作流動起來。
8）看板幾乎對任何做法都是開放的。它僅有的約束就是將流程視覺化和限制在製品。
9）看板的實時度量指標：平均生產週期、瓶頸（如：典型症狀就是x 列裡面堆滿了卡片，但是 x+1 列裡空空如也。找找板上**有「氣泡」 吧。）。
10）？：在看板圖中，整條價值流上所有的狀態都要加上上限，開始點越早越好，結束點越晚越好。一旦 wip 上限都設定完畢，我們就可以開始度量和預估生產週期──即一張卡片在圖上從頭移動到尾所用的平均時間。估好了生產週期，我們就能對sla（服務品質協議，service level agreements）做出承諾，制定出合理的發布計畫。
11）看板的一天。圖p49~p51。
12）看板應該有哪幾列？每一列都代表乙個狀態，或是兩個狀態之間的（緩衝）佇列。應該先從簡單的開始，逼不得已的時候再增加。
13）看板上限應該是多少？如果「 你」 的某一列已經到了看板上限，而你也沒有任何事情可作，那就去找下游的瓶頸吧（也就是向右邊找一下，看哪列裡面有堆起來的卡片），找出來以後幫著把它乾掉。如果找不到瓶頸，看板上限可能就太低了，因為設定上限的目的就是為了減少給下游瓶頸添亂的風險。
14）注意：
ø 使用恰當的工具可以幫助你成功，但不能確保成功。人們很容易把專案成敗跟工具成敗弄混。
ø 把工具搭配著用，用在合適的地方！不過我們還是要關注每樣工具有哪些約束的。假如你在用scrum ，又決定不用固定時長的迭代（或是其他任一款 scrum 的要素），就不要說你在用scrum 了。scrum 本身已經足夠濃縮了，如果你去掉一些東西，然後還叫它 scrum ，那這個詞就失去了意義，只會帶來困擾。你可以給它起個別的名字，比如「scrum 衍生品」。
好書沒廢話 《看板和Scrum相得益彰》讀書筆記
今天花了大概90分鐘讀了 看板和scrum相得益彰 一書，讓我擊節讚嘆，確實是一本好書！1 本書很薄。薄的書能讓人有耐心讀完。2 本書言簡意賅，觀點明確。能讓人產生共鳴，能解惑。3 充滿了乾貨，讀後讓人有收穫，可實際操作。ch1 1 scrum方法 團隊拆小，任務拆小，時間拆小 看板 視覺化 wip...
敏捷開發 Scrum與精益相得益彰
摘要 瀑布模型是軟體工程中最初的經典模型。這種方法對於那些在初期需求就很完整清晰，並且在開發過程中不會有太多變化的專案非常適用。但是，大多數情況下在 軟體開發過程中需求會不斷變化，而瀑布式開發很難適應這種變化。針對瀑布模型的這一不足，隨後湧現了許多開發模式，比如螺旋模型和統一過程開發 rup 模型。...
重複資料刪除與虛擬容災相得益彰
從物理伺服器轉變為整合的虛擬化基礎設施具有不可否認的 it 優勢。但是，快速遷移到 vmware 使災難恢復 dr 的傳統方法過時了，也增加了 dr 實施的複雜性。使用重複資料刪除所節約的成本可以使 dr 在成本可能會受到控制的情況下變得切實可行。例如，有個客戶曾報告在重複刪除其 vmware vi...