ScrumMaster

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 云是手段，而非目的。完整的标准化和自动化战略可促进这样的成果，即通过云来实现IT现代化。 云计算的采用一直在迅速增长，人们预计特定于云的支出将在整个2020年以一般IT支出的六倍以上的速度增长。虽然大型组织已成功实施了特定的SaaS解决方案或已经为新系统采用了云优先的战略，但仍有很多组织在努力将大量企业系统迁移到云端，以此将价值最大化。 这是因为公司往往会掉进这样的陷阱，即把IT系统迁移到云端与最大化利用云端所需的转型策略搞混淆了。将遗留应用程序迁移到云端(“直接迁移”)是不会自动产生云基础设施和系统所能带来的好处。实际上，在某些情况下，这种方法可能导致IT架构比以前更加复杂，繁琐且昂贵。 云的全部价值源自将这些选择视为实现数字化转型的整体战略的一部分，而不是一次性的战术决策。这种策略是可以实现的，其方法是通过开放的API模型将IT环境标准化和自动化，采用现代化的安全性，在自动化的敏捷操作模型中进行工作以及利用新功能来推动创新的业务解决方案。尽管云并不是所有这些功能的先决条件，但它确实起到了推波助澜的作用。以这种方式应用云功能的公司可以创建下一代IT，从而能够在快速发展的数字时代实现业务增长和创新。 直接迁移是不够的 Amazon Web Services(AWS)

300天350个版本，路孚特旗舰移动产品“0”到“1”的交付之路 2020-05-26 02:41 InfoQ 作者 | Eileen 要想认识路孚特这家金融数据科技公司，没有什么比数据更直观。 路孚特为全球 190 多个国家的 4 万多家机构和 40 万用户提供金融信息服务，其交易数据每秒传递高达 700 万条更新，支撑着全球 5000 多家投资公司和对冲基金的交易，每天更新的市场数据多达 400 亿条。在其开放平台上，超过 1 万 3 千名开发者和 2200 多家合作伙伴，共同以安全、有效、高效的方式构建金融行业的业务发展以及其各项创新。 2018 年，路孚特完成从汤森路透金融与风险业务部门到路孚特（Refinitiv）的转变。作为世界上最大的金融市场数据和基础设施供应商之一，160 多年历史的专业经验铸就了路孚特新一代业务流程优化系统 Refinitiv Workspace，针对全球金融市场从业人士的不同需求，以此为用户提供全面深入的金融数据、分析、新闻、工具等客制化解决方案。 在移动设备已经非常普及的今天，时间的碎片化带来流量的碎片化。面向消费者的互联网产品早在五六年前便完成了 PC 端向移动端的过渡，但对监管严格的金融行业来说，一切似乎才刚刚开始。在路孚特的移动平台战略中，非常重要的一步是打造 Refinitiv Workspace 的移动版本——Refinitiv

敏捷转型有很多坑，今天你跳了没有？ 1、敏捷和瀑布式只能二选一？× 1、敏捷开发和瀑布式开发是有结合的可能的，举一个例子，当有一个新的项目创意时，我们可以采用敏捷的方式快速试错，快速获得市场反馈，产出符合客户和市场需求的产品，但是如果后续的市场和需求比较稳定，我们完全可以回归的瀑布式开发的模式。 2、另一方面如果一个组织原有的模式是瀑布式开发，现在要转型为敏捷模式，那一定会有一个过渡期，这个转变的过程绝不是“一刀切”，会有很长一段时间采用混合模式！ 2、项目敏捷就够了（有项目就申请资源，结束了就回到资源池）；× 这是非常欠妥的做法，这种模式是希望做到项目敏捷，而不是组织敏捷，理想的认为项目采用敏捷管理方式即可，项目结束了就回到职能团队，所以每当有新的项目都要有一个磨合期，要重新确定项目角色，而职能组织并不能有效的给予支持，这样的结果是组织永远停留在原有的模式，项目敏捷也最终会变为伪敏捷。 3、TDD和ATDD是测试团队的实践；× 不管TDD还是ATDD都是团队整体的实践，TDD让测试与开发界限模糊，ATDD让需求与测试界限模糊；所以归根结底都是各个角色间合作的实践，而不是测试自己的变革； 4、价值驱动；× 价值驱动其实是没有错的，这正是敏捷提倡的交付原则，但是只有价值驱动吗，如果一切的情况只考虑价值，那就会带来很多问题，价值高的风险低，价值低的风险高，这样的情况一定是先做价值高的吗

