功能点估算案例
在第1部分中 ,我讨论了数量级估计和目标。 在第2部分中 ,我说过如何滥用估计值。 在这一部分中,我将讨论估算何时有用。 这里有几种可能性:
- 我们要解决的问题有多大?
- 这个问题的风险在哪里?
- 我们可以采取一些措施来管理风险并进一步说明我们需要做什么?
当评估有助于人们理解问题的严重性时,评估会很有用。
我以前的实践产品负责人中的一位学生说:“我们使用故事的大小来确定何时向故事中涌动或暴动。” 人们处理的故事最多为5个。(他们使用斐波那契数列来确定故事的大小。)他们可能会配对或蜂拥而至8个开始的故事。即使他们有21个(或更大)的故事,他们也会对其进行蜂拥而至。几天,而不是分开讲故事。
他们使用估计来了解功能的大小和复杂性。 (我将其功能称为“功能集”,但他们喜欢将一件大事称为功能。)
您可能不喜欢这种方法。 我认为这是不与PO争执来拆分故事的好方法。 一起解决问题也很有帮助。 一起工作将知识传播到整个团队中,成为一个团队。
我的估计经验是,我很容易不理解工作的规模。 我们通过一起评估,一起工作或以某种方式与时间限制一起来灵活/精简地解决此问题。
我们第一次解决特定问题时,需要花费更长的时间。 第一次使用控制系统(嵌入式软件)时,我必须学习如何协同工作。 软件在哪里与硬件交互? 这种产品的一般风险是什么? 第一次我自己出版一本书,一切都花了更长的时间。 我需要按什么顺序完成哪些步骤?
我以开发人员的身份从事许多控制系统的工作。 一旦了解了一般风险,我的估计就会更好。 在我应用基于交付的计划的规则之前,它们还不够准确。 我需要交付哪些可交付成果? (即使我每周至少交付一次,即使这是我现在知道的数据是峰值)。创建该交付项我需要多少英寸鹅卵石 ?
我将工作分解为可交付成果的次数越多,估计就越好。 块越小,我的估计就越好。 我越是分解问题,就越了解我要做的事情和所面临的风险。
我喜欢敏捷和精益的一件事是坚持小块价值。 我的块越小,我的估计就越准确。
估算值可以帮助人们了解风险。
您会注意到我在上一节中谈到了很多风险。 存在一般的项目风险,例如推动项目发展的因素是什么? (请参阅“ 管理它!”或“ 预测不可预测” ,或者我几年前写的系列文章《 估计未知》 。)当我们知道推动项目发展的因素时,我们会优化不同的工作。 那就是项目视图。
我们在许多可交付成果中都有潜在的风险。 我们有一般的风险:人们生病,他们需要说话,他们有多重任务。 但是,每个可交付成果都有其自身的风险。
在软件学习,创新之前,我已经说过。 您之前可能已经做过类似该项目的工作,所以您具有领域专业知识。 但是,您可能尚未在此处完成此新操作。
当我估计时,我开始思考我需要做什么,如何解决这个问题。 然后,我开始思考在解决这些问题时可能遇到的问题。
除非我有英寸鹅卵石,否则我无法解决问题。 我是个大人物。 我看到了整个问题,甚至可能看到了整个解决方案,并且跳过了脑海中的某些步骤。 我估计自上而下是一个开始。 除非创建英寸鹅卵石,否则我可能会掩盖一些风险,因为我从上而下开始。
你可能不像我。 您可能会估计自下而上。 您可能会看到所有详细信息。 考虑问题时,您可能不会错过任何解决问题的步骤。 (我想知道像您这样的人:您一开始看到的是大图景,还是为您发展?)
我遇见了一些由内而外估计的人。 他们告诉我他们看到了大局的一部分和小步的一部分。 他们在两个部分上进行迭代,直到看到并可以估计整个过程为止。
我教过许多估算研讨会。 我的大多数参与者都是自上而下的人。 他们看到了想要的结果,然后设想了达到目标的步骤。 我遇到了一些自下而上的人。 我遇到了两个由内而外的人。 我不知道这是正常分布,还是仅是参加我的研讨会的人员。
估算值可以帮助人们了解可能的第一步。
当人们想到可以提供价值的第一件东西,并且考虑如何缩小第一件东西(寸鹅卵石或敏捷故事)时,他们可以更轻松地看到第一个可交付成果。 他们可以讨论可交付的进度(与产品负责人保持敏捷,并与项目经理或产品经理讨论更传统的生命周期)。
我发现对可交付进度的讨论非常有帮助。 许多年前,我是量规检查系统(装配线上的机器视觉)的首席开发人员。 我问客户他想先看什么。 “您能看到足够的量规,以便给我们一些关于它是否是一个好的量规的答案吗?” 是他的答案。
请注意,他说的是“足够”,而不是“完美的检查”。 我们在几天内做了概念验证。 在实验室中,在正确的照明条件下,我们有一种效果很好的算法。 您可能会认为这是一个发现项目。 基于该交付成果,我们获得了该项目其余部分的合同。 如果我没记错的话,我们花了近6个月的时间才交付了最终系统。
对于那个项目,我担任项目经理和现在称为产品所有者的角色。 我们有该项目的发布标准,所以我知道我们的去向。 在展示了我们每两周完成的演示之后,我每两周与客户一起定义可交付成果。 (这是分阶段交付,而不是敏捷。我们每星期进行一次为期一周的时间盒演示,并向客户进行演示。)
这是在我们拥有项目计划软件之前的日子。 我为客户绘制了PERT图,显示了日期范围和预期的可交付成果。
几年前,我曾担任项目经理。 她是甘特王后。 她可以使甘特图做任何事情。 我对她敬畏。
但是,她的项目总是迟到了很多个月。 她将与团队合作。 他们会认为这是一个为期六个月的项目。 她会将任务分别进行了两周,三周和四周的时间,交给了甘特。 那是我了解估算单位的问题的时候。 “如果以周为单位进行测量,那么您将有数周的时间。” 和我一样,她的人民都是自上而下的思想家。 他们掩盖了使产品正常工作所需的一些步骤。
我解释了如何使用黄色便笺纸进行基于交付的计划。 人们可以制定任务并查看他们的交叉点和必须交付的内容。 她和团队意识到他们没有一个为期六个月的项目。 他们有一个至少一年的项目,那就是要求没有变化。
当他们开始考虑估算位时,而不是总估算并应用了忽悠系数,他们意识到必须花更多的时间进行估算,并且估算是有用的。 对于他们来说,估计时间就是探索时间。 (是的,我曾建议他们做些尖刺 。他们不喜欢这个主意。每个项目都有自己的文化。)
您的估算如何为您提供帮助?
也许您的估计会以我未提及的某些特定方式为您提供帮助。 如果是这样,那太好了。
我在使用估算值时遇到的问题是,很难正确估计它们。 看到Pawel Brodzinski的帖子, 估算? 很复杂……在
在预测不可预测中 ,我有一张图表,说明了我的估计如何工作。 请参阅《幂律分布:估计示例》。 (在那本书中,对于如何获得合理的估算以及如果您的估算有误,该怎么办,我也有很多建议。)
在与客户的评估中,随着时间的流逝,我不再购买估算的锥体。 我不能使其适用于敏捷或增量方法。 根据我的经验,我的估计值偏离了数百%,或者我非常接近。 当客户看到第一个可交付成果时,我们发现我付出了多少。 (在Bossavit的软件工程妖精中 ,(或在leanpub上,他说估算的锥度永远是不正确的。)
对我来说,可交付成果是理解估算的关键。 如果通过估算,您了解更多可交付成果,那么估算时间可能会有用。
由于我使用敏捷和精益的方法,因此对我而言,估计时间不一定有用。 获得排名积压的订单,了解我是否对项目有约束并进行交付,这一点更为重要。 当我交付时,我们发现:需求的变化,我们已经做了足够的事情。 我的交付内容包含反馈。 得到的反馈越多,我越能帮助客户了解实际需要什么和不需要什么。 (我经常在需求发生变化的项目中工作。也许您没有。)
我意识到我需要第4部分,专门讨论估计值以及如何决定是否要使用估计值。 足够这篇文章。
翻译自: https://www.javacodegeeks.com/2016/06/case-estimates-part-3.html
功能点估算案例