首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何在Team Services中将我的主板从CMMI更改为Agile?

在Team Services中将主板从CMMI更改为Agile,可以按照以下步骤进行操作:

  1. 登录到Team Services的控制台。
  2. 打开你的项目,并选择“设置”选项。
  3. 在“设置”页面中,选择“工程设置”。
  4. 在“工程设置”页面中,选择“过程”选项卡。
  5. 在“过程”选项卡中,你将看到一个“选择过程模板”部分。
  6. 在该部分中,你可以看到当前选择的过程模板,一般默认为CMMI。
  7. 点击“更改过程模板”按钮。
  8. 在弹出的对话框中,选择“Agile”作为新的过程模板。
  9. 点击“确定”按钮进行确认。
  10. 系统将会开始将你的主板从CMMI更改为Agile,这个过程可能需要一些时间。
  11. 当过程完成后,你的主板将会成功更改为Agile。

值得注意的是,将主板从CMMI更改为Agile可能会导致一些配置和设置的变化,因此在进行此操作之前,建议备份你的项目数据以及相关配置。此外,更改过程模板可能会影响到项目的工作流程和团队成员的角色分配,建议在更改之前与团队成员进行充分的沟通和准备。

关于Team Services的更多信息和使用指南,你可以参考腾讯云的产品介绍页面:Team Services产品介绍

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • .Net Core with 微服务 - 使用 AgileDT 快速实现基于可靠消息的分布式事务

    前面对于分布式事务也讲了好几篇了(可靠消息最终一致性 分布式事务 - TCC 分布式事务 - 2PC、3PC),但是还没有实战过。那么本篇我们就来演示下如何在 .NET 环境下实现一个基于可靠消息的分布式事务。基于可靠消息的分布式事务流程上还是比较清晰明了的,但是要用代码去一个个实现还是比较费事的。通过分析可以发现这个事务的关键点就是要在真正的业务逻辑的前面、后面插入对应的流程。很明显这种流程是可以通过 AOP 技术来简化操作的。于是就有了 AgileDT 。AgileDT 使用 Natasha 在启动的时候动态生成代理类,来为你完成跟消息部分的操作,使用者只需关心核心业务逻辑就可以了。 https://github.com/kklldog/AgileDT 开源不易,大家多多 ✨✨✨

    02

    .Net Core with 微服务 - 使用 AgileDT 快速实现基于可靠消息的分布式事务

    前面对于分布式事务也讲了好几篇了(可靠消息最终一致性 分布式事务 - TCC 分布式事务 - 2PC、3PC),但是还没有实战过。那么本篇我们就来演示下如何在 .NET 环境下实现一个基于可靠消息的分布式事务。基于可靠消息的分布式事务流程上还是比较清晰明了的,但是要用代码去一个个实现还是比较费事的。通过分析可以发现这个事务的关键点就是要在真正的业务逻辑的前面、后面插入对应的流程。很明显这种流程是可以通过 AOP 技术来简化操作的。于是就有了 AgileDT 。AgileDT 使用 Natasha 在启动的时候动态生成代理类,来为你完成跟消息部分的操作,使用者只需关心核心业务逻辑就可以了。 https://github.com/kklldog/AgileDT 开源不易,大家多多 ✨✨✨

    04

    Artifacts VS OPA

    1 过程财富库的含义 CMMI中提到的organizational process assets 通常翻译为组织过程资产或者是组织过程财富,可以简写为OPA。 什么是OPA呢?按照V1.3中的术语定义: Artifacts that relate to describing, implementing, and improving processes. Examples of these artifacts include policies, measurement descriptions, process descriptions, process implementation support tools. The term “process assets” is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value. (See also “process asset library.”) 对上述的定义需要这么来理解: (1) the artifacts of describing processes,描述过程的制品,如方针、度量元定义、过程定义、规程定义、指南等; (2) the artifacts of implementing processes,实施过程的制品,如文档模板、过程裁剪报告、检查单等; (3) the artifacts of improving processes,改进过程的制品,如过程改进建议、经验教训总结等; 之所以用”assets”这个单词是从投资回报的角度来讲,过程财富不是只有投入没有产出的,是可以给我们带来回报的,过程财富服务于商业目标的。 在OPD过程域中SP 1.7 Establish Rules and Guidelines for Teams中还描述了在组织过程资产中还包括了: 团队结构指南; 团队信息指南; 团队授权和职责指南; 建立沟通渠道、授权和扩编指南; 团队负责人筛选准则等。 由以上可以看出,凡事在组织内有共享价值的与管理有关的资料都可以称为过程财富。 2 过程财富库中的内容 对于过程财富库在CMMI中做了如下的定义: A library of information used to store and make process assets available that are useful to those who are defining, implementing, and managing processes in the organization. This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons learned documents, templates, standards, procedures, plans, and training materials. 对于过程财富库中的内容在SP 1.5 Establish the Organization’s Process Asset Library中作了如下的举例: 过程财富库中包含了如下的内容: 组织级的方针; 过程描述; 规程(如估算规程); 开发计划; 采购计划; 质量保证计划; 培训材料; 过程支持工具(如检查单); 经验教训报告等。 在这个举例中,列举的3个计划,可以理解为是计划的模板,而不是某个项目的具体计划,如果是理解为某个项目的具

    02

    CMMI是什么? 看完这篇你就懂了

    最近受朋友公司所托,帮他们的测试团队与产品线质量保障体系业务进行业务咨询。其中让我比较感兴趣的就是一个50人的测试部门,从5年前的初创的十几人团队开始,经历了从混乱到有序的流程演变,通过团队乃至公司整体的意识认知与实际行动,自始至终将产品质量思维贯彻其中,最后让公司通过了CMMI4级认证。能获得这样的成,最根本的原因就在于公司上下团结一致,各层部门与人员有效的发挥着各自的作用,坚持不断创新、总结、优化各类工作流程与项目经验。而更难得的是公司内的人员与团队又始终保持着高度的目的与价值观统一。这样的公司总体来说想不成功都很难。

    03

    什么是软件质量?

    Functional Quality - How well software complies with or conforms to customer specifications.Structural Quality - How software meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability.质量是个很抽象的相对概念,如果打个比喻的话,会觉得质量和安全感有很多相似之处。安全感是什么?看不见摸不着,是不怕走夜路?不怕下水?抑或可以自在独处?每个人对安全感的要求是不一样的,同一个人在不同的年龄段对安全感的要求也不一样。襁褓中的婴儿大部分都很怕和母亲分离,因为他们和母亲从生命开始的那一刻起就有了切不断的联系,他们怕离开母亲独自面对子宫以外的环境。有些人可能因为小时候有溺水的经历,即便成年之后,也无法涉水,对河流,大海有难以言状的恐惧。同样的,在不同行业,有不同的质量标准。广义上讲,我们有食品质量,有工程质量,有软件质量等等。狭义到我们的软件开发,即使同一产品,不同的用户对产品质量的高低感受肯定也是有个体差异的。另外质量像安全一样是个相对的概念,一般情况下我们会认为家里相对马路上来说是更安全的。但这是一般大概率的情况下,但当地震发生的时候,空旷的马路上也许就比家里安全多了。质量也一样,软件质量的优劣,是需要满足特定行业特定用户群体的产品诉求,符合某一年龄段或者特定性别用户的使用习惯,兼容大部分目标用户特定设备需求等等。软件质量是一个抽象的存在软件质量在线的时候我们是比较难察觉它的存在的,我们不知道它就存在于我们的每一次需求讨论中、每一念的设计斟酌里、每一回车的代码提交时。但是一旦有客户抱怨产品不好用,或者发现产品缺陷时,质量这个隐形的存在似乎就变得特别醒目。貌似跟我们的健康一样,我们健健康康的时候,很少觉察到健康的重要性,快乐地熬着夜撸着串。但是一旦我们生病了,这要忌口,那要注意,我们惊觉原来健康和我们的一餐一眠,一时一刻的情绪都息息相关。软件质量是各个质量属性的综合通常情况下,人们习惯说好的软件质量就是实现了客户对软件的所有需求。但是什么是需求呢?在敏捷开发环境下,我们用用户故事来管理,沟通产品需求。而用户故事我们通常会归类为功能需求和非功能需求。举个例子,小区门禁系统通过人脸识别实现自动开门,这是个很明确的功能需求。满足了功能需求我们就能说这个软件的质量很好了吗?某天某位业主画了个浓妆,或者剪了个刘海,该系统无法识别了,功能无法满足了。你会发现,通常功能性需求和非功能性需求是交织在一起的,很多非功能性需求是为了辅助功能性需求的更好实现。软件质量一定是需要去界定质量特性,及满足这些特性应该具备哪些质量属性。再举个例子,我们可以拿生活中送礼物这事儿来类比。比如情人节到了,我们或多或少会期望收到一份来自另一半的礼物。而且还期待对方能无需提示,主动自愿,悄咪咪地准备一个自己心仪的礼物。把‘收到礼物’ 看作‘What’,那‘无需提示,主动自愿,悄咪咪地准备’,就是‘How’。如果跟你说:钱都在你那里,你想买什么自己买就是了。毫无仪式感和主动性,这个礼物会让人开心吗?质量模型作为一个妈妈(被迫营业的非专业的育儿家),我知道孩子的安全感是可以被定义为很多维度的:满足感,可控感,信任感等等。而且这些不同的安全感有其特定的建立阶段,例如一岁之前,如果孩子能得到父母很好的照顾,持续的慈爱,婴儿的满足感就能被适当建立。我相信育儿专家们对孩子的安全感一定有更专业的系统定义、建立及评估方法。质量也一样,即使很抽象,具有行业差异,但是IT从业者从来没放弃过对其进行定义和评估,因此产生了各种不同的质量评估模型。

    01
    领券