不能方便地利用递增和迭代的方式去确定发布计划以及发布目标。 当开始进行一个产品或者项目规划的时候，首先需要梳理出一个backlog，在其中按照优先级列出所要实现的场景和具体功能。这时我们首先遇到的一个问题就是：如何确保backlog覆盖了最重要的用户体验路径，是否我们当前所规划的场景确实可以为用户提供价值？这点对于敏捷开发非常重要。

查看更多 →

Scrum所使用的工件很简单，主要包括： Sprint待办列表 Sprint Backlog 产品待办列表 Product Backlog 增量 Increment 05 什么是产品待办列表？ 在团队获取可用的Sprint待办列表sprint backlog之前，PO需要使用另外一个列表来管理新特性、变更

查看更多 →

创建外出推送积压策略 create-routing-backlog-policy createRoutingBacklogPolicy 修改外出推送积压策略 update-routing-backlog-policy updateRoutingBacklogPolicy 删除外出推送积压策略

查看更多 →

最小长度：1 最大长度：32 name String 状态名称 最小长度：1 最大长度：60 type String 工作项状态的类型， BACK LOG ( "初始化"), READY("待启动"), IN_PROGRESS("进行中"), COMPLETE("已完成"), DONE("已结束")

查看更多 →

startup.allocated Redis启动占用的内存字节数 replication.backlog Redis复制积压缓冲区（replication backlog）内存使用字节数，通过repl-backlog-size参数设置，默认1M clients.slaves 在master侧，所有slave

查看更多 →

参数 推荐值 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.core.netdev_max_backlog 65535 net.ipv4.tcp_retries1 5 net.ipv4.tcp_retries2

查看更多 →

indicators, including completed shipbuilding, new orders, and order backlog, is ranked first in the world. 父主题： 文案样例（基础版）

查看更多 →

somaxconn = 1024 net.ipv4.tcp_max_tw_buckets = 5000 net.ipv4.tcp_max_syn_backlog = 1024 kernel.pid_max = 65530 父主题： 操作系统类（Linux）

查看更多 →

以当成用户故事（User Story）排进产品待办事项（Product Backlog）开始开发了呢？答案是还不可以。 用户故事是敏捷开发中普遍使用的实践，但常见的困惑是：产品负责人整理了一大堆的产品Backlog，还编排了优先级，过早地陷入到细节的讨论中，只见树木不见森林。 传

查看更多 →

net.core.somaxconn net.ipv4.tcp_max_tw_buckets net.ipv4.tcp_max_syn_backlog /etc/sysctl.d/huawei.conf * soft nofile 65535 * hard nofile 65535

查看更多 →

默认的TCP数据发送窗口大小（字节）。 net.core.wmem_max 最大的TCP数据发送窗口（字节）。 net.core.netdev_max_backlog 在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。 net.core.somaxconn

查看更多 →

工作。 在迭代计划会议上，产品经理PD对高优先级需求进行串讲，团队提出问题，并充实或调整产品Backlog的优先级，进而设定Sprint目标。根据团队速率，选择进行Sprint Backlog填充。以目前一周的迭代长度而言，这一过程大概会进行1-2小时。 通过CodeArts提供

查看更多 →

Smell，用户故事也一样会有坏味道： 几十页上百项需求堆在Product Backlog里。 提交的需求，自始至终没人和你沟通，某一天突然发现需求被实现了。 排在Product Backlog中段和后段的用户故事太过详尽。 大家依赖Product Backlog电子系统，而不是面对面进行沟通。 用户故事长得像需求规格说明书。

查看更多 →

通过配置容器内核参数增大监听队列长度 使用场景 net.core.somaxconn默认监听队列（backlog）长度为128，当服务繁忙时，如果连接请求超过了监听队列的长度，新的连接请求将会被拒绝。为了避免这种情况的发生，您可以通过配置内核参数net.core.somaxconn来增大监听队列的长度。

查看更多 →

单击“使用模板”进入画布编排界面。 单击“CodeArts Req”节点事件，按照页面提示完成“选择连接”和“配置参数”配置。 单击“修改Jira工作项状态为Backlog”节点事件，按照页面提示完成“选择连接”和“配置参数”配置。 保存该业务流程编排到组合应用，并对该业务流进行调式、启动等后续运行操作。

查看更多 →

对于模块清单的维护，可以在工作项编辑状态，单击“模块”字段右侧的，即可在弹出窗口进行操作，可以添加、修改、删除模块。 图3 编辑模块 在工作项管理的Backlog视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，也可以进行过滤。 父主题： 需求管理

查看更多 →

proto-max-bulk-len Redis协议中的最大的请求大小。 - 1,048,576～536,870,912 单位：字节 536,870,912 repl-backlog-size 用于增量同步的复制积压缓冲区大小。这是一个用来在从节点断开连接时，存放从节点数据的缓冲区，当从节点重新连接时，如果丢失

查看更多 →

通常翻译为用户故事，User Story的简称。是从用户角度对产品需求的详细描述，更小粒度的功能。 Story承接Feature，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的Story更早的交付给客户。 Story应遵循如下的INVEST原则： Indepe

查看更多 →

参数解释: 查询类型, 约束限制：正则表达式，^(epic|feature|backlog|\s*)$ 取值范围：backlog(Story|Task|Bug), feature, epic 默认取值：backlog severity_ids 否 Array of integers 参数解释:

查看更多 →

Req服务首页。 在项目主页，选择“工作项”。 选择视图类型。 全部：可以创建“Epic”、“FE”、“US”、“Task”、“Bug”类型的工作项。 Backlog：可以创建“US”、“Task”、“Bug”类型的工作项。 缺陷：只可以创建“Bug”类型的工作项。 单击“新建”，选择需要新建的

查看更多 →

量。 已使用的内存量包括两部分： 用户存储的数据； Redis-server内部的buffer（如client buffer、repl-backlog等），以及内部的数据结构。 CPU D CS 缓存实例的CPU架构。只有Redis实例才会显示该字段。实例创建后，不支持变更CPU架构。

查看更多 →