【敏捷】综述,验收标准,实际时间估计,验收测试

【敏捷】综述,验收标准,实际时间估计,验收测试
0

英文版:
https://guide.freecodecamp.org/agile
https://guide.freecodecamp.org/agile/acceptance-criteria
https://guide.freecodecamp.org/agile/actual-time-estimation
https://guide.freecodecamp.org/agile/acceptance-testing

敏捷

敏捷软件开发(Agile Software Development)是用于管理开发团队的方法集合。它倡导适应性规划,循序渐进,提前交付和持续改进,并鼓励对变化做出快速灵活的反应。成员和沟通被认为比工具和流程更重要。

敏捷强调向用户询问他们最终想要什么,并经常在开发阶段向他们演示产品。这与瀑布式开发(Waterfall Approach),规范驱动开发(Specification-driven Development)以及敏捷实践者所谓的“大型前端设计(Big Up-Front Design)”形成鲜明对比。在这些方法中,功能在开发之前计划出来并编入预算。

对于敏捷,重点是“敏捷性(agility)”:能够快速响应用户的反馈和其他不断变化的环境。 一般来说最佳小团队人数是4 - 7人左右。

敏捷有许多不同的风格,包括Scrum和极限编程(Extreme Programming)。

更多信息

敏捷联盟的主页

验收标准

用户素材作为待办事项中的项目,是对话的占位符。在这次谈话中, 产品负责人和交付团队了解所需的结果。

验收标准告诉交付团队代码的行为方式。避免写出用户故事的 “如何” ;坚持 “什么” 。 如果团队遵循测试驱动开发(TDD),它可以为自动化测试提供框架。 接受标准将是QA团队测试计划的开始。

最重要的是,如果故事不符合每个接受标准,那么产品负责人不应该在迭代结束时接受故事。

验收标准可视为保护交付团队的工具。当交付团队在Sprint计划中承诺一组固定的故事时,他们也承诺修复一组验收标准。这有助于避免范围蔓延。

请考虑以下情况:在接受用户故事时,产品负责人建议添加不在用户故事范围内的内容。在这种情况下,交付团队可以拒绝此请求(无论多么小),并要求产品所有者创建一个可以在另一个Sprint中处理的新用户故事。

更多信息:

Nomad8提供了关于验收标准常见问题解答

接受标准上领先敏捷

实际时间估计

实际时间估计是预测基于不完整,不确定和嘈杂输入开发或维护软件所需的最实际的努力量(以人 - 小时或金钱表示)的过程。努力估算可用作项目计划,迭代计划,预算,投资分析,定价流程和投标轮次的输入。

国家的实践

已发布的估算实践调查表明,在评估软件开发工作时,专家评估是主要策略。

通常情况下,工作量估算过于乐观,并且对其准确性存在强烈的过度信任。平均努力超支似乎约为30%而不会随着时间的推移而减少。有关工作量估算误差调查的评论,请参阅。但是,估算误差的测量存在问题,请参阅评估估算的准确性。平均而言,如果软件专业人员有90%的信心或“几乎肯定”将实际工作量包括在最小 - 最大间隔内,则可以看出,工作量估算准确性的强烈过度自信,包括实际工作量仅为60-70%。

目前,“努力估计”一词用于表示不同的概念,如最有可能使用努力(模态值),相应于50%不超过(中位数)概率的努力,计划的努力,预算的努力或用于向客户提出出价或价格的努力。这被认为是不幸的,因为可能发生通信问题并且因为概念服务于不同的目标。

历史

自从至少20世纪60年代以来,软件研究人员和从业人员一直在解决软件开发项目的工作量估算问题;比如,见法尔和尼尔森的作品。

大多数研究都集中在正式软件工作量估算模型的构建上。早期模型通常基于回归分析或数学上来自其他领域的理论。从那时起,已经评估了大量的模型构建方法,例如基于案例推理的方法,分类和回归树,模拟,神经网络,贝叶斯统计,需求规范的词汇分析,遗传编程,线性规划,经济生产模型,软计算,模糊逻辑建模,统计自举以及这些模型中的两个或更多个的组合。

目前最常见的估计方法是参数估计模型COCOMO,SEER-SEM和SLIM。它们的基础是在20世纪70年代和80年代进行的估算研究,并且从那时起更新了新的校准数据,最后一个主要版本是2000年的COCOMO II。估算方法基于基于功能的尺寸测量,例如功能这一点也是基于20世纪70年代和80年代进行的研究,但是采用改进的尺寸测量和不同的计数方法进行了重新校准,例如20世纪90年代的用例点或对象点以及2000年代的COSMIC。

实际时间估算是一种估算开发工作的基于时间的方法。

能够估计敏捷项目的完成时间至关重要,遗憾的是,它也是规划敏捷项目最困难的部分之一。

其目的是最好地估计完成给定开发任务所需的时间量。

