Scrum敏捷管理学习心得 - Certified ScrumMaster 课后作业记录

Bob Jiang
Scrum敏捷管理学习心得 敏捷开发是一种能应对快速变化需求的软件开发能力,包含Scrum、极限编程(XP)、晶体、特征驱动开发等多种方法。其中Scrum是最被广泛使用的一种方法,旨在指导团队进行产品的快速迭代和增量交付。 敏捷软件开发宣言: 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人,由此我们建立了如下价值观:个体的互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。 敏捷宣言遵循的原则: 1、我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化,即使在开发后期也一样,为了客户的竞争优势,敏捷过程掌控变化。 3、经常的交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。 4、业务人员和开发人员必须相互合作,项目中的每一天都不例外。 5、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。 6、不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。 7、可工作的软件是进度的首要度量标准。 8、敏捷过程倡导可持续开发。责任人、开发人员和用户能够共同维持其步调稳定延续。 9、坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。 10、以简洁为本,它是极力减少不必要工作量的艺术。 11、最好的架构、需求和设计涌现于自组织团队。 12、团队定期地反思如何提高成效,并依此调整自身的举止表现。 敏捷的五个核心价值观:专注、公开、承诺、勇气、尊重。 Scrum的三个核心角色:Product Owner(PO)、Scrum Master(SM)、Scrum Term(团队)。 其中 PO的核心工作为:对团队对外交付的价值负责,定义需求、定义需求的优先级和验收标准、定义产品发布内容与日期。 SM的核心工作为:帮助团队遵循Scrum框架,持续改进,促进团队工作,帮助团队排除影响生产力的障碍、保护团队不受干扰。 Scrum Team则对交付结果负责,敏捷团队是自组织的团队、小而美,一般团队成员定义为5-9个人。 Scrum的3个工件:Product Backlog(产品待办列表)、Sprint Backlog(Sprint待办列表)和Increment(可交付产品增量)。 Product Backlog即产品视角的需求清单,由PO负责维护,并根据优先级进行排序,优先级高的颗粒度更细,优先级低的对应颗粒度粗。用户故事是其中一种最佳实践,每项需求都应该描述其外部价值。 Sprint Backlog即冲刺周期内规划要完成内容,来源于Product Backlog,由团队评估和选择Product Backlog中哪些放入Sprint Backlog,同时团队需要一起定义完成的标准。 Increment即冲刺结束后可对外发布的产品功能增量部分。 Scrum的5个事件:Product Backlog梳理会议、迭代计划会议、每日站会、迭代评审会、迭代回顾会: Product Backlog梳理会议贯穿整个Scrum项目的始终,主要保持产品待办列表有序、凸显价值。 迭代计划会议作为Sprint的开始,决定在迭代中完成哪些待办列表,明确任务和战前鼓舞。会议时长对应Sprint周期每周2小时。 每日站会,会议时长建议为15分钟,检视上一个工作日做了什么,当天的工作计划和存在的问题,阐述最好是可视可量化的,问题不发散,做好时间管理。 迭代评审会议:会议时长一般每周对应1小时,在sprint结束时团队和相关干系人一起评审sprint的产出、完成工作是否符合需求预期,并展示当前产品增量情况。 迭代回顾会议:会议时长一般每周对应45分钟,在sprint结束后,scrum团队开会反省和检讨,对迭代周期内做的好的进行表扬和鼓励,不好的,提出改善方案和完成计划。 Scrum敏捷开发的优势:拥有快速反应的能力,精确要求,精准结果,更大的灵活性和稳定性、提高团队绩效,降低成本,失败的代价降低。劣势:敏捷注重人员的沟通,文档维护难度增加,在新员工较多未形成战斗力时,老员工较累。 结合当前项目实际情况的分析: 1)团队人员数量超出了Scrum的最优定义,站会易超时; 2)PO是新人,没有明确的职责定义,对产品认识度不够。 3)验收标准有时候没有很明确的定义,在长期不上线使用的情况下,拉通联调的支持周期过长,容易“带病”到后面的迭代。 4)新人较多,效能提升,共同价值目标磨合需要时间沉淀。 5)对于迭代评审会议,目前做的不够,没有很好的展示迭代输出成果。 6)奖惩制度不合理,在不断的高压冲刺中,难以长期的保持团队成员的斗志和凝聚力。 相信每个SM在Scrum交付过程中,总会遇到由内到外、由外到内等各种问题,需要不断地反思、学习、总结,所有的管理问题,最终都是人的问题,唯有持之以恒的学习反省,才能走的更远。 限于时间精力和篇幅,先写这么多吧,望谅解! CSM考试学员:徐某 2020-12-23

敏捷交付 - Certified ScrumMaster 课后作业记录

Bob Jiang
敏捷交付 对于敏捷交付培训与实际运用中,我理解为我们需要持续不断的及早交付满足客户有价值的的软件,在交付过程中不断通过变化,通过及时沟通,标准的流程,统一化的工具,进行可持续,高效的交付。 在软件开发中,领导阶层的指挥控制方式(经理创建详细的工作细分结构、向团队分配任务,并告诉他们每项任务要花多长时间完成的方式)存在问题。敏捷方法从业者认识到,实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务,他们执行自己的评估,他们自愿挑选任务,他们自行分担工作量。在本质上,他们就像一个高效运转、自行组建的团队,没有明确定义项目经理职位。相反,该团队指派某个人作为团队领导,帮助推进整个流程,让团队成长,让团队在缺少SM这个角色后,还能依然运转。 我从如下几点详细描述我了解的敏捷交付: 产品路线图, 项目目标与里程碑, 团队成员责任划分, 团队流程与工具管理, 项目风险管理, 团队反思。 第一,产品路线图。 在产品路线定下来以后,根据产品的背景、前景和价值,让团队意识到该项目的重要性,了解产品的主要交付路线,产品主要需求的优先级,以及大致上线时间点。 第二,项目目标与里程碑。 主要是对产品路线的补充,对交付功能模块的细化,项目完结交付的所有功能点,SM基于产品路线和需求进行模块拆解,澄清所有功能点,对总目标功能点的里程碑设定,以及每个里程碑各个职能组完成的主要任务; 第三,团队成员责任划分。 主要是基于项目功能,明确团队成员和职责,让团队对每个人所负责有概念认识,基于功能和流程,明确团队成员和职责,对项目开展的相关环节的必要说明,大家共同遵守的团队规则章程,明确团队共识的协作方式。 第四,团队流程与工具管理。 为了确保共识计划得到落地执行,团队保持高效交付,那么就需要借助一些研发管理工具,辅助我们进行项目开展实施,同时在项目交付的过程中不断优化交付流程,代码管理,需求管理,人员管理,交付件的管理,将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具,持续跟进、督促、检查,争取将所有事务录入项目管理工具,包括未被考虑的事情,让团队自己给自己建任务。 第五,项目风险管理。 主要是向团队成员告知个人任务进度和安排,以及需要支持的相关事项,及时暴露风险和问题;同时交付过程中存在需求理解,表达不清晰的地方,人员理解不一样的地方,要及早暴露出来这些风险,通过与客户沟通及视补救,沟通过程流程与工具能够尽早把风险扑灭。 第六,团队反思。 团队定期的反思如何提高效率,并以此调整自己的能力,让团队没个人都能够成长,同时淘汰不符合团队的人,让团队人员更加稳定延续,人员稳定才能保证项目的稳定,让团队成员执行力强,凝聚力强,没有旁观者、推诿者,共担解决;能力强,独挡一面,人人都是神枪手。 通过这6点,我们能够提醒、督促、辅助我们落地美好计划,让团队管理更加透明,让项目实施更加具体、让项目风险更加可预期,同时也可以加速交付节奏,做到极限编程,有着稳定的工具,流程,人员,并以即时的方式来让项目投资获得最高回报。 – CSM 学员陈某

Github指定本地私钥访问仓库

Bob Jiang
一共有三个关键步骤: 生成新的私钥 上传公钥到github 修改本地ssh配置 Mac pro迁移后,本地的 github 私钥忘记是哪个,重新生成一个新的私钥放在一个新目录。(怕覆盖了原来的私钥,其他应用受影响) 1. 生成新的私钥 ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/<default>/.ssh/id_rsa): <your new path>/id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in <your new path>/id_rsa. Your public key has been saved in <your new path>/id_rsa.pub. The key fingerprint is: ... ... 注意指定一个新的目录 <your new path>

Gitcoin第八轮支持活动(如何申请资金支持)

Bob Jiang
Gitcoin第八轮支持活动 原文链接 发表于 2020年11月26日SCOTT MOORE 以下内容为机器翻译,准确信息已上述的原文链接为主。本活动是Gitcoin组织,解释权归Gitcoin。 从12月2日至12月17日,获得50万美元的集合资金,立即创建您的赠款 今天,我们很高兴宣布最新一轮的Gitcoin Grants。在过去的七轮中,在您的支持下,我们已经为超过700个关键的以太坊生态系统项目分配了超过3百万美元的资金。它不仅取得了巨大的回报,看关键 成员 的 我们的 社区获得可持续的资金来源,它是惊人的测试二次资金作为一种机制来满足我们不断增长和维持3D人类是建立我们依靠开源软件的更广泛的使命(OG Internet创建者有很多方式)。 但是,与以太坊生态系统一起工作有一些独特之处。如果我们不得不尝试提炼它,那就是社区总是团结在一起。我们将彼此之间的关系视为连续的,无限的游戏,并将与其他创作者的所有工作视为正和。我们发现,这不仅在补助金中而且在与社区的许多其他互动中都是如此。以太坊擅长建立小队财富。 正是这种认识使我们决定在Gitcoin Grants第8轮中尝试一些独特的事情(毕竟这是一个幸运的数字)。使人们团结在一起,共同学习并维护公共物品。 因此,我们很高兴宣布Gitcoin Grants Round 8(GR8)Hackathon,以及我们最大的配对资金池,其中有超过50万美元来自我们的新资助者联盟资助的6个类别。我们希望随着牛市的回归,我们可以使开源创作者获得最高100万美元的资金,并吸引更多的二次自由职业者。 如果您有兴趣参加此活动,则需要以下所有链接: 创建一个Grant。您要在Web 3中进行构建吗?您的工作很有价值。资助+加入社区!  注册到Hack:使用1inch,Balancer,Ceramic,Gnosis,Keep,Panvala,Nexus Mutual和其他10个版本进行构建  加入我们(虚拟)庆祝Web 3。在2周内始终开放的GR8 Airmeet中进行20多次活动 如果您不确定要做什么,或者只是想与我们discord,请加入Gitcoin的全新Discord,在此回合中,受赠者,贡献者和黑客将在这里闲逛!  那么,Gitcoin Grants如何运作? 它从”赠款”页面,资金池和贡献者社区开始 赠款从您的项目页面(或您自己!)开始,以及一组匹配的资金。借助二次资助的力量,捐助者将表明他们对受赠者的支持,并民主地决定匹配资金的去向。 如果您是受赠人,则需要注意的关键是,对项目的每笔捐款的*数量*和*金额*都会影响分配给您的总额。如果您是贡献者,那么即使是很小的贡献也会对受赠者获得的对等资助金额产生巨大影响。 换句话说,Gitcoin Grants实际上就是社区共同努力,以帮助为公共物品提供资金和表示支持。而且我们都受益于公共物品。 前往https://wtfisqf.com/?grant=1,1,1,1&grant=4&match=1000来体验QF的基本功能! 第七轮回顾 第七回合的配对资金为45万美元(较上一轮增加150%),这主要要归功于DeFi的所有人(甚至是匿名人士)。主要资助者包括以太坊基金会(我们的第一个主要支持者<3),optimism(另一个长期支持者),yearn(在第七轮成功的许多方面的催化剂),balancer,Synthetix,Chainlink,threearrowscap等。 我们还看到了近200个新项目参与,使总数达到850个以上。在产品方面,我们将工作重点放在了更好的Sybil抗性,更快的(和更便宜的)第2层结帐交易以及集合上! 在第7轮中,社区支持的新水平对我们而言是一个重要的里程碑,也是朝着实现二次自由职业的愿景迈出的非常谦卑而重要的一步。如果您想了解更多信息,请在此处查看Vitalik的Round 7回顾展。 第8轮–有什么新功能? 除了修正总体贡献者和受让人的体验之外,我们还指导了以下几项工作: 多个CLR;多种资金  作为资助者,您可以捐赠到多个类别或收藏集。作为受赠者,您可以轻松参与多个匹配池! 您的资助页面 我们希望获得一个赠款页面,该页面中的描述中要包含清晰的”要求”,因此,作为Gitcoin,我们可以在GR8黑客马拉松期间与我们的社区联系,以解决特定问题。在此处阅读更多一些技巧,以最大限度地提高您的匹配度。 赠款页面现在显示了更美的爱墙  现在可以选择将视频简介上传到您的资助说明中  向Sybil抵抗前进(一次整合!) 除了SMS,BrightID和Twitter,我们现在还集成了Idena,POAP和Gmail,以验证您是否是贡献者,以增加您为之贡献的赠款的匹配金额。 受赠者通过Twitter进行自我验证,而贡献者通过各种选择以增加其信任奖金的方式进行自我验证。 活动阵容! GR8黑客马拉松 第一个旗舰Gitcoin授予Hackathon!此次联合活动不仅有机会召集社区,不仅围绕他们关心的资金项目,而且也有助于建立社区,请在此处阅读更多内容。

