04 | 流程优化：怎样才能让敏捷、精益真正为我所用？

我会在看板中针对每一道工序都设定两个环节，一个是等待中，一个是处理中，处理完的就到下个工序的等待中或处理中。我们会合理控制处理中的在制品数量，于是等待中就会有任务堆积，当某个工序的等待中的任务数量多起来了，我们就会去分析这中间有什么问题，一般问题分为三类，资源数量(人不够多)，资源能力(人不够强)，资源协同(流程机制方面的的问题)。 既有可视化面板的作用，也有看板的作用，不过现在是用一块白板搞的，没有屏幕，也没有系统，所以白板上写完，还要录到文档里，比较麻烦。

一个问题：大公司流行的方法论，为什么到我们身上就没用了？ 1.原封不动的照搬。 2.文中提到的WHY?HOW?WHAT?没有思考 WHY=为什么会发生这个问题？原因在哪？ HOW=找到原因后我们该怎么做？ WHAT=做完后我们得到了什么？不正确就返回WHY 3.管理和员工传达不准确，只有向下的传达，没有向上的反馈。 当团队思考清晰后，不再是看哪个方法论流行就套用，而是根据目前存在的问题去寻找答案。 实践原则时候则有二个目标： 1.寻找用户价值 2.提高用户价值的流动效率 用户价值，PM或者运营接触的更多，接触的更近，这里要和团队追求的用户价值一样，需要协同思考。挺担心PM或者运营解释模糊，甚至要求开发直接做出来，干好自己的本分，别多问。在前面有看见说：“开发周期长，经常加班，上线时间紧急，上线BUG不断，都是PM经常改需求造成的，PM最后还甩锅开发完不成。”实践原则的第一个目标寻找用户价值，不仅仅对开发提出了问题，还要求团队之间的相互支持和信任。 有了上面条件后，我们就可以把寻找的过程拆分为两个： 1.衡量每一个时间段成功的标准，应该是价值假设方面的进展。 2.使用最小可行性产品来帮助学习。 为什么是这两个参考呢？单纯看数量，团队会因为利益的问题只把数量推高，公司不知道哪个成功、哪个失败。就像第三篇有团队做出了50+个微服务，但每一个都没用，大家是完成了指标，但是公司利益，用户价值全被丢一边了。 用价值时间段成功为团队指引方向，最小可行性产品为团队改进优化，形成一个正向循环。 用户价值流动效率，它包括四个点： 1.让功能尽快流动 2.让节点之间的联动更加顺畅 3.节点之间的融合 4.发现整个流程中的瓶颈，并解决 个人理解这里更关注人，关注技术的沟通。缩短生产周期，提高不同工具之间的流通效率，个人工作的流畅性，出现问题后如何找到问题和复盘问题。 运营岗位，我要做的是和其他部门沟通，看看他们的问题是什么？我有什么工具或者数字可以作为一个指标而不是kpi来指引方向。对于自己而言，则是如何改进优化工作。 思考题： 第一次看到。目前理解的是梳理工作流程，找到问题积压最多的一个地方，我可能套用不了。

我们公司的看板会分为：待评审需求，已评审需求，转开发，开发中，转测试，测试中，待上线（任务纬度），需求底下由开发自己创建任务，一个需求，不同的任务有时可以分开上线有时候需要一起上线，通过这样分可以了解到，需求消化瓶颈在哪，可以针对，开发，测试，产品进行优化

最近正在把部门所有的移动 App 接入基本的 CI，直接用 gitlab ci 工具最简单，之前试过 Jenkins 可把我烦死了。

“在具体实践上，个人代码上线后，在和他人的代码集成时容易出现问题”---这个问题老师可以给出具体的实例吗？我理解本地构建经过两步：第一步是自己的代码的本地构建，第二部是拉取最新代码仓库的代码进行集成后的本地构建。如此之后，在什么场景之下，还会有代码集成的问题。这种问题多吗，还是极少数情况？

看了下面的评论，有所老师总结的好的，有说有些东西太形式主义了的 大学学的东西，出生社会工作后才发现，几乎全是「形式主义」，那大家怎么把这个社会向前推动的呢？ 方法论没有对错，大学老师给你讲授的课程，是让你通过3-4年的学习，带领你到这个行业，出来以在这个行业如何发展、还得靠自己的努力 葛老师给给我们教授的也是方法论，希望我们有高效研发的意识，这个很重要，没有这个意识和意愿再多干活也没有，其次根据自身公司、 所处工作环境去摸索一套适合自己、 适合公司的流程和方法才是重点

老师总结得很好，我也很喜欢Facebook这种实用主义，很讨厌形式主义，我们就冲着目标去，完成目标，达到目标，遇到问题解决问题，而不是为了敏捷而敏捷，站会要不要开怎么开，都可以根据团队的需要去设定。寻找用户价值、提高用户价值的流动效率，这两个目标是今天的重点，要记在心里。

我司的开发瓶颈，在于中间件。每个产品都要用到少则五六个多达十几个的中间件，那那些中间件都是在不同的国家开发的，质量良莠不齐，互相的依赖性又很强，幸好有CI的存在，对于新安装的产品，中间件表现还行，但对于已经安装好的产品在升级时，由于组件版本繁多，升级路径扑朔迷离，基本上产品的每个版本，要花费六成的资源在中间件的整合与升级上，团队苦不堪言。

围绕提高用户价值的目标出发，尽快让用户验证我们现在做的事是正确的，为了提高速度，利用工具让节点通达，使用任务看板和进度工具找到瓶颈。我们使用任务看板和员工日志，系统识别哪个任务超出预期了。我们现在的瓶颈是需求不细、用户验证慢，导致连带返工。

云效目前自身的问题还是挺多的，但是对于流程方面的建设确实不错！比如老师提到的复盘系统，云效有与之对应的故障台！云效开发模式中，开发利用云效平台拉取分支，编码后可以一键构建部署，之后进入运维系统查看是否有问题，自行快速回滚！云效商业化后，对很多传统公司都起到了一个很好的效能提升！