在敏捷开发的框架及方法中（比如：Scrum），有一个和sprint相关的概念叫product increment。它属于3大artifacts的一种，对于项目的推进和产品最终交付有着重要的意义。今天的文章中，睿珑学苑和大家分享的是：究竟什么是敏捷开发中的“product increment”？中文可以如何翻译？其优点或好处是什么？ 版权声明：如无特别说明，本站所有文章均由睿珑（Ruilong-edu.com）原创。我们欢迎少量文字引用，但请注明出处。任何网站或个人，未经授权，不得抄袭、转载、盗用本站内容，违者必究。 所谓的product increament，是指在每个sprint（冲刺）阶段中，开发团队都会完成的一些产品新增功能或特性，它们可能只是最终产品的一小部分。这些新增的功能或特性应该处于一种可用于交付的状态（deliverable state），满足项目的完成定义（Definition of Done，DoD）要求，并被PO（Product Owner）所认可。中文里，可以将product increment翻译为：产品增量。 产品增量的优点或好处在于：它不仅可以向利益相关者提供工作成果，且可以实际展示它，甚至让客户自己与产品进行交互。这会产生更有意义的反馈，帮助团队改进。需要注意的是，在软件研发环境中，创建潜在可交付产品增量通常是没有问题的。在硬件开发中，可能不一定适用或存在难度。

Story points是敏捷项目管理中的一个概念。中文里，有人将其翻译为“故事点”，也有将其译为“故事点数”，个人认为后面这个译法更为接近原意。 事实上，story points是对完成一个user story（用户故事）所需努力做出的粗略的估算，并将此估算以数字点数（points）的形式体现。比如：完成单个静态WEB页面的开发所需的工作量需要1个点数，那么完成10个类似静态页面所需的工作量则可能需要10个点数（1*10），又或者因为熟练度的增加，而只需要5个点数。 版权声明：如无特别说明，本站所有文章均由睿珑（Ruilong-edu.com）原创。我们欢迎少量文字引用，但请注明出处。任何网站或个人，未经授权，不得抄袭、转载、盗用本站内容，违者必究。 当然，评估story points需要考量的不止是工作量，还包括：工作的复杂度、风险及不确定性等。 通常，人们认为story points来估算工作量的方法要比通过小时数（hours）估算要更加客观，因为不同个体对同一件工作所估算的小时数可能会存在较大差异，而story points因为是采用相对比较的方法，所以要更准确一些。 参考链接： https://whatis.techtarget.com/definition/story-point https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating https://www.mountaingoatsoftware.com/blog/what-are-story-points https://rubygarage.org/blog/how-to-estimate-with-story-points https://pm.stackexchange.com/questions/2765/why-use-story-points-instead-of-hours-for-estimating/

User story，中文常译为：用户故事。它是敏捷开发中用到的对需求进行描述的方法。与传统冗长、复杂的需求说明书文档不同，user story有意将用户需求的重心从“编写”转变为“讨论”。 在敏捷开发中，用户故事指的是：从系统用户（或顾客）使用的角度，对其功能需求进行的简单描述。其描述方法常遵循以下形式： 版权声明：如无特别说明，本站所有文章均由睿珑（Ruilong-edu.com）原创。我们欢迎少量文字引用，但请注明出处。任何网站或个人，未经授权，不得抄袭、转载、盗用本站内容，违者必究。 “作为一个（填写用户类型），我希望具有（填写某某功能），以便（填写理由）。” 注：括号中是对填写内容的说明。 用户故事可写在可贴便签纸上，保存在纸盒中，在讨论时，它们被有序组织起来贴到白板或墙上。由于用户故事简洁明了，且易于讨论，所以它们的效果往往优于那些长篇大论的需求说明书。 参考链接： https://searchsoftwarequality.techtarget.com/definition/user-story https://en.wikipedia.org/wiki/User_story https://www.leadingagile.com/2012/07/user-story/ https://www.softwaretestinghelp.com/user-story-acceptance-criteria/

在敏捷开发项目中，Product Owner（简称为：PO）指的是：产品所有者、或产品负责人。他对敏捷项目的最终交付物负责。他的角色有些类似于传统项目管理中的“项目经理”（project manager），但又不完全一样。项目经理更关注deadline（项目截至日期），并以公司为中心；而product owner则聚焦于产品，以最终用户为中心。 版权声明：如无特别说明，本站所有文章均由睿珑（Ruilong-edu.com）原创。我们欢迎少量文字引用，但请注明出处。任何网站或个人，未经授权，不得抄袭、转载、盗用本站内容，违者必究。 具体而言，Product Owner的最重要的职责包括：对最终产品具有清晰的Vision，即：知道最终产品做出来应该是什么样子的；管理和维护Product Backlog，包括对其中的item（即：需求项）进行增减、优先级进行排序、将需求清晰的传递和解释给开发团队等。他也是公司、用户、Scrum团队之间的协调者、粘合剂。此外，许多观点认为，尽管理论上敏捷项目不关注deadline和成本，但现实世界中Product Owner也是对此负责的角色。 参考链接： https://www.scrum.org/resources/what-is-a-product-owner https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner