2019-08-30一个问题：大公司流行的方法论，为什么到我们身上就没用了？
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来指引方向。对于自己而言，则是如何改进优化工作。
思考题：
第一次看到。目前理解的是梳理工作流程，找到问题积压最多的一个地方，我可能套用不了。展开作者回复: 关于思考题，有空可以看一下这本书理解看板：
中文版：https://book.douban.com/subject/25788807/
英文版：https://book.douban.com/subject/5350839/ 2 3
2019-09-08我们公司的看板会分为：待评审需求，已评审需求，转开发，开发中，转测试，测试中，待上线（任务纬度），需求底下由开发自己创建任务，一个需求，不同的任务有时可以分开上线有时候需要一起上线，通过这样分可以了解到，需求消化瓶颈在哪，可以针对，开发，测试，产品进行优化作者回复: 看起来你们的看板使用的不错👍
你们有限制WIP吗？ 2
2019-09-01我会在看板中针对每一道工序都设定两个环节，一个是等待中，一个是处理中，处理完的就到下个工序的等待中或处理中。我们会合理控制处理中的在制品数量，于是等待中就会有任务堆积，当某个工序的等待中的任务数量多起来了，我们就会去分析这中间有什么问题，一般问题分为三类，资源数量(人不够多)，资源能力(人不够强)，资源协同(流程机制方面的的问题)。
既有可视化面板的作用，也有看板的作用，不过现在是用一块白板搞的，没有屏幕，也没有系统，所以白板上写完，还要录到文档里，比较麻烦。作者回复: 赞！这个是正确使用看板的姿势。工具麻烦一点不要紧，慢慢慢提高，关键是方式正确。
至于具体工具，Trello这样的应该可以实现你们实用的这种工作流呀？
推荐阅读：4 BENEFITS OF WIP LIMITS（https://leankit.com/learn/kanban/benefits-of-wip-limits/） 2
2019-08-30看了下面的评论，有所老师总结的好的，有说有些东西太形式主义了的
大学学的东西，出生社会工作后才发现，几乎全是「形式主义」，那大家怎么把这个社会向前推动的呢？
方法论没有对错，大学老师给你讲授的课程，是让你通过3-4年的学习，带领你到这个行业，出来以在这个行业如何发展、还得靠自己的努力
葛老师给给我们教授的也是方法论，希望我们有高效研发的意识，这个很重要，没有这个意识和意愿再多干活也没有，其次根据自身公司、 所处工作环境去摸索一套适合自己、 适合公司的流程和方法才是重点展开作者回复: 越灵活的东西，越需要掌握本质。
2
2019-08-30最近正在把部门所有的移动 App 接入基本的 CI，直接用 gitlab ci 工具最简单，之前试过 Jenkins 可把我烦死了。作者回复: Jenkins 比较麻烦，但是比较成熟，跟其他工具集成比较完备。 GitLab CI比较新，好用很多，但是有一些场景应该不支持（新的东西的通病）。如果你们的场景能使用GitLab CI，那就最棒了。
2 2
2019-09-14“在具体实践上，个人代码上线后，在和他人的代码集成时容易出现问题”---这个问题老师可以给出具体的实例吗？我理解本地构建经过两步：第一步是自己的代码的本地构建，第二部是拉取最新代码仓库的代码进行集成后的本地构建。如此之后，在什么场景之下，还会有代码集成的问题。这种问题多吗，还是极少数情况？作者回复: > 我理解本地构建经过两步：第一步是自己的代码的本地构建，第二部是拉取最新代码仓库的代码进行集成后的本地构建。
一般本地构建并没有要求做第二步。如果做了第二步，实际上是你在代码入库之前，在自己的本地做过了集成验证。所以会避免很多上面提到的”再和他人代码集成时出现问题” 1
2019-08-31围绕提高用户价值的目标出发，尽快让用户验证我们现在做的事是正确的，为了提高速度，利用工具让节点通达，使用任务看板和进度工具找到瓶颈。我们使用任务看板和员工日志，系统识别哪个任务超出预期了。我们现在的瓶颈是需求不细、用户验证慢，导致连带返工。作者回复: > 我们现在的瓶颈是需求不细、用户验证慢，导致连带返工。
你们有什么提高计划吗？ 2 1
2019-08-30无招胜有招 1 1
2020-01-13Nuclide已经被Facebook放弃了 https://nuclide.io/作者回复: 是的。在我写专栏的时候，他们停止了对Nuclide的更新。第11篇文章(https://time.geekbang.org/column/article/136070)中我也提到了这一点："...另外，在去年年底，Facebook 停止了对 Nuclide 的开源项目的维护，这也意味着后面他们可能还会有对 IDE 的一轮新的优化。"
2019年11月，FB全面转向VS Code：https://visualstudiomagazine.com/articles/2019/11/21/fb-vs-code.aspx。
2019-09-17在复盘方面，Facebook 做得也很好。他们有一个 SEV 复盘系统，用来记录公司发生的重要事故进行复盘。能否请教这个复盘系统主要的功能是什么，主要记录哪些关键的信息？作者回复: 好的，我后面文章里面做一些详细介绍。
- 2019-08-31我司的开发瓶颈，在于中间件。每个产品都要用到少则五六个多达十几个的中间件，那那些中间件都是在不同的国家开发的，质量良莠不齐，互相的依赖性又很强，幸好有CI的存在，对于新安装的产品，中间件表现还行，但对于已经安装好的产品在升级时，由于组件版本繁多，升级路径扑朔迷离，基本上产品的每个版本，要花费六成的资源在中间件的整合与升级上，团队苦不堪言。
作者回复: 这些组件都是在不断更新吗？
安装好的产品升级，总是使用最新的版本，还是有的情况继续使用旧版本？ 
2019-08-31云效目前自身的问题还是挺多的，但是对于流程方面的建设确实不错！比如老师提到的复盘系统，云效有与之对应的故障台！云效开发模式中，开发利用云效平台拉取分支，编码后可以一键构建部署，之后进入运维系统查看是否有问题，自行快速回滚！云效商业化后，对很多传统公司都起到了一个很好的效能提升！作者回复: 云效对推动国内企业对研发效能的重视度，起到了很重要的作用
- 2019-08-30软件开发会用到钉钉么？如果用到，会要求写日报，周报，月报不？写短了被批评，长了也很少人看，大家都很痛苦的那种？
作者回复: 日报，周报，月报如果用得好，可以达到至少两大作用：1. 沟通信息并电子化；2. 促进自己和团队计划、总结、反思
> 写短了被批评，长了也很少人看
主管要明确这些周报的作用。让花在写报告的时间花得值得。 2 
2019-08-30老师总结得很好，我也很喜欢Facebook这种实用主义，很讨厌形式主义，我们就冲着目标去，完成目标，达到目标，遇到问题解决问题，而不是为了敏捷而敏捷，站会要不要开怎么开，都可以根据团队的需要去设定。寻找用户价值、提高用户价值的流动效率，这两个目标是今天的重点，要记在心里。作者回复: 👍👍👍