敏捷方法指南 — Scrum 团队角色,敏捷仪式,常见问题解答

Skip navigation

敏捷开发

速度与协作的结合

什么是敏捷方法?

敏捷开发的核心原则包括加强协作,赋能开发团队,保证开发过程透明。虽然每种敏捷方法都有其独特之处,但在创建应用程序时都包含了迭代开发和持续反馈两个要素。任何敏捷开发项目都涉及持续不断的规划、测试、集成以及其他形式的持续开发。

Agile Intro Image

Scrum 项目中的角色

  • Scrum Master

    Scrum 大师

    教练与监督

    Scrum 大师的双重身份决定了其在敏捷框架下的责任:提供指导和培训,消除障碍和干扰。Scrum 大师直接与产品负责人合作,以决定在冲刺中将解决哪些用户情景。

    Read more
  • Product Owner

    产品负责人

    沟通联络

    该角色的职责包括定义项目及其标准,确保团队充分了解目标;管理积压的用户情景并确定优先顺序;与 Scrum 其他团队成员协作,确定优先级别最高的项目,并将其作为下一个冲刺的内容。

    Read more
  • Subject Matter Experts

    主题专家

    提供专业知识

    主题专家拥有团队成功交付产品所需的知识。例如,系统管理员是“基础设施主题专家”,UX 专家是“UX 主题专家”。主题专家是项目的利益相关者,但并非所有利益相关者都必须是主题专家。尽管主题专家不是 Scrum 团队成员,但如果团队在开发产品时需要额外的协助,则相应的主题专家将全程参与项目。

    Read more
  • Business Owner

    业务所有者

    促进营收增长

    业务所有者为 Scrum 团队提供资金支持,依靠产品负责人管理团队工作能力,是主要的利益相关者。它既为产品提供支持,也为产品负责人提供指导,传达业务需求。

    Read more
  • Development team

    开发团队

    创建与开发

    开发团队是实际进行软件开发的一群人。开发团队通常规模很小,一般不到 7 个人。 将业务开发人员纳入 Scrum 团队可以改善应用程序交付,满足业务需求和客户期望,而不仅仅是用户情景需求。

    Read more

敏捷仪式

冲刺规划

冲刺是 Scrum 开发的基本单位。冲刺规划是 Scrum 大师、产品负责人和整个敏捷开发团队协同工作的过程。在此过程中,Scrum 大师负责推动会议,产品负责人负责明确待办工作详情及各项工作标准,而敏捷开发团队则负责确定达到冲刺目标所需的工作和努力。

每日站立会议

每日站立会议是敏捷开发中协同工作的重要组成部分。整个 Scrum 团队每日召开例会,从而快速掌握进展并发现冲刺过程中的任何障碍。团队通常会检查燃尽图,衡量已完成的工作量与冲刺所需的全部工作量。成员们站着开例会,保证会议言简意赅、直切主题。

冲刺评审会议

冲刺结束时召开冲刺评审会议,供敏捷开发团队介绍和评审已完成的工作,同时向更多人员(包括产品负责人、管理层和最终用户)展示可交付的软件改进。除了根据冲刺目标评估项目之外,开发团队还可以提供有关当前解决方案和待解决需求的反馈,为下一个冲刺规划会议做准备。

回顾

回顾会议一般在每个冲刺或每个主要开发周期结束时召开,是实现开放沟通的关键渠道。在回顾会议期间,团队应总结行之有效的方法,以及在未来冲刺中可以进一步改善的方面。

将敏捷方法与低代码平台结合的优势

Transparency Icon

透明度

平台应处于中心位置,每位开发人员都可以通过注释和故事实时掌握应用程序开发的情况,深入了解相关业务目标和需求。将注释和故事链接到正在开发的软件中,可以为接收者和评审者提供相关语境,从而减少歧义、误解和错误,提高每位成员的工作效率。

Rapid Iteration Icon

快速迭代

开发团队和业务所有者可以使用通用语言,促进所有相关成员之间的理解和沟通,开发出可同时满足业务和技术需求的解决方案。低代码平台采用可视化、模型驱动开发技术来定义应用程序的用户界面、数据模型和逻辑。可视化模型易于理解,可以促进开发人员和业务人员之间频繁持续的协作。

User Feedback Icon

用户反馈

低代码平台内置用户反馈组件,可让用户直接在应用程序内提供即时反馈。封闭的反馈循环可让开发团队快速解决来自业务的问题,实现迅速迭代。内置的应用程序验证具有即时应用共享功能,可以进一步加强敏捷协作。对工作内容进行实时、跨设备的预览和共享,可让最终用户在开发过程中第一时间接触应用程序并做出频繁反馈,从而促进持续反馈。

Development Agility Icon

实现敏捷开发

将敏捷开发原则嵌入到低代码平台的核心,可让用户进行频繁且实时的反馈和协作。如果将业务所有者也包含其中,可大幅缩短反馈循环,确保团队在更短时间内交付满足用户需求和业务目标的解决方案,更快地实现价值。了解为什么开发人员需要低代码

经常问的问题

  • 低代码如何帮助支持敏捷软件开发?

    像Mendix这样的低代码开发平台通过提供有助于连续快速sprints的协作工具,很好地适应了敏捷方法论。Mendix的Sprint特性让项目管理、调试和反馈循环更加直观。

    另请阅读:

  • 什么是Scrum?

    Scrum是适用于管理和控制所有类型的迭代和增量项目的一个轻量级敏捷框架。此外,还有其他敏捷开发框架,比如广受欢迎的看板和极限编程。

  • 敏捷框架的其他用例有哪些?

    看板关注的是一个将工作分解成小块的可视化工作流。通过遵守明确的项目限制,遵循明确的流程政策,测量和管理流程,看板特别适用于识别瓶颈和浪费,以及减少等待时间。

    极限编程是一个以工程原理为中心的敏捷框架,专注于确保符合随时变化的客户需求的高质量软件交付。该过程甚至定义了开发过程中考虑的新需求或变更需求的点。开发人员通常会结对工作,并且可能有频繁的代码审查。

  • 敏捷与设计思维有何关系?

    敏捷是一种以软件开发方式为目标的方法,而设计思维则专注于确保所开发的是符合客户期望的。设计思维的基本概念是从客户开始,并从那里着手处理需求。了解更多企业IT组织是如何结合敏捷和设计思维以找到正确的问题来解决。

  • Epics vs. Stories vs. Tasks

    Epics是可以跨越多个sprints的完整特性和功能, 并可以被分解成 stories,而 stories可以进一步分解成 tasks。一个epic可以有多个stories,每个story可以有多个 tasks。虽然epics可以跨越多个sprints,但stories应在当前的sprint中完成。

    Stories的优先级排序和创建需根据利益相关者的反馈进行。在创建Stories时,应该始终使用此模板:As a , I want to so that I can。

  • 敏捷开发只适用于创新项目吗?

    敏捷不仅仅适用于创新项目,现已成为企业开发应用程序的主流方式。实际上,IDC的研究显示,在2016年,48%的企业将敏捷应用于“创新项目”,目前这一比例已降至23%。而将敏捷作为其“主要发展路径”的企业比例则从2016年的32%上升至2017年的45%。