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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

驱动开发等。 From:《敏捷软件测试：测试人员与敏捷团队的实践指南》 团队构成 敏捷项目团队是跨职能的，敏捷团队与传统的跨职能团队的区别就是敏捷是向整体团队运作的方向努力，但是不可避免的是每个成员都有出于他自己的背景，尤其是团队组建初期。不同背景的成员给团队带来的既有不好的地方

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

迭代才能完成最终的交付。 Epic应该对所有研发人员可见，这样可以让研发人员了解交付的Story承载怎样的战略举措，让研发人员能更好的理解其工作的价值。 Epic通常和公司的经营、竞争力、市场环境紧密相关，举例如下： 市场差异化：用户体验全面超越竞争对手。 更好的解决方案：新增支持 工业互联网 的解决方案。

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

复杂的项目。 一致长度 每个冲刺的长度建议保持一致。 一致的持续期更有节奏感。冲刺中，稳定的节奏感让团队中的成员进入最好的状态；稳定的节奏感使单调而必要的活动成为习惯，从而让团队成员留出心力，集中做有趣、增值的工作。比如，为期一年的开发工作中执行时间盒为2周的冲刺，那么对于接下来

查看更多 →

布道师和产品经理，线下交流、布道、技术沙龙。 如何开好敏捷回顾会议 布道师和产品经理，线下交流、布道、技术沙龙。 智能客服 您好！我是有问必答知识渊博的 智能问答机器人 ，有问题欢迎随时求助哦！ 社区求助 华为云社区是华为云用户的聚集地。这里有来自容器服务的技术牛人，为您解决技术难题。

查看更多 →

《复盘+：把经验转化为能力》，邱昭良 Scrum指南（2017-Scrum-Guide-Chinese-Simplified），2017年11月版 Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社 Scrum指南2007版 Mark C. Layton. 敏捷项目管理[M]

查看更多 →

而DevOps的出现，是为了解决开发与运维之间的鸿沟。前端的敏捷的确是快了，却发现因为Dev与Ops之间的隔阂，无法真正的将价值持续的交付给客户。 开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定

查看更多 →