ScrumMaster

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 框架

原文作者：Sjoerd Nijland 原文地址： https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779 翻译：柴晓燕&付新圆 对于敏捷中的活动有很多，本文先从Sprint计划开始，分享一些方法、建议和注意事项，这些对理解和实践Scrum都很有帮助。 Who？ Sprint计划的参与者：整个Scrum团队。 请注意， Sprint计划是 一个积极的、合作的活动。如果需要的话，大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙，在会议期间能收集到更多信息。 “开发团队还可以邀请其他人参加，以提供技术或领域建议。” — Scrum指南 参与性 并不是每位成员都会在参与活动时表现出积极主动和创造性，有些成员只有在感到自信或舒服时才会加入。 出勤率和参与度低都会降低透明度，并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。 “ Scrum Master可以确保活动进行，并确保参与者了解其目的。” — Scrum指南 我认为，解释出勤和参与的价值，同时创造一个舒适、愉快、平静和尊重的环境，是Scrum Master 激励团队成员参与的最佳方法。 “给他们提供所需的环境和支持，并信任他们来完成工作。” —敏捷宣言。 有时，参与者可能会占据主导地位

​ 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。 在现代社会中，软件应用于多个方面。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。 在大公司里，软件工程的应用已经非常普遍，比如敏捷开发，领域模型驱动这类的实践方法已经深入人心，今天我们就来推荐一下关于软件工程的一些经典书籍。 软件工程系列书单 ​ 人月神话 在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了具有洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。 《人月神话（40周年中文纪念版）》内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。 《人月神话（40周年中文纪念版）》英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。 在《人月神话（40周年中文纪念版）》第首次出版40年后的今天

摘要： 团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。 背景 敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下： 问题一： 团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？ 问题二： 团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？ 团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。 问题分析 以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下： 问题一：团队只关心数字。 团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算

Scrum 是敏捷开发流派中最著名和最落地的一支，全球 70% 以上公司的敏捷转型都是以 Scrum 起步。CODING 特邀敏捷顾问、CST & CTC 认证敏捷教练 申健 老师将在本课程 《Scrum 敏捷项目管理核心要素之 3355》 中介绍 Scrum 框架的核心要素，帮助大家更好地学习实践 Scrum。 大家好，本次我将为大家详细讲解敏捷的一个流派，叫做 Scrum 敏捷项目管理核心 ，它起源于 2001 年，当时有 17 位大牛共同讨论了他们的想法和各种软件开发方法，经过交流，他们最后达成了价值观和原则上的共识，共同发布了敏捷软件开发宣言。 而迭代的概念则可以追溯到 1970 年左右，Scrum 也是用迭代式去进行发展，与之相应对的就是瀑布式，所有工作像流水线一样有计划且按部就班的去进行。例如：在软件开发中，先是需求分析、设计，然后进入开发编码、测试，到最后上线，整个过程有前后顺序，不过现实中总会在某个地方出现问题从而造成返工。 有两个日本学者在 1986 年研究了丰田、本田、佳能等高科技公司怎样在一个不确定的情况下去研发一个新产品，他们发现这些公司不再去区分职能部门，而是具有跨职能团队的特点。就像打英式橄榄球，每个人都有各自的专长，但是目标是统一的：要进球赢球。 所以他们在管理智力型研发项目时，没有再用瀑布流式来管理，而是用一种不断迭代的方式。项目的迭代时间不超过四周

案例背景 为什么银行要像灰狗一样快？ 荷兰国际集团（ING） ，成立于1991年，主营业务银行与保险业务，在全球45个国家和地区拥有分支机构，总资产887亿欧元（2018），全球53,000多名员工，拥有3840万个体客户。世界500强排名171（2018），世界品牌500强排名120。 ING的敏捷转型始于2010年，当时还只是涉及IT部门的基础员工。2014年，首席执行官Nick Jue和高级领导团队在制定银行“Think Forward”战略的时候，他们意识周围的世界正在迅速变化。银行不是只与传统机构竞争，对于新技术和新竞争对手，ING必须非常迅速地改变。 紧紧抓住过去不会让我们拥有未来。 转型不只是将组织从A移动到B，因为一旦你击中B，你需要转到C，当你到达C时，你可能不得不开始考虑D。 Nick Jue, ING CEO 当ING引入敏捷工作方式时，公司表现良好，利率仍处于不错的水平，没有特别的财务要求。然而，客户行为随着新的数字分销渠道的变化而迅速变化，客户的期望也受到其他行业数字化领导者的影响，ING需要停止传统上关于产品营销的思考，并开始了解这个新的全渠道环境中的客户旅程。必须提供无缝且始终如一的高质量服务，以便客户可以通过一个渠道开始他们的旅程，并通过另一个渠道继续。灵活的工作方式是实现该战略的必要手段。 创新解决方案 四个关键支柱实现集团总部的全面敏捷转型

转自本人运营的公众号“ 携程技术中心PMO ”（ID：cso_pmo） 作者简介 Ollie Guan，携程PMO高级项目集经理，负责 敏捷总动员 及携程技术中心PMO微信公众号运营。 上海AUG Leader ，Atlassian Community Champion，Top 10 super-contributors。 Why ？ 做技术同学们都知道，在项目初始阶段我们会对需求、任务进行估算，估算往往很花时间，更要命的是总做不到准确。既然这个值即不准，又花时间，那为什么还要做估算呢？ 对于用户：用户需要一个这样的预期（甚至是承诺），什么时候才能用上这个功能； 对于管理者：管理者需要这个估算来做决策，包括调整工作优先级、人员调整、甚至是否砍掉这个功能等； 对于团队自己：不仅是团队内的合作，还包括团队之间的合作（如联调的时间的确定），都需要基于估算给出。 除了上面这三个角色对估算的期望之外，估算还有一个重要的价值，那就是在估算活动中大家对需求能够趋向达成一致的理解，减少一些被忽略的假设和背景。所谓“磨刀不误砍柴工”，在估算上花费的时间是值得的。 What ？ 扑克 估算，顾名思义，我们在估算的活动中加入了扑克这套工具。 传统估算通常是一个人在思考，而扑克估算鼓励跨职能团队的多个团队成员参与，团队成员可以从不同的视角来思考和分析问题，考虑更加全面、估算也更加准确。

在图的最下方灰色的横条是实施SAFe的基础，包括如下内容： 核心价值：包括四个核心价值，见下图： https://blog.csdn.net/wejiyu/article/details/105454644 PI计划（ 项目集增量计划 ）：这是SAFe中非常重要的一个计划，它为ART提供了决策，并且将业务和技术目标进行统一；实际上PI计划和ART处于同一层级。 IP（创新和规划）冲刺：创新和规划会发生在每个PI，并且会有多个目的。它扮演了满足PI的目标的缓冲，并为创新、继续教育、PI规划，以及检视和适应提供了专用的时间。IP冲刺活动实现了许多精益敏捷的原则，这些原则可以使业务敏捷性。 在SAFe的敏捷团队中，包括了两个关键的角色，一个是 Scrum Master；另外一个是Product Owner。 项目集增量（PI）目标是敏捷团队或者火车为即将到来的项目集增量中要达成的商业和技术目的的摘要。在PI规划中，团队要创建PI目标，下图为团队PI目标。 https://blog.csdn.net/wejiyu/article/details/105454711?depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-2&utm_source=distribute.pc_relevant.none-task

“它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。” 了解敏捷的朋友都知道backlog和spring是待办事项和冲刺的意思，但在使用Choerodon实践敏捷开发的时候这些敏捷术语对应的系统功能是哪些呢？为了解决大家在使用Choerodon时的困扰，整理了以下Choerodon功能与敏捷术语的对应表，以便大家进一步了解Choerodon的具体功能。 功能 敏捷术语 说明 问题 史诗(Epic) 非常大型的故事，可以横跨多个迭代周期。史诗故事在战术层面上使用前必须分解为一个个相关的用户故事。 故事（Story） 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1. 角色：谁要使用这个功能。2. 活动：需要完成什么样的功能。3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。 任务（Task） 是完成需求的过程性的工作。在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。 子任务 子任务通常是故事的具体拆分，拆分出的子任务将交给具体的开发、业务等人员处理，属于具体的任务交付

今天是2月5日，春节假期结束后的第三天了。为了能够应对来势汹汹的疫情，众多互联网企业纷纷开启了远程办公模式。不知道各团队前两天的远程办公效果如何，我们 Worktile 管理层在大年初四就开始讨论远程办公的事情，并且将可能出现的问题都尽量提前想到并做了准备。从这两天实际执行的情况看，我所在的研发团队执行的还不错，基本没有受到什么明显的影响。因此我们希望将我们远程办公的一些思考、准备和实践分享给大家，共渡难关。 先简单介绍下，我是 Worktile 基础平台部的负责人，部门包括负责核心组件开发的平台组和负责线上及公司内部服务器管理的运维组。我们的运维团队一直都是一个分布式团队，成员包含北京和杭州，我本人之前也有几年跨国公司的工作经历，对远程工作并不陌生。接下来我想就以下几个方面聊一下我们 Worktile 研发团队是如何实施远程办公的。 明确远程办公的原则 首先，作为研发线的一名主管，我首先给自己明确了一条远程办公的原则——信任，并且首先是自上而下的信任。也就是说，远程办公首先要求管理者，无论是公司CEO还是普通的小组长，都要完全信任自己的团队成员是有责任、有担当，能够自觉的按时按质完成任务，能够主动沟通工作中的问题。只有基于这样的信任，远程办公才可能展开。否则，就会陷入到监视、控制、猜疑这种危险的状况中。所以，信任是远程办公的基础。 其次，任何一级的管理者都要以身作则