Scrum敏捷项目管理

为什么不应该以小时或天为单位进行估算

开发人员不喜欢提供实施软件功能的时间估算。另一方面,管理层对项目管理估算有合理的需求。本文介绍了Scrum Agile项目管理框架如何为这种冲突提供解决方案。

作者:SonicAgile的Stephen Walther,  http://SonicAgile.com

不要让我说谎

我一生中花费了大量时间来计划软件产品会议。这些会议的目的是确定产品功能的优先级,并估计实现每个功能所需的时间。通常,这些会议涉及整个软件团队,包括与项目有关的所有开发人员,质量保证(QA)工程师,市场营销人员和文档编制人员。

例如,我一直在计划会议以构建新的Web应用程序。目标可能是构建一个新的电子商务应用程序,其中该应用程序包括购物车,产品目录和产品详细信息页面等功能。

这些会议通常分为两部分。在会议的第一部分中,就不同功能的优先级进行了健康的辩论。会议第一部分的目的是确定必须实现哪些功能以及以什么顺序实现。例如,应该首先实施产品目录还是购物车?到现在为止还挺好。

在会议的第二部分,事情总是开始很糟糕。在会议的第二部分中,团队中的每个人都被要求估计实现这些功能将花费多长时间。我一直在计划会议,团队中的开发人员拒绝回答这个问题。开发人员有时会对提供嘲笑或敌意的时间估计的请求做出响应。

管理层希望获得这些估计,因为管理层希望知道他们需要分配给一个项目多少资源。例如,管理层想知道一个项目将消耗多少开发人员小时,质量保证工程师小时和文档小时。这是一个合理的问题。如果计划中的项目消耗过多的资源,则取决于项目的业务价值,则可能不值得追求该项目。

不幸的是,开发人员几乎从不希望提供时间估计。问题在于,很难估计实现软件功能所需的时间。

编写软件更像是找到治愈癌症的方法,而不是建造砖墙。如果您问我建造砖墙需要多长时间,我可以为您提供一个非常准确的估计。根据经验,我知道在墙上增加一块砖需要一定的时间。添加其他积木将花费大约相同的时间。因此,我可以给您一些准确的预测,说明建造一整面墙需要多长时间。

另一方面,如果您组建一个科学家团队并要求他们估计找到癌症的治疗方法需要花费多长时间,则您将得到非常不准确的估计。问题在于未知数太多了。科学家将无法汇总任何估计,因为他们无法从以前的经验中推论得出。

像寻找癌症的治愈方法一样,编写软件更是一项研究活动。实施软件功能时,我经常花更多的时间在Google搜索上,而不是实际编写代码。通常,在我实际编写代码之前,我不知道是否会有任何效果。

因此,出于充分的理由,软件开发人员经常会对提供沮丧的估算值做出响应。正确的答案通常是“我不知道!”。要求开发人员提供确切的小时数来实施功能,这被解释为要求开发人员躺下并整理东西。

所以你会怎么做?管理层有合理的必要了解项目将消耗多少资源。他们需要估算以确定一个项目是否值得。但是,软件团队的成员有充分的理由不提供时间估算–没有人愿意被迫撒谎。

Scrum是敏捷软件社区所采用的一种项目管理方法。 Scrum提供了三个概念,可以帮助解决这一估计问题:
*使用故事点估算
*在冲刺中工作
*将故事分解为任务

使用故事点估算

在Scrum中,您可以估算使用Story Points而不是数小时或数天来完成某件事所需的工作量。例如,您估计创建购物车将需要特定数量的故事点,而不是估计创建购物车将花费5天。

不同的团队为故事点使用不同的单位。例如,某些团队喜欢使用衬衫尺码,例如小,中,大和X大。其他团队喜欢使用斐波那契系列。我个人喜欢使用“短”,“高”,“大”和“文蒂”等咖啡杯尺寸。例如,创建购物车需要大量的精力,而不需要大量的精力。

开发人员更愿意使用故事点来提供估计,而不是时间。故事点的优点是它们比时间更粗糙。例如,开发人员可能拒绝说明创建购物车所需的确切小时数。但是,开发人员可能愿意说“创建购物车”是Grande工作项目,而不是Venti工作项目。

这样想吧。如果要求您估计创建购物车所需的小时数,那么您很可能会错。另一方面,如果要求您说明“创建购物车”是大型工作项目还是小型工作项目,则您很可能是对的。通过使用故事点,您可以通过逐步评估工作量来消除精度的错觉。

在冲刺中工作

根据Scrum的说法,试图准确估计完成整个软件项目所需的时间几乎总是注定要失败。相反,Scrum团队在Sprint中工作。 Sprint是一个时间间隔,开发团队致力于在其中完成一定数量的工作。

例如,一个开发团队可能需要一周的冲刺。每周,开发团队都会尝试完成一定数量的工作(以故事点数衡量)。团队可能会发现它一次冲刺可以完成50个故事点。

团队可以在Sprint中完成的平均工作量称为团队速度。您可以通过计算团队在前三个或四个Sprint中完成的故事点数的平均值来计算团队速度。

您无需预测预先完成一个项目所需的时间,而是可以对随着项目的进行而完成一个项目所花费的时间越来越准确。在每个Sprint的末尾,您将对团队速度有一个更清晰的了解,并且对团队在未来的Sprint中可以完成多少工作有一个更清晰的了解。

将故事分解为任务

在Scrum中,区分用户故事和任务。用户故事是项目需求的非技术性表达。例如,用户案例可能是“创建购物车”。

在Sprint的开始,开发团队致力于完成一组用户故事。在Sprint的开始但不是之前,Sprint中的用户故事分为任务。

例如,“创建购物车用户故事”可能分为以下四个任务:
*创建Oracle数据库表
*编写MVC控制器动作
*设计购物车的外观
*编写硒测试

与用户故事不同,任务包含实现细节。例如,要完成创建购物车故事,团队可能需要创建某些数据库对象并编写某些质量检查测试。

将故事分解为任务会迫使开发团队更深入地思考故事。在Sprint开始之前,团队可能不了解实现“创建购物车故事”所涉及的所有内容。

在Scrum中,您使用故事点来估计完成用户故事所需的工作量,并使用小时来估计完成任务所需的工作量。因此,您可能会估计“创建购物车用户故事”是一个“大故事”,并提供完成故事所需的每个任务的小时估计。例如,您可能估计需要3个小时才能完成“编写硒测试”任务。

使用小时来估计“任务”而不是“故事”是有两个原因的。首先,任务总是比故事小。一个故事通常需要一定天数。一项任务通常需要花费几个小时。

其次,与故事不同的是,您直到开始从事任务之前,才估计完成任务所需的工作量。在开始执行实现故事的Sprint之前,不要将故事分解为任务,不要估计完成每个任务所需的时间。您的估计很可能是准确的,因为您将要进行这项工作。

管理层呢?

那么,Scrum对管理意味着什么?根据Scrum的说法,准确估算完成复杂软件项目所需的时间注定会失败。您能做的最好的事情就是提高对从Sprint到Sprint的团队速度的估计。

这意味着,在项目开始之前,管理层无法准确估计项目的业务价值。每个Sprint,每个人都会对未来的Sprint中可以完成的工作有一个更清晰的认识。每个Sprint管理层都会对可以从项目中交付的业务价值有一个更清晰的认识。

这似乎令人失望。如果您是经理,那么您可能会无奈地哭泣。您可能确实非常希望估算完成一个项目所需的时间。这种愿望是可以理解的,但是根据Scrum的说法,这种愿望无法满足。

结论

开发人员不愿意提供合理的时间估算。估计完成一个软件功能所需的小时数或天数几乎总是不准确的。要求开发人员提供时间估计会迫使开发人员撒谎,没有人喜欢撒谎。

在Scrum中,您代表使用用户故事的工作,并且您不会尝试使用小时或天来估算完成用户故事所需的工作量。相反,您可以使用故事点进行估算。例如,您可能会估计使用“咖啡杯大小”,并将一个故事估计为短,高,大或通风故事。

此外,在Scrum中,您将完成项目所需的工作分解为Sprints。每个Sprint,您都要完成一定数量的工作,以“故事点”衡量。在每个Sprint结束时,开发团队对他们的团队速度有一个更清晰的了解,并且开发团队可以更准确地预测他们在下一个Sprint中可以完成的工作量。

最后,在Scrum中,开发团队在每个Sprint的开始将用户故事分解为任务。任务(而非用户故事)以小时为单位进行估算。使用小时来估计任务是有意义的,因为任务要短于用户故事,并且直到开发团队准备开始处理任务时才估计任务。

要了解有关使用Scrum进行项目管理的更多信息,建议您阅读我的文章。 5分钟内Scrum.

11评论为什么你不应该在几小时或几天内估算

  1. 因此,这是一个永恒的问题:一个团队可能倾向于高估故事,从而以更少的时间/精力来提高速度。我们如何平衡呢?也许介绍某种“objetive estimator”?

  2. 这往往是自我纠正。也许一个组的速度为50,因为他们估计的速度往往比另一组的正常速度为100的速度低。实际上,两组相似,但是一组在分配的点数上往往较高。当你’重新计算进入下一个冲刺的点数’一组将为50,另一组为100。

  3. “像寻找癌症的治愈方法一样,编写软件更是一项研究活动。”

    这实际上取决于开发人员的经验水平。经过几十年的经验,人们发现大多数编码基本上是相似的。那是你’之前已经编写了接口,规范化的模式,后端的架构,淘汰的算法等。在那时,尽管环境,过程和技术改变了创建,测试和扩展代码的基本工作,’t.

    您可能无法预测分析失败,人格问题或潜在的技术故障,但是一旦将这些问题考虑在内,实施工作实际上仅取决于您是否遇到了故障。‘good’ day or a ‘bad’ 上 e.

    对我来说,我将所有相关技术问题作为原型,并始终认为分析不力,需要进行修订。然后我’我很愿意根据时间范围进行估算。从来没有几小时,但是几天,几周,几个月甚至几年都无法正常工作。

    保罗

  4. “这种愿望是可以理解的,但是根据Scrum的说法,这种愿望无法满足。”

    这就是为什么敏捷的软件开发方法存在根本缺陷的原因。它消除了对开发人员或PM负责的责任,而无需做任何事情。目标球’和迈向他们一样重要,无论他们碰巧发生在这个星期,

  5. @蒂姆–敏捷团队对每个冲刺都做出承诺。开发团队必须承诺在Sprint计划会议期间完成Sprint中的工作。因为团队完全了解自己的承诺,所以他们更有可能兑现这一承诺。

  6. 一开始就吸引整个团队的荣誉。作为一名开发人员,我最讨厌的事情是项目经理选择最高级的开发人员和质量保证人员,然后又无法将问题或愿景传达给整个团队。坦率地说,这对被排除在外的成员是无礼的。

    在这些会议上我的问题通常是’商业价值。一世’m希望有一个财务数字或球场数以千计10,000或100,000s。因此,我很少获得估算值,这很有趣。我们的估计值必须与其他情况进行比较’提出要点。

    我的真实观点是质疑为什么我们要进行估算舞,是否可以设计一个简单的实验来查看某个特征是否’值得。例如,不是实施新产品,而是需要自动化各种当前的手动系统和流程来应对需求。

    如果我们只是简单地在按钮上放置一个实时广告按钮,该产品会记录点击并要求您填写表格或进行销售,那该怎么办?这种想法是从精益创业公司借来的。结果是购买产品的点击次数或购买意向以及与销售联系非常感兴趣的人数。

    可以用美元来衡量需求并证明对该功能进行合理的投资。

  7. 估计是估计。可能是客人。但是,这不是谎言!你不可以撒谎,而你不知道!
    我同意使用基于大小的工作量估算,而不是直接跳入时间单位。
    干杯,
    kk

  8. 从一开始就让团队参与,在调整估计准确性的过程中,将故事分解成详细的任务,有很多好处。但是,无论您如何旋转它,或者给方法论起一个不同的名称,甚至给它一个更漂亮的名称,估计都是一种估计,并且它将始终是计划中的关键要素。如果没有计划,您会怎么做?只是必须这样做,除非您当然生活在一个利益相关者会同意您所说的话而又不承诺日期的世界中。

2引用和引用

  1. 软件开发Linkopedia 2012年9月
  2. 五个博客– 2012年9月18日« 5blogs

评论被关闭。