2014年1月14日星期二09:51

帕累托和你-将小麦与切夫分离

撰写者

我不记得第一次提出帕累托原理的时候。我想可能是我为六西格码绿带学习的时候。但是我不确定。我知道我当时担任质量检查主管,因为我的大多数示例用法都围绕着测试和缺陷。不过,可能已经超过15年了。

话虽这么说,我认为我听不到人们在日常活动中足够“考虑”帕累托,所以我想提起它并提醒所有人帕累托原理或80:20规则及其含义适用于一般的软件工程,尤其是敏捷团队。

基本

1906年,意大利经济学家维尔弗雷多·帕累托(Vilfredo Pareto)创建了一个数学公式来描述该国财富的不平等分配,观察到百分之二十的人民拥有百分之八十的财富。在1940年代后期,Joseph M. Juran博士将80/20规则错误地归因于帕累托,称其为帕累托原理。虽然它可能会被错误命名,但有时被称为帕累托原理或帕累托定律,可以是帮助您有效管理的非常有效的工具。

它来自哪里

帕累托进行观察并创建公式后,许多其他人在各自的专业领域也观察到了类似现象。质量管理先驱约瑟夫·朱兰(Joseph Juran)博士在1930年代和40年代在美国工作,他认识到一个普遍的原则,他称之为“重要的和琐碎的许多”,并将其简化为文字。在早期的工作中,Juran缺乏精确性,似乎使他将Pareto关于经济学的观点应用于更广泛的工作领域。帕累托原则之所以被保留,可能是因为它听起来比朱兰原则更好。

结果,Juran博士对“重要的少数和琐碎的许多”的观察即帕累托原理或80/20规则被认为是一种原则,即只有20%的东西总是占结果的80%。

-引自About.com

含义

让我给您介绍一些场景,这些场景说明“ 80/20在行动”:

  • 如果您正在测试软件应用程序,则80%的错误将由20%的应用程序组件驻留/浮出水面。
  • 如果您要计算成本,那么丰田Prius的成本的80%将包含在20%的零部件中。
  • 继续以Prius为例,重量的80%也将包含在20%的零部件中。而且,如果我们将它们存放在仓库中,将有一个相当于仓库的空间。
  • 回到软件,技术复杂性的80%(也称为风险)驻留在20%的应用程序组件中。
  • 等等…

我非常喜欢朱兰(Juran)所说的“最重要的几个人”。原来20%确实很有趣,一旦找到它,我们就可以调整视图以与80%截然不同。

免责声明

当然,现在的数字还不是那么精确,我也不希望您在帕累托周围或周围建立起每一个动作。但是,将其作为您分析和思考的一部分,多年来一直专注于真正重要的事情,对我很有帮助。

敏捷含义

现在,我们来探讨敏捷团队中的一些含义或示例:

积压& Product Ownership

  • 20%的用户故事可能需要某种“研究峰值”,以便对技术含义和歧义进行分类。
  • 20%的用户案例(功能作品)可能包含80%的客户价值。因此,找到它们并首先进行操作。
  • 20%的用户案例(非功能性工作)可能需要扩展的验收标准,以更好地指导完整性的确认。
  • 在“准备”执行冲刺之前,需要对20%的用户故事进行多次修饰(讨论,分解,估计,探索)。
  • 20%的功能可能会驱动80%的客户使用率。
  • 20%的功能将包含80%的利益相关者&客户驱动的变化。

技术风险

  • 80%的技术复杂性是团队承担的20%的组件工作。找到并以不同的方式处理:例如设计和设计审查,团队合作和配对。
  • 对于更复杂的用户故事,有20%的估计将不准确或包含更多差异。估算时请考虑这一点。
  • 积压的订单中有20%具有很强的体系结构含义。
  • 积压的订单中有20%具有跨团队的技术依赖性。
  • 申请的20%将包含80%的技术债务。或将成为重构的诱人目标。
  • 20%的应用程序将需要80%的维护活动。

规划

  • 发行计划的20%将包含80%的风险。
  • 20%的Sprint计划(积压)将包含80%的价值,80%的风险,80%的蜂拥机会。
  • 20%的Sprint计划(积压)将包含80%的测试活动,测试工作,测试风险,错误/返工。
  • 整体工作的20%将占用80%的时间;我想知道这是否与“ 90%完成综合症”有关?
  • 20%的团队工作将导致80%的“阻塞问题”。

质量& Testing

  • 20%的用户故事将包含80%的错误。
  • 20%的用户案例将包含80%的测试复杂性和/或重复测试风险。
  • 80%的用户故事或功能所需要的测试数量少于您最初想像的数量-在此处考虑基于风险的测试。
  • 您的测试策略和计划应包括80/20规则。
  • 20%的缺陷修复将包含80%的缺陷返工。
  • 您有20%的测试将花费80%的时间运行;找到这些并将它们自动化...然后去海滩。

这些并非旨在作为“详尽的清单”。更重要的是,它们旨在让您思考帕累托原理在您日常敏捷之旅中的含义。

包起来

现在所有这些,使用80/20规则存在挑战。

找到20%!在哪里并不总是很明显。

让我们以错误示例为例。很明显,根据我的经验,在我测试过的每个应用程序中,有80%的错误会“聚集”在很小一部分代码中。我们称之为20%。因此,从测试策略和计划的角度来看,我应将80%的精力(测试时间)集中在这里。但是,找到或预测这些缺陷簇并不容易。如果我很自以为是,并且认为自己可以预测所有情况,那么我很可能会浪费一些时间,错过了一些关键领域。因此,盲目使用帕累托既不符合您的最大利益,也不明智。

但是,您应该在日常工作中不断思考帕累托的最佳位置。它与敏捷宣言原则,精益思想和常识很好地吻合。

一个最终要求:请在敏捷上下文中为您添加评论以及其他“帕累托方案”。我希望以我提供的示例为基础。

保持敏捷,我的朋友们,
鲍勃

不要忘记在下面留下您的评论。

快速参考:
1. 这张照片来自维基百科上关于Vilfredo Pareto的文章。
2. http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
3. http://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站