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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

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

查看更多 →

先制定一个能够明确表达主题的提示词（若模型训练时包含相似任务，可参考模型训练使用的提示词），再由简至繁，逐步增加细节和说明。打好基础是后续提示词优化的前提，基础提示词生成效果差，优化只会事倍功半。 例如，文学创作类可以使用“请创作一个关于{故事主题}的故事”，邮件写作类可以使用“根

查看更多 →

根据实际需要对系统字段或自定义字段的“新建页显示”进行设定。 根据实际需要对系统字段或自定义字段的“是否必填”进行设定。 根据实际需要对系统字段或自定义字段的“默认值”进行设定。 根据实际需要对系统字段或自定义字段的“是否基线锁定”进行设定。 鼠标单击工作项字段左侧的，可根据实际需要对字段顺序进行拖拽修改。

查看更多 →

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

查看更多 →

根据实际需要对系统字段或自定义字段的“新建页显示”进行设定。 根据实际需要对系统字段或自定义字段的“是否必填”进行设定。 根据实际需要对系统字段或自定义字段的“默认值”进行设定。 鼠标单击工作项字段左侧的，可根据实际需要对字段顺序进行拖拽修改。 选择“工作项管理 > 用户故事(US) > 描述模

查看更多 →

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

查看更多 →

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

查看更多 →

单击左侧，在“全部状态”中选择“新建的公共状态01”拖拽至状态流画布中，根据需要用鼠标绘制该状态的流入线和流出线，单击“执行”，可完成状态流的更新。 图1 展开全部状态 在项目的“工作项 > 需求管理 > 工作项”中，用户故事(US)已配置的状态流转中会显示参数“新建的公共状态01”。 已自定义好的公共状态

查看更多 →

此处仅以用户故事(US)类型工作项模板为例操作。每种类型的工作项模板只需添加一次，其他类型工作项模板添加公共字段的方式一样。 在项目下自定义公共字段的个数最大为100个。 在租户设置中配置工作项的公共字段 字段管理是租户级的公共字段库，在此页面中新建的字段，可以配置在租户下所有IPD类型项目工作项中。 登

查看更多 →

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

查看更多 →

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

查看更多 →