精益产品开发

最近一段时间在断断续续看老板推荐的一本书《精益产品开发》

背景

最近一段时间在断断续续看老板推荐的一本书《精益产品开发》。

我这人不太爱看书，是因为看书要犯困，我也不知道为啥，我内心是想看书的，但是一看上就打瞌睡，太难受了，所以导致我看书的节奏是只能概看，偶尔能专注（比如遇到难理解的、有兴趣的）。

在这儿记个流水账啦。纯属个人观点，不喜就算了。

开始

XP方法

即极限编程，一开始以为XP是啥没听过的新东西，一查原来就是早有耳闻的极限编程。

这里想说一说，XP里有个点，正是我目前比较推崇且是这么做的-简单设计

极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。也就是不过度设计不追求完美不刻意追求可扩展（需要申明一下当你个人都不清楚或者不确定未来的场景的情况下），以最短的时间和最简单的方式实现。

这儿我不跟任何人抬杠，我目前就是认为“简单设计”是让我体验最好的编程方式。

我从中能获益两点，这两点带给我的正反馈是可以让我放弃追求完美和一定要可扩展的目标的。

• 时间，通常会加快我对产出的交付，特别是当我扮演的是生产者或者叫被依赖方时，会让使用方的用户体验比较好，比如写后端的时候前端开发者会少一些抱怨和矛盾，比如写前端的时候，产品、UE会比较满意。总体来说，不仅仅只是少花了一些时间，在各方的满意度方面都会有所提升，从而最终个人幸福感得到提升。多说一句，团队为啥搞敏捷，说的直白点，很大的一个因素不就是各位消费方都想尽快看到产出吗？而不是多方动不动就墨迹工期的问题。

• 可靠性，因为是简单设计，所以满足当前场景的出错概念低，且易于维护。

聚焦价值流动效率，而不是资源利用效率。
这一点是我一直比较坚持的观点（虽然没啥人听我的），只是不知道有这么个专业的词语“价值流动效率”，现在公司几乎我接触过的team，不管是办啥事一上来都是先聊资源问题，往往就把事情聊死了或者需要老大出面了。

其实我觉得，不管啥事先要搞清楚，这个事的背景，是为了解决什么问题，最终对于产品的价值的是什么。这就是我认为的价值流动效率，就是咱们得聚焦于交付的价值，而不是资源问题。

控制在制品的数量
其中有一节讲看板方法的实践，里面说到一个实践：控制在制品的数量。
个人认为，首先产品端要克制，每个迭代不要以故事数来定，而是基于故事闭环以及研发工作量，聚焦最终交付的价值

看板

可视化价值流动

看板系统设计的原则

• 体现价值

• 反映协作

• 暴露问题

1. 分析价值流动过程
   1. 识别团队交付的价值类型（业务需求、技术改进等）
   2. 确定看板系统的基本流动单元（通常选取工作比重较大的价值类型，比如：业务需求。）
   3. 分析流动单元的流动步骤（分析、开发、测试等）
   4. 识别流动过程中的价值分解和合并（分解为多人完成再合并）
2. 选取可视化设计元素
   1. 队列。形成的条件：某个状态存在一段时间的停留。比如：开发中、测试中等
      1. 列的划分可以很细，具体细化到哪个级别，依赖于:
         1. 工作是否会在该阶段显著停留。比如：待验证
         2. 使用者是否需要特别关注这些阶段。比如：自测阶段
   2. 泳道。表达流动单元的层级关系，起分割作用，常用的划分依据:
      1. 处理规则的不同，如:业务需求和现场问题。
      2. 需要给予不同的关注，如需求的受益方不一样。
   3. 区域。表示特定信息。
   4. 卡片及标识
3. 用看板墙建模价值流动过程

显示化流程规则

核心要求：团队成员对流程规则形成一致的理解和承诺。