正儿八经 - 资深软件工程师

把我知乎回答的一篇文章拿过来。

背景

人到30总想多做点什么，不然怕被干趴下了，毕竟不能被干趴下，所以就写写说说，万一走上一条不归路呢，那多刺激。

第一篇知乎文章啊 就给了前端，可见爱的多么深沉。

前几年除了迷茫时期浪的其他行业，都是在做后端，最近这两年由于公司当时的业务需要赶鸭子上架写起了前端代码，对于当时只会一点js和html以及削微一点点css的我来说，那是酸爽的一比啊。

一入前端深似海啊深似海。

因为我属于半路出家，所以没有系统性的学习，我只能在这儿随便抒发我的游击路线。

如果你着急

先找个视频根据自己的需要搭建好本地环境。

这个时候就别再想着拿本恁厚的犀牛书或者JavaScript高级程序设计等等书来啃了，因为来不及，我的建议是边做边学，先让自己动起来。

• 找学习内容

网上一大堆学习网站和博客，所以其实这个时候你会发现你最需要的是掌握搜索技巧。首先尽量别用百度搜索，体验太差，可以用必应或者最近比较火的夸克之类的。

我的建议是如果不能访问外网，就尽量到垂直领域类的网站去搜索，比如github、开源中国、博客园等，以及一些视频网站比如网易公开课，这里特别要注意github，它可是个宝藏啊，啥都有。

如果实在找不到质量好的课程最简单的方法就是花钱，现在网上各种课程一大堆，首先能确定一点能开课且还收钱的肯定有两把刷子最起码比你强，那你花点钱不冤枉。这个时候尽量挑实操性强的有针对性的课程，讲原理、扩展类的就先别接触了。

• 学习方式

边学边跟着练。要多练不停的练，想不明白甚至照着敲几遍都行。

如果有必要可以边学边写工作代码，不要怕先干起来。当然前提有几点：

1. 首先你可以放心一点：除非你们的系统是PPT或者KPI系统，不然是没人敢放你写代码的，所以人给了机会你就得先迈一步，没事走两步。
2. 团队有code review，找大牛给你code review，你会成长得很快。这个时候就别要脸了。你根本没脸，不要问我咋知道得。
3. 不要一开始就写核心业务代码，当然也几乎不可能让你上。
4. 做好对当前代码会不断重构的心理准备。

这个时候还有个东西很重要，那就是工具，提效的工具。

代码规范

Gamehu：Lint工具zhuanlan.zhihu.comLint笔记-ESLintgamehu.run

代码调试

Chrome Tools-Sourcesgamehu.run

如果你不着急

可以先看看这个

Front-end web developerdeveloper.mozilla.org

目标

整个系统性的学习框架出来，如果自己搞出来有难度，很简单随便上网用关键字搜一下，比如搜面试指南、前端技术雷达、前端知识框架、前端技术思维导图等然后把你搜索到的内容对比一下，基本上就能知道你需要在不同阶段掌握哪些内容了。

总之先整个可量化的内容以及明确的目标出来。

目标要阶段性且有挑战性且可给与你反馈的。

然后可能需要这么干：

• 从基础类内容开始学起。比如HTML、CSS、ES6等

可能很多时候当人开始准备做前端的时候，就有一种冲动选择像React、Bootstrap、AntD等流行的库或者框架，并开始投入大量时间到基于它们构建的内容中。
这是不明智的，你要控zhi你自己。 如果不了解基础知识，就永远无法使用这些主流框架更高级的特效以及创建更高级的项目。 要记住不积硅步无以至千里啊，盆友们。

• 应用

注意，学习和应用之间存在巨大差异。
从0开始，使用HTML / CSS / JavaScript创建一个小型但有效的项目。 然后，不断的一个又一个的创建练习的项目。
在此过程中，不断增加项目的复杂性和期望值，直到达到你设定的目标。

这个时候你再考虑拿一些主流的库和框架来联手了，深刻理解“造轮子”这个词。

• 看书

书那就太多了，这个时候你应该大体对前端有一定的认知，这个时候你就可以选书看看了，我不太爱看书啊，一看书就打瞌睡，所以看书慢且比较少，所以看个人了，下面是我看的部分书。有机会后续会把书单完整列一个。另外如果喜欢电子书可以买个阅读器，市面上茫茫多，我自己是几年前买了个Kindle上面的书比我纸质书多。

