1. 手機每日看板是什麼意思啊
手機每日看板是指人們使用手機時每天打開的網站或應用程序，用於獲取關於新聞、娛樂、生活、學習等方面的信息。隨著智能手機的普及和互聯網的發展，手機看板已經成為人們日常生活中必不可少的一部分，方便快捷、豐富多樣的內容極大地滿足了人們的需求。
手機看板的使用范圍非常廣泛，涵蓋諸如微信、新浪微博、今日頭條、騰訊新聞、抖音等網站和應用程序。人們可以隨時隨地利用手機看板獲取熱門話題、時事新聞、科技資訊、生活方式、健康保健、娛樂八卦等內容，使得個人在一定程度上獲取了更為全面和及時的信息。
手機看板也具有一些限制，比如可能會導致用戶過度依賴、浪費時間、沉迷網路等現象。此外，在使用手機看板的同時，大多數人也會暴露出信息泄露、網路攻擊等風險，因此，保護個人隱私和安全也成為了極為重要的問題。因此，在使用手機看板時，人們也需要具備一定的網路素養和信息安全意識。
2. 淺談敏捷開發方法之看板(KanBan)
最近剛剛完成Agile的課程， 對Agile的幾種methodology (Scrum, Lean IT, XP, DSDM, FDD, Etc.) 有了一個淺顯的了解，之前和現在的幾個project都有在用KanBan和Scrum，所以准備寫篇文章記錄並分享課堂和項目所學。有何不當之處，歡迎各路大神指正。後續會繼續分享其他幾種methodology。
註： 本人是程序猿一名，所以會偏向介紹kanban在軟體行業的使用。
1. 什麼是看板？
關於看板的定義，網上一搜一籮筐。這里引用一下David Anderson一段話。有人可能想問這哥們是誰。 一句話，Taiichi Ohno (大野耐一)是Kanban之父，David 就是把Kanban引進IT行業的先鋒。
這句話意思就是說，Kanban可以被引入進任何開發框架去支持和推動持續性軟體開發，不管你的開發模式是Agile的(比如: XP, FDD, TDD)還是傳統的開發方式(比如:waterfall, iterative)。
個人的理解就是，這個一種軟體開發流程管理的方法，保證軟體的持續集成並且不讓你的開發團隊超負荷。很程序猿是不是應該很喜歡聽到這句 「不讓你的開發團隊超負荷」。 根據團隊能力，限定WIP(work in progress)的tasks數量。
2. 為什麼看板？
1）可視化你的工作流程。所有的task的進度會全部顯示Kanban上，每一個人都可以一目瞭然了解進度和流程。
2）限制WIP中的tasks數量。一般情況下，這個數量是等於Team中的developer數量。
3）管理並優化流程。當WIP中的某一個task完成時，在ToDo中的優先順序最高的task會被移到WIP中，這也是為什麼當一個項目中需要經常更改優先順序時，會選擇Kanban的原因。
4）量化開發周期。
5）縮短開發周期。這個其實可以理解為發現問題，解決問題，從而找到更科學的方法提高開發效率。
6）變push system (just in case) 為 pull system(just in time)。新的case只能在team有能力情況下再開始。
3. 看板模型
根據我們現在項目的看板，我畫了一個上面的Kanban牆。
1）劃分list， backlog:還沒做的，一般是來自產品部(新需求)或者你們的線上support的客服人員(bug)。design:正在准備design的，一般這個部分都是solution architecture或者UI Designer負責，並不是所有的task都會到這個list中來。 development:這部分就很明顯是coding部分，由developer負責。 test:測試部分，由測試人員負責，done：已完成，等待上線。每個項目可以根據自己的需求建立自己Kanban。上面這個不是唯一的。
2）在上面的每個流程中設置了限定的task數量。這是Kanban核心思想之一，意思就是說同一時間，只能做這么多task。比如Design是2 這個階段只能有兩個task進行。這個一般是根據人數來決定這個限定數目。
3）我們project已經上線，所以經常會有一些bug來自我們客戶，同時也會有些新需求來自我們的產品組，有時也會需要對項目中某一部分的function做一個提高。所以我們用不同顏色的代表不同類型的需求。藍色是bug，綠色是improvement，紫色是新需求。這樣可以更加清晰和歸類。
4）我們項目的產品組是project的stakeholder，所以一般由他們來劃分backlog中task優先順序。然後team在做完一個task之後，去選擇下一個最高優先順序的task。產品組是可以隨時更改這些backlog中task的優先順序除了下面兩種情況：1. task已經開始，不可以替換正在做的task。2. 項目周期剩餘時間已經小於task的預估完成時間，這個task是不可以更改作為下個更高優先順序。
4. 卡片模型
1) Ticket ID 是某個task的唯一標識。 我們項目中，是使用了物理看板(就是買的一個大白板，自己畫裡面的內容)，當某一個task結束上線後，我們就會把task取下錄入系統做備份。所以每次去系統里，我們都會根據ID找這些task。
2）task的描述。就是這個task要做什麼。
3）Estimated Cycle Days 就是預估完成這個task要花費的時間。根據這個時間，我們可以預估出完成所有task可能需要的時間。我們也能預估出一個迭代能夠做多少task，從而可以更好的排列backlog中task的優先順序。一般是由開發組集體討論給出這個預估時間。
4）Actual Cycle Days 是完成一個task真正花費的時間，如果這個時間跟Estimated Cycle Days（預估時間）相差很大的話，整個team就要做回顧和總結，哪裡出了問題。從而解決問題。一般一個新的組建初期，estimated Cycle Days和Actual Cycle Days相差都會比較大。通過幾次迭代之後，大家都相互了解之後，estimated Cycle Days會變得越來越准確。
5）task優先順序。用來排序拿個task要先做的。這個是由產品擁有者來決定，scrum裡面叫proct owner, 傳統項目中叫bussiness user。 就是誰來出錢做這個項目的。 我們項目中是由產品組的人來決定。
6）task 負責人。這個很明顯了，就是要做這個task的人。
5. KanBan和Scrum的區別。
有的項目可能用的是Scrum，Scrum會比Kanban來的復雜很多。在Scrum有嚴格角色定義，開發周期管理。但是看板是沒有的。個人總結，Scrum是一個完成的開發管理框架，比較完善的，而kanban只是開發流程的管理工具，可以放到各種開發框架中去的。各位可以看下面的圖來對比Kanban和scrum板的區別。可能不是包括所有的不同。
大家也可以去看下這篇文章，https://blog.csdn.net/iamdll/article/details/18552607
6. KanBan工具。
kanban的工具有很多，大家可以自己去網上找找，我們的項目中主要是用物理看板，Trello和JIRA。因為我們有些project是外包的，所以我們只能使用Trello和JIRA這種online的tool跟vendor溝通。如果是自己的開發團隊，個人建議還是使用物理看板。
7. Work Agreement
其實work agreement不只是Kanban會有，Agile所有methodology都會有。只是為了適應不同的methodology或者project，agreement會有不一樣而已。這個agreement不是給某一team或者人設立。 而是給所有參加project的team。Agreement可以保證project穩定前進。下面有幾個例子。
1）Task開始後，不可以修改task的要求或者更換task。
2）task的估算時間，不可以大於迭代剩餘時間（只包括working time）。
3）早上9點之前到公司並開始工作，下午6點離開辦公室。
4） 會議期間，不可使用手機並集中會議主題。
5）會議期間，只討論跟會議主題相關內容，以保證會議可以准時結束。
總結
每個project都有各自不同的環境和人員的組成，Kanban是一種流程管理的工具， 每個project可以根據自己的情況，找出適合自己的使用方式。 大家在參與的過程中才會學會更多的東西。