检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
服务韧性 需求管理通过多活无状态的跨AZ部署、AZ之间数据容灾等技术方案,保证业务进程故障时快速拉起并修复,以保障服务的持久性和可靠性。 父主题: 安全
都会面临如下几种情况和挑战: 新员工加入,需要诸多方面的培养(培训),以便能快速进入工作状态。 老员工的离职,导致项目中缺少能了解和掌握关键技术和业务的人员。 员工在工作了一段时间后,对自己的规划有了新的想法,从而想要转换工作方向。 那么,项目负责人应该如何应对这些事件呢? 问题分析
可以将所要解决的问题重新描述如下: 如何进行需求结构化管理? 如何进行需求优先级管理? 如何避免重要需求遗漏? 如何进行需求结构化管理? 首先,并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联,而且即便是已经实现的需求也需要进行一定的管理、维护的情
本节介绍REST API请求的组成,并以调用IAM服务的获取用户Token获取请求认证接口说明如何调用API,该API获取用户的Token,Token可以用于调用其他API时鉴权。 您还可以通过这个视频教程了解如何构造请求调用API:https://bbs.huaweicloud.com/videos/102987
如何理解敏捷需求管理的四个关键词 背景 常见到Epic、Feature、Story和Task这些和敏捷相关的概念,它们之间的关系是什么?如何灵活使用这些概念,从而让敏捷的需求管理更为高效?本文为您详细剖析这四个关键词。 什么是Epic、Feature、Story和Task? Ep
返回结果 状态码 请求发送以后,您会收到响应,包含状态码、响应消息头和消息体。 状态码是一组从1xx到5xx的数字代码,状态码表示了请求响应的状态,完整的状态码列表请参见状态码。 对于获取用户Token获取请求认证接口,如果调用后返回状态码为“201”,则表示请求成功。 响应消息头
如何进行需求结构化管理 为什么要进行需求结构化管理? 并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求,也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联,那么不需要思考需求结构化管理这个问题。这种情况下,不
例如:项目中在免费额度(5个人)基础上再加入1个人,则此时需求管理服务的用户数共有6(即5+1)人,计费也按照6个人计费。 当前用户数和存储空间按小时计量和计费。 表1 服务计费标准 计费因子 价格 价格单位 用户数*时间 0.08 元/用户/小时 存储空间*时间 0.000442 元/GB/小时
最佳实践和关键点来帮助团队开好站会。 解决措施 如何玩转站会?按照如下思路学习下。 图2 站会学习思路 理解站会价值 团队每天站着召开的短时间会议称之为每日站会。每日站会是团队对每天工作检视和调整,提前进行自组织。 通过站会团队每个人可以了解全局,知道发生了什么事情,实现冲刺目标
K/SK对请求进行签名,也可以使用专门的签名SDK对请求进行签名。详细的签名方法和SDK使用方法请参见API签名指南。 签名SDK只提供签名功能,与服务提供的SDK不同,使用时请注意。 父主题: 如何调用API
如何调用API 构造请求 认证鉴权 返回结果
如何在软件开发团队中管理突发性任务 背景 开发团队如何管理突发性工作?企业的一些软件开发团队经常出现类似培训支撑等突发性工作,开发团队不清楚如何管理好这样的工作。解决突发性工作的问题被很多开发团队所重视,它直接影响开发团队工作的进度和效率,间接影响迭代目标是否能完成,甚至整个项目
Req提供的看板项目是一种业界流行的轻量、灵活和简单的团队协作方法,它将项目的需求、缺陷和任务可视,让每个人一目了然地掌握每项工作的状态,团队通过移动工作卡片的方式更新工作进展,及时暴露风险和问题。 用户可以创建看板项目对项目进行需求规划,通过新建工作项、分配工作项、处理工作项等来实现项目的需求规划与交付
如何有效管理项目成员的权限 背景 本文主要是解决客服管理成员权限分配、成员添加的问题。 问题分析 如何使用IAM来控制权限? 通常一个IAM主账号下,可以创建多个软件开发项目。默认情况下,只有IAM主账号默认可以设置是否能允许子账号创建项目,只有IAM主账号能查看所有项目和成员等
序”字段来实现,该字段取值范围1~100。 图2 Story工作项优先级顺序展示 调整需求优先级顺序 调整顺序本身非常简单,只要在CodeArts中重新设定该需求的“优先级顺序”字段的值就可以。但重要的是,需要将优先级顺序调整这件事情记录下来,包括为什么要调整、具体如何调整的、调
基线管理和变更评审 产品从规划到上市要经过复杂的研发过程,Req工具的IPD需求管理提供了基线评审和变更管理能力,实现版本基线-受控变更-变更评审-变更管理过程,让基线变更如门禁一样,达到阈值才能启动下一步,确保产品研发“做正确的事”。 支持将发布/迭代基线化,基线后,不能再修改
进措施。 事后的处理 事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,
团队成员自己“拉”工作,不是被动等待领导分配工作。 团队作为一个整体管理工作。 团队仍然需要辅导和指导,但不需要指挥和控制。 团队成员彼此沟通紧密,互通有无。 团队主动发现和提出问题并共同解决。 团队不断提高自己的技能,鼓励探索和创新。 更多关于自组织的相关内容不在本文的范围内,如感兴趣请参阅参考文档。
如何移动迭代中需求变更后看板中的任务卡片 背景 围绕迭代中需求变更后,如何移动看板中的任务卡片,本文将从正常情况下的移动和需求变更情况下的移动两个方面进行细致讲解。 正常情况下的移动 使用看板主要意图之一是控制在制品数量(WIP,work in process),需要拉动式的移动
布式开发有里程碑,例如分析、设计、编码、测试和运行。这些里程碑其实是一些不太准确的指标。Scrum在每个冲刺结束时会有一个有意义的检查点(冲刺评审会议),团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正,就能更好地应对复杂的项目。 父主题: 迭代计划