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

查看更多 →

以最小的投入发布对用户有价值的产品，快速试错，并通过不停的迭代最终找到产品的正确方向。 这个思路很好，但如何确认backlog中的内容是“最小的”而且“可用”的产品却是件很困难的事情。 团队一起讨论初始产品需求的时候，常常会因为团队成员的理解不同而花费大量的时间进行梳理。即使每次

查看更多 →

行，将重要的结论写在工作项提供的讨论功能中。简单的讨论可以直接通过工作项的讨论进行，但需要牢记的是，文字的讨论永远无法取代面对面或是电话的沟通。 Confirmation（确认）：用户故事并不具备契约性质，达成协议的验证要点是测试的依据，用来验证用户故事是否符合用户的期望。在用户

查看更多 →

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

查看更多 →

产品包需求：由产品经理/规划代表规划出来的、完整一致的、成系列的一组正式需求。 原则上特性是产品包的主要卖点（销售亮点）集合，每条特性都是满足客户特定商业价值诉求的端到端解决方案。其中，有一部分特性是可以通过License控制单独销售。 客户问题（PB） ：客户面对的挑战与机会（客户战略与痛点

查看更多 →

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

查看更多 →

速地发现和利用稍纵即逝的商机。 持续期短的冲刺所犯的错误也是有限的。在短短一周或两周的时间内，就算出现失误，也只是失去了短短的一周或两周的时间，不会带来巨大的损失。坚持持续期短的冲刺能够进行频繁地试错，协调和反馈。 持续期短的冲刺投入产出比（ROI）更高。持续期短可以更早、更频繁

查看更多 →

”持续交付也好，DevOps也罢，最终目标是快速的交付价值。 如果说管理实践的目的是为了鉴别什么是正确的事情，以及正确的做事情。那么工程实践的目的，是除了正确的做事情以外，还能高效的做事。 工程实践就像人体的肌肉，是强调执行力的，是大脑想到然后肌肉能够做到并且快速的做到。每一丝的赘肉都会影响身体执行的速度，所以需要

查看更多 →

参考文档 《Scrum精髓》，Kenneth S. Rubin 《用户故事与敏捷方法》，Mike Cohn 2019年中国DevOps行业现状报告：中国信息通信研究院、华为云DevCloud、南京大学联合发布 《用户故事实战》，Mike Cohn 《成为技术领导者》，杰拉尔德·温伯格 《复盘+：把经验转化为能力》，邱昭良

查看更多 →

完成该培训后，您将熟悉物联网的基本概念、发展历程、相关国家政策，掌握物联网技术架构知识，把握新技术（5G、AI）对物联网发展趋势的影响，全方位了解智慧家庭、园区及城市行业发展趋势与典型应用场景。 培训内容 培训内容 说明 物联网的前世今生 物联网概念，发展趋势，AIoT的概念与发展，物联网对政府和企业的重要性

查看更多 →

Master更多的需要和人打交道，很多实际问题的处理方式是必须在实践中才能体会的，有些还很微妙。 也许您对这些知识点的理解不尽相同，这没有关系，同样的框架和方法由于应用的环境与对象的不同，所使用的方法和理解也不一定一样，这也正是Scrum的特色之一，它帮助你找到最适合你的方式。Scrum并不是你需要严格执行的流程，而是帮助你找到适合自己的流程的框架。

查看更多 →

影响地图是一个简单却极高效的协作性的策略规划方法。 有的产品，它还活着，却已经死了；有的产品，还没发布，就已经死了。太多的产品失败的案例，源于方向性错误，基于错误的假设，功能与业务目标/价值之间缺乏必然的关联与一致性，在做的事与期望的目标南辕北辙。 影响地图试图通过结构化、可视化、协作化的方式来从源头解决上述问题。

查看更多 →

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

查看更多 →

用户D希望增加昵称功能，让用户更个性化。 US（用户故事） 中文通常翻译为用户故事，US的简称。是从用户角度对产品需求的详细描述，更小粒度的功能。 US承接FE，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的US更早的交付给客户。 US应遵循如下的INVEST原则： Inde

查看更多 →

找到相互提出批评意见的方法。因为团队成员对产品都负有责任。 归属感：在跨功能的全功能团队中，每个人逐渐开始与部分产品密切结合，而不是锁定在某一很窄的专业技能上。 共识：团队因为有共同的交付目标而走到一起，并且 共同承担每项特性的责任，所以一定程度的开放是必须的。很多团队 重新组织

查看更多 →

为“需求”以外的工作项。 原因分析 在Scrum项目中，Task更偏向具体开发任务，而不是一个完整的需求故事点。 因此测试用例仅可以关联Scrum项目的Epic/Feature/Story以及看板项目默认的“需求”类型的工作项，不支持关联Task及其它自定义类型的工作项。

查看更多 →

，将Scrum的框架与团队日常的开发活动，很好的融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表；核心的团队活动包括Sprint计划会议、团队每日站会、Sprint演示会议、Sprint回顾会议等会议、以及团队的日常更新。 同

查看更多 →

新建及更新测试计划时无法添加Task等类型的工作项 问题现象 Scrum项目下，测试计划添加需求时，无法选择类型为“Task”工作项。看板项目下，测试计划添加需求时，无法选择类型为“需求”以外的工作项。 原因分析 在Scrum项目中，Task更偏向具体开发任务，而不是一个完整的需求故事点。 因此测试计划

查看更多 →

，将Scrum的框架与团队日常的开发活动，很好的融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表；核心的团队活动包括Sprint计划会议、团队每日站会、Sprint演示会议、Sprint回顾会议等会议、以及团队的日常更新。 同

查看更多 →

，将Scrum的框架与团队日常的开发活动，很好的融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表；核心的团队活动包括Sprint计划会议、团队每日站会、Sprint演示会议、Sprint回顾会议等会议、以及团队的日常更新。 同

查看更多 →

采购招投标管理 主要功能：采购计划管理、采购过程管理（采购方案、发标、回标、开标、评标、定标)、战略采购管理、供应商投标协同，保障企业的招标采购过程的合规与公正。 说明： 包含采购门户 PC端、公众号端和 APP 端，云采购供应商资源服务(供应商寻源、精选供应商等） 资产管理 资管中心

查看更多 →