一、有必要对何勉的表述进行补充阐述之处：
1）何勉所举企业网盘开发的案例中，原始做法的本质问题并非是前、后端的划分。事实上，进入开发后，最终必然会需要做前、后端的分割。问题之要害是"过早"的进行了前、后端划分；从尽量体现用户价值、让用户价值充分流动的原则角度，更为合理的做法是尽量延后前后端的任务分割，让尽量多的环节是能明确体现用户价值的，不到迫不得已，就尽量别破坏对用户价值的可读性体现（只要能保持用户价值的可读，是允许拆分用户价值的，譬如将一个需求拆分为几个用户故事） 。更进一步理解，其实就是对“将用户价值可视化”这一条原则的体现，即让用户价值在尽可能多的环节中可见（可视、可读）。
2）该案例的原始做法没有反应团队协作过程。项目经理成为需求、bug等工作的协调枢纽。精益敏捷的一个核心诉求是实现用户价值尽量“顺畅无阻的自动流动”，所以应该尽量减少工作中出现”枢纽“节点，无论是看板墙上还是看板墙之外。一定程度上，又是”去中心化“的体现——从用户价值需求输入到用户价值输出兑现的全过程去中心化。当协作规则、价值流动规则不清晰、未全员形成相同理解时，就会出现依赖于某个人来协调的”中心化“倾向，该中心就很有可能成为价值流动的瓶颈所在。
因此，何勉才对该做法进行了改造，设计出文中的新看板系统。
3）控制在在制品数量的理由”束水攻沙“，将“水”解释为团队力量，“束水”解释为集中团队力量，似乎更为直观些。
二、看板墙示范模板
以下是基于何勉案例整理编制出的看板墙示范模板（excel，源文件可从网盘下载：https://pan.baidu.com/s/1HEWSEQS2VwrDvB4K18cKrg 提取码：fi8c）。由于一张整图不清晰，这里截成前、中、后三部分贴出。
三、看板系统建立过程中的一些方法、要诀收录
1）需求抛弃区；
2）用不同颜色、大小的卡片代表不同类型需求；
3）分别设计需求和任务的卡片模板，打印；
4）统一粘贴标识语言（什么代表紧急、代表重点等），形成统一的符号语言体系；
5）定义初始规则、充分传达规则、持续迭代规则。规则显示化（明文化），才能通过规则的版本迭代，实现规则的改进。
需要显示化的规则可以归为三类，例如包括：需求的准入条件是什么；优先满足哪类需求；怎么应对紧急需求；移交给测试前，需求要达到怎样的质量标准；短期进度和长期质量冲突时，如何决策；多长时间进行一次需求排期等等。
6）三类主要规则：价值流转规则、周期性事件相关的规则、其它日常协作规则。
价值流转规则：譬如需求可以开始分析的接收标准；需求进入就绪的标准；代码提交和任务完成的标准；功能转测试的标准；功能提交验收的标准；需求发布的标准等等。
譬如需求进入就绪（故事队列）的标准，包括大的原则和特定团队自己特有的内容。其中大的原则有：已识别业务风险、关联风险、技术风险，并作出应对；需求不不能太大。（特定内容则参考原文中示图）
看板方法中主要的定期事件有：每日站立会议、就绪队列填充会议、产品发布规划会议，以及定期的改进活动等。（在规划方案阶段，可以明确罗列出这些事件）。可用时钟标记。需要明确它们的节奏、内容及相关规则。以就绪队列填充为例，团队需明确：1）事件的频率；2）事件进行开展的方式，如：要完成哪些目标，和大致的流程；3）适用的规则，如怎么选择需求，一次选择多少需求。4）例外情况，如：正常的就绪队列填充节奏之外，出现紧急需求如何应对。
日常协作规则，如：看板墙的更新和可视化规则；在制品限制的规则；度量、反馈的收集和分析机制；改进行动的制定和跟踪规则等。初始时，可以先只明确那些影响较大的规则。
7）将看板可视化准备好，达到傻瓜化，让团队们直接往里填具体项目内容、可直接用的状态，无需再为物料、规则花费精力的程度。
8）限制在制品数量。该上限值取多少适宜？ “偶尔达到，但不总是达到”，所谓“偶尔达到”，每一到两周达到上限一次，是一个合适的初始值。
控制在制品的数量，只是“果”，实现控制需要有端到端的思维，要从“用户价值流动”的视角，不能局限于一个环节上。
9）在制品数量的限制，可以不一步到位，而是先松后紧，逐步调低"水位"，从而所揭示的问题也先简单容易再复杂困难。（流过看板墙的应该是连续不断的一批需求）
10）要以用户价值为单位控制在制品数据量。在制品数量不等于任务数量！控制在制品数量不等于控制任务的并发数！
11）限制在制品数量的方法：通过限制泳道数实现、通过限制特定阶段最大需求数(譬如待测试的需求数）实现、通过限制每个人并行任务数实现。
12）关于在制品数量限制的初始值设定，方法有：对现状进行看板可视化后得到、基于团队人数进行估算、利用利特尔法则从目标交付周期导出（在制品数目 =交付周期 * 交付速率）
13）解决在制品的阻塞问题，首先是一定要将在制品可视出来。在制品队列阻塞，是致使产品开发低质低效的最重要因素。
四、需要解决的疑问
1）泳道里什么时候可以拉入新的任务? 是等整个泳道行（或整个模块列）空出才能拉取, 还是只要有空格出现就能拉取？
2）最终的验证、验收环节都是以“故事”为单元，不进行合并为用户需求的动作？与看板流程发起前期的环节不对应，不回到"用户价值"？
3）以目前的看板架构看，对如何体现用户价值这一点似乎还未充分体现。比较明显，这个是偏开发的流程。需求设计、产品设计阶段还应该有对应的细分流程。
4）看板是基于每个项目进行个性化设计，还是各种项目统一？（早期可以一对一设计，逐步确定一些后续哪些可共用，哪些需要个项目自己做） 如果看板形式是不那么确定的，那么价值流转的规则又如何提前明确呢？（从A环节到B环节的规则，连A、B的名称/内容都不固定，怎么确定A到B的规则？） 所以一个办法是先找一个案例，写一个示范（包括初始规则、初始手册等），然后基于案例示范和响应的初始手册尽早启动真实的试点项目，在试点中再确定后续工作（对“后续工作”能否做出初步预判和初步的具体安排？不能完全一抹黑）。 此外，对于一些可以提前相对确定的环节，可以提前形成初始的通用规则。 再有，先明确影响大的重要规则。
从在制品数量可以先松后紧来看，看板墙是针对"团队“的，一个（或一类）团队，或一种类型需求，用一种看板，这样在制品就是能够由松到紧进行变化的。总之，流过看板墙的应该是一批接一批的需求，而非单一个需求。
5）如果造成阻塞的问题本身很棘手，在限制在制品的情况下集中团队力量也没法很快排除，怎么办？
附注：
（只列原文标题，跳出链接太多会被平台封号；主要参考何勉的公众号，看板方法实践体系）
原文一、实践一（上）：可视化价值流动——案例
原文二、实践一（下）：可视化价值流动——实践
原文三、实践二：显式化流程规则实践
原文四、实践三（上）：控制在制品数量——束水攻沙
原文五、实践三（中）：控制在制品数量——暂缓开始、聚焦完成
原文六、实践三（下）：控制在制品数量——湖水岩石效应