【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

节奏大师:敏捷团队中的需求分析岗

  • 2019-06-22
  • 本文字数:5920 字

    阅读完需:约 19 分钟

节奏大师:敏捷团队中的需求分析岗

良好运作的团队都是相似的,而问题团队则各有各的问题。


如果你走进任何一个流畅运转的敏捷团队,你会发现人们做的事情都很简单,端到端的交付能力,清晰的验收条件,明确的优先级,充足但是不会让人焦虑的 backlog,甚至还有友善的、喜欢开玩笑的团队成员。他们会从简单的事情入手,逐步的加强其功能,在过程中还会伴随着重构,甚至部分重写的发生,不过人们有充分的信心,代码的质量也由于一直在维护的大量测试保证。


如果你问这个敏捷团队里任何一个人这样一个问题:“你觉得敏捷的核心理念是什么?”,你会惊讶于答案的种类之多。有人认为各种工程实践比如结对编程,TDD,持续集成等至为关键;另一些人则认为迭代会议,故事墙,尽量频繁的 showcase 是重中之重;还有人会更抽象的将敏捷的核心描述为拥抱变化,响应变更等。这些回答当然都没有错,每个人在实施过程中,都自然会形成自己对敏捷实践的理解和看法。而在我眼中,敏捷的核心可以归纳成四个字:“渐进增强”。

渐进增强

这里的“渐进增强”可以理解为:先让一部分需求高优先级,而且想清楚了的需求先做起来,在做的过程中让团队建立起自己的节奏和工作文化,最后带动其他需求也被按部就班的完成,最终实现共同富裕……。而这篇文章要讨论的正是:如何让渐进增强在团队里变为可能?特别是在很多项目的各种范围都是固定的前提下。


要让这样的渐进增强变为可能,你事实上需要预先付出一些额外努力的,比如:


  • 需求拆分

  • 正确使用 INVEST 原则

  • 过程可视化

  • 文化建设


这些额外的努力事实上都需要团队里的 BA 作为主力来驱动的。就像田忌赛马一样,不同的拆分方法需求的释放方式可能带来截然相反的结果。不过在进入如何实现的细节之前,我们先来看看节奏在任何一个团队中的重要作用。

反馈,节奏与心流

1975 年,心理学家米哈里·齐克森米哈里(Mihaly Csikszentmihalyi)正式将心流概念化并通过科学的方式来研究。


心流(英语:Flow),也有别名以化境(Zone)表示,亦有人翻译为神驰状态,定义是一种将个人精神力完全投注在某种活动上的感觉;心流产生时同时会有高度的兴奋及充实感。


我在《反馈拯救世界》中讨论过反馈机制和心流(Flow)之间的关系。它是一种奇妙而值得追求的境界,或者心理状态,也是知识工作者所一直追求的状态。在这样顺畅的状态下工作,不但个人会获得空前的满足感,而且团队从客观上来看,会更加的高效,成员会更加的团结,不论你将什么样的需求交给他们,他们总是会顺利的将其完成。


要进入理想的,忘我的心流状态,齐克森米哈里提到至少需要满足这三点:


  • 有清晰的目标

  • 有明确且事实的反馈

  • 能力和挑战的平衡(都处于比较高的状态)



既然节奏的建立如此关键,而 BA 又是建立这种机制的关键,那么如何在实际中实施呢?我们从一个典型的场景来入手

需求拆分

在我看来,通过传统的工具比如INVEST(+SMART)对需求进行合理的拆分,就已经可以在很大程度上确保在团队正确的道路上行进了。当然,前提是你选对了正确的工具,并且完成了正确的拆分。这里面其实包含了两个问题:


  • 怎样就算把 INVEST 做对了?

  • 按照教科书般的 INVEST 划分之后不工作怎么办?


对于INVEST的正确使用,包括诸如用户故事多大比较合适,常见的拆分模式如工作流,业务规则变种等相关的文章,已经可以算是前人之述备矣,此处不再赘述。在这里我只关注第二个问题:即,在你已经可以熟练运用INVEST拆分比较复杂需求,并且在大部分场景下都可以采用合适的模式,但是这种拆分和开发团队的能力结构又不很契合的场景。

前后端分离

