检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
请求什么类型的操作。 GET:请求服务器返回指定资源。 PUT:请求服务器更新指定资源。 POST:请求服务器新增资源或执行特殊操作。 DELETE:请求服务器删除指定资源,如删除对象等。 HEAD:请求服务器资源头部。 PATCH:请求服务器更新资源的部分内容。当资源不存在的时
如何查看CodeArts Req当前使用的总用户数? 在软件开发生产线控制台总览页中,可以查看需求管理中当前使用的总人数(用户数)。 由于控制台中数据并非实时刷新,为每个小时刷新一次,若要查看实时的用户数,请进入需求管理首页,查看实际的项目人数,以此为准。 父主题: 成员管理
用户为CodeArts项目成员进行操作。 操作完成后,子账号通过IAM用户登录CodeArts访问需求管理服务即可,详细操作请参见IAM用户登录。 父主题: 成员管理
如何处理IPD类项目导入工作项条数校验异常的问题? 问题现象 在IPD项目中,导入包含300条数据的工作项文件后提示“导入工作项单次数据量最大仅支持300个”。 原因分析 导入的工作项文件中存在有格式的多余空行或者已删除的工作项数据。已删除的工作项数据可能会被识别为空行。 处理方法
所示。 图1 站会常见问题 如何正确的开站会?站会的意义在哪里?可以不开站会吗?这些问题一直困惑着不少的团队。 问题分析 关于站会的问题大致分为两种场景: 场景一:团队非常清楚应该开站会,认识到站会确实有一些价值,但是对于目前的站会状况不是很满意,如何玩转站会是团队关心的。对于这
如何删除文件夹下临时文件? 问题现象 文件库内上传文件夹时,统计的文件数量与本地文件夹内的文件数量不一致。 原因分析 本地文件夹内可能产生了不可见的临时文件。 处理方法 在本地文件夹内通过鼠标右键菜单打开Git bash Here,使用如下命令查看该文件夹下的所有文件。 ls -a
Scrum项目工作项如何分配给多个人员? Scrum项目中,一个工作项仅指定一个处理人。 如果需要将工作项指定多个处理人,可以给工作项创建多个子工作项,分别指定处理人。 父主题: 工作项
如何在软件开发团队中管理突发性任务 背景 开发团队如何管理突发性工作?企业的一些软件开发团队经常出现类似培训支撑等突发性工作,开发团队不清楚如何管理好这样的工作。解决突发性工作的问题被很多开发团队所重视,它直接影响开发团队工作的进度和效率,间接影响迭代目标是否能完成,甚至整个项目
如何调用API 构造请求 认证鉴权 返回结果
如何在项目团队人员变动频繁时对新人进行有效培养和管理 背景 企业随着业务的扩张,需要新员工不断加入,经常会遇到这样的问题,其开发组长要对每一位新人交代相关的知识点、工作方式以及团队信息等,工作量在短期内激增。在一个项目中,随着时间推移、业务的扩张,项目中的核心成员,如项目经理、开
息头,从而通过身份认证。 AK(Access Key ID):访问密钥ID。与私有访问密钥关联的唯一标识符;访问密钥ID和私有访问密钥一起使用,对请求进行加密签名。 SK(Secret Access Key):与访问密钥ID结合使用的密钥,对请求进行加密签名,可标识发送方,并防止请求被修改。
如何有效管理项目成员的权限 背景 本文主要是解决客服管理成员权限分配、成员添加的问题。 问题分析 如何使用IAM来控制权限? 通常一个IAM主账号下,可以创建多个软件开发项目。默认情况下,只有IAM主账号默认可以设置是否能允许子账号创建项目,只有IAM主账号能查看所有项目和成员等
”就是需要获取的用户Token。有了Token之后,您就可以使用Token认证调用其他API。 图1 获取用户Token响应消息头 响应消息体 响应消息体通常以结构化格式返回,与响应消息头中Content-type对应,传递除响应消息头之外的内容。 对于获取用户Token获取请求
如何避免重要需求遗漏 避免重要需求遗漏的思路 避免重要需求遗漏,首先需要反问一句——为什么这些紧急重要的需求无法更早预见?同样的,需要了解: 具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理。 增加的需求有无共性特点?有的话,可以针对性处理。 临时增加有多临时?是否
说明。 按需计费项 需求管理服务的计费项为用户数和存储空间。 用户数,即用于计费计量的用户数,是该租户下加入项目的去重用户数,也包括从其他租户邀请加入到本租户项目的用户数。 如果该租户下的某个用户加入该租户下的多个项目,也只作为一个用户数计费。 例如:有A、B两个项目,A项目10
团队成员间知识共享,随着能力提升学习成本会逐渐减少。 2 工作领域不熟悉,需要学习成本 3 用户故事比较大 由于工作项的特殊性,用户故事普遍比较大,可以考虑拆分为更小的故事,或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。 4 PO完成标准高
int才能够完成。 Story:通常所说的用户故事,是User Story的简称。Story是从用户角度对产品功能的详细描述,承接Feature,并放入产品Backlog中,持续规划,滚动调整,始终让高优先级Story交付给客户,具有用户价值。Story要符合INVEST原则(I
Failed 未满足前提条件,服务器未满足请求者在请求中设置的其中一个前提条件。 413 Request Entity Too Large 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息。
将产品或系统的业务模块作为Epic,比如用户中心、购物车、配送管理等,比如一家货运云商的油卡业务,就适合作为一个Epic,针对油卡的各种功能,就可以作为Feature展开。 Feature要承载用户价值,也即对于用户来说,是可以理解这个Feature,且认可其价值的,通常Feature也是用户可以直接感知、可以操作的。
包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来,同样,建议记录在知识库中。用于后续的复盘回顾中作为参考信息,比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。 图3 Sprint回顾会议记录 改进优先级模型 市场在变化,用户在变化,产品在变化,优先