it-swarm.cn

处理不良/不完整/不清楚的规格?

我正在一个项目中,我们的开发团队从公司的业务部门获取规范。业务管理和IT管理都需要估计值和截止日期预测。

好处是,估算值大部分由实际的开发人员完成,这些开发人员可以执行所需的功能。不好的是,规范通常太简单(事实证明您遗漏了很多问号,因为似乎缺少很多信息)或过于复杂(直到您可以甚至无法想象一切都将“适合”应用程序的位置)。通常,规范的业务部分要么不完整,要么不知道可以做什么和不能做什么(考虑到先前实现的业务逻辑)。

每个新规范都会给开发团队大约一天的时间进行估算,我们通常会与任何制定规范的人会面,以消除不确定性。大多数时候,事实证明规范编写者并没有真正考虑到所有问题,通常只有在我们开始设计和开发时,我们才会陷入困境,因为很多规范似乎都有漏洞。

您如何处理?您是否愿意提前估计?

44
eagerMoose

如果在设计阶段发现问题,您真的有问题吗?

确保创建规范的人不会觉得自己必须做所有事情。他们无法思考所有事情,我们也无法。他们还需要知道,他们不能只对某个规范文档进行通宵的工作,然后再完成该项目。这种做法还导致他们添加他们可能想到的每件事,因为他们“可能”需要它,如果现在不提出要求,他们将永远得到它。他们必须一遍又一遍地审查,测试和批准其需求。

不要尝试一次设计或构建整个应用程序。任何项目/应用程序都可以分为某些阶段,部分,模块或任何他们想调用的项目。如果那不是您的事,那么您不必敏捷。从“用户安全性”部分开始,然后从那里开始。

花时间与这些人坐下来,找出他们真正想要的。我希望有人能给我一些规格,使我能够一次创建整个项目,但接下来的一年半我将做什么?

13
JeffO

我使用 不确定性锥 用洪亮的声音说

基本上,您会做出最好的估计,从而可以提供所拥有的信息。
但是您也要指出,鉴于规范中的含糊不清,这些估算存在很大的不确定性(现场的积分管理,以便他们可以阅读该原理)。

当您朝着目标前进并收紧规格时,可以更新估算值并收紧不确定性。

20
Martin York

是的,我很慷慨。别忘了 霍夫施塔特定律

霍夫施塔特定律:即使您考虑霍夫施塔特定律,也总是比您期望的更长。出自哥德尔,埃舍尔,巴赫:永恒的金色辫子。

9
Brian Carlton

您所描述的过程实际上是很正常的。问题是业务类型倾向于按照“需求阶段”,然后是“设计阶段”等来思考事物。当团队创建产品时,您确实需要一种迭代方法。我发现有效的一些想法是:

  • 为拟议的变更/新应用定义主要目标。这些都是与业务相关的目标,例如“将索赔处理成本降低10%”或“从我们的卫星办公室进行的市场研究,从而使产品更好地满足客户的需求”。它有助于将重点放在真正需求的开放式需求上。
  • 对最初编写的错误要求进行最初的Swag处理(严重荒谬-A ** Guess),但请记录下yo假定实现的条件。这是业务人员(和您的客户)需要改进并考虑这些问题的反馈。他们依靠你。
  • 如果您在一个很长的估计值和一个很短的估计值之间进行选择,请务必做长。要求您工作的人都会感到震惊,这是一件好事。这将迫使你们两个讨论他们真正的追求。

请记住,您的第一个估算值可能不准确。根据对所获得需求的合理解释进行估算,并记录您的假设/解释。由于您发现了漏洞,因此会有更多派生要求。这个是正常的。

6
Berin Loritsch

慷慨的估计听起来不错,但是它可以解决什么问题呢?这不会使规格变得更好,也不会使计划变得更容易。这是说“比X差不了多少”,而不是说“可能是Y”。事实是你不知道。找出你能做的。

如果业务分析师需要尽快让开发人员参与,请告诉他们。书面报告并不是真正的最佳交流方式。如果您可以在初始需求收集方面得到开发人员的帮助,而在开发和测试方面可以得到业务分析师的帮助,那么您的结果将会更好。

我刚刚读过《不确定性锥》;这是好东西,但很容易弄错。管理层可能会看第一张图说:'好吧,我们有业务需求,因此您的估计应根据您的判断准确度为50%。告诉我'。那无济于事。

打车类比:有人问您一辆车要多少钱,并给您一份要求的文件。报纸说,它应该重1200公斤左右,有四个轮子和至少两个门,但也许四个,应该可以容纳四个人,而且良好的头灯确实很重要。颜色应为灰色(但也可以是黑色吗?)。

您可以说$ 25K,如果后来发现他想要一辆全新的Range Rover,您会被搞砸。但这并不能使它更正确,或者说花费10万美元会更有用。他可能只需要二手(抱歉,二手)Prius。如果您没有时间找出哪一个,您将永远不会知道。

