敏捷开发的评估方法_敏捷开发点数评估 - CSDN
  • 基于时间敏捷开发的工作量评估

    千次阅读 2018-08-29 18:15:38
    在我们的开发工作中一共有两类东西要开发, 一种是数据,一种是操作。 所谓数据,就是比如要编写一个CRM,其中有“用户、角色、权限”这三种东西,就是要管理的数据,这里权且记下用户有“3个数据”要管理。 ...

    什么是简化的功能点估算

    在我们的开发工作中一共有两类东西要开发,

    一种是数据,一种是操作。

    所谓数据,就是比如要编写一个CRM,其中有“用户、角色、权限”这三种东西,就是要管理的数据,这里权且记下用户有“3个数据”要管理。

    所谓操作,就是对用户,应该有增、删、改、查、加入角色……这些称之为操作,这里权且记下对用户,用户会做“5个操作”。

    倘若角色和权限没有操作(虽然这是不可能的),那么在NESMA简化方法中由于每个数据是7点,而每个操作是4点左右,那么就可以算出来一共有:
    3 × 7 + 5 × 4 = 21 + 20 = 41点。

    ISBSG/IFPUG包括中国的CSBSG等都有不同行业/不同类型软件的生产率统计,如果你在中国,用C#或Java开发一个类似OA/CRM这样的业务流转软件,那么生产率大约是9小时/功能点(来自于10多个学员的课后数据),也就是上面那个小软件,要用9×41 = 369小时大约是46人天。

    “什么?这点内容我不到一星期就能做完。”是,也不是。这一时间的包含了需求分析/设计/编码/测试/集成/上线部署期间的所有时间,还包括开会讨论的时间,和别的功能联调的时间,培训的时间,修改万恶的Bug的时间,提升性能的时间,改善易用性的时间,上网找图标的时间,上班看博客的时间——总之一个真实项目中可能发生的时间全都平摊在这


    业务流程:需求分析====设计====编码====测试=====集成====上线部署
    沟通衔接:开会讨论===功能联调===培训===bug修改===提升性能====易用性改善====资料查找

    展开全文
  • 敏捷开发团队成熟度评估参考标准

    千次阅读 2015-04-17 19:00:36
    当一个产品团队采用敏捷开发模式时,如何来确认这个团队是否真的已经敏捷了呢?这个是非常重要的,在日常工作过程当中,团队的工作模式很大程度上会受团队负责人或者服务性领导的影响,有时候会因为这个负责人的一些...

    当一个产品团队采用敏捷开发模式时,如何来确认这个团队是否真的已经敏捷了呢?这个是非常重要的,在日常工作过程当中,团队的工作模式很大程度上会受团队负责人或者服务性领导的影响,有时候会因为这个负责人的一些个人工作风格,而使团队的敏捷模式偏离了方向,没有让团队真正的敏捷起来。前面一篇文章也介绍过,在敏捷开发模式团队内部,Product Owner和Scrum Master这两个角色非常重要,他们是带领整个团队前进的,下面的评估参考标准其实基本上是围绕这两个角色展开的。

    一个团队花了很多钱请来了外部的培训师和教练,同时雇佣5个员工组成“敏捷办公室”为新的Scrum团队提供建议和帮助。他们失败是因为他们认为实施Scrum仅限于开发团队。发起敏捷转型的管理层认为,只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对产品经理、测试人员、UED等人员的工作带来的影响。如果这些地方没有改变,组织惰性会把整个团队带回原点。

    Scrum简单但并不容易,原因如下:

    1、成功的变革不是完全的自上而下或者自下而上;

    2、结束状态是不可预知的,Scrum需要持续的改进;

    3、Scrum在整个组织中是无处不在的;

    4、Scrum和传统培训/教育是截然不同的;

    5、变化来的比以往更快;

    6、最佳实践是危险的,要找到适合自身的方法;

    Scrum不仅是技术层面的转型,更意味着理念的革新,整个团队都要参与进来

    1、团队要学会在没有大而全的计划的情况下开始工作;

    2、团队要学会在没有详细需求文档的情况下,通过用户故事和交流分析和理解需求,开始设计和编程;

    3、团队要习惯于频繁递交代码和持续集成;

    4、团队是在高度透明的环境下工作,每个人的进展被所有人都了如指掌;

    5、团队需要进行结对编程,需要频繁的沟通和讨论;

    初级敏捷团队

    1、Team内PO角色清楚,PO负责管理Product Backlog;

    2、PO是需求的主要来源,并负责并从各方收集需求,并对需求负责;

    3、PO负责Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中有一个人可以承担Scrum Master这个角色的工作,基本上由此人长期承担Scrum Master的工作;

    5、基本能够协调Team解决在Sprint内遇到的问题。但是对跨Domain的问题解决推动能力弱;

    6、由Scrum Master协助团队成员进行维护Sprint Backlog,并培养团队成员自行维护Sprint Backlog的习惯;

    7、Scrum Master负责主导和主持站会,站会在固定地点和固定时间,在标准时长内结束,Scrum Master对团队每个成员的工作内容都很清楚,可以通过站会发现大部分问题和风险;

    8、Scrum Master负责各种会议的如期进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master负责主导和主持plan meeting,给出工时的评估方式,给出本次sprint的计划内容和优先级别,引导大家进行sprint内容的拆分,引导大家完成工时的评估;

    10、Scrum Master负责主导和主持总结会议,主要由Scrum Master负责总结本次迭代的优点和缺点,并针对缺点制定出改进措施并进行跟进;

    11、Scrum Master负责监控风险和进度,并能知会给利益相关人;

    12、Team大部分情况下能够完成对DOD的承若;

    中级敏捷团队

    1、PO负责管理Product Backlog,Team认可Product Backlog内容;

    2、Team会协助PO收集需求,也会积极提出需求,Team认可需求并对需求负责;

    3、PO协助Team进行Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中Scrum Master这个角色的工作有Backup,当Scrum Master不在时,Backup可完全承担该角色的工作;

    5、完全能够协调Team解决在Sprint内遇到的问题。对跨Domain的问题解决推动能力较强,但对跨部门的问题解决推动能力较弱;

    6、团队成员自行维护Sprint Backlog的习惯已形成,Scrum Master只需监督和提醒;

    7、Scrum Master协助站会有效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员可以协助Scrum Master发现一些问题和风险,大部分问题和风险还是由Scrum Master发现;

    8、Scrum Master协助各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master协助plan meeting有效进行,和团队成员共同商讨确定工时的评估方式、本次sprint的计划内容和优先级别,进而共同完成sprint内容的拆分和工时的评估;

    10、Scrum Master协助总结会议有效进行,和团队成员共同商讨总结本次迭代的优点和不足,能够针对不足制定出有效的改进措施并进行有效的改进,而优点能够继续保持;

    11、Scrum Master主导,团队成员参与监控风险和进度,并能定期通知给利益相关人;

    12、Team共同完成对DOD的承若;

    高级敏捷团队

    1、Product Backlog由PO发起管理,由Team共同参与讨论完善;

    2、Team共同提出和收集需求,共同对产品负责;

    3、Team共同对Product Backlog优先级进行确定并负责,当变动发生时也是如此;

    4、Team中任何一个人都可以承担Scrum Master这个角色的工作;

    5、可以帮助Team跨越Sprint中遇到的一切障碍,对跨Domain和跨部门的问题解决推动能力均较强,保障DoD按约定完成;

    6、团队成员自觉维护Sprint Backlog,Scrum Master定期检查团队成员维护Sprint Backlog的情况;

    7、团队成员积极地参加站会,站会高效地效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员积极提出问题与风险,和Scrum Master共同发现所有问题和风险;

    8、Scrum Master辅助,团队成员主导各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master辅助,团队成员主导plan meeting,Team共同对工时评估的结果,本次sprint的计划内容及拆分结果,优先级别确认结果负责;

    10、Scrum Master辅助,团队成员主导总结会议,Team共同对本次迭代的结果负责,能够共同认识到不足的根本原因所在,后期所有团队成员都积极有效的改进,将不足逐渐转变为优点,而优点能够越做越好;

    11、Team共同积极监控风险和进度,并能及时通知给利益相关人;

    12、Team从专注功能实现专为专注产品实现,Team有能力识别产品的正确路线,共同促使产品不断被完善;

    同样都是十二条参考评估标准,越成熟的敏捷团队,不光对PO和SM的要求越高,还对团队成员的要求也逐渐提高。在敏捷开发团队内部,是一个互相学习,互相进步的过程,可以促进整个团队的能力和水平的提升,因此对团队的发展是非常有好处的,特别是团队内部职场新人比较多的时候,化大成本去培训、去传帮带,还不如让他们在团队工作当中去学习和成长,这样可以更加快速的帮助他们提高,也提高了团队整体的实力。


    本文转自:《IT民工 or IT精英》

    原文链接:http://www.itfarmer.com.cn/1787.html


    展开全文
  • 敏捷开发的评价指标 敏捷方法用于项目管理的思想是鼓励协作,透明性和对集成团队之间反馈的响应能力。 敏捷软件开发是指使用敏捷宣言中概述的一组原则来频繁开发高质量的工作软件。 敏捷方法论着重于快节奏的软件...

    敏捷开发的评价指标

    敏捷方法用于项目管理的思想是鼓励协作,透明性和对集成团队之间反馈的响应能力。 敏捷软件开发是指使用敏捷宣言中概述的一组原则来频繁开发高质量的工作软件。

    敏捷方法论着重于快节奏的软件开发,这意味着软件测试还必须在保持足够透彻以确保高质量的同时快速进行。

    对于敏捷团队来说 ,找到一种评估和改进测试工作的方法至关重要。 测试指标对于提供敏捷团队中任何软件测试工作的有效性的基本度量非常有用。

    这篇文章通过将测试与旧的瀑布式软件开发框架中的传统测试进行比较,概述了敏捷开发中的确切测试。 您还将找到有关敏捷测试计划的信息,并对一些有用的敏捷测试指标进行了深入了解。

    我们关注与敏捷团队中的测试相关的六个关键指标。 请参阅SeaLights的测试指标学习部分 ,以获取建议指标的更广泛列表。

    阅读本文后,您将更好地了解如何衡量软件开发团队的测试工作并对其进行改进,从而带来更高质量的软件和更高效的开发。 换句话说,您将更容易实现敏捷开发的目标。

    什么是敏捷测试和敏捷测试计划?

    在敏捷框架流行之前, 质量检查是由独立的测试团队执行的单独活动 如今,敏捷测试意味着像敏捷开发团队一样对软件进行缺陷测试。

    借助敏捷测试,开发人员可以在工作中自行改进测试,并借助增强的自动化和快速反馈,敏捷团队可以交付更高质量的软件,并更快地将产品交付生产。

    测试计划是正式概述软件测试范围和活动的重要文档。 敏捷测试计划不同于旧瀑布方法中使用的传统测试计划。

    Waterfall是一种非迭代的顺序软件开发方法,该方法将开发分为预定的阶段。 由于在软件设计阶段之前已定义了详细的要求,所以瀑布式测试计划是静态的。 这样的计划在项目的整个生命周期中不需要太多修改。

    与瀑布式方法相反,敏捷方法需要动态测试计划,该计划具有适应不断变化的需求的适应性。 测试策略至关重要,因为它可以帮助团队:

    • 了解在冲刺中哪些点需要测试功能;
    • 主动创建测试数据以测试仍在开发中的组件之间的依赖关系;
    • 了解谁负责单元测试,何时开始自动化测试以及使用哪些工具进行测试。

    因此,动态测试计划可以通过确保为软件测试做充分准备并由于测试策略和过程的透明性而提高效率来提高敏捷团队​​的生产力。 这种测试计划可以帮助敏捷团队提前计划,同时允许团队适应不断变化的需求。

    敏捷测试指标

    在创建测试计划并开始软件测试之后,通过查看相关指标形式的数据来评估软件测试的有效性非常重要。 以下度量标准是可以帮助敏捷团队更好地实现其目标的度量类型的示例。

    燃尽图

    精简表非常有用,因为它作为度量标准很简单。 燃尽图根据时间绘制出色的工作。 时间单位可以是天,迭代或冲刺。 您可以衡量故事点,功能和功能方面的出色工作。

    理想线是从迭代或项目的开始绘制的,并以直线连接到项目的终点。 您可以使用Microsoft Excel或几个项目管理工具(例如Team Foundation Server)中的任何一个来创建燃尽图。

    资源

    实际生产线应尽可能紧密地跟踪估计。 燃尽图中实际与理想之间的差异可以快速衡量团队的生产力。 假设团队根据理想的线准确地估计了其生产率,燃尽图提供了简单的可视化帮助,可以在实际剩余工作远远超出估计任务时Swift解决任何问题。

    在敏捷中,当开发和测试都完成时,任务被视为完成。 用来定义完成的一个通用术语是“完成”,表示燃尽图上显示的已完成任务已经过测试,没有其他相关活动。

    运行经过测试的功能

    运行测试功能(RTF)是一种敏捷度量标准,用于衡量经过软件测试验证可以正常运行的客户定义软件功能的数量。 该指标很有用,因为它可以通过以下方式使团队更加敏捷:

    • 关注功能而不是设计或基础架构,以及
    • 验证每个功能是否正常运行,并在每次迭代时生成随时可用的软件。

    资源

    通过测量给定项目的RTF增长,团队可以轻松分析软件编码或用于验证功能是否正常的测试是否存在问题。 数据以运行测试功能的数量为基础,以折线图的形式直观地表示,从而轻松验证运行测试功能的数量是否随每次迭代(预期)增长。

    累积流量

    累积流程图映射了整个项目的工作流程,包括团队仍需要完成的任务和已经完成的任务。 由于测试是团队工作流程的一部分,因此通常包含在累积流程图中。

    资源

    通过绘制整个项目工作流,敏捷团队可以对最终成为瓶颈的区域进行有价值的度量,而非生产性工作则显示为在项目过程中不断扩大的垂直带。 例如,在上图中,以红色区域表示的在制品在项目过程中不断扩大,表示该项目中存在瓶颈。 可以使用此度量标准来识别和解决此类关注的领域。 您可以在Excel中创建CFD。

    缺陷循环时间

    敏捷团队应努力尽快修复错误。 实际上,协作敏捷方法的主要目标之一是更快地修复错误,以便更快地发布软件。 仅当编写好的测试并且测试人员与开发人员就缺陷进行有效沟通时,才会出现这种快速解决方案。 周期时间衡量从完成一项任务开始完成一项任务所花费的总时间。 因此,缺陷循环时间是一个有用的敏捷度量标准,因为它传达了敏捷团队作为一个团队修复缺陷的能力。

    资源

    可以使用Office应用程序将缺陷循环时间绘制成图形,以图表形式显示在y轴上修复缺陷所需的时间与在x轴上进行迭代(或其他间隔)的时间。 最终目的是通过精心设计的测试,较短的缺陷周期时间,良好的测试团队反馈以及开发人员Swift修复的结果。 上图中的迭代6、7和8具有相对于阈值而言较短的缺陷循环时间。

    缺陷溢出

    敏捷团队的目标是在每次迭代中生产可运行的软件。 缺陷溢出可以通过简单地计算每次冲刺或迭代开始时剩余的缺陷来衡量在给定的迭代或冲刺中无法修复的缺陷。

    当团队忽略这些缺陷时,这些缺陷会随着时间累积,从而导致技术欠债,从而降低生产率。 衡量此指标可使敏捷团队了解他们处理出现问题的效率。 一个简单的条形图提供了直观的帮助,可显示每个sprint或迭代的剩余缺陷。 理想情况下,很少有缺陷会在两次间隔之间溢出。

    资源

    速度

    速度是单个团队的有用指标。 该指标仅将给定长度的冲刺期间完成的工作单位与交付该冲刺所需的估计工作单位进行比较。

    资源

    速度是衡量敏捷团队随着时间推移成熟程度的好方法。 理想情况下,每次冲刺都应提高速度,然后在团队达到最佳生产率时达到一个峰值。 您可以在项目管理软件(例如Atlassian)中查看速度图表。

    常见的敏捷测试问题

    即使要衡量许多不同的指标,测试本身对于敏捷团队也是一个问题。 在发布软件之前,对软件进行彻底的测试显然很重要,但是测试会减慢软件的上市时间。 因此,主要的敏捷测试问题围绕着实施解决方案以提高效率和生产率。 敏捷测试的一些主要挑战是:

    • 缺乏测试覆盖率。 快速推出软件的压力可能导致团队为用户案例编写的测试太少。 拥有对所有代码更改的可见性以编写足够的测试以覆盖给定用户案例中的代码,这一点很重要。
    • 密码破损。 团队交付构建的频率越高,破坏现有代码的机会就越大。 每日回归测试与手动测试运行不切实际。 此外,随着微服务的使用变得越来越普遍,每个微服务都在其自己的生产管道中运行,因此必须验证所有活动部件是否正常工作并正确集成。
    • 赶上缺陷太迟了。 在开发周期后期发现的缺陷修复成本要高于早期发现的缺陷。 无论您的项目框架如何,都适用此规则。 面临的挑战是在敏捷框架中尽早找出最好的识别缺陷的方法。 需要左移,这意味着在开发周期中尽早进行软件测试。
    • 性能瓶颈。 敏捷团队需要了解如何最好地监视软件性能,以使其他功能不会导致系统严重下降。

    跟踪某些测试指标还存在许多问题。 这样的度量标准会产生问题,因为它们可能引起混乱,违反敏捷原则或提供很少的价值。 例如:

    • 跟踪个人指标 这违反了敏捷精神,因为它鼓励同一团队成员之间的过度竞争。 例如,通过计算编写的测试数量来衡量生产率。 太多的竞争会损害团队合作精神并产生质量测试问题。
    • 跟踪无意义的指标。 毫无意义的指标是那些没有告诉您测试生产力的指标。 例如,比较两个敏捷Scrum团队在各自速度上的指标很差,因为速度对于每个团队都是唯一的,因为速度取决于每个团队唯一的估计。 比较团队之间的速度会鼓励团队弄乱他们的估计,从而导致对冲刺的规划不佳。

    克服潜在使用有问题的测试指标或不正确使用测试指标的唯一方法是在团队成员和项目经理之间提高对敏捷团队中有用的测试指标构成的认识。

    敏捷测试:如何向左移动以使其正确

    左移意味着在开发阶段而不是随后转向测试软件。 在开发阶段进行的测试是预防性的,而不是诊断性的; 通过在构建前进之前主动处理问题,可以减少浪费的时间来以后再查找这些问题。

    左移可以解决敏捷中的一些主要挑战,包括尽早发现缺陷和提高代码覆盖率。 开始进行左移测试的一些方法是:

    • 使用测试自动化来改善连续交付,并最大程度地减少与破坏代码相关的问题,例如,使用自动化回归工具;
    • 鼓励开发人员考虑可测试性进行编码,从而提高测试框架的可靠性并加快测试周期;
    • 在软件开发生命周期的所有阶段定义质量控制。 这些控制措施导致在相关阶段采取纠正措施,而不是随后采取措施,最终改善了项目的运行状况。

    重要的是要记住,指标在左移测试方法中仍然非常相关。 您仍然需要评估测试以改进它们,并且测试指标提供了做出有关未来软件测试的明智决策所需的证据。 始终从测试工作开始的那一刻开始收集数据。

    通过测试计划克服敏捷挑战

    敏捷团队需要一种能够反映敏捷鼓励的跨功能环境的测试方法。

    在开始任何测试之前,概述测试计划很重要。 敏捷的测试计划是动态的,随着时间的推移不断纳入新的和不断变化的需求。

    敏捷上下文中的测试指标非常相关,但是了解和使用适当的指标很重要。 应劝阻敏捷管理者不要跟踪面向个人的指标。

    “左移”概念旨在克服与敏捷团队中的测试相关的挑战。

    翻译自: https://www.javacodegeeks.com/2017/10/use-testing-metrics-agile-environment.html

    敏捷开发的评价指标

    展开全文
  • 1.几种开发方法 1.1瀑布式开发——瀑布模型(Waterfall Model)1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是...

    1.几种开发方法

    1.1瀑布式开发——瀑布模型(Waterfall Model)

    1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

    瀑布模型要求软件开发严格按按照需求→分析→设计→编码→测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过后才能够进入到下一个阶段。遵循自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

    瀑布模型式是最典型的预见性的方法。

    瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性

    瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

    1.2 迭代式开发

    迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

    在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,在需求被完整地确定之前就能启动开发工作,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

    1.3螺旋开发——螺旋模型(Spiral Model)

    螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于强调其他模型所忽视的风险分析,螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。。

    通常螺旋模型由四个阶段组成:制定计划、风险分析、实施工程和客户评估。

    (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

    (2)风险分析:分析评估所选方案,考虑如何识别和消除风险;

    (3)实施工程:实施软件开发和验证;

    (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。

    螺旋模型适用于庞大并且复杂,高风险的项目,需求不明确的情况下,便于风险控制和需求变更。

    2.敏捷开发

    2.1 敏捷开发的诞生

    程序员说,要有敏捷

    于是就有了敏捷。

    敏捷这个词被用的过于泛滥了,大家都在讨论它,可以把它视为一种宗教。

    美国在计算机行业已经走了几十年,瀑布流、螺旋模型、快速迭代…各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善,但互联网的加速发展让传统方法显得笨重,难以快速适应变化。有十七个程序员(程序员改变世界)在美国犹他州盐城湖的一个风景区开了个碰头会,找到了一个团队耦合度高,流程极其灵活的方法,他们把它称为敏捷开发(Agile program development)。

    2.2 敏捷开发宣言

    • 个体和交互重于过程和工具

    敏捷方法认为,人是软件开发中最重要的因素,开发团队要能做到团结协作,人与人面对面的交流、沟通,是最快速、最有效的途径。

    • 可以工作的软件重于面面俱到的文档

    文档的意义在于为程序服务,过多的文档需要开发人员花费大量的时间去维护,而且还要确保文档与代码的实时性,否则就失去了文档的意义。而问题也就在于,开发人员没有把时间、精力放到最重要的任务上,能力、资源没有最大化的发挥效能。敏捷方法认为,文档应当短小精悍、易于维护,而且主题突出。

    • 客户协作重于合同谈判

    做过软件开发的人都知道,客户对产品的需求是不断变化的,试图一开始就规定项目的细节和进度,显然是不现实的,只有开发团队和客户彼此精诚合作,常与沟通,频繁的客户反馈,才能促使项目的成功。

    • 随时响应变化重于循规蹈矩

    客户的需求在产品的开发阶段是不断变化的,即使谈判时确定的需求,也可能会根据某些因素而发生巨大的改变。因此,敏捷方法认为,在制定计划时应尽可能的简洁、灵活,以适应技术和需求方面的变动。当然,所有的未知的因素是不可能考虑周全的,这就要求我们在制定计划时,留出一定的缓冲期,来应对这些未知情况。

    • 适应变化

    传统的软件开发强调的是,足够清晰的需求,制定详细的文档,按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化,无法应对客户对需求的实时更改,后续的维护必将会付出巨大的代价。

    而敏捷方法则是以最简的方式来迎接变化,客户在整个开发过程中都是参与者,开发团队能够在最短的时间内得到客户的反馈,不断适应需求的变更,从而使得最终的产品能够充分的符合客户的要求。

    2.3敏捷开发

    敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    敏捷开发可以说是在迭代开发的基础上发展形成的,它额外强调了沟通合作、以人为本的思想。敏捷开发的缺陷可能在于团队不能过大,一般少于20人,且要求成员都是精干,有互相信任的基础。

    3.敏捷开发方法:

    3.1 Scrum

    Scrum 是当前最流行的敏捷软件开发方法论和实施框架。

    Scrum 是一种团队管理工作的方式,其将工作分解为较小的工作单元,并在周期性固定的时间段内持续地交付工作单元

    上面描述的周期性固定的时间段,称为迭代(Iteration)或者冲刺(Sprint)。

    上面描述的较小的工作单元,称为用户故事(User Story)。

    用户故事可以使用特定的格式来描述,其描述了一个对于客户有价值的工作,而且可以在一个迭代周期内完成。

    Scrum 框架结构

    Scrum敏捷开发流程主要包括:三个角色、三个物件和四个会议。

    三个角色:

    • 产品经理(Product Owner):主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    • 敏捷教练(Scrum Master):主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    • 开发团队(Scrum Team):主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右。

    三个物件:

    1、product Backlog : 产品Backlog指根据初始需求分解出的任务列表,包括功能性和非功能性的所有功能。

    2、Sprint Backlog ,这是一个迭代计划会议的输出,包含开发团队在迭代周期内所要完成的工作列表。 如果说产品backlog是以story为单位,文档归属为PM团队,那么Sprint Backlog 是以小时(时间)为单位的,文档归属为开发团队。

    3、燃尽图。

    燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。(引自百度百科)

    scrum基本流程(四个会议):

    1.产品负责人负责整理user story,形成左侧的product backlog。

    2.产品发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。

    3.spring计划会议:在每个迭代之初,开发团队和 Product Owner 共同来计划在迭代周期内要完成的工作。Product Owner 负责向团队讲解要完成的工作的内容,开发团队负责对工作进行估计。

    4.spring每日立会:每天,开发团队和产品负责人都要进行一个短暂的沟通。团队成员回答昨天做了什么?今天计划做什么?遇到了什么问题?

    5.spring演示会议:在迭代周期结束时,开发团队向产品负责人及所有干系人进行演示,并接受反馈。

    6.spring回顾会议:在迭代周期结束时,Scrum 团队通过会议来对迭代的过程进行总结,以促使团队自我持续改进。

    3.2其他开发方法介绍

    水晶方法,Crystal ,是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列,其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程,它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

    透明水晶方法,适合于一个小团队来进行敏捷开发,人数在6人以下为宜。

    七大体系特征:

    • 1. 经常交付

    任何项目,无论大小、敏捷程度,其最重要的一项体系特征是每过几个月就向用户交付已测试的运行代码。如果你使用了此体系特征,你就会发现,“经常交付”的作用还是很让人吃惊的。

    项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的,也有机会将观察结果反馈到开发当中。开发人员打破未决问题的死结,从而实现对重点的持续关注。团队得以调整开发和配置的过程,并通过完成这些工作鼓舞团队的士气。

    • 2.反思改进

    在我们的开发中,时常会出现这样那样的问题,技术难题、各种烦心事等等,这会在很大的程度上影响项目的进展。而且,如果其他任务对这项任务有依赖的话,那么其他的任务也会被推迟,这就很可能会导致项目的失败。

    换句话说,如果,我们能够经常在迭代会中及时的反思和改进,那么,这种事情应该是不会发生的,或者说发生了,也能够很快的找到解决方案去应对它。事实上,从慌乱的日常开发中,抽出一点时间来思考更为行之有效的工作方法就已经足够了。

    • 3.渗透式交流

    渗透交流就是信息流向团队成员的背景听觉,使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。若其中一名成员提出问题,工作室内的其他成员可以选择关注或不关注的态度,可以加入到这个问题的讨论当中来,也可以继续忙自己的工作。

    • 4. 个人安全

    个人安全指的是当您指出困扰您的问题时,您不用担心受到报复。个人安全非常重要,有了它,团队可以发现和改正自身的缺点。没有它,团队成员们知而不言,缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任,团队协作才能真正的实施,开发效率也就会直线上升的。

    • 5.焦点

    所谓“焦点”,就是确定首先要做什么,然后安排时间,以平和的心态开展工作。确保团队成员清楚的了解他们自己最重要的任务是什么,确保他们能够有充分的时间去完成这些任务。

    • 6.与专家用户建立方便的联系

    与专家用户持续建立方便的联系能够给团队提供:对经常交付进行配置以及测试的地方,关于成品质量的快速反馈,关于设计理念的快速反馈,最新的(用户)需求。

    • 7.配有自动测试、配置管理和经常集成功能的技术环境

    自动测试可以为开发人员在代码修改后就可以进行自动测试,并且能够发现存在的一些bug,以至开发人员能够及时的进行修改,对于他们来说,节省了时间,提高了效率,而且还不用为烦人的测试而苦恼。

    总结:

    基于敏捷指导思想 ,形成了不少敏捷软件开发方法 (例如XP、scrum、水晶方法等 ),它们大都强调适应性而非预测性、强调以人为中心,而不以流程为中心 ,以及对变化的适应和对人性的关注。

    纵观所有敏捷开发方法,其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点 。

    展开全文
  • 敏捷估算方法 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在故事拆分之后需要对我们...
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:20:54
    敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • 敏捷开发和迭代开发

    千次阅读 2019-06-27 17:05:44
    敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 浅谈敏捷开发

    2020-04-11 14:29:17
    敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 章节 什么是敏捷...
  • 敏捷开发的起源在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对其...
  • 但是人们选择敏捷开发作为管理方法是有原因的:更高的交付保障,更高的生产率,更高的质量……这和人们选择C++(而不是C)的原因还是很接近的:都是为了更高的绩效。在下面的所有文章中,“敏捷开发绩效管理”都将...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    这里是pm小课堂,每篇分享文从 【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】 八个方面深度解析pm知识/技能。 本篇分享的是:【什么是...3.敏捷开发方法 ...
  • 随着软件开发技术的不断发展,现在出现了很多种不同的开发模式,其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案。那么什么是敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发...
  • 敏捷开发人员结构 本文旨在分享在敏捷组织中使用开发软件接口运行项目的经验。 为了有机会加入团队,使用了这种方法来查看不同的观点。 通过阅读或听取他人的意见,我认为这对于研究和应用读者很有用。 或补充现有的...
  • 敏捷开发入门教程

    2019-06-12 14:53:12
    敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 一、迭代开发 ...
  • 敏捷开发初步了解

    千次阅读 2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?... 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法...
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 敏捷开发与敏捷测试

    2020-07-02 15:25:48
    敏捷开发:1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,...
  • 敏捷开发与传统开发的区别

    千次阅读 2017-03-21 14:38:41
    敏捷方法与传统方法的区别与联系  首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行... 其次,说一下敏捷开发的方式流程
  • 增量交付开发 敏捷开发 当操纵金属和塑料而不是一和零时,是否有可能进行敏捷开发过程? 还是敏捷开发硬件的想法是错误的? 事实是,越来越多的组织给了瀑布式的支持,并转向基于scrum , lean和看板的模型,因为...
1 2 3 4 5 ... 20
收藏数 28,467
精华内容 11,386
关键字:

敏捷开发的评估方法