在 Scrum站立会议中，可能有不同部门或岗位的人一起参加，但是要注意，只有真正参与项目的人才有发言权。 视频地址： https://www.zentao.net/scrum/daily-standup-80186.html 会议中可准备一个话筒或道具，只有拿着该道具的人才能发言，每个人说一下昨天做了什么，今天做什么，以及遇到的问题，但会议中并不去解决问题，可以会后探讨。 其他非参与项目的与会人员可以旁听，但不可喧宾夺主，每个人的角色、职责不同。 视频中跟大家分享了“猪”与“鸡”的故事， 在Scrum中，“猪”类角色包括Scrum Master 、产品所有者、开发团队等成员，而客户，市场商务人员都是Scrum中的“鸡”类角色。“ 猪”类角色才是团队的核心，拥有较大的话语权。 但实际项目中往往是“猪”类角色没有发言，而“鸡”类角色喋喋不休，最后每个决定却让“猪”去承担后果，这是Scrum要尽力避免的。 更多精彩视频请见： https://www.zentao.net/page/college.html 来源： oschina 链接： https://my.oschina.net/candou/blog/4327829

“我，程序员，32岁，距离退休，只剩3年了！” 这句话用来形容2019年互联网行业最适合不过了。从18年开始，大大小小的互联网公司开始了不止一轮的裁员，19年网上开始充斥一类文章，专门写互联网公司超过35岁的人，如果到这个年龄，还不是leader，业务又不核心，那么请焦虑吧。 昨天听罗胖的跨年演讲，主题是：基本盘。意思是不要受到人云亦云的情绪影响，而是转过头，看手中的资源，基于基本盘看清自己的努力方向，非常感慨和受启发。中国互联网经过过去十多年野蛮式的发展似乎这2年开始慢下来了，程序员35岁的退休年龄虽然只是贩卖焦虑的一种说法，但是整个行业对人的要求越来越高是不争的事实，要求我们的成长速度必须跟上。2020年开始，希望自己在技术、管理、业务3个维度再做更深层次的学习，体系化个人的认知，做一个有特点的IT人。 下面要写的主题是关于『工程师如何从技术转型做管理』，这是我在团队管理上第一篇系统性的总结。之所以选择这个主题，一方面，个人觉得转型做管理是当前环境下大部分程序员会选择的职业路径，另一方面，自己亲身经历了比较漫长的转型过程，应该能写出点心得体会。希望下面的内容对于『正在转型挣扎期』或者『后续有规划往管理转型』的同学，让你们有所启发，内容大概分成以下4个部分： 什么样的工程师会被提拔做管理？ 你选择做管理的初衷是什么？ 转型期你会遇到哪些困惑或者挑战？ 转型期应该具备哪些心智？

7分钟揭晓Scrum的秘密（Scrum框架） 什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则... Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。 Scrum 是: 轻量级的 易于理解的 难以精通的 Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。 -- Scrum指南 从 Scrum指南 中我们可以快速总结如下： Scrum是一个过程框架 Scrum框架用于开发复杂产品 Scrum框架帮助人们解决复杂的自适应难题 Scrum能帮助人们高效交付尽可能高价值产品 Scrum框架中可以使用各种不同的过程和技术 因此，Ken Schwaber 曾经说过： Scrum 就像你的丈母娘，不断的指出你的问题。 由此也不难看出，Scrum框架的核心在于不断暴露问题。即它是一个暴露问题的反馈框架。 下面我们来看看Scrum框架中具体包含什么内容。 Scrum 框架

摘要： 《Scrum精髓》一书中将Scrum Master的职责总结为六类：敏捷教练，服务型领导，“保护伞”，“清道夫”，过程权威，“变革代言人”。作为“保护伞“，Scrum Master应该保护团队免受任何干扰，当然也包括团队内冲突，成员关系等。 背景 拜访企业的过程中，不少企业领导提到过一个相似的问题：“我们团队有个人平时总是和我（或者其他成员）对着干，把团队氛围搞得很差，Scrum Master应该怎么引导他们，让他们好好工作？” 本文就针对这样的问题来聊聊，团队中遇到“刺头”应该怎么办？ 问题分析 学生时代班级里总有几个刺头，他们惹是生非，扰乱课堂纪律——课堂上讲话，接老师话茬，让老师很是头疼。企业中，很多团队也有一两个成员，他们难以合作，常常捅娄子，给团队交付带来不良影响，令管理层也很头疼。 在交流过程中，笔者从不同人口中了解到不同类型的刺头，分别有： 技术骨干 技术骨干通常掌握着项目的核心技术，是开发交付不可或缺的关键角色，项目少了他很可能会产生较大的影响。有的技术骨干对其他人，甚至是领导都爱答不理，和团队很难沟通协作。 原地踏步的“老人” 同一时期入职的员工，有的人做上了项目经理，有的人还在原地踏步写一些基础代码 做同一个项目的团队成员，有的人绩效一直是A，奖金丰厚，有的人一直作为“吊车尾”混迹于团队尾端 两种情况的后者会存在一部分人表现出对工作消极懈怠

