ZenHub Epics创造了GitHub中敏捷Epics

简介:

基于GitHub的项目管理方案ZenHub最近创造了“Epics”。这个新工具提供了一个完整的GitHub 问题和问题管理的返工方案,旨在在GitHub中完全管理产品开发过程。

ZenHub Epics使敏捷epics集成到开发工作流中成为可能,ZenHub说,在敏捷术语中,epics是更大的用户故事,这些用户故事的实现跨越了几个迭代过程,因此需要被逐步分解为可行的任务,即更小的用户故事。使用GitHub的开发者们之前没有更简单的方式来在GitHub中创造epics,ZenHub说道,或者他们需要转而使用GitHub以外的第三方工具,例如JIRA。Epics使完全在GitHub内计划产品backlog成为可能,ZenHub说道。

ZenHub Epics帮助开发者们将较大的用户故事分解,允许开发者们将其分成几个子任务并在将来的开发中追踪这些任务在整体目标中的完成度。现存的GitHub问题可以被加入epic中,或者可以直接在epic中创建新的问题。此外,一个问题可以被在任何时间转化成epic以适应开发过程中问题变得更复杂的情况。

在拥有自己的详细信息页面基础上,ZenHub Epics还在ZenHub “Boards”中进行了集成,这允许使用GitHub的开发者们在看板管理中管理问题。看板中根据用户定义的标准组成的问题群在不同的区域给用户提供了一个项目状态的快速总览。Epics在用户的其他GitHub 问题旁边展示并且用户可以使用过滤工具来筛选所有属于一个特定epic的问题。

  为了更加了解Epics,InfoQ采访了ZenHub的缔造者者Matt Butler。

使用ZenHub Epics对开发者们有什么好处?

Epics给GitHub问题提供了一个关键的、额外的层次结构。开发者们可以将他们的任务板与ZenHub Epics匹配起来用,这样就可以更容易地看到他们离下一次发布目标的距离。通过使用epics规划开发任务,软件工程师可以更精确地满足发布期限,并从根本上杜绝技术负债。最重要的是,由于Epics使用了GitHub的原生界面(并使用了GitHub已存在的数据),开发者们可以留在他们熟知并喜爱的环境中。

使用ZenHub Epics对管理者们有什么好处?

开发团队的日常工作和生活中已经离不开GitHub了,ZenHub Epics能让管理者们在GitHub内计划并共享项目backlog,这是他们的。这可能是第一次真正地在GitHub中管理所有的sprint计划,而不是使用第三方的平台。众所周知,第三方平台开销较高,并且功能过于繁杂,权限结构过于分明。由于ZenHub利用了已存在的GitHub数据,他们可以确定信息总是精确和最新的。ZenHub和ZenHub Epics为团队每个人,从管理者到开发者再到执行者,创造了一个“唯一真实的数据来源”。

ZenHub Epics和JIRA哪个对敏捷epics的支持更好?

JIRA已被证明是在非技术项目经理中极受欢迎,而ZenHub是特别为敏捷开发团队和技术管理搭建的。

首先,ZenHub Epics开销低,拥有更简单的权限结构,灵活性更高,并且配置时间几乎为零。它们是特别为敏捷开发团队搭建的,他们需要一个能做他们所需要的事情、然后“解决事情”的工具。

它们最重要的不同之处在于ZenHub所有的功能都以GitHub的原生界面呈现,并且它是唯一的一个提供这样功能的工具。为什么这很重要呢?

集中一个单独的工具,消除“信息烟囱”,使团队把他们的工具集固定下来。

“上下文切换”开销很高,特别是对于开发者们来说。ZenHub消除了在工具之间的这种“上下文切换”浪费的时间。因此项目经理可以花更少的时间提醒开发人员来更新任务,并且开发人员也自发地参与到更多的项目管理过程了,因为它就寄生于他们的环境中——而不是一个沉重的管理平台。

ZenHub是一个类似Trello的、拖放式的项目管理方案,它搭建在GitHub的基础上,并与其进行了全集成。它可以在开源项目中免费试用,否则需要付费。在几个月前就已发布了ZenHub 2.0,它引进了更多有价值的功能,例如使项目可以跨越多个库的多库支持,还引入了燃尽图、时间估计针对GitHub企业自运营服务的支持。



本文转自d1net(转载)

相关文章
|
JavaScript 前端开发 数据建模
探索未来编程新范式:响应式编程的崛起与实践
本文将深入探讨响应式编程的核心概念、技术优势及其在现代软件开发中的应用。通过实例解析,揭示这一新兴编程范式如何简化异步数据处理,提高代码的可维护性和效率,为读者提供从传统命令式编程向声明式编程转型的新视角。 ####
|
11月前
|
存储 缓存 资源调度
# Qwen3-8B 的 TTFT 性能分析:16K 与 32K 输入 Prompt 的推算公式与底层原理详解
Qwen3-8B 是通义实验室推出的 80 亿参数大模型,支持最长 32,768 token 上下文,适用于长文本处理场景。通过 FP8 量化、CUDA Kernel 优化及 RoPE 位置编码技术,提升推理效率与稳定性。模型在 16K 输入下 TTFT 约 150-200ms,32K 输入下约 250-300ms,适用于文档摘要与长对话交互。
3001 8
|
存储 安全 数据库
阿里巴巴的云计算平台有哪些服务?
【7月更文挑战第1天】阿里巴巴的云计算平台有哪些服务?
1934 57
|
Serverless API
【MCP教程系列】在阿里云百炼,实现超级简单的MCP服务部署
阿里云百炼推出业界首个全生命周期MCP服务,支持一键在线注册托管。企业可将自研或外部MCP服务部署于阿里云百炼平台,借助FC函数计算能力,免去资源购买与服务部署的复杂流程,快速实现开发。创建MCP服务仅需四步,平台提供预置服务与自定义部署选项,如通过npx安装代码配置Flomo等服务。还可直接在控制台开通预置服务,体验高效便捷的企业级解决方案。
4344 0
|
人工智能 智能设计 安全
2024云栖大会《设计的未来&未来的设计》全记录
2024云栖大会《设计的未来&未来的设计》全记录
|
Web App开发 XML 开发框架
技术心得记录:在IE浏览器中的奇怪页面表现
技术心得记录:在IE浏览器中的奇怪页面表现
323 0
|
网络安全 Nacos 开发者
【Nacos】神操作!节点提示暂时不可用?别急!7步排查法+实战代码,手把手教你解决Nacos服务实例状态异常,让服务瞬间满血复活!
【8月更文挑战第15天】Nacos作为微服务注册与配置中心,虽广受好评,但仍可能遇到“节点提示暂时不可用”的问题。本文解析此现象及其解决之道。首先需理解该提示意味着服务实例未能正常响应。解决步骤包括:检查服务状态与网络、审查Nacos配置、调整健康检查策略、重启服务及分析日志。通过系统化排查,可有效保障服务稳定运行。
1289 0
|
机器人 C++ Python
[ROS2] --- 通信接口
[ROS2] --- 通信接口
641 0
|
存储 Linux 数据处理
【阿里云】对象存储 OSS 产品评测
对象存储服务的全流程使用体验,带你由浅入深玩转 OSS 的日常操作
5413 4
【阿里云】对象存储 OSS 产品评测
|
JavaScript Java 测试技术
基于springboot+vue.js+uniapp小程序的高校学生选课系统附带文章源码部署视频讲解等
基于springboot+vue.js+uniapp小程序的高校学生选课系统附带文章源码部署视频讲解等
255 4