1. 价值流动
1.1 盈利
程序员们进行软件开发工作，其首要目的是交付用户价值，
我想这件事再怎么强调也不为过，技术本身只是实现价值的手段。
软件开发是需要成本的，如果开发团队不能持续的交付用户价值，
那么在负反馈作用下，现有资源就会消耗殆尽，
无法支撑起后续的开发工作。
因此，如何有效的，更快的交付价值，成为了软件项目管理的重点。
1.2 用户价值流
在实际的生产实践、或软件开发实践中，
用户价值不是由一道工序完成的，而是经历了一系列过程，
这些交付过程是有依赖关系的，共同构成了一道用户价值流。
价值流，指的是一个组织基于客户的需求所执行的一系列有序的交付活动。
2. 过程改进
2.1 约束
为了提高产能，最大化用户价值流，
以色列物理学家、企业管理顾问戈德拉特博士，提出了约束理论。
任何非瓶颈资源究竟能使系统赚多少钱，不是由它自己的潜能所决定，
而是由系统中的其他制约因素所决定。
任何不针对约束点而做出的优化都是假象。
例如，如果我们优化约束点之前的那道工序，
那么工作必将在这个约束点上更快的积压起来。
反之，如果优化约束点之后的那道工序，
那么它还是会处于空闲状态，等待约束点处工作的结束。
2.2 排队论
排队论是运筹学的一个分支，
是研究服务系统中排队现象随机规律的学科。
其中有一项重要的法则，称为利特尔法则，
在一个稳定系统中，每个人的平均等待时间，等于平均滞留人数除以吞吐率，。
其中，吞吐率是单位时间内进入或离开的人数。
因此，要想缩短平均等待时间，
只能通过减少平均滞留人数，或增加吞吐率来实现。
吞吐率一般是很难立即提高的，这涉及到系统本身提供服务的效率。
但是平均滞留人数却可以通过管理学手段人为减少。
即，对任何一道工序而言，在不增加工序本身工作效率（吞吐率）的情况下，
仅仅减少在制品数量（平均滞留人数），
就可以大幅度的减少平均前置时间（平均等待时间）。
2.3 拉动
为了限制在制品数量，丰田公司提出了看板方法，
后道工序在需要时，通过看板向前道工序发出信号，
前道工序只会根据看板按需生产。
看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。
拉动的源头是最下游的客户价值，也就是客户订单或需求。
通过限制在制品数量，还能更容易的发现工作中的阻碍。
例如，当限制在制品时，可能会发现有些工序居然没什么工作可干，
因为要等待其他人。
虽然进行一项新工作（即，干点什么总比什么都不干强）可能很诱人，
但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。
实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，造成了很多优先级冲突问题。
2.4 敏捷
敏捷开发，
是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，
它可以有效的应对快速变化的需求。
与之前瀑布式开发相比，
敏捷开发推荐采用更短的交付周期，
强调使用小批量任务进行增量发布，频繁的交付可工作的软件。
持续交付正是敏捷思想的工程上的实现和保障。
3. 知识
3.1 可见性
与传统制造业项目不同的是，软件项目的工作内容是不可见的，
在技术价值流中发现过程的阻塞点，是一件困难的事情，
用户价值在哪里受阻了，在哪个环节产生了积压，都很难被察觉到。
此外，价值流中还包含了大量的信息和知识，这是一种无形的价值，
即使在最好的情况下，也难免在交接过程中丢失，
因此，沟通结构对产品形态会产生约束。
这就是著名的康威定律，
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
产品结构反映了设计该产品的组织的沟通结构。
3.2 抽象性
我们知道，在软件工程方面没有银弹。
因为，软件开发的真正困难不在于如何表示一个抽象概念，
而在于如何将这个抽象概念传递给其他人。
《人月神话》提到了Brooks's law，
Adding human resources to a late software project makes it later.
向进度落后的项目中增加人手，只会使项目更加落后。
软件活动是围绕那些人为创造的抽象概念展开的，
所以，如何传递这些由抽象概念构成的知识，是软件活动中最困难的部分。
3.3 领域知识
在这些抽象的概念中，最重要的是领域知识，
很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。
当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。
如何表示这些知识，是《领域驱动设计》所探讨的主要内容。
只有软件项目的各参与者，在领域层对知识达成共识，
才能做出好的设计，并贯彻执行下去。
敏捷宣言中也提到了，
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
3.4 架构
一个架构要落到实处，同样也必须考虑人为因素，这就好比销售，
只有一个人是不可能做成买卖的，必须得有另一个人购买所推销的东西。
《软件系统架构》中提到了架构设计中必须考虑的利益相关者（stakeholder），
Stakeholders are the people for whom we build systems.
A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs.
好的系统架构必须满足所有相关者的利益。
优雅的架构不见得能够落实下去，必须所有参与者同意这样落实才行。
这也是一个知识和关注点的汇总和协调过程。
4. 前端
4.1 业务价值
Web前端工程师，是最近这些年才兴起的软件开发工种，
Front-end web development is the practice of converting data to graphical interface for user to view and interact with data through digital interaction using HTML, CSS and Javascript.
与Web后端相比，前端更关注数据的展示以及和用户之间的交互，
而复杂的业务流程会放到后端来做，
因此，从职责上来看，前端对业务领域的认知要求就不必太高。
那么，前端对业务价值的贡献是不是就不明显了？
其实不然。
因为软件开发过程，还没有从提高单一过程的产能，
向提高整个系统产能的方式而转变。
在整个用户价值流中，前端在所有开发者中处于最下游，
用户对界面的一系列需求，拉动了上游所有工序的进展。
4.2 异常流
在软件系统中，如果用户提交的一项任务失败了，结果却没有任何提示，
这样的体验是非常差的，
静默失败，无疑向用户展示了一个不可靠的系统。
此外，吞掉异常也不利于人们对错误进行排查，
这会大幅度的延迟合适的人看到错误的时机。
所以，要想提高可靠性，加速反馈循环，
在系统的异常处理上就得仔细斟酌。
将异常透传到最外层，由前端来决定展示方式，是一项好的实践。
不必担心用户看到了异常也无能为力，
实际上，帮用户拿主意，才是导致无能为力的根源。
透传异常，与其说是异常的传递，倒不如说是各开发者对异常认知的传递，
是一个知识传递过程，
前端对信息的拉动作用，至关重要。
4.3 调用链路
业务逻辑最终会体现在用户界面上，
隐藏在界面之后，可能有复杂的调用链路和处理逻辑，
因此，前端在链路联调中也处于关键作用。
而链路下游的任何改动，也必将引起上游的一系列调整，
包括数据格式，或者数据源的重新组合，等等。
因此，前端和用户之间的沟通还必须是紧密的，
对需求的变更也是最敏感的。
通过增加和减少前端的任务量，
能快速识别出，系统中哪里产生了积压，哪里是效率的瓶颈。
结语
本文汇总了以下这些概念，
企业的盈利本质，用户价值流，约束理论，利特尔法则，看板方法，敏捷，
康威定律，没有银弹，领域知识，等等。
这些概念统一起来，共同描绘了一副完整的现代软件工程的新画面，
从各个维度反映了软件项目的特点，以及与传统项目的不同。
文末我们提到了Web前端这个新兴岗位，
在传统软件开发过程中，人们认为，产能是由原材料的丰富程度决定的，
但实际上这是不符合现代管理理念的，
整个系统的产能，应该取决于最薄弱的那个环节。
前端在用户价值流的交付中处于最下游，
能看到所有交付链路中的产能过剩和瓶颈，
此外，又是与用户关系最紧密的开发人员。
毫无疑问，前端在创造业务价值方面，还有更大的施展空间。