使專案管理的工作視覺化。
注：1.下圖是我們真實工作中的看板**。
2.由於物料與辦公場地大小的限制，所以我們把本來是兩個看板的內容貼到了一塊板子上——上面是組內版本開發的看板，下面是對合做夥伴系統的聯調工作的看板——以下在做介紹時只以內部版本開發為例做介紹。
從上到下，整個看板分為三個部分：標題、緊急通道、正常通道。
在圖中的紅色向右指向的箭頭那一行是緊急通道，由於緊急的工作是比較少的，所以我只規劃了一小條，而把大部分空間留給了正常工作的通道。
標題從左到右分別為工作的各個階段——這裡的工作階段如何劃分是要看具體的專案情況的，我這個專案的劃分為：
最左邊是backlog：即為當前尚未開始的工作。
緊挨著backlog的是ready：在這裡的工作是已經決定在當前迭代中實現的。
然後是develop：這個開發階段又分為doing和done兩個。
然後是test：表示測試中。
再然後是兩個預發布：這裡把預發布分成兩個階段是為了做報表時統計方便（後面會講到報表）。
這裡沒有發布階段，原因是發布階段並不在我的職權範圍之內，無法直接操作那個階段的工作。
一般認為在ready和develop之間還應該有乙個「分析」階段，實際上我們的看板一開始的確是有這個階段的，但後來去掉了，主要是因為：1.系統已是運維階段，需要通常不大，不需要專門的分析團隊；2.有這個階段的時候，基本上是經理在做這個工作，很少其它組員做這個工作，而經理自己是可以直接分析好需求再拿到ready的，而沒有必要單獨有乙個分析階段。
總之，工作的各個階段是由專案的管理團隊來設計的，而且也不是一成不變的。
在develop和test兩個部分的標題上還有乙個數字，這個數字表示在這個階段的工作數量限制，這裡注意：
1.阻塞的工作並不計數——在這個板子中阻塞的工作上貼了乙個粉紅色的小紙條。
2.緊急通道中的工作並不計數。
3.開發中和開發完成兩個階段是共用乙個工作數量限制的（如果還有「分析中」和「分析完成」則也是要共用乙個工作數量限制的）。
卡片是一項可獨立交付的工作——團隊經理（可能是產品經理、專案經理或研發經理）需要把工作盡量拆分到比較小的單位，但需要可獨立開發、測試及發布。
卡片上的內容通常有：各階段處理人員（可以有處理時間），卡片拿到ready中的日期（即開始日期）、卡片拿到預發布當天的日期（結束日期【實際上要到發布才算結束，但因發布團隊是單獨的，不在我的團隊內，所以直接以預發布做為工作結束】）、**工作量（後續會說到如何**工作量）。
一、在backlog中的工作應該是已經拆分後的，可以獨立開發、測試及交付的——但如果專案比較大，或專案需要比較複雜，需要有乙個「分析」階段的情況下，則工作可以在分析階段之後再拆分為可獨立交付的。
二、在backlog中的工作通常也是要進行分類的，例如：可分為「正常需求」、「有工期或資源限制的需求」、「內部持續改進工作」；或分為「需求」、「系統問題」、「內部優化」等等——這個工作我們並沒有做，讀者自己看是否需要做吧。
三、把工作從backlog拿到ready：這個工作要產品經理來做，通常這個原則一般是越重要的，越先實現（但在需求量比較大的情況下，如果一直挑重要的做，則會有不重要的東西一直不會做安排，所以我們後來修改了一下看板，如下圖。其實不修改看板也是可以的，只要完全由產品經理自己人為控制即可）。
四、後續的工作完全採用「拉」的方式來執行——「拉」的方式的意思是，由下乙個階段的工作人員主動去前乙個階段拿工作，這與傳統的工作方式是相反的（傳統的工作方式通常是上級指派工作，而不是自己領任務）——研發人員從ready中拉工作到「研發中」，實現完成之後，再把卡片拿到「研發完成」，測試人員從「研發完成」中拉工作到test階段，在測試完成之後把卡片移到預發布。
1.細心的讀者可以想到：這裡把開發階段分為「開發中」和「開發完成」兩個部分的原因就是為了服務於「拉」這種工作方式（必須要對「開發完成」有乙個視覺化的表示，測試的同事才可以知道應該拿哪些工作過來）。而在後續的所有統計中，我們還是把開發階段做為乙個整體來統計的。
五、在拉取工作到自己的工作階段時需要注意「工作數量限制」，如：下面的圖中，研發階段最多限制為8個工作，則「研發中」和「研發完成」的工作加起來最多不能超過8個。
1.這裡安排「工作數量限制」的原因是控制交付的速度，以及控制效能瓶頸。
2.首先，我們要有乙個共識，即：「在乙個敏捷的團隊中，我們希望每個成員都可以做各個階段的工作（如果乙個成員只能做其中乙個階段的工作，那麼這個成員的價值就會小於通職的成員）」。所以，在我的團隊中，我並不控制工作的分工，即：測試同事可以「拉」ready的工作來做開發，開發的同事也可以「拉」取「開發完成」的工作來做測試。
3.而在實踐中，每個階段的工作速度是很難平衡的。在我的團隊中的現象是「開發的速度要快於測試的速度」，這樣的情況下，如果我們沒有乙個「工作數量限制」，那麼就會出現有大量的工作積壓在「開發完成」階段中。
4.為了避免工作的積壓，我們通常有兩種做法：a.經理人為控制，當開發完成的工作過多時，指派一部分開發人員參與到測試的工作中；b.增加「工作數量限制」，讓團隊成員自發的控制，發現研發階段的工作資料已經飽和的情況，則轉到其它階段的工作。我們選擇讓組員自發的控制方式。
5.這樣就達到了我們控制工作流速的目的：當一部分階段的工作過快時，資源自動轉移到其它階段去。
六、關於阻塞的工作：所謂阻塞的工作是指由於某些外部原因導致暫停的工作（例如：需要與另外乙個系統做聯調，但對方系統有問題需要修改，則暫時這個工作就要暫停一段時間），這類工作我們是用乙個紙條標示一下這個工作阻塞的原因，待阻塞結束之後再把線條去掉（這裡實際上是有乙個問題的，即：在統計工作時長的時候，阻塞的時間是沒有很好的辦法統計的，因為工作往後流的時候並沒有阻塞的痕跡）。
七、補充一點：當測試發現bug時，工作還是留在測試階段的，開發的同事直接參與到這裡來修改問題，而不是把卡片退回去。當bug過多時，也會產生阻塞，這時就需要開發把資源傾斜到測試階段來，解決這部分工作量的累積——但這種並不是外部原因造成的工作阻塞，所以並不貼工作阻塞的標記。
緊急的工作其實不多的，但是一旦發生就需要馬上處理——緊急的工作通常可能是：系統問題、非常緊急的需求——這裡的工作方式就不是以「拉」為主了，而是團隊主管主動推動工作的進展，直接指派工作。
這裡不再多說了。
對於工作量的**，通常是對相關系統邏輯越熟悉、並且設計能力越強的人的**是越準的，理論上是不需要團隊共同決策的。但少量精英做決策的工作方式並不利於團隊成員的進步，所以我們通過打下圖這種**卡來一起評估工作量。
卡片的樣式如下圖：
一、有多個數字卡和乙個問號卡及乙個熱咖啡卡。
二、「問號」卡代表對這個工作完全沒有概念，無法評估工作量。
三、「咖啡」卡代表「我已經很累了，需要休息一下，所以不對這個需求做評估了」。
四、數字卡代表「我對這份工作的預估量」，數字越大，代表工作量越大（或工作比較複雜）。
五、這裡的數字本身的意義並不明確（即：1並不代表是1天，也不代表是1小時），而是由打牌的人自己把握，打牌次數越多，團隊成員對數字的意義就越趨於一致——之所以並不明確具體的意義是因為：不同人做同乙個工作其工作時間也是不一樣的（有的人1小時搞定，而有的人三天也未必搞得定）。
六、這裡的數字越大，數字的差距越大，原因是：越大的工作或越難的工作，其評估的準確度也是越低的。
工作方式是這樣的：
一、每週一次工作溝通會議。
二、讓最了解工作內容的人先介紹工作，大家有疑問的這個時候都可以提出來。
三、每介紹完一項工作內容之後開始打牌。
四、打「問號」牌的人數超過三個，就要重新溝通這項工作——我們有20多個人一起打牌——如果組比較小，則建議每個人都要理解工作。
五、出牌前不可讓其它人看到，待所有人都選好牌之後一起出牌。
六、如果有人打出的數字過大或過小，就要說一下原因——可能某些人的想法錯誤或設計複雜——溝通之後要重新打牌。
七、如果大家的想法差不多，但打的牌不一樣，則說明大家對這個數字的理解不一樣，此時取多數人的數字或大致的平均數即可。磨合一段時間之後對數字的理解就會趨近。
我們這裡會做兩個報表（下面我只列出圖表，而不貼數字上來）。
我們並不畫一般專案管理上的燃盡圖或燃起圖，因為對於我們這種運維階段的專案，工作是持續性的，沒有燃盡的說法。
第一張圖表如下圖所示。
這裡的橫軸是「日期」，縱軸是「累計工作數量」，每條折線就是各個階段的累計工作量的增長趨勢。
由於我們的規則是「工作」只能從左往右移，而不能返方向移動，所以這個圖中的折線絕對不會下降。
這個圖是用來分析工作瓶頸所在以及直**到工作速度的，但這個分析在這裡描述比較麻煩，所以就不講了，如果以後有強烈的需求，我可以再寫一篇文章來描述這個圖的分析。
第二個表如下圖所示。
這個表的橫軸是工作持續的天數，柱的高度是工作的數量。
這個表可以每個版本做乙個，或一直累積。
歷史的資料結合「預估的工作量」可以用於分析團隊的戰鬥力（團隊未來承接需求的能力）。
內容不少，但我文采不行，只是流水賬式的記了一下。
完全憑記憶寫的這篇，所以肯定會有什麼漏掉的，以後想到了再補上去或再寫其它的文章來做補充。
如何優雅的使用「看板」？
你需要通過看板達到什麼目的 看板三原則 1.使工作視覺化，給每人乙個專案目前的big picture。2.減少並行工作。乙個user story的生命週期被切分成較小的塊，每個人應該keep在其中一塊。3.優化工作流程。在實踐中不斷迭代看板的流程，增減某些階段，或調整從乙個階段跳轉到下乙個階段的邊界...
PHP引號的正確使用方式介紹
對於沒有多少編碼經驗的新手來說，php引號的正確使用是乙個比較頭疼的事情，經常會因為php引號的錯誤使用導致程式的出錯。下面我們就向大家具體介紹一下有關php引號的正確使用方法。一.首先想想php裡所有的單詞 其實應該叫符號 有幾類.2.常量.新手可能用得不多,常量的好處是全域性性,穿透函式.速度也...
執行緒池的幾種使用方式介紹
一 執行緒池的優點 關於執行緒池的使用優點網路上介紹的有很多，可以歸結為以下幾點 1.減少在建立和銷毀執行緒上所花的時間及系統資源的開銷。2.提高執行緒的可管理性，對執行緒進行統一的分配 調優和監控，從而也提高相應速度。二 執行緒池的uml圖和使用方式 執行緒池的uml圖如下，使用執行緒池的方式總共...