有时候你会发现,你从书上读来的敏捷实践在你的团队里不工作。比如需求要纵向的、端到端的划分。然而实际运作中,在实际进入开发阶段之前,很可能最终的视觉设计已经基本定稿,甚至一些典型页面已经向客户(如果是产品的话,此处替换为产品经理)汇报过了。而且很多时候客户只关注最后结果,过程中的半成品性质的汇报往往只是走过场,最终的验收客户往往会产生新的想法,但是为时已晚。


在这种范围相对固定的场景下,似乎用前后端分离的拆分方式似乎可以更快完成任务,也更合乎直觉,毕竟有专门的UI Dev可以很轻松的将高保真转换为HTML/CSS/JS。而那些关注性能,关注高并发/高可靠的后端开发者似乎也没有必要参与其中。事实上,我见过的很多项目正是这样运作的,而且看起来这种分法在工作内容相对固定的项目中也是可以工作的。


当然,这种划分存在一些无法回避的问题:


  • 前端为了不被阻塞,会开发一套 mock

  • 后端需要一个机制来确保实现之后通知前端以保持一致

  • 需要额外的测试来保证集成的正确性

  • 集成会被延后

  • 需求无法端到端交付(必须至少等到最晚的一端完全实现)


如果操作不当,很容易出现前端做完在等后端,或者后端等前端的现象。由于变更的不透明性,又很容易产生相互指责,内部消耗。即使我们有着精湛的工程技巧,比如通过 mock 后端,契约测试等手段可以使得过程不至于太痛苦,但是在开发过程中,由于迟迟不能集成并做实际演示对于客户和开发团队来说,都会显得难以放心。

端到端交付

另一方面,如果你考虑实施端到端的拆分和交付方式,完整的交付一个功能点。不过这种方式的一个重要的 blocker 是团队成员能力的不均衡分配(也可能是团队成员的兴趣所在),而且这一矛盾随着前后端的不断精细化变得更加明显。在端到端的划分中,我们往往需要开发同时具备前后端开发的能力,退一步讲也应该具有与前/后端同事结对完成特性的能力。


此外,这种划分方式则需要面对另外一些问题:


  • 各有专长的前后端开发如何合作

  • 单个用户故事交付时间可能过长

  • 开发人员能力磨合/提升需要时间


乍看起来,这两种做法看似互相矛盾,无法调和。甚至在很多情况下,如果从客观的结果上来看,两种做法可能产生的物理结果是一样的:都按时的,按质量的完成了需求。不过,我觉得前后端分离的拆分方法中忽略了一个重要的点:开发体验。就我自己而言,我痛恨那种上不着天,下不着地的开发体验:你负责的永远是系统的中间一环,你有依赖的上游,也有依赖你的下游,每个功能都永远无法真正知道有没有人用,会不会给人们带来价值。因此在项目中,我尽量会尝试端到端的贯穿一个需求,最好可以从界面到数据库表。


我觉得即使在极端的场景下,也应该采用端到端拆分和交付的方式来工作。首先,团队不再以技术为分界线来看待用户故事,而是以功能(或者说业务价值)来划分。毕竟,不管是 Fixbid 还是人天的项目,客户都是以功能收费的嘛。一个功能可能在实施的时候需要不同的技术细节来支撑,但是功能本身应该被作为原子级别的需求,而不是物理上前后端的割裂。其次,如果从项目交付的另一个成果:人员的能力提升来看,端到端交付方式的问题就反而会变成优势。在一个项目结束之后,前端掌握了一些后端语言/工具的使用,甚至 Cloud 的维护;而后端则从前端了解到 JavaScript 中的测试框架,组件化等知识。


此外,你事实上只需要做很小的调整,就可以让团队获得很好的开发体验。即使项目范围在一开始就基本固定,即使关键页面的设计稿都已经经过汇报。仅仅做好符合 INVEST 原则的将需求拆分就可以很大程度上帮助团队形成高效的,顺畅而稳定的交付节奏。

INVEST 原则

INVEST是渐进增强的基础,没有合适粒度、相互独立的用户故事划分,要进行迭代式的渐进增强就成了空中楼阁。事实上,这个基本功需要在很多层次去刻意练习。INVEST 事实上在敏捷实践中影响深远:过小的划分会引入更高的管理成本,而过大的划分则可能导致优先级难以界定,而且很容易影响士气:没有人愿意看到在墙上挂一周的卡。