Scrum指南最新版 2020 Scrum权威指南 游戏规则

Bob Jiang
Scrum 官方权威指南 收听有声版 | 官网下载PDF 由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护 版本:2020中文版 | 查看旧版本(2017) Scrum 指南的目的 在 1990 年代初,我们开发了 Scrum。在 2010 年,我们撰写首版 Scrum 指南,以帮助全世界的人们理解 Scrum。自那时起,我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。 Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的,这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则,将掩盖问题并限制 Scrum 的好处,甚至可能变得毫无用途。 我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用,超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大,developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此,我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者,而是为了简化统称。如果您从 Scrum 中获得价值,那么您可以将自己视为其中一员。 在使用 Scrum 时,可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的,因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异,因此不在本文中描述。 Ken Schwaber & Jeff Sutherland 2020 年 11 月

敏捷之旅中国 2020 汇总

Bob Jiang
敏捷之旅介绍 Agiletour(以下称为敏捷之旅)是一个国际非盈利性组织,于2008年成立,总部位于法国,由帕特里斯·佩蒂特发起。其目的是提供一个高效有趣的敏捷开发学习途径,在全球范围内推广敏捷的思想和实践,帮助企业更好的实施敏捷。 2020 各地敏捷之旅时间 11.22 北京敏捷之旅 11.28 郑州敏捷之旅 11.29 长春敏捷之旅 11.29 深圳敏捷之旅 12.5 大连敏捷之旅 12.6 沈阳敏捷之旅 12.13 上海敏捷之旅 [12.13 天津敏捷之旅]() [12.27 广州敏捷之旅]() 英文官方网站 敏捷之旅英文官方网站 招募 如果你想为敏捷在中国的推广贡献自己的力量,可以联系 bob@bobjiang.com 如果你想举办所在城市的敏捷之旅,欢迎在下面的issue留言。 - 申请举办敏捷之旅2020 提交举办信息(已经确定举办,尚未列在上面) - 申请举办敏捷之旅2020 目标 敏捷之旅的主要目标是: 大量交流敏捷 我们的主要任务是在整个十月和十二月的几个月里,以我们的行为进行一次“大众交流”。我们希望在有受众的任何地方进行交流,以吸引更多对我们新的专业方法的关注 分享我们对敏捷的看法 由于敏捷不断发展,我们希望向新视野开放,同时也为敏捷社区贡献我们的理解,解释和想法 联邦制 鼓励世界各地在敏捷领域中发挥领导作用,同时与敏捷文化和自我组织保持一致 支持 协助我们的同事和当地企业采用敏捷 总而言之,AgileTour敏捷之旅的任务是突出世界各地的领导组织并创建敏捷领导者,并协助大众传播敏捷的好处及其对世界专业人士的影响。因此,AgileTour敏捷之旅旨在帮助所有的组织和企业,这些组织和企业将以敏捷方法论为基础和使命。 以往活动的总结

Scrum指南最新变化 2020版本

