🔥架构之路 – 颗粒度是团队和谐的核心(互联网黑话、用户故事)

前言

大家好,我是大S 。

熟悉的朋友一定都知道,我算是一个相当务实的作者。一般来讲,我的文章都会针对某一个细节展开,讲清、讲透。
同时,我在某一个时间段里,都特别讨厌务虚,讨厌老领导之前每天挂在嘴边的 颗粒度、MECE原则、紧急重要四象限、MVP 原则

但随着在行业里的时间越来越长,开始慢慢理解这些我们所讨厌的 互联网黑话 的意义。同时也感觉到,在开发领域真正具有宏观思维的人真是少之又少。

因此,这篇文章并不是一篇 “务实” 的文章,整篇文章遵循发散的逻辑,聊一聊 颗粒度 对开发的重要性。

务虚也是另一种抽象的务实。

互联网黑话

不懂互联网黑话的人在学会互联网黑话之前是理解不了互联网黑话的意义是什么的,所以互联网黑话的出圈同时也代表着互联网黑话势必要受到大众的批判。

我尝试简单解释一下。

最简单的互联网黑话:Silder、tooltip、bannar。
再难一些的互联网黑话:熵增、图灵完备。
更难的互联网黑话:颗粒度、MECE原则、MVP原则、PDCA。

这些开发中的常用词,如果你在这个语境中,那么这个词一说出来你基本就明白它的含义。
但你不在这个语境中,它一说出来你可能会感觉:这个人是不是在装杯?

很多人讲互联网黑话,尤其是大厂出来的员工,会遇到一个问题: 大家好像不明白我在讲什么

在我看来,这就是大厂员工的问题。尤其是一毕业就进大厂的员工。他们很难讲清楚自己说的黑话到底是什么,同时也不能理解你为什么听不懂他讲话。

建议小公司在招聘时,避免招一毕业就在大厂的员工,这不是能力问题。这是因为他们没有做过脱离这个语境的工作,进而导致公司原本的员工与大厂员工的冲突。

如果公司整体团队(或 CEO)是大厂毕业的除外。

颗粒度

在我看来,一个颗粒度是一个开发团队的魂。但好像并没有团队在乎这些,很多团队面试只会问八股文、问项目难点、问底层原理、看算法能力。实际这些远远没有 颗粒度、语境 等能力来的重要。

其他暂且不聊,下面简单聊聊颗粒度及颗粒度对团队的影响。

项目难点每个团队需要也仅需要一个大神,技术大神多了一定会打架。除非你们团队开发的是一个极其复杂的系统。
好的架构应该将代码质量的影响隔离开,如果这点都做不到,那么架构师存在的意义便不存在了。

什么是颗粒度

颗粒度简单的讲,就是一个东西的划分的程度。但这句话没有人能理解,它太笼统了。这也正是颗粒度理解容易使用难的原因。大多数了解颗粒度的人,都是从一次次的任务被打回、拆解 的轮回中理解的,因此它们也不知道如何将颗粒度讲给别人听。

因此,了解颗粒度的最好方法是通过一个个的小例子来感受颗粒度的作用。

一个小例子来了解颗粒度:

  • 一个旅游城市
  • 一个景点
  • 一个沙滩
  • 一个沙丘
  • 一粒沙子

颗粒度的好坏并不跟绝对的粒度呈正相关。

拿上面的例子举例:

  • 对一个国家来讲,颗粒度最好是 一个旅游城市
  • 对一个市长来讲,颗粒度最好是 一个景点
  • 对一个泳裤批发商来讲,颗粒度最好是 一个沙滩
  • 对一个游客来讲,颗粒度最好是 一个沙丘
  • 对一个哲学家来讲,颗粒度最好是 一粒沙子

颗粒度与用户故事

颗粒度和用户故事其实算是孪生父子,伴随敏捷开发而生。因此,我们带着用户故事看一下颗粒度。

