2019年三月21日星期四09:17

为什么常识对软件开发团队不利?

撰写者

最近,我不得不为我的一个孩子创建一个帐户's school-related matters.

创建帐户后,用于验证电子邮件地址的令牌已发送到我的电子邮件地址。

另一个电子邮件提供商使用旧的POP3协议检索发送到该电子邮件地址的电子邮件。当带有令牌的电子邮件到达时,我单击了链接,发出请求的服务器回答:“提供的令牌不正确或已过期”。

我获得了一个新令牌,但它也已过期,下一个令牌也是如此,依此类推!对于这种特定的POP3场景,允许的响应时间设置得太短,这意味着我被卡在两次单击之间,无法继续。

我最终能够克服这个问题,但是关键是在软件开发和帐户创建功能测试期间,以某种方式忽略了这种特殊情况。开发团队可能会使用常识或“非常稀有,不值得”的说法来避免进行进一步的分析,或者只是没有人考虑过。

在这种情况下,不会产生巨大的后果(只剩下我剩下的几根),但是在不同的情况下,不能从需求,用户故事或功能中得出重要的业务场景可能是非常昂贵的监督。


广告

不只是常识

敏捷从业人员有时将业务分析(BA)的特征描述为“常识”,从而排除了进一步了解功能的重要方面的努力。即客户的实际需求,以及从中提取需求的业务环境。

我们声称效忠于“客户满意度”或“改善产品的用户体验”,但是我们只能做到“常识”吗?如果提出“常识”,业务分析师实际上会非常疲倦,尤其是当它用作跳入“快速解决方案”模式的手段时。

通常,“常识”只会导致解决方案乏善可陈,或者由于缺乏理解而导致开发和/或测试时间增加。模仿敏捷开发团队中使用的“技术债务”一词,我们可以说缺乏真正的业务理解会产生一种“业务债务”,从而可能使一段软件代码不合适。

这就是为什么BA不仅是“问题解决者”,而且更重要的是,它们是“问题理解者”。

大量的BA技能可以用来探索,分析和理解实际需求和业务环境。场景分析,角色,客户旅程图和业务价值条件是我想到的一些流行方法。

正确的心态

工作中的一位同事最近提到,“虽然每个人都可以拍照,但并不是每个人都是摄影师”。他说得很对!

技能和技巧本身不足以理解某些东西。它们是必需的,但它们只是“什么”,而没有“如何”应用它们的感觉。

这突显了业务分析师的重要能力,即“ BA思维定式”。广管局的思维模式有其基础,专注于通过积累的知识和能力来提供业务价值,并可以帮助您确定在特定情况下使用技能的能力。就像专业摄影师一样。

敏捷团队不仅生产软件,而且还必须生产“有价值的”软件,并且“价值”与业务领域有关。如果我们想首先创造价值,就需要探索和理解业务领域。这就是广管局的工作!

敏捷团队中的“分析”任务,无论由谁来执行,都超出常识,这需要业务分析技术以及业务分析师的技能和能力。尽管可以学习这些知识,但为了在敏捷团队中真正建立强大的分析能力,无论职位,职位或在开发团队中的位置如何,最好都是该团队的专门成员。如果不是BA,BA可以指导他们!

©BA Times.com 2020

麦格雷戈徽标白色网站