您可以使用的一种技术是估计完成用户故事所需的时间。当您这样做时,请记得咨询敏捷团队的其他成员。对于每个用户故事,请确保您估计一个现实可行的时间,但不要太多,以至于客户端因简单工作而被多收费用。咨询您团队的成员,以便您能够利用他们的专业知识来了解需要多少工作以及需要多长时间。当您对每个用户故事达成共识时,您可以累计时间来进行时间估算。

随着项目要求的变化,您可以更新估算值。如果项目丢失了最初分配给它的一些资源,您可能需要剪切用户故事,以便能够在相同的总时间内完成它们。同样,如果您想提高应用程序的质量,您可能需要为每个用户故事分配更多时间,以确保您的团队有时间以所需的质量完成应用程序。

通常,这些估算是使用理想的工程时间计算的。

例子:

此任务将在10天内完成。

要么…

这项任务将于1月10日完成。

要么…

此任务需要25个开发时间才能完成。

更多信息:

验收测试

验收测试,执行测试技术以确定软件系统是否符合要求规范。此测试的主要目的是评估系统是否符合业务要求,并验证其是否符合向最终用户交付的必要条件。

有各种形式的验收测试:

  • 用户验收测试

  • 业务验收测试

  • Alpha测试

  • Beta测试

验收标准

验收标准是基于以下属性定义的

  • 功能正确和完整

  • 数据完整性

  • 数据转换

  • 可用性

  • 性能

  • 及时性

  • 机密性和可用性

  • 可安装性和可升级性

  • 可扩展性

  • 文档

验收测试计划 - 属性

验收测试活动分阶段进行。首先,执行基本测试,如果测试结果令人满意,则执行更复杂的场景。

验收测试计划具有以下属性:

  • 简介

  • 验收测试类别

  • 操作环境

  • 测试用例ID

  • 测试题目

  • 测试目标

  • 测试程序

  • 测试时间表

  • 资源

=>验收测试活动旨在得出以下结论之一:

接受系统交付

在请求的修改完成后接受系统

不要接受系统

验收测试报告 - 属性

验收测试报告具有以下属性:

  • 报告标识符

  • 结果摘要

  • 变化

  • 建议

  • To-Do列表摘要

- >批准决定

验收测试侧重于检查开发的软件是否满足所有要求。其主要目的是检查开发的解决方案是否满足用户期望。

这种快速风格指南有助于确保您的拉取请求被接受

验收测试是软件开发中的成熟实践。验收测试是代码功能测试的主要部分。

验收测试测试代码按预期执行,即在给定预期输入的情况下产生预期输出。

验收测试用于测试相对较大的软件功能块,即功能。

例子

您创建了一个页面,要求用户首先在对话框中输入其名称,然后才能看到内容。您有一个受邀用户列表,因此任何其他用户都将返回错误。

这里有多种方案,例如:

  • 每次加载页面时,都需要输入您的名字。
  • 如果您的名字在列表中,则对话框将消失,您将看到该文章。
  • 如果您的名称不在列表中,则对话框将显示错误。

您可以为较大的对话框功能的每个子功能编写验收测试

除了处理测试将如何执行的基础结构的代码之外,您对第一个场景的测试看起来像(在伪代码中):

鉴于该页面已打开 该对话框应该是可见的 对话框应包含一个输入框 并且输入框应该有占位符文本“你的名字,请!”

笔记

验收测试可以用任何语言编写,并使用各种适合的工具运行,这些工具可以处理上面提到的基础结构,例如打开浏览器,加载页面,提供访问页面元素的方法,断言库等等。

每次你编写一个将再次使用的软件(即使是你自己),它也有助于为它编写测试。当您自己或其他人对此代码进行更改时,运行测试将确保您没有破坏现有功能。

它通常由用户或主题专家执行。它也被称为用户验收测试(UAT)。 UAT涉及最常见的现实生活场景。与系统测试不同,它不关注错误或崩溃,而是关注功能。 UAT在测试生命周期结束时完成,并将决定软件是否移至下一个环境。

定义应该编写哪些验收测试的好方法是为用户故事添加验收标准。使用验收标准,您可以定义用户故事何时可以部署,并根据您的意愿完成问题。

在敏捷项目中,团队必须为所有用户故事定义验收标准。验收测试工作将使用定义的标准来评估交付的功能。当故事可以通过所有验收标准时,它就完成了。

验收测试还可以验证完成的史诗/故事/任务是否满足定义的验收标准。与完成的定义相反,此标准可以涵盖团队想要解决的特定业务案例。这提供了良好的工作质量验证。

更多信息:

With Agile, the emphasis is on “agility” - being able to quickly respond to feedback from users and other changing circumstances.

粗体字好像原文没有

我从这里直接复制的啊 https://chinese.freecodecamp.dev/guide/agile
难道原文更新了??真让人摸不着头脑 :joy:

英文原文确实没有~

1赞