为什么?如此有力的问题

最近,我正在与一个开发团队一起观看一个情况,那里似乎忘记了一个非常重要的问题……为什么?这让我想到了无数次我无缘无故地看完工作的经历,除了“在心愿单上”,“我们有这张卡片”或“因为客户服务如此说”。

我多次看到功能是在发布结束时创建的,功能的最终用户说:“哦,大约3个月以来我们不需要它了”。这部分要求已久。

这使我回到了瀑布方法论,以及我期望看到的东西。由于采用线性方法进行软件开发周期,几乎可以预料会有这种性质的浪费。这并不是说瀑布永远不适合。如果您的开发周期较长,那么这只是过程的预期部分。

However, using an 敏捷 我 thodology such as Scrum or OpenAgile, this should simply not happen.  Agile methodologies are based on Communication.  This communication is paramount during the Sprint or Cycle but is absolutely mandatory during the planning meeting. A team cannot simply be given a list of instructions to follow.  The team needs to understand what their Goal is.

在Scrum中,产品负责人负责指导团队,根据投资回报率(通常意味着实际需要),下一步应该排队哪些功能。

在OpenAgile中,团队可以采用类似的方式与“最终用户”进行协商,并根据“价值回报”进行工作计划,并进行适当的计划。

尽管在Scrum和OpenAgile中,有关于投资回报率,价值,无错误代码,测试驱动开发等的讨论。关于为什么要做某事的想法通常似乎很少讨论。

用户故事(如果做得正确)可以显着改善此问题,因为“故事”需要有一个使谁受益的目标。我们正在为此“ x”执行此功能以获得此好处。

但是,团队的责任是问“为什么有人要这样做?”或“为什么我们要首先更新此信息”。通常,这些见解非常有启发性。

让我们举一个简单的例子。

在80年代后期,我曾在一家公司担任开发人员,该公司的方法是向开发人员提供“要求”,选择一名开发人员,然后派他们去做工作(在Scrum之前)。

开发人员将修改存储过程以通过一个表,并将表中的每个第3条记录更新为高出50%。这是一个相当复杂的过程,该公司的开发人员花了近一周的时间重新编写该过程并使其得以实施。开发团队与工程师和客户坐下来,开发了一种测试和验证方法,对数据库进行了备份,并开始了实施工作。

没有人问为什么。

几周后,系统的其他部分也提出了类似的要求。我与开发人员一起度过了一段时间,并鼓励他们问为什么要进行第一次修改。答案是“那是雪利酒对我们说的应该做的。客户大喊大叫,这就是我们需要解决的问题。”

那些使用Scrum或OpenAgile的人可能已经在畏缩和思考了。Gees…您可以仅就这一段写一本书。我要再待一天:->

实际的问题是系统的不同部分根据季度结果更新了表格。这是表中每个第3条记录错误的实际原因。该过程不正确,已由系统的其他部分共享。

如果没有人介入,那么修复缺陷副产品的周期可能还要持续几个月。

我说服所有者更改程序,使开发人员可以在团队排队之前提出问题。我只是要求这项简单的权利。

几个月后,应用程序的总错误率下降了,客户投诉下降了,开发团队开始感到投入并参与了该过程。那之后是另一个地方。人们喜欢在那里工作。

在您的Sprint或Cycle计划阶段,请考虑提出以下问题:

-为什么我们将字段大小从80个字符更改为250个字符?
-为什么系统需要一个程序来更新这些类型的记录。.系统不能正确执行吗?
-为什么我们要在没有CVV代码(安全号码)的情况下强制进行信用卡交易?
–为什么我们要建立一个全新的身份验证系统?
–这是如何成为要求的?

这种类型的问题并不旨在成为对抗性的事情!通常,那些要求使用这些功能的人可能会觉得您在对抗。保持冷静,并确保让请求者知道这是您流程的标准部分,而不是他们的能力或知识的问题。目的是获得知识,而不是弄清楚谁是对还是错。

与人员讨论后,您可能会发现他们对他们为何要求功能或更改没有真正的了解。仅仅是从交流中就可以改变想法或做事的想法(这就是您希望它发生的时间,而不是在完成之后)。讨论也可能使产品比他们最初设想的更好。

OpenAgile有一个称为“协商性决策”的术语。这个想法是基于与所有可能对做出决策具有宝贵意见的相关人员的磋商和讨论而做出的决策。

Scrum还将讨论和交流视为发展的基本组成部分。

The FIRST value of the Manifesto for 敏捷 Software Development is “个人与互动 超过流程和工具”

在上面的示例中,我们选择修复正在创建不良数据的存储过程,并编写了一次性脚本来调整损坏的记录。我们再也不必重新考虑这个问题。

听起来很简单,但是WHY的基本前提绝对是此过程的强制性要求,否则所有决策都将基于盲目遵循的指示而没有团队的归属感。

在脸书上分享
Facebook
分享到Twitter
Twitter
在linkedin上分享
LinkedIn

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

最近的帖子

文化,技能和能力//如何成为数据驱动型组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析,以改善数据驱动型决策创新:通过假设测试和学习来测试假设数据平台:获得新见解

Read More »

数据平台//如何成为更具数据驱动力的组织

这是我们关于“如何成为一个由数据驱动的更多组织”系列文章中的第四篇,我们将专注于数据平台。在这一点上,大多数人开始深入研究Data Lakes vs Data Warehouse的技术方面,但是我们想让我们回到一个更高的水平,并要求

Read More »

创新//如何成为更具数据驱动力的组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析以改善以数据为依据的决策制定创新:通过假设检验和学习来检验假设数据平台:获得新

Read More »

搜索博客

敏捷 Management Made Easy!

All About 敏捷

凯利·沃特斯(Kelly Waters)

“’Agile’ is one of the biggest buzzwords of the last decade. 敏捷 methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

凯利·沃特斯

敏捷 101 is available to purchase. GAME ON!

敏捷 101

艾玛·霍普金森火花

“尽管有很多方法可以根据您拥有的团队和想要的学习成果来改变游戏,但是游戏的基本流程是所有人共有的。”
艾玛·霍普金森火花

我们为什么制作游戏?

怎么玩游戏?

伦敦

101种方式Limited
城市路145号
伦敦
EC1V 1AZ
英国

阿姆斯特丹

101种方式BV
Weesperstraat 61-105
1018 VN阿姆斯特丹
荷兰

联系我们

如果您想与101 Ways的团队之一联系,请填写以下表格或给我们发送电子邮件: contact-us@101ways.com.