用户故事

任何一个领域都遵循从新人到熟手，从熟手到专家的路径。在成长过程中，DevOps人经常会陷入没人带，没人管，找不到职业方向的迷茫。 DevOps是在商业演进与企业协作的进化过程中诞生的一个全新职业，被很多人看成是一个“全栈”岗位，是能开发、会运维的复合型人才，但想要从事DevOps工作要从哪学起？如何入门？又该如何精进？ 我们对101名DevOps专家进行调研，问题只有一个：从入门到熟手，再从熟手到专家的成长路径中都看了哪些书？最终选出了39本推荐度最高的书籍，分成基础敏捷实战、敏捷测试、精益系列、技术工程、DevOps、教练、引导、大规模敏捷这8大部分，建议每一个DevOps从业者收藏阅读。 基础敏捷实战 《Scrum要素》 本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。Scrum 入门级读物，内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。 《敏捷革命：提升个人创造力与企业效率的全新协作模式》 本书由Scrum创始人写就，以讲故事的方式，讲述Scrum的由来，并逐步推进的过程。同样是入门级读物。 《Scrum精髓：敏捷转型指南》 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。

1. 什么是 Scrum 　　Scrum 是一种轻量级的框架，适合于小型的、结合紧密的团队开发复杂的产品。 Scrum 是二十世纪后期一些软件工程师协同努力的脑力劳动的成果，现已成为技术领域最具魅力的方法。但 Scrum 并不因此而复杂难用，相反，它不仅适用于技术领域，你还可以轻易将本文中介绍的工具和实践应用于其他领域。 　　一个 Scrum 团队通常由 7 人± 2 人组成，他们在固定的周期用迭代开发的方式一起协同工作。在每个迭代中，他们有充分的时间来评审和反思。“ 检查和调整 ”是 Scrum 的口头禅之一， Scrum 团队还有一个显著的特点就是非常关注 持续改进 ——既包括他们采用的过程，也包括他们的产品。 2. 角色（ Roles ） 　　Scrum 中有三种角色：产品负责人（ Product Owner ）、 Scrum Master 和团队成员。 2.1. 产品负责人（ Product Owner ） 　　从企业的角度看，一个开发团队代表了一笔重大的投资，包括：人员工资、办公室租金、计算机和软件的采购和维护费用等等。 产品负责人的责任在于帮助企业获得最高的投资回报 （ ROI ）。 　　其中一个最大化 ROI 的方法是引导团队做最有价值的工作，同时远离那些低价值的工作。产品负责人控制团队的待办列表中待办事项的优先级顺序。在 Scrum 中

在代码层次，在编码之前写测试脚本，可以称为单元测试驱动开发（Unit Test Driven Development，UTDD） 在业务层次，在需求分析时就确定需求（如用户故事）的验收标准，即验收测试驱动开发（Acceptance Test Driven Development，ATDD）。 来源： https://www.cnblogs.com/sea-stream/p/11844802.html

在你撰写用户故事或列出待办事项清单时，有两个问题很重要：用户故事够完整吗？你如何才能知道自己已经完成了任务？ 比如，我们看一看斯托尔写的用户故事：“作为特种部队的医生，我必须为学生们传授基本的生理学知识，这样他们才能了解人体。” INVEST 标准： 可协商性 （ N 有价值 （ V 可评估 （ E 规模小 （ S 可测试 （ T 斯托尔的故事是独立的，因为他的学生们就在老挝，他不必考虑学生们前往老挝所需的直升机燃油费之类的事情，他能够独立完成任务。 他的故事是可修改的，因为虽然他一开始打算为学生们传授基本的生理学知识，但如果他到了那里之后发现学生们已经具备这样的知识，或是已经有了一定的了解，那么他有其他的教学方法可以用。他的故事有价值：学生们学到人体知识之后，可以派得上用场。他的故事规模小：他只给学生们传授基本的解剖学知识，而不是教他们运用这些知识去开展外科手术。他的故事可测试：他很清楚自己想要传递的信息，也可以对学生开展一些小的测试，以便确认他们是否真的吸收了这些信息。 每个有待落实的用户故事都应该要有“完整”的定义（比如是否符合INVEST标准），同样，最后的结果也要符合“完成的定义”（比如必须符合什么条件、通过什么测试才能结束等）。在现实中，我们发现，如果用户故事足够完整，那么团队在落实项目的过程中速度就会加快一倍。此外，如果一个阶段的Sprint完成了相应的用户故事，那么

​本文选自网易云音乐推荐算法负责人-肖强前辈在全球人工智能峰会上的分享，主要介绍了三方面：关于网易云音乐，AI算法在音乐推荐中的应用和AI场景下的音乐思考。这里拿来分享给大家，并加上自己的理解，希望对大家有所帮助。 首先说明我是网易云音乐的深度用户，目前级别LV9，每天都会去听日推。喜欢网易云音乐的原因不仅是友好的用户交互设计，而且还是因为在网易云音乐中能看到一个个陌生的故事。虽不知这些故事是真是假，但总会找到一些共鸣，在这里像是一个心灵的寄托一样。我相信大多数人和我一样，喜欢在敲代码的时候戴上耳机，来一个燥一点的音乐，所有的事情与我无关，我只想专心写代码，哈哈，开篇小小的题外话，下面进入正题。 关于本文的PDF，可关注公号 合作=>私信 获取小编微信 ，私聊获取！ 本文将从三个方面介绍AI算法在网易云音乐推荐中的应用： 关于网易云音乐 AI算法在音乐推荐中的应用 音乐场景下的AI思考 关于网易云音乐 关于网易云音乐的介绍就不用多说了，相信大家都知道这个产品。但是这个产品里边也有很多其他的业务，如下这些。当然推荐也会在各个业务线进行应用，最大化的提高用户体验。 AI算法在音乐推荐中的应用 除了上图中介绍的三个场景以外，推荐在云音乐还有其他很多的应用，比如推荐的MV/视频，推荐的电台，推荐的Look直播等。 几乎所有的推荐系统或者业务系统的分析和底层数据支持都离不开用户的行为日志

什么是User Story其实我觉得要对User Story做一个定义还是挺难的。 曾经的我以为，所谓User Story是User来讲述的Story。 你看啊，User Story的编写范式： As a role, I want to do something or a piece of functionality, so that I can achieve some business value or statement of intent. 但是，随着真正的实践，我发现，User总是一个缺席的定义者。 我们指望User来定义User Story，而大部分情况下是由我们这群BA来定义的。 我曾经和一名敏捷教练讨论，我们BA总是在臆想用户的需要而写User Story，这样有意义吗？ 这名来自美国的副总裁回答我说，至少你们从用户的角度来思考了，不是吗？ 不过，并没有解答我的疑问，我也相信有很多人和我有同样的问题：User Story到底是从哪里来的？谁来写？ 也有很多人认为需求提出方应该来写User Story，至少也应该来确认User Story是否恰当。 但实际情况是，很多时候我们真的只能靠想象，充分利用我们的“同理心”来想象。 我翻了一下BABOK中对于User Story的定义： A user story represents a small, concise

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师