用户故事(User Story)是敏捷软件开发中的一个术语,它是一种简洁的、非技术性的语言描述,用来表达软件用户的需求。用户故事帮助团队集中关注用户的经验和需求,而不是过于关注技术细节或系统的内部构造。

一个用户故事通常包括三个基本元素:

  1. 角色:使用软件的人或系统。
  2. 需求:角色想要完成的任务或实现的目标。
  3. 价值:这个需求完成后,角色能够获得的好处。

这里不单独讲用户故事了,大家感兴趣我会单开一篇。

我这里给大家几个用户故事感受一下:

  • 作为顾客,我希望在网络上看到 xx 公司的官网,以便于我了解 xx 公司
  • 作为顾客,我希望在 xx 公司官网上看到 xx 页面,以便于我使用 xx 功能
  • 作为顾客,我希望在 xx 公司官网上看到 xx 公司的联系方式,以便于我联系你们

上面这三个需求是很明确的,颗粒度也说不上好坏,但是我们作为开发者,接收到这样的需求,一定是一脸懵逼🤯🤯。这就是需求的颗粒度不适合我们。

因此,我们才需要产品经理帮我们进行第一次转化:

  • 作为产品,我希望新增一个公司官网,公司官网包括 xx/xx/xx 页面,以便于用户了解我们公司
  • 作为产品,我希望新增一个产品详情页,页面包括 xx/xx ,以便于用户了解我司产品
  • 作为产品,我希望在联系我们页面新增客服联系方式,以便于用户联系我司

到这一步,需求便初见雏形,但这个需求还不满足开发需求,因此需要我们自己将它们拆成对应的任务:

  • 作为开发,我希望根据 UI 图开发 xx 页面,以便于用户了解我们公司
  • 作为开发,我希望根据 UI 图新增产品详情页,以便于用户了解我司产品
  • 作为开发,我希望在联系我们页面页脚,添加客服联系方式,以便于用户联系我司

到这一步,便能感觉到,这些需求我们拿来就能进行开发了。

但不同公司对于颗粒度的拆分方式不同,这种认知的转变才是最折磨人的。

颗粒度对团队的影响

对于习惯不同颗粒度的人,在同一个团队中,一定是痛苦的。

如果你是一个 大厂员工 ,跳槽到了一个初创企业。入职第二天,公司扔给你一个 vscode 。告诉你,我们公司想仿照这个做一个编译器,你预估一下时间开始做吧。

我想你一定是崩溃的,一定会觉得,这个公司领导不长脑子吗?这怎么做?咋评估?
但很多初创公司员工就是这么干的,一边做一边对,一边对一边改,再做。

这就是 颗粒度不协调 的结果。

再举一个例子:

如果你是一个 初创公司的员工 ,面试进了大厂。进来之后扔给你20个任务,让你看看,排排优先级。每个任务要对应写描述,中间遇到问题要记录,每个任务对应一次 git 提交,git 提交要和任务链接绑定。一天至少完成并提交两个任务。

我想你一定也是崩溃的,一定会觉得,大厂是不是都是弱智?老子的时间都浪费在跟你做这些没用的事儿上了。

这也是 颗粒度不协调 的结果。

总结

接下来我会出一个互联网黑话的合集,讲讲互联网黑话到底都说了什么,以及这些对我们开发的帮助。

文章讲的比较发散,大家有不懂的可以评论区问一下。整体主要讲颗粒度是什么以及对团队的影响。同时也提醒各位组建团队及面试的时候,记着考虑颗粒度的协调度,以便于我们更好的完成开发任务。

我的颗粒度:
任务最小完成时长不小于两小时,最大完成时长不超过两天。

大家动动小手,点赞、收藏、评论~

原文链接:https://juejin.cn/post/7345105816242159655 作者:sincenir

(0)
上一篇 2024年3月12日 上午10:27
下一篇 2024年3月12日 上午10:38

相关推荐

发表回复

登录后才能评论