3
Jaap

在大多数情况下,事实证明规范编写者并没有真正考虑到所有问题,通常只有在我们开始设计和开发时,我们才会陷入困境,因为许多规范似乎都有漏洞。

使用most是不正确的。

规范编写者不可能通过everything进行思考。期。如果他们想通everything,他们会知道要编写多少行代码以及正确的代码行。

由于规格必须不正确,因此您无能为力。

遇到麻烦了是问题所在。

业务管理和IT管理都需要估计值和截止日期预测。

也许不是。总体估算和截止日期并不是最有用的事情。

因此,敏捷方法的发展。

关键是这个。所有基于规格的估计都必须有错误。他们只是靠运气才对。一半时间,估算值低于估算值,一半时间超过估算值。这是试图用不完整的信息预测未来的逻辑结果。

由于它必须发生,所以当您错了时,您不应该陷入麻烦。你一定是错的。而且您必须始终如一且随机地犯错。否则,您会混淆数字。

2
S.Lott

您应该向管理层说明,模糊的规格说明对估算的信心不足。即您估计可能相差30%或40%或50%或您认为的任何变化。因此,如果估计为2天,则实际上是2-3天。
然后创建一个项目发行记录(可以在Wiki或Jira等上)。将所有问题创建为问题,并让企业回答您的问题。只要仍未解决问题,估计就仍然不确定。如果可能的话,请业务分析师来协助进行此操作并提出更好的要求。让您的测试团队查看规范,因为他们必须根据规范创建测试用例。通常,他们的参与可以导致编写更好的规范。每天/每周向管理层报告您有多少未解决的问题。解决的越多,您的估计就越好。始终向管理人员提出指标,因为数字可以使他们客观地思考,也可以使您立足。
还要根据项目的大小,在解决方案设计阶段投入1-4周的时间来解决主要问题(包括需求和技术)。与中小型企业举办许多研讨会,并尝试了解它们,然后解释您的观点以得出结论。只有在理解了主要用例并且您的估计达到大约80%的置信度之后,您才可以开始构建阶段。

1
softveda

至少在一个健康的组织中,沟通通常会有所帮助。

这不是灵丹妙药,但是我试图做的事情(在我们公司中起作用)是说服商人解释问题,而不是立即提出解决方案。因此,我们的功能要求从描述问题或他们想要实现的目标开始。

然后,具有某些领域知识的开发人员会在与业务方面的人员进行咨询的同时,尝试完善解决方案。通常,此过程会产生几种备选解决方案,并提供估计值。

此时要根据成本和解决方案的完善程度来选择一个。您也可以通过这种方式将这种方法卖给他们,让他们在这里有选择权,而不仅仅是很多工作日,选择或放弃。当然,它也需要更多资源,但是如果您在估计和规格方面遇到问题,这是一项值得的投资。

0
biziclop

为什么您会接受不完整,包含冲突需求或不可行的需求规范?我建议您的过程中应包含一种方法,供您评估规格,然后在接受并提供任何估计值之前将其发送回更正。

0
oosterwal

说服力值得在更好的规格上进行投资的管理层/客户。尝试让更多具有领域知识的人参与进来。最后,每个人都将从中受益。

0
FabianB

消除规格。

说服企业为项目尝试敏捷(或至少采用敏捷流程)。

而是写出规格

  • 与业务人员会面以识别功能
  • 与他们合作,确定有用的最小功能集(即使仅用于内部发行)
  • 整理工作
  • 设置工作日期(功能/工作越少,准确估算日期就越容易)。
  • 与企业合作确定工作的优先级,确保他们有能力改变对卡订单的看法,并告诉他们卡件对日期的影响
  • 每个完成的功能都有工作系统来显示它们,并让它们在完成的每一项工作上签字
  • 释放
  • 冲洗
  • 重复

正在显示功能完成。尽早发布并经常发布。要透明且反应迅速。我发现这将导致消除毫无意义的期限。

编辑建筑

领导者谁都应该举行开工会议,与开发人员交流架构的含义。领导者实际上也是应该尽力确保所有需求得到满足的人。

如果您需要在流程中执行其他步骤而不是添加这些步骤,则可以使用一个流程来促进团队完成工作的能力。如果某事不起作用,请对其进行更改。添加到它,从中删除,更改它以满足your需要。如果您需要特别关注安全性,请为其添加步骤。

0
dietbuddha

请记住,每次更改规范以添加新功能或清除问题时,都该重新评估该估计了。考虑到我们被告知的内容,并不是说我们的原始估算很差,但是当提供更多详细信息时,我们不要后悔并说不,我们不需要。如果我是建造房屋的承包商,并且我是根据使用lamiante台面来估算成本的,而一个月后客户想要一块花岗岩,则可以打赌,我会和他一起重新估算成本。我们让客户摆脱低劣的要求,然后当事实证明要做的事情比最初设想的要多得多时,不要退缩。

0
HLGEM