Bob Jiang
Scrum指南 更少的规范性 多年以来,《Scrum指南》变得更具规范性(Prescriptive)。2020版旨在通过删除或软化说明性语言,将其恢复为最低限度的框架。 例如: 删除了每日Scrum问题, 软化了围绕PBI属性的语言, 软化了Sprint待办事项围绕回顾会的语言的条目 缩短了取消Sprint的部分等。 一个团队专注于一个产品 一个团队专注于一个产品的目的是消除团队内独立团队的概念,这会导致产品负责人(PO)和开发团队之间的“代理”或“我们和他们“的行为。现在只有一个Scrum团队专注于同一个团队目标,具有三组不同的职责:PO,SM和开发人员。 产品目标的介绍 2020版的《Scrum指南》引入了产品目标的概念,为Scrum团队向更大的有价值的目标迈进提供了重点。每个Sprint都应使产品更接近整体产品目标。 冲刺目标,完成的定义和产品目标的目录 之前的《Scrum指南》描述了Sprint目标和完成的定义,但并没有真正给它们提供身份。它们不完全是工件,而是有些附属于工件。除了2020版对产品目标提供了更清晰的说明。现在,每个工件中都包含对它们的“承诺”。 对于产品待办事项列表(Product Backlog),是产品目标; Sprint待办事项列表(Sprint Backlog)则有Sprint目标, 增量(Increment)则有完成的定义(现在不带引号)。 它们的存在是为了带来透明并专注于每个工件的进度。 自我管理超越自我组织 self-managing over self-orgainzing 之前的《Scrum指南》将开发团队称为自组织,团队选择和谁一起工作以及如何完成工作。 2020版本则更着重于Scrum团队,强调了自我管理的Scrum团队,团队选择和谁一起工作、如何做以及做什么。 三个Sprint计划的主题 除了“什么”和“如何”的Sprint计划主题外,2020的《Scrum指南》还强调了第三个主题“为什么”,指的是冲刺目标(Sprint Goal)。 全面简化语言,扩大受众范围 2020版本的《Scrum指南》着重于消除冗余和复杂的陈述,以及消除了余下的对IT工作的任何推断(例如测试,系统,设计,需求等)。现在,《 Scrum指南》不到13页。 加入社区? 加入社区参与讨论? 欢迎报名我的线上课程 - Scrum敏捷精髓

用户故事和任务 | 敏捷小知识 | 敏捷家出品

Bob Jiang
定义 什么是用户故事 用户故事是一种敏捷的实践,帮助开发团队从写需求的视角切换到与客户交谈需求的视角。敏捷用户故事中会有1-2句话简要描述需求,更重要的是基于这几句话的一系列交谈。 用户故事是从最终用户(或客户)的视角出发,对于他们有价值的特性的简单描述。通常是如下的格式: 作为 <某类用户>, 我想要<达成某个目标> 由于 <某个原因> 什么是任务 a: a usually assigned piece of work often to be finished within a certain time b: something hard or unpleasant that has to be done 任务的定义,来自于 韦氏词典 任务,通常是一定时间内要完成的、已分配的工作 任务,必须要做的,较困难的(令人不愉快的)的事情 这里的任务是通用的定义,在敏捷工作环境中,任务指的是团队为了完成用户故事而拆分更加细粒度的、功能模块的工作。 用户故事和任务的相同点 用户故事和任务都是开发团队必须参与的 用户故事和任务都是为了完成特性(feature)和产品的 用户故事和任务,通常都是较难的、必须完成的工作 用户故事和任务,通常都有截止日期(时间)的要求 用户故事和任务的不同点 用户故事就像裤子,而任务就像内裤 用户故事通常是解释特性的why,而任务通常是实现特性的how 用户故事是面向用户(或客户)的,而任务是面向团队的 用户故事通常是产品负责人(或客户)关注的,而任务通常是开发团队关注的 (注:开发团队也需要关注用户故事) 用户故事通常是以用户的语言进行描述(通俗易懂),而任务通常偏向于技术语言描述(如用python实现某个算法) 社区的回复 需求的价值版本描述和需求的BA-编程行为拆解? – 悟空 用户故事用户能听懂,可以参与。任务是团队自己能理解的功能做拆解。用户故事可以是一个mvp,任务可能只是故事的一个部分,不完整。 – Bruce Wang 任务是用户故事拆分后的子项,有指定的执行者 – 嘿,愉快的人儿啊 用户故事是需求点描述。任务是拆分出来的,用以实现用户故事的条目,任务指导开发团队实施具体的工作。– Fiona W.