和现实世界中的很多事情一样,对于一名 BA 来说,划分出合理大小的用户故事需要很多方面的平衡,有时候简直是一门艺术。我们可以通过一个简单的例子来稍作解释

个人主页

比如,我们要实现Jigsaw的个人主页,页面有很多个部分组成:导航,提示信息,项目历史清单,用户 Profile 入口等等:



假设我们的第一个用户故事:显示提示信息 Heading(如下图红框圈定部分所示)。



这个用户故事需要从后台读取数据,并展现在客户端。数据可以从后端数据库中读取,也可以从后台文件中读取,这个取决于后台数据存储的技术有没有选定。作为第一个用户故事,它可能还会关联一个技术卡:搭建前后端的基础代码,比如用create-react-app创建一个前端工程,用 gradle 创建一个后端工程之类。要不要独立成一个单独的卡可能取决于团队的能力结构。


作为一个有业务价值的用户故事,这个需求需要满足:


  • 端到端实现(即,连通从页面到数据库)

  • UI 和 Mockup 基本一致


另一个好处是它要求开发者在做的过程中建立基本的反馈机制,比如 TDD、结对编程/Code Review Session等细节,并体验Kick OffDesk Check等实践在团队里是如何工作的等等。换句话说,就是尝试从一个简单、实际的需求入手,建立一个可以运作的反馈机制。一旦熟悉了如何做一个用户故事,那么进一步稍微复杂的用户故事(还记得吗?控制节奏)就会相对顺畅很多。毕竟一回生二回熟嘛。

异常处理

一些可能的后续的、针对上一个用户故事的增强版本可能是:


  • 当用户名不存在时,显示错误消息

  • 日期不存在时,做一些 fallback 等


由于有第一个用户故事的存在,团队的节奏会比上一个更娴熟,加上合适的粒度(半天到一天),开发可以清楚的看到一个很有成就感的组件从无到有的产生,从而产生足够的信心和动力去拉动第二张卡。

更进一步

即使对于复杂的用户故事来说,也可以通过渐进增强的方式来拆分,并分别验收。在验收基本版本时,可以假设最终版中的设计不存在,并分别验收。



上面的例子中,红框部分的内容来自于另一个服务器,或者说团队需要和其他的产品集成,因此需要不同的交付节奏。另一方面,其优先级并没有最终定下来,如果将整个 section 作为一个验收单元,则会影响整个产品的开发进度。一个合理的方式是假设其不存在(out of 范围),然后对其他部分进行估点、开发和测试。


换句话说,BA 应该在即使有高保真的前提下,仍然按照业务价值、优先级和其他限制条件(比如集成成本)的因素来划分用户故事,而不是物理的、机械的从界面出发,一个页面一个页面的切分。那样,业务价值固然难以贯穿,团队也难以产生流畅的节奏感。


从微观的角度来看,一个个的粒度始终,端到端交付,有业务价值的用户故事已经满足产生心流的可能性。而从宏观的角度来看,BA 可以通过一些实践,让团队看到明确的目标,并确保团队正在不断的向着目标前进。毫无疑问,各式各样的可视化工具可以很大程度上确保其能够发生。

可视化

之前有一种提法:敏捷开发中的可视化是在利用人的羞耻心,比如你早上站会的时候,发现卡在墙上三四天没动静了,自然会 shame。我认为这种思路比较浅层次。敏捷本身应该是在一个高度信任的环境中的实践,人们应该感到的是:这个卡是不是有什么 blocker?比如我们没有预料到的难点,或者划分的方式不对?并在识别出这些点之后全力以赴的解决它。



在项目进行的过程中,有很多需要可视化的元素。从物理卡墙/电子墙到迭代报告,从燃尽图到 RAID 等,这些工具可以将团队正在进行的工作一目了然的展示出来,又可以帮助团队对要实现的目标,和目标之间的 gap,甚至如何到达这个目标的路径都清晰的呈现。