[《Web开发经典丛书：HTML & CSS 设计与构建网站》(美]Jon Duckett)【摘要 书评 试读】- 京东图书item.jd.com[《JavaScript高级程序设计 第4版(图灵出品）》(美]马特·弗里斯比（Matt,Frisbie）)【摘要 书评 试读】- 京东图书item.jd.com

我的一部分…

• 看源码

先别直接上来就看React等源码，相信我你可能会自闭的。

找一些基础的库比如lodash等看看源码，你会印证和学到很多。

循序渐进，弄清楚一些主流的框架为什么要这么做。有时候，直接使用某些框架可能并不是最好的选择，但是在大多数情况下，了解它们是没错的。

• 了解工具

在开始前端开发的过程中，了解不同的工具选项是很重要的。 出色的工具应用将让你的更加的得心应手。

Chrome Tools、git、npm、webpack、node、postman、nginx等，其中chrome tools、git、nginx我个人认为熟练掌握很重要。

• 用户体验

这其实属于软技能了，需要一种思维的转变。

做一个好用的产品。

作为前端开发人员，需要意识到自己处于某种中间人角色。 作为中间人，与QA人员，产品，UCD以及其他开发人员都会有交集。你将需要考虑不同的观点。在这个过程中你会发现你可能会做了一些产品、UCD等角色的工作。
始终保持良好的用户体验不仅是从用户的角度，还是从其他开发人员的角度。

• 参加开源项目

这块好处那就多了，成就感、能力提升、献出自己的一份力、结交新朋友等等

这个是我一直的痛，个人能力有限吧，或者说没找到入门的方式或者说懒，我迟迟没有跨出这一个步…我也要加油了

小结

暂时写这么多吧，感觉如果还不收手的话，写一个星期的写不完，因为其实里面的很小一个点估计也能写好多文字，前端为什么深似海就是因为轮子太多，技术栈更新快，前端地位愈发重要等等。

我跟你们放一张图你们就明白深似海，我为何感慨了。

这张图就是现在我主要下手的内容，这只是前端工程化部分的内容，已经够够够学好久了。。。

​ 很抱歉我确实忘记是从哪儿看到的的图了，如果有侵权请联系我删除，由此给您带来的困扰我十分抱歉。

另外说一下如果要报课程，我建议大家还是慎重，毕竟现在市面上各类培训或者课程太多，别挑花眼的同事把自己整的太浮躁，一口吃不成胖子。我还是提倡实操为主，直接找公司实习，不要钱都行。

如果非要报，报个系统性的线上或者线下课程，最好是选择学习时能直接产生交互或者反馈的那类课程，最好不要录播的。

背景

之前关注比较多的还是js以及js扩展语言方面的检测工具，对css方面的检查工具了解较少，个人感觉css的检查确实比较难。刚好这两天看到了一篇css检查工具的文章，刚好蹩脚的翻译一下，做个记录。

就如文中作者所说，当然自身也有体会，css检查一个很大的难点就是：可以通过许多不同的方式来实现相同的样式。这已经就让CSS审核起来有些棘手。

通过之前我在团队内分享的stylelint等工具可以避免一些问题，但是其实是不够的。仍然还有一些问题时无法解决的比如：太多的颜色，排版或z-indexs。

所以作者给我们列举了一些工具，用于检查css。

开始

浏览器内的开发工具

用Chrome DevTools 的 CSS 检查工具举例。 详细的可参考 Umar Hansa 的这篇文章 —Chrome一大堆发布于 2020 年的「伟大的」 DevTool 功能。
如果你喜欢手动检查 CSS 代码，我们可以使用 Inspect 工具以找出应用于特定元素的 CSS 代码。使用 “Inspect arrow”，我们甚至可以看到关于颜色、字体、大小和可访问性的那些额外的细节。

Grid 和 Flex 的检查器

DevTools 界面中有很多实用的工具，我最喜欢的是 Grid 和 Flex 检查器。要启用它们，请进入设置（DevTools 右上方的一个小齿轮图标），点击 Experiments，然后启用 CSS Grid 和 Flexbox 调试功能。虽然这个工具主要用于调试布局问题，但我有时也会用它来快速判断页面上是否使用了 CSS Grid 或 Flexbox。

CSS Overview

让我们看看一些更高级的 DevTools 功能。CSS Overview 就是其中之一。

要启用 CSS Overview 工具，进入设置，点击 Experiments，启用 CSS Overview 选项。
要打开 CSS Overview 面板，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 css overview，然后选择 Show CSS Overview。这个工具可以展现 CSS 属性的概览，比如颜色、字体、对比度问题、未使用的声明和media查询。我通常用这个工具来判断当前 CSS 代码的好坏。例如，如果有 50 种灰度色彩或过多的排版定义，就意味着样式规范没有被应用到实际，或者甚至可能不存在样式规范。

不过请注意，该工具会对应用于这个页面的样式做出概览，而不是对单个文件做出概览。

Coverage panel

Coverage Panel 工具会显示页面上使用的代码数量和百分比。要查看它，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，键入 Coverage，选择 Show Coverage，然后点击刷新图标。
你可以在 URL 过滤器中输入 .css 以用于过滤专门显示 CSS 文件。我通常使用这个工具来了解网站的交付技术。例如，如果我看到 CSS 的覆盖率相当的高，我就可以认为 CSS 文件是为每个页面单独生成的。这可能不是关键数据，但有时它有助于了解缓存策略。

Rendering Panel

Rendering Panel 是另一个有用的工具。要打开渲染面板，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键。这次输入 “Rendering”，然后选择 “Show Rendering” 选项。这个工具有很多选项，个人觉得最好用的是：

• Paint flashing — 当重绘事件发生时会显示绿色矩形。我用它来识别需要花费太多渲染时间的区域。
• Layout Shift Regions — 当布局移动发生时显示蓝色矩形。为了充分利用这些选项，我通常在 “网络” 选项卡下设置 “Slow 3G” 预设。我有时会录制我的屏幕，然后放慢视频速度来寻找布局转移。
• Frame Rendering Stats — 显示 GPU 和帧的实时使用情况。这个工具在识别动画卡顿和滚动问题时很方便。

这些工具会给出常规检查中没有的数据，它对于了解 CSS 代码是否具有性能以及消耗设备的能量的多少提供依据。
其他选项可能对调试问题更有利，比如模拟和禁用各种功能，强制使用 prefers-color-scheme 功能或打印媒体类型，以及禁用本地字体。

Performance Monitor

另一个检查 CSS 代码性能的工具是 Performance Monitor。要启用它，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 Performance Monitor，然后选择 Show Performance Monitor 选项。我通常使用这个工具来查看与页面交互或动画发生时会触发多少次重新计算和布局。

Performance Panel

在 Performance Panel 上，我们可以详细查看页面加载过程中的所有浏览器事件。要启用性能工具，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 Performance，选择 Show Performance，然后点击 “重新加载” 图标。我通常会启用 Screenshots 和 Web Vitals 选项。对我来说，最感兴趣的是First Paint、 First Contentful Paint、Layout Shifts、 Largest Contentful Paint这几个指标。

还有一个饼图显示了绘制和渲染时间。

DevTools 可能不算是一个经典的检查工具，但它可以帮助我们了解哪些 CSS 功能被使用，代码的效率，以及代码的执行情况，而这些都是 CSS 代码检查的关键所在。

在线工具

DevTools 只是用于检查css的其中一个工具，下面介绍一下其它可用来检查 CSS 代码的工具：

Specificity Visualizer

Specificity Visualizer显示代码库中 CSS 选择器的特殊性。只需访问网站并粘贴 CSS。
主图 Main Chart 会显示特定样式与样式表中的位置的关系。另外两个图表显示了特定样式的使用情况。我经常使用这个网站来寻找 “bad” 选择器。例如，如果我看到许多特定样式被标记为红色，我很容易得出结论 —— 这里的 CSS 代码可以改进得更好。在你努力改进时，保存截图以供参考是很有帮助的。

CSS Specificity Graph Generator

CSS Specificity Graph Generator是一个类似的可视化特定样式工具。它显示了一个略有不同的图表，可能会帮助你看到你的 CSS 选择器是如何按特定样式组织的。正如它在工具页面上所说的那样，”波峰是不好的，总的趋势应该是在样式表的后期有更高的特定样式”。进一步讨论这个问题会很有意思，但这不在本文的讨论范围内。然而，Harry Roberts 在他的文章 “The Specificity Graph” 中确实广泛地写到了这一点，值得一试。

CSS Stats

CSS Stats 是另一个为你的样式表提供分析和可视化的工具。事实上，Robin 在不久前写过关于它的文章，并展示了他如何使用它来审核他工作中的样式表。
你需要做的就是输入网站的 URL，然后点击 Enter。这些信息被分割成有意义的部分，包括了样式的声明数、颜色、排版、z-index 和特定样式等等。同样，你可能要把截图存储起来，以备日后参考。

Project Wallace

Project Wallace 是由 Bart Veneman 开发的，而他已经在 CSS Tricks 上介绍了这个项目。Project Wallace 的强大之处在于，它可以比较和可视化基于导入的变化。这意味着你可以看到你的 CSS 代码库以前的状态，并看到你的代码在不同状态之间的变化。我觉得这个功能相当有用，特别是当你想说服别人代码是改进过的。该工具对单个项目是免费的，并为更多项目提供付费计划。

CLI 工具

除了 DevTools 和在线工具，还有命令行界面（CLI）工具可以帮助我们检查 CSS：

Wallace

我最喜欢的 CLI 工具之一是Wallace。安装后，输入wallace，然后输入网站名称，它就会自动输出显示了你需要知道的关于网站的 CSS 代码的一切。我最喜欢看的是 !important 的使用次数，以及代码中有多少个 ID。另一个信息是顶级特定样式的数量以及有多少选择器使用它。这些可能是 “坏” 代码的危险信号。
我最喜欢这个工具的地方是，它可以从网站中提取所有的 CSS 代码 —— 不仅是外部文件，还能够包括内联代码。这就是为什么 CSS Stats 和 Wallace 的报告不匹配的原因。

csscss

csscss CLI 工具可以显示哪些规则共享相同的声明，而这对于识别重复的代码和减少编写的代码量是很有用的。在这样做之前，我会三思而后行，因为这可能是不值得的，尤其是在今天的缓存机制下。值得一提的是，csscss 需要 Ruby 运行环境。

其他有用的工具

• Color Sorter — 先按色调，再按饱和度对 CSS 颜色进行排序。
• CSS Analyzer —  对一串 CSS 进行分析。
• constyble — 这是一个基于 CSS Analyzer 的 CSS 复杂性分析器。
• Extract CSS Now — 从一个网页中获取所有 CSS。
• Get CSS — 从一个网页中获取所有的 CSS。
• uCSS — 抓取网站以识别未使用的 CSS。

结语

CSS在我们周围无处不在，我们需要将其视为每个项目的头等公民。 如果您的CSS井井有条且编写精良，那么您将花费更少的时间调试它，而将更多的时间用于开发新功能。 在理想的世界中，我们会训练每个人都编写出色的CSS，但这需要时间。

今天是开始关心CSS代码的日子。

我知道审核CSS对每个人都不会很有趣。 但是，如果您针对这些工具中的任何一个运行代码，并尝试甚至改善CSS代码库的一部分，那么这篇文章就完成了它的工作。

最近，我越来越多地考虑CSS代码，并且试图使更多的开发人员更加尊重CSS代码。 我甚至开始了一个新项目css-auditors.com，该项目专门用于审核CSS。

交代

最近看了篇Google出的关于DevOps的文章《度量DevOps四个关键指标》，在这儿做个记录。google翻译+蹩脚的自我理解，莫吐槽，将就看。

开始

通过六年的研究，DevOps研究与评估（DORA）团队确定了四个关键指标，这些指标指示了软件开发团队的绩效：

• 部署频率 - 成功发布产品的频率。
• 变更前置时间 - 变更从提交到发布所需要的时间
• 变更失败率 - 发布失败次数在部署中的占比
• 恢复服务的时间 - 从生产故障中恢复需要多长时间

变更的部署频率和变更前置时间可以衡量速度，变更失败率和恢复服务的时间可以衡量稳定性。通过衡量这些价值，并不断进行迭代来改进它们，团队可以取得更好的业务成果。

然后说了一下google cloud的做法。后面跟google cloud提供的服务有关的就不翻译文字了。

指标计算

本节讨论如何将DORA度量标准转换为系统级计算。DORA团队所做的原始研究是对真实的人进行调查，而不是收集系统数据并将指标存储到性能级别中，如下所示：

部署频率

1

一个组织成功地部署到生产环境的百分比。

部署频率是最容易收集的指标，因为它只需要一个表。但是，频率存储也是要计算的棘手元素之一。显示每日部署数量或每周获取平均部署数量将很简单明了，但指标是部署频率，而不是数量。

在“Four Keys”脚本中，当每周至少进行一次成功部署的中位数天数等于或大于三时，“部署频率”将落入“每日”时段。简而言之，要想部署频率值为“每日一次”，则必须在大多数工作日进行部署。同样，如果大多数部署都是一星期一次，则将是每周一次，然后是每月一次，依此类推。

接下来，则需要考虑是基于哪些原因及资源构成了成功的生产部署。您是否包括仅占5％流量的部署？80％？默认情况下，仪表板包括任何成功部署到任何级别的流量。

变更前置时间

1

一次提交进入生产环境所花费的时间。

“变更前置时间”度量标准需要两个重要的数据：何时发生提交和何时进行部署。这意味着对于每个部署，需要维护对应的更改的列表。使用部署表中的更改列表，每次数据的重新加入时同时获取相应的时间戳，用于计算中位数。

变更失败率

1

用于生产环境部署失败的百分比

变更失败率取决于两件事：尝试了多少次部署，多少次导致生产部署失败？

恢复服务的时间

“组织从生产故障中恢复需要多长时间”

要测量恢复服务的时间，您需要知道事件的创建时间和解决时间。还需要知道何时发生故障以及何时部署解决了该故障。与上一个指标类似，此数据可以来自任何故障管理系统。

仪表板

这个就不多说了。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

看到DXCon一篇文章，做个记录

怎么理解数字化转型？

优化是通过把你的服务线上化，减少摩擦，提供更好的服务体验。

那数字化转型真正转的应该是什么？

数字化转型，最终转的是客户价值的创造。

通过数字化智能化的方式，使原来没有办法传递的价值，现在可以传递出去。最终的目的是创造一种模式，不管是商业模式，还是运营模式，使得能够颠覆原来没办法做到的事情，或者是原来很难做到的事情。通过数字化来达成原来不可能达成的价值创造的一种方式，最终的核心应该是要创造价值。

通过数字化来达成原来不可能达成的价值创造的一种方式，就是数字化最终的目的应该是要创造价值。

最后来句废话

我从参加工作开始几乎都是在ToB行业，刚好有两家公司就是干数字化转型的，我一开始的理解不过是从纸质媒介转到网络媒介，从线下到线上，实操经验告诉我，最终看的还是为用户创造了哪些价值，实用为主的客户你跟他扯概念鸟用没有。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

背景

因为最近遇到一个包多版本依赖的问题，遂研究研究npm包管理…

结果发现了这个宝藏**pnpm**

https://zhuanlan.zhihu.com/p/137535779

PNPM

pnpm使用内容可寻址文件系统将磁盘上所有模块目录中的所有文件存储在磁盘上。

使用pnpm，lodash将存储在可寻址内容的存储中，因此：

如果您依赖lodash的不同版本，则仅将不同的文件添加到存储中。 如果lodash有100个文件，而新版本仅对其中一个文件进行了更改，则pnpm update将仅向存储添加1个新文件。

所有文件都保存在磁盘上的单个位置。 安装软件包时，它们的文件从该单个位置链接，不占用额外的磁盘空间。 使用硬链接或ref链接（写时复制）执行链接。

结果，您在磁盘上节省了数GB的空间，并且安装速度大大提高了！ 如果您想了解有关pnpm创建的唯一node_modules结构以及为什么它可以在Node.js生态系统中正常工作的更多详细信息，请阅读这篇小文章：平坦的node_modules不是唯一的方法。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

新产品线跑了一段时间了，这两天团队复盘了一哈，其中谈到了产品和研发沟通问题。

简单记录一下

梳理了这么一个公式

• 我做了xx设计(实现)

  1.xx
  2.xx
  3.xx

• 能达到xx效果

  1.xx
  2.xx
  3.xx

  ---

  point来了，我分割一下

• 它的限制是什么

  1.xx
  2.xx
  3.xx

  导致达不到xx效果
  1.xx
  2.xx

切记

所以说做东西别上来先傲娇吧啦吧啦说一通，报喜不报忧，后面只会任由PO摩擦。

背景

因为团队内部经常会有问题复盘以及技术故事讨论等活动，怎么让这个讨论是有营养且找到根因，保证最终能落到具体的行动项上面。我觉得这是一门很大的学问。

不信你留心观察你参加相关会议或者讨论，你会发现弄了半天问题好像解了又好像没解，过程可能还会伴有撕逼和甩锅…，有句古语说得好：我在旁边坐，锅从天上来。

那咋聊呢

Point 1 描述问题

描述问题，切忌采用下结论的思维和话语，比如：我认为、我觉得…。

我们是为了解问题的，所以你只需要言简意赅的把问题说清楚，这个时候你是一个莫得感情的机器。

怎么言简意赅呢?

站在第三视角陈述：只说现象不说结论，时间、环境、人物、操作过程、发生的现象、造成什么影响…。

如果有必要还可以进行一个动作：过程还原

直接叙述工作过程，有问题的环节或阶段，什么人，做了什么事，当时是怎么考虑的，在这个动作后结果是什么。

Point 2 根因分析

描述之后这个时候可以说说自己的看法了：描述最终定位到的直接原因是什么

有个模板可参考

1.技术根因分析

• 引入环节：

  产品设计是否有问题？

  需求分析是否有问题？

  设计环节是否有问题？

  代码编写是否有问题？

  其他？

• 流出环节：

  各评审环节是否有遗漏？

  是否进行研发自测？

  测试场景、测试用例是否覆盖全？

  是否进行了系统测试？

  其他？

• 确定关键根因是什么：

  如果有多个根因在逻辑层次上相同，则取关键的原因，根因应该是具体的、客观的、在目前组织能力下可被改进的。

2.管理根因分析

• 流程/制度原因：

• 组织因素：

• 执行原因：

  【帮助】流程/制度方面：考虑组织管理上是否有合适的流程、指导书、管理Checklist；

  组织因素方面：考虑人员分配、个人技能、培训、组织环境等原因；

  执行方面：考虑计划、监控、沟通方面的原因。

这个活动一定要有被随便蹂躏的那种奔放和豁达！！！

Point 3 纠正、预防措施

分析完了之后，一定要有落地的行动项。

背景

前前后后经历了几个公司敏捷的做法，有些些感悟，在此表一表。

开始

首先咱们说一下为啥需要敏捷，因为敏捷的业务目标是更早的交付价值以及更灵活的应对变化。我认为这是之所以那么多公司或者团队想要实践敏捷的最大原因之一。

让我知道敏捷的公司，那是在14年我进了一家主打3D数字建模的公司，我的直接领导是公司敏捷的推崇者，当时两个研发团队也是按照敏捷走的，但是敏捷到底是个啥？当时老大给了我一本书让我自己去悟。书名好像是《Scrum敏捷软件开发》。之后大体有了个了解，至少对站会、用户故事、backlog、sprint、SM、PO等词有个概念。

那时候觉得挺新鲜因为在此之前我只知道瀑布模式。在这家公司时我对敏捷印象是最深的，因为我经历了新旧之间的碰撞，不仅是思想上的还有实操上的。因为公司还有个管评审的年长型主管A大，他刚好更偏向于瀑布模式。

正文

chapter 1 ：

先交代一些往事，当时的我，迷茫的一逼，感觉写代码不适合我，我想要转产品，当然我说的产品不是UE性质那种产品哈，我说的是正儿八经的那种产品经理，“那种”指的是：从0到1打造适合用户且用户要买单的那种产品的产品经理。

刚好我的leader就有个类似经历的人，他曾经因为在上海的一个研究所交付的产品令客户不满意，他去呆了3个月，硬生生从0到1重新根据需求设计产品，最终成功交付，当时研究所的人对他的评价是，他比我更懂我得工作。不然为啥他被现在的公司拉去当了副总？你品一品他当时只是一个研发岗。

我虽然面试的是开发岗，刚好当时负责面试的人有事出去了，他刚好遇到了就说先跟他聊一聊，当我告诉他有意向走产品的时候，由于聊的很好，他果断把我留下来当他的助手了。所以我入职是没有经过技术面试的…。

入职的title是产品助理，前期主要干的事就是看书，用Latex写公司宣传文档和摸鱼，后期就让我跟项目，主要是做项目需求。

由于我们的客户多是各种工厂所以通常位置都比较偏僻，想去泡个脚都要摩托转公交再转出租的节奏。

犹记得当时把我一个人丢到工厂的时候，那种无助…工厂里的人通常都比较务实比较直接。被怼的体无完肤到和颜悦色，中间也就是几顿酒的事….故事太多以后写小说再用。

说这些是怎么个意思呢？其实没啥意思，就是说说一些背景，任何事物都是有联系的，你再细品。

chapter 2：

接上，在工厂第一次差不多进一个月，工作内容就是梳理各个环节各个干系人的需求，并整理成文档。

感觉终于告一段落之后，速度赶回北京。然后就是评审，这个时候问题就来了，我老大觉得现有的需求可以开始准备进入研发了，遇到需求问题再澄清就行，但是评审主管就不干了，说你这需求文档需要细化的地方还有挺多，不能进入研发，所以评审没过。会后两位大佬分别拉我谈了一次，一个觉得需求不够完整（瀑布），一个觉得需求已经够了（敏捷）。那为什么双方没有达成一致呢，在我看来当时我老大推崇的敏捷没有玩好，比如A提的一点，研发是敏捷了节奏都挺快，交付周期也缩短了，但是交付结果不太好，老有返工，导致一个项目迟迟不能最终验收，这就是A不赞同的根本原因，因为连客户想要什么都没有完全搞清楚。

对应到敏捷里的内容就是，在检视和调整两块没有足够重视。也就是下面的几个会议没有开好：

1. Sprint 计划会议
2. 每日 Scrum 站会
3. Sprint 评审会议
4. Sprint 回顾会议

我理解以上四个会议就是每个迭代里防止走偏的措施，但最后还是走偏了。

chapter 3：

现公司一进来就是敏捷，但是大多数时间也是走的不顺，有段时间还专门找了教练带着跑了几个月，效果也是一般般。

当时我想了想可能原因有下面几方面：

1. 公司是家传统意义上的软件公司，前面都是瀑布模式，虽然是新产品线但是也有很多老员工，所以不管从公司还是从人来说，这个转变是需要时间且需要强有力的刺激，很明显是时间给够了但是刺激不够。我们都知道有刺激才会有反应。

2. 大家对敏捷的理解参差不齐，很多朋友是随波逐流，且最致命的是这类朋友基本上都认为自己是懂敏捷的，但是真的懂吗，大概率不是的或者只停留在字面上的理解（我其实也是一知半解）。

   敏捷应用其实在我看来是一系列的动作的组合，该套组合需是不断优化且需要组织严格遵守的，组合好之后，把该组合套在软件的开发周期里，然后一遍一遍的重复重复再重复。

   另外很多人的误解是，敏捷就不用写任何文档了，在我看来不是的，必要的文档还是需要的比如设计文档。

前段时间公司大佬给够了刺激，比如重新梳理组织架构、丰富了工具、完善了开发/评审流程（必要的设计文档等）、强制执行双周迭代、双周演示会等等，我的感受是团队的流转效率是有提高的。

小结

我理解的敏捷其实是门大学问，不是只有简单的一些关键词，比如还有“以赋能和信任个人为中心的文化”这类的理念内容，持续学习中。

所以其实我没啥发言权，不过随便说说，也没谁管得着，反正是我自己的博客….。

从我的经历来看，敏捷是个好东西，但是落地也确实不容易，除了敏捷本身就代表一种变革（动作大）以外，它本身也涉及到很多关于人的因素，比如人的思维、习惯、团队文化等，但是如果因为对敏捷应用的不成功，就觉得敏捷不好用，并怀疑它的价值，不可取哈。

另外敏捷只是解决问题的一种方式，也不要把它捧得太高。

任何方法或者工具都有它所适用的上下文。

我认为敏捷是解决问题的一种方式，技术越来越多成为变现的一种手段。那当然你会问谁先行呢？思维观念要变，同时也需要给搭配上不同的手段，谁先谁后并不是主要矛盾。— DXcon

敏捷的价值观

摘自<说透敏捷>

1. 个体和交互胜过过程和工具。
2. 可以工作的软件胜过面面俱到的文档。
3. 客户合作胜过合同谈判。
4. 响应变化胜过遵循计划。
5. 虽然右项有价值，但我们更重视左项。

一个公司或者团队要应用敏捷，不代表要全套接收，有可能只需要敏捷里的某块就可以，不信谣不传谣。

真正的敏捷应该是Be Agile而不是Do Agile。在我们强调/争执xx方法论，xx实践的时候，我们往往在做敏捷，而不是真正的敏捷了。

多说一句

团队，除了学会传统”规划、组织、领导、控制 “的管理方式之外，还需要”激励、授权、支持、交流 “，这实际上意味着，领导者(特别是CEO)把资源分配采取分布式，而不是集中制(集中在自己手里)。这对团队/组织/公司，在应对复杂、即时、阶层式问题时的灵活度、适应度增加很多。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。