虽然，一个放之四海而皆准的方法是不存在的，但在更高的层面上，笔者仍然觉得这是可行的。也就是说，管理模型是一致的，但是其中采用的方法可能各有不同。最终目标是唯一的：打造一支可以快速适应变化的高质量团队，并输出高质量的产品！ 用户故事的主要问题 用户故事可以帮助开发团队从用户的角度来理解需求，

查看更多 →

Scrum项目类型中，预置了敏捷实践中推荐的“Epic > Feature > Story > Task”的四层模型。 按迭代持续交付，实现闭环反馈 Scrum是增量迭代式的软件开发方法，也是当前主流的敏捷开发过程。通过迭代冲刺的方式，持续交付，从用户需求到用户反馈实现各个迭代闭环的软件开发过程。

查看更多 →

Master也不应该冒昧干预，这样的自组织拥有非凡的稳定性和产生惊人的新颖性。 由T型技能的员工组成 T型技能的意思是即要有深度又要有广度。 团队成员拥有适合的技能，覆盖各个专业领域，并且总体上技能有一些重叠，团队有额外的灵活性。有深度的专家型的员工，可以分配到数量合理的产品团队中，但不能让他

查看更多 →

Scrum项目实践概述 Scrum适用于敏捷开发模式的研发管理平台，短周期持续交付，快速响应需求和市场变化。一个完整的Scrum迭代流程大概涉及需求规划、迭代计划、迭代开发、敏捷回顾四个阶段，整体流程图如图1所示。 图1 Scrum迭代流程 本文将基于前期和大量客户交流识别出来的

查看更多 →

持续规划与设计 什么是敏捷 影响地图 用户故事地图 用户故事驱动的敏捷开发 我在CodeArts做需求 Scrum的22个基础知识点 Scrum实践之团队 Scrum实践之冲刺 敏捷项目管理 敏捷实践之物理看板与电子看板

查看更多 →

团队不断提高自己的技能，鼓励探索和创新。 更多关于自组织的相关内容不在本文的范围内，如感兴趣请参阅参考文档。 从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，而开发任务也就由原来的指派变

查看更多 →

同时需求管理服务为用户提供思维导图的需求规划与分解功能。 迭代 在敏捷软件开发的语境下，迭代是重复式的持续交付并持续获取反馈的软件开发活动，其对应的是瀑布式软件开发中的固定顺序全部完成才交付的软件活动。 每一个迭代都追求尽可能的发布产品并获取用户的反馈，每次迭代获取的反馈都同时作为下一个迭代的改进输入。

查看更多 →

产生的价值是千差万别的，有可能我们浪费精力跟踪得来的指标最终只代表了一些数字，除了评估之外不会产生其他附加的价值，对团队的进步也起不到一定的帮助。因此，选择合适的度量指标，获得较高的度量投资回报率对团队起到的帮助的很大的。 缺陷跟踪也是敏捷团队在项目转型过程中一个比较矛盾的地方，

查看更多 →

团队级敏捷导入，即在涉及一个开发团队的范围内应用Scrum。Scrum所定义的开发团队规模为5-9人，可以完整交付一个有价值的产品增量。按照Scrum指南的定义，Scrum团队包括了产品负责人、Scrum Master以及开发团队。团队级敏捷导入标准包，基于客户团队管理和软件生命

查看更多 →

锁定在某一很窄的专业技能上。 共识：团队因为有共同的交付目标而走到一起，并且 共同承担每项特性的责任，所以一定程度的开放是必须的。很多团队 重新组织、规划远景、再分配资源、改变计划都没有遇到棘手的分歧。 均衡：全功能团队中的均衡指的是不同技能、不同任务、不同观点的均衡。 全功能团队的优势：

查看更多 →

《华为云CodeArts实践DevOps开发培训基础课件》 《CodeArts的代码托管操作手册》 《CodeArts代码检查操作手册》 《CodeArts编译构建模块的操作手册》 《CodeArts的测试计划操作手册》 《CodeArts部署模块的操作手册》 《CodeArts流水线模块的操作手册》 《DevOps工程师工作指南》

查看更多 →

板。 Scrum：适用于敏捷开发模式的研发管理平台，短周期持续交付，快速响应需求和市场变化。 看板：适用于轻量团队看板模板。 Scrum的基本使用流程分三种场景： 项目经理：快速创建并设置项目 开发人员：快速进入项目处理工作 项目经理：快速掌握项目进展和风险 本文中涉及的操作角色说明：

查看更多 →

有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。 Scrum Kanban（看板方法）

查看更多 →

Scrum项目最佳实践 Scrum项目实践概述 需求管理 迭代计划 迭代开发 敏捷回顾 成员管理 附录

查看更多 →

了解更多常见问题、案例和解决方案 热门案例 Scrum项目的开发流程是怎么样的？ Scrum项目如何做需求规划和需求分解？ 更多 项目 如何使用Scrum项目 如何限制用户“新建项目” 更多 工作项 Scrum项目如何导出全部类型的工作项 被指派的处理人可以修改工作项的哪些内容 更多 技术专题 技术、观点、课程专题呈现

查看更多 →

产品优势 专业方法论与实践的承载 承载敏捷管理、精益的软件项目需求管理理念。 支持Scrum项目和看板项目模板，面向不同的软件管理场景，兼顾标准和轻量灵活的软件开发场景。 支持Scrum推荐的需求规划和需求分解层次。 支持敏捷迭代开发、迭代计划和时间线清晰展现项目进展。 内置IPD等多种研发模式

查看更多 →

敏捷回顾 如何玩转每日站会 父主题： Scrum项目最佳实践

查看更多 →

变化随时可能发生。 交付周期 固定的Sprint时间盒。 完成一项工作的时间。 团队规模 项目需要有固定的迭代交付时间（2到4周）。 项目的初期探索迎合市场的阶段。 看板是比Scrum敏捷模式更简洁的模式，适合小、微团队和个体开发者。 团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级。

查看更多 →

品是如何制定它的开发计划的。 两级项目计划 计划是演进的，试图在项目一开始制定“完备”的甚至是“完美”的计划是不现实的。做计划的目的之一是减少风险，但在信息最少的项目初期阶段做出最重要的决定是不切实际并且风险巨大的。 敏捷计划的模式是渐进式的，一开始只规划一个大的方向，并制定最近

查看更多 →

在迭代中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。 挑选的需求在迭代计划会议上经过讨论、分析和估算得到相应的任务列表，称为迭代Backlog。 在每个迭代结束时，Scrum团队将递交可交付的产品增量需求。 Scrum流程是标准的敏捷开发流程，工作项层级为传统的Scrum划分方法，为“Epic

查看更多 →

图2 支持敏捷开发模式的双模模式 一般来讲，组织在经历了最初敏捷尝试（包括相关专题）之后，通常都会面临敏捷实践的团队级向项目级扩展的问题，在团队级（通常是敏捷实践局限在开发团队内部）无法交付完整的业务价值，也使得敏捷所倡导的业务价值驱动交付较难得以实现。所以，成功的试点很自然会考虑进

查看更多 →