在项目进行过程中,开发很容易迷失在众多的技术细节中,往往会不记得身在何处。一份清晰的迭代报告就可以很清晰的让团队看到迭代中的 achievement:Sign Off 的需求数量,人天消耗,Cycle Time,重要的业务价值等等。(在 TW 事实上一直有一种不太重视文档,甚至不喜欢统计数字的传统,甚至可以说是“陋习”,不过这个主题可以单独找时间写一篇文章来讨论)我发现花费一些时间来生成这样一份报告可以给团队成员 — 包括内部开发和客户 stakeholder —— 一个很好阶段性总结,让人们明确的知道,我们走到哪里了,离目的地还有多远?

文化建设

在曾经的一个咨询项目上,我帮助客户团队建设需求拆分的能力。有一次在讲到INVEST原则的时候,团队里有个开发弱弱的问我:其他的我都可以明白,这里的可协商(Negotiable)是什么意思呢?


这个客户的企业文化是:业务方已经分析完成的需求不接受挑战,只能服从,开发计划都是按照 deadline 来倒排(这是传统制造业的典型做法,我们也知道在软件产业这种方式从来就不工作)。也就是说,开发并没有议价能力,在无需开发者参与的情况下,由某些人达成一致后的 deadline 却要由实施的开发者来承担。


显然,每个团队都需要团队文化,团队的文化会决定团队做事情的方式,也做事情的方式又反过来塑造团队中的人,从而影响团队文化。幸运的是,对于我们的大多数团队来说,团队文化无需、也无法通过外部强加而产生。一次简单的类似 Retro 的头脑风暴就可以充分发掘和高亮出团队成员的价值观、期望形成的文化氛围。下图是我们最近一次团队价值观 Session 中收集到的点:



文化的一个神奇之处就在于你可以将几乎任何东西放进去(而且每个人都觉得自己放进去的东西才最重要)。不过这里我想特别强调这么几点有关形成流畅交付节奏的点:


  • 将失败看成学习的过程

  • 使用度量来发现理想和现实的差距

  • 通畅的反馈机制

  • 职业化(请参见《你要专业》


流动的,不断调整优先级的,微小而具体的 Achievement 就是孵化这些文化元素最理想的工具。人们其实不在乎你口头宣称的诸多价值,但是他们会在乎你实际是如何行动的。为每个用户故事设置潜在的固定的 deadline,显然已经包含了“不能失败,不能出错”隐含条件。而清晰定义的用户故事,明确的验收条件,[范围外]中的注释,用户故事的 DoD 等等则切实展示着如何度量、如何发现期望和现实的差距。而说到反馈,敏捷中的哪一个实践又不是在不断强调反馈呢?

小结

团队里的 BA 是事实上控制团队节奏的大师,TA 往往起着承上启下,联通内外的重要作用。对交付团队内部,TA 需要把握需求的拆分粒度,细心的构建快速反馈机制,以期团队产生流畅的配合。对需求方来讲,需要紧密配合,促进多项活动的产生:比如将 blocker 可视化出来,并驱动依赖项的消除,分析实际的需求,并根据业务价值进行优先级排定,然后源源不断的为交付团队产生可交付单元


即使对于范围相对固定的项目,BA 仍然可以通过精巧的运用 INVEST 来拆分出合适粒度、方便团队形成顺畅运转的用户故事流。另一方面,通过在项目过程中使用各种可视化工具,可以方便反馈机制的形成。在实施过程中,BA 通过实际的行动,比如更强调从失败中学习而不是计划然后实施,强调小步前进、渐进增强而不是面面俱到,明确的定义出需求的验收条件,DoD,并实时的将潜在的阻碍呈现出来。最终可以使得项目在相对安全的环境中,透明,有序而顺畅的运转。

作者简介

邱俊涛,ThoughtWorks 咨询师,著有《JavaScript 核心概念及实践》,《轻量级 Web 应用开发》等技术书籍。


本文转载自 ThoughtWorks 洞见


原文链接


https://insights.thoughtworks.cn/ba/


2019-06-22 08:004930
用户头像

发布了 98 篇内容, 共 31.3 次阅读, 收获喜欢 249 次。

关注

评论

发布
暂无评论
发现更多内容

领域知识图谱-中式菜谱知识图谱:实现知识图谱可视化和知识库智能问答系统(KBQA)

汀丶人工智能

人工智能 深度学习 nlp 知识图谱 智能问答

春分将至,发版当时:StoneDB-5.7-v1.0.3版本正式发布!优化主备能力,提高主从同步性能,众多细节优化,快来体验~

StoneDB

版本更新 StoneDB

低代码平台之流程自动化测试

鲸品堂

低代码 企业号 7 月 PK 榜

国家电投江西公司与特斯联设立合资公司 发掘资本在新能源行业的潜在投资机遇

TE智库

Gluten + Celeborn: 让 Native Spark 拥抱 Cloud Native

阿里云大数据AI技术

后端 企业号 7 月 PK 榜 Push Shuffle

面向大模型的存储加速方案设计和实践

Baidu AICLOUD

数据湖 大模型 并行文件系统 缓存加速

OWASP 定义的大模型应用最常见的10个关键安全问题

华为云PaaS服务小智

云计算 华为云 代码检查 华为开发者大会

API全场景零码测试机器人——ATGen带来“超自动化”测试模式

华为云PaaS服务小智

云计算 华为云 华为开发者大会2023

StoneDB 开源社区月刊 | 202303期

StoneDB

MySQL 数据库 StoneDB

2023-07-10:Kafka如何做到消息不丢失?

福大大架构师每日一题

福大大架构师每日一题

MySQL生态的下一代HTAP数据库创新与实践 | StoneDB邀您参加第12届数据技术嘉年华(2023 DTC)

StoneDB

MySQL 数据库 StoneDB

消除企业信息孤岛的低代码开发平台

力软低代码开发平台

率先布局 RWA 赛道,PoseiSwap 成为最具先进性的 DEX

威廉META

【HDC.Cloud 2023】华为云区块链分论坛内容值得再读!

华为云PaaS服务小智

云计算 软件开发 华为云 华为开发者大会2023

从零开始的知识图谱生活,构建一个百科知识图谱,完成基于Deepdive的知识抽取、基于ES的简单语义搜索、基于 REfO 的简单KBQA

汀丶人工智能

人工智能 自然语言处理 深度学习 知识图谱 智能搜索

数字税务时代的革新利器:低代码开发平台助力税务办公数字化大步迈进!

快乐非自愿限量之名

人工智能 低代码 数智化 税务云

六月更新 | MeetingOps:让有效协作与高效会议共同发生在云端

CODING DevOps

率先布局 RWA 赛道,PoseiSwap 成为最具先进性的 DEX

鳄鱼视界

率先布局 RWA 赛道,PoseiSwap 成为最具先进性的 DEX

BlockChain先知

软件测试/测试开发丨Windows系统chromedriver安装与环境变量配置

测试人

软件测试 windows 环境变量 测试开发 chromedriver

超级App快速开发的一种创新模式

FinFish

小程序 小程序生态 超级app 小程序化

Region Failover在GreptimeDB 集群中的实现

Greptime 格睿科技

时序数据库 云原生数据库 failover region datanode

活动回顾 | StoneDB亮相2023数据技术嘉年华:增强AP、升级TP、信创替换,让万千DBA用得更省心,企业用得更省钱

StoneDB

数据技术 StoneDB 数据技术嘉年华

什么是CI/CD?让你的项目变得更加敏捷!

这我可不懂

CI/CD Github Action

华为云“All in ”大模型:革命性助推!华为盘古3.0点燃人工智能巨星之梦

EquatorCoco

华为云 盘古大模型 大模型 数智化

数智浪潮!低代码开发平台扬帆迈向智慧诊疗领域新纪元!

不在线第一只蜗牛

人工智能 低代码 数智化 医疗健康

MySQL:我的从库竟是我自己!?

爱可生开源社区

神州数码:我们和阿里云是市场和技术的共同体

新云力量

云计算 阿里云 神州数码

Last Week in Milvus

Zilliz

云服务 非结构化数据 Milvus Zilliz zillizcloud

OpenTiny 前端组件库正式开源啦!面向未来,为开发者而生

OpenTiny社区

开源 前端 UI组件库

低代码平台实用吗?有哪些大型企业在用低代码?

优秀

低代码

节奏大师:敏捷团队中的需求分析岗_文化 & 方法_张凯峰_InfoQ精选文章