摘要： 企业在做敏捷转型中，需求无法按时交付的困扰你是否也遇到过呢？ 背景 在之前组织的一次敏捷线下活动中，有家企业问道：“我们公司刚做敏捷转型不久，遇到一个比较头疼的问题——团队每天都很忙，从转型到现在已经两个多月了，基本没有一个迭代能做完全部任务，问题出在哪？”该问题一提出后，引发了激烈讨论： “我们公司也是，总有那么几个人完不成手头任务，每次拖后腿让客户不满意”； “最近我们项目用了个新框架，很多人他没用过啊，不知道从哪下手，项目评审的时候一片惨淡”。 其实上述几种情况归根到底都属于需求无法按时交付，类似这样的困扰你是否也遇到过呢？ 问题分析 在交流中，笔者了解到每家公司的情况： 背景中第一家企业在第一个迭代认领了15个故事，团队很容易就完成了；老板觉得以团队的能力可以做到每个迭代完成30个故事，于是后续每个迭代都希望团队认领30个故事，团队认领30个任务后，累死累活只能完成20左右的故事； 第二家企业研发团队8人，每个迭代总有两个成员工作完不成：团队每天早会正常开，但是总感觉那两个成员整个迭代都在做那一两个故事，做的功能也没啥进展，有时候还做不完； 第三家企业使用了一个新框架，近两个迭代团队按以往的速率进行任务认领，结果由于团队对框架不熟，每个迭代只完成了冲刺待办列表中一半的故事。 笔者结合交流结果及以往经验，对需求延期交付的原因进行了如下分析：

推荐Scrum书籍 直接上干货，推荐书籍清单如下（推荐有顺序的哦） Scrum指南 Scrum精髓 Scrum敏捷软件开发 Scrum捷径 硝烟中的Scrum和XP : 我们如何实施Scrum 敏捷软件开发:Scrum实战指南 Scrum要素 大规模Scrum:大规模敏捷组织的设计 用户故事地图 用户故事与敏捷方法 Scrum指南 作者：Ken Schwaber & Jeff Sutherland 出版社：Online 译者：Jiancheng Zhou 链接： https://scrumguides.org/ 内容简介： Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。 Scrum精髓 作者：Kenneth Rubin 出版社：清华大学出版社 译者：姜信宝 / 米全喜 / 左洪斌 / （审校）徐毅 链接： https://item.jd.com/11462889.html 内容简介： 短短几年时间，Scrum跃升为敏捷首选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书以通俗易懂的语言

原文地址： https://www.knowledgehut.com/blog/agile/scrum-vs-safe Scrum是基于敏捷的价值观和原则的框架，而SAFe是在企业级别实施Scrum的框架，它们都是基于敏捷价值和原则下的产物。Scrum和SAFe之间的区别是有限的，但也存在着明显的差别。简单来说，Scrum主要基于敏捷的原则和价值观，侧重于少量团队，SAFe是在企业级别的实施敏捷的。 Scrum和SAFe之间的主要差异 让我们看一下Scrum和SAFe之间的主要区别： Sr. No. Scrum SAFe 1. 适用于小型的、阵列的、跨职能的团队 适用于大型的、多区域的团队 2. 它主要被敏捷团队采用 被整个企业采用，而不仅仅是一个团队。(Scrum的扩展) 3. 中层管理人员起不了任何作用 项目群和投资组合层是SAFe的两个重要层次 4. 基本组成部分是Scrum团队. 基本组成部分是敏捷发布火车（ART） 5. Scrum遗漏了各个基本方面。 整个组织的几乎全部的特性和各个方面通过SAFe都可以被管理。 Scrum是管理软件开发的敏捷方法，而SAFe是企业级敏捷的建立方法。 两者之间的主要区别取决于他们选择处理工作的方式。简而言之，Scrum基本上用于组织小型团队，而SAFe用于组织整个大型团队甚至企业。此外， SAFe填补了Scrum在各个重要方面的空缺。