一、软件项目与工程项目管理有什么本质性的不同呢？

前一篇笔记讨论了软件开发与产品制造的区别。要对软件开发项目的性质做更精准定位，这里还很有必要整理软件项目与工程项目管理的本质区别。进而解释，精益产品开发与传统的软件工程管理方法为何不同、有何改进。

主要区别有三点：

1）通过试运行（或集成测试）跑一跑是很重要的软件纠错手段；因为软件的“软、易修改”，试运行中的问题可以通过发布新版本予以修正，所增加的项目成本并不严重；而传统的工程项目，一旦实施，如果还要修改，成本是极其巨大的。所以，传统工程项目管理方会不惜代价的实以严格、复杂的过程控制手段，尽量在过程中排除错误。但，若软件项目管理也照搬，实质上是对软件自身本质优点的一种无视、舍弃。

2）软件项目所针对的用户需求，往往难以一开始就明确，是需要不断挖掘的；或者干脆需求就是时间的函数，根本就没有固定的需求，而是随着时间的推移不断演变；甚至可能，演变规律本身也是时间的函数。

3）检验软件项目成功与否的标准应该是最终的实际运行效果，而不是项目开初的需求定义。

总结起来，仍然是“不确定、变”

软件项目的最终产出是一种过程，在持续变化中实现价值的一种过程；而并非只是一种固化的“物”（无论制造业，还工程项目，其产出都最终体现为一种固化的“物”）。

二、关于如何建立看板系统的三项关键工作

1、价值可视化。软件开发中实施看板方法，难点之一为：与生产制造不同，产品开发中的价值流动是不可见的，因此也更加难以管理和优化。 所以让价值“可视化”成为软件开发中的一个关键考虑，以及将价值流动的过程可视化，然后问题和瓶颈也要被可视化。

2、看板系统规则显式化。例如，价值什么情况下可以从一个环节流转到下一个环节，这些规则则要显示化，让所有的项目参与者都能明白无误的准确认知。这一条隐含的是团队内协作规则的显示化（全员有明确的共同理解），从而尽量不依赖于某个人来进行协调（依赖某个人，就很可能在此人处形成阻塞、低效以及不明确因素，影响规模化价值流动的自动、顺畅）

3、控制在制品数量。在制品数量是以“用户价值”为单位的，并不等于任务数量！相比之下，在制品数量更像是用户故事数量？（如果用户故事是看板墙流程中，最细粒度的用户价值单元）。对任务数限制，是实现对在制品数量进行限制的一种方法。

      “Stop starting, start finishing”的原则。以通过任务数限制实现在制品数量限制为例，对应工作环节有一个任务数上限，只有当处于该环节的任务数低于上限时，才能从上游拉取新的任务。当本环节中的任务已经达到上限，则应该秉持“Stop starting, start finishing”的原则，尽快处理完成当前环节淤积的工作任务，并应该反省总结，是什么原因导致了本环节陷入任务淤积的？ 针对原因积极改进，不能让淤积现象再次发生。控制在制品数量有利于凸显问题，集中力量全面扫清问题，加快价值流动，从而使得交付提速。 这个数量控制在多少是适宜的？

三、看板系统建立后，进入运行阶段后的两项主要工作

1.对价值流动的管理

a）管理价值的输入。譬如就绪队列填充活动。即用户价值的输入列表。注意，是位于看板系统的左端。

b）管理价值的流动过程。看板站会是其中的主要手段。通过每天例行站会，整个团队一起，按照价值流转规则，共同迅速完成价值流动的每日更新操作。站会上，对“价值看板”的处理（流动与否），是从右向左的顺序进行，即是“拉动”，而非“推动”。

c）管理价值的输出。譬如，发布评审，用户价值最终正式输出前的一个环节。输出位于看板系统的右端。

2.对价值流程状况建立反馈评价及改进机制。

首先就是要对看板系统的价值流动状况进行度量。

四、精益看板方法的一些疑问及思考

1）价值输出频率为周、甚至月时，什么机制来保证按天的用户响应速度？ 以及一些突发的紧急需求？   能否增加一个按天为单位的小口径的看板系统，以应对快节奏需求？以及再准备一套更为紧急的流程，以做到实时响应。 普通看板、小口径按天看板、紧急流程，三层金字塔。如果发现大部分需求都是在小口径看板中流动，那就缩短普通看板的周期为天，而小口径看板的周期则调整为2小时之类。。。。。如此形成一个对金字塔的整体迭代机制。