Agile

敏捷开发自2001年提出敏捷软件开发宣言后有20年，但在中文里很少有一篇文章详细介绍敏捷开发。因此本文从敏捷开发，敏捷开发的历史，敏捷开发的分类，敏捷宣言（价值观），以及敏捷精髓等方面详细阐述了敏捷开发。本文的最后还列举了敏捷在除了软件行业以外的应用，比如硬件、人力资源、市场、等等。

敏捷是老套领导力无法比拟的。过时的领导力注重的是管理和工人的分离；如何更好的把敏捷明道理实施落地，1. 专注于集体智慧；2. 创造创新的心理和职业安全；3. KPI和奖励基于价值创造而不是利用价值

写在前面 非常感谢 ETH123.org 的启发，在以太坊资源大全网站上线的时候，给我提供了灵感。尤其他们的网站是开源的，我可以直接 fork 下来进行改造即可。真心感谢ETH123.org，尤其还是感谢以太坊爱好者的曾汨和开发小伙伴。（帮我解决了一个技术问题） 还有哪些需要优化 目前还有几个地方有待进一步优化： 收集更多的敏捷相关学习资源 制作 Agile123.net logo 每个资源（网站）的logo收集 对于资源分类的建议 任何想法和建议，都欢迎在 github 上面提交issue。 目前有哪些资源 敏捷学习资源分类 当前的分类如下： 热门推荐、社区、敏捷框架、Scrum专区、大规模敏捷、产品设计、DevOps、敏捷度量、意见领袖、工具、资讯、博客、咨询公司、敏捷图书、敏捷实践等 收集的敏捷学习资源网站 这里就不一一列举了，如果你的博客，网站也想收录进来 欢迎在 github 上面提交issue。 最后，如果你认为这个站点对你有帮助，欢迎分享给更多的伙伴。 谢谢你的分享。

CSM培训总结 为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。 在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点： 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。 SM除了主持Daily Scrum之外，还有三个主要职责： SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。 SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。 SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。 现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。 不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。 – CSM学员 宋

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

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

内容来源：敏捷+社区线上直播009期，《在敏捷实践中加速成长》分享实录 分享者：平安壹钱包杨大鹏 关注本公众号回复”平安”即可获取本次分享的视频回放、下载PPT 平安集团是国内少有的，具备成体系的敏捷教练队伍的企业，从上到下拥有很好的敏捷土壤。再介绍一下我自己，我有十几年的工作经验，最初几年是做程序员，后来转向了项目管理和技术团队的管理，长期服务于外资银行和金融互联网的企业，我曾经在日本生活过很多年，非常熟悉传统的软件研发流程，也算是比较成功的 it项目管理者。我可以非常准确的挖掘客户需求，管控项目成本，管理团队，把成果物非常高品质的交付给客户。 但是后来我发现了一个问题，我不知道我交付的成果物能否为客户带来价值，项目结束结项以后，团队可能就会解散重组，我也没有办法持续地去帮助团队的成长。针对这两点我曾经非常的苦恼，后来就开始逐步学习敏捷的理论，毫不回头的走向了敏捷实践。 今天我和大家分享两部分内容，第一部分是在敏捷实践里，个人应该树立怎样的目标。第二部分我会用我自己的一个比较接地气的案例，来分享针对团队级别的敏捷实践，我怎样去具体解决一些常见的难点问题。用这个案例来分享我的思路和认知，希望能给大家带来一些参考。也希望能够帮大家少走一些弯路。 第一部分，我们现在是身处复杂的互联网时代，非常复杂，也被称为乌卡时代，典型的案例小黄车ofo，几年的时间里跌宕起伏，让人叹为观止。 查看原文获取更多材料和音频

内容来源：敏捷+社区线上直播008期，《敏捷的潘多拉魔盒》分享实录 分享者：李聃 关注本公众号回复”潘多拉”即可获取本次分享的视频回放、下载PPT 今天我给大家带来了一些关于敏捷方面的分享，也希望大家能有所收获。由于疫情我被困在了家中，所以在此我插播一个广告，非常感谢敏捷家及网易杭研组织这次课程，同时也感谢Bob老师以及在场的各位小伙伴。 今天我要分享的Topic是敏捷的潘多拉魔盒，当然了在讲课之前先做一个自我介绍，我叫李聃，我的聃和老子同名，我的姓也和老子同姓，所以我跟老子是同名同姓的。在我过去的16年的工作经验中，将近有10年是在做项目管理工作的。近5年其实我主要是公司的PMO负责人，管理公司的项目，并帮助组织做一些敏捷转型的相关工作，也辅导过很多的敏捷团队，也组织过或者作为演讲嘉宾参加过国内的一些敏捷或DevOps大会，并翻译过相关的一些书籍。关于专业认证方面，我有41个国际认证，包括项目管理、产品管理、精益敏捷、DeveOps、规模化敏捷和IT服务管理，同时我也是非常热门的火星着陆器和凤凰项目的沙盘授权讲师。 下面我们正式进入今天的课题，今天要分享的内容主要是围绕着敏捷及敏捷的一些反模式的话题所展开的。它其中包括4个小节： 乌卡时代的魔盒  潘多拉打开了魔盒  敏捷魔盒中的这些冰与火  敏捷魔盒中的最后的希望 我会通过几个故事和大家聊一下敏捷这个事情。 VUCA时代的魔盒 下面我们开始一起来揭开今天的潘多拉魔盒。说到乌卡这个词，它是由美国陆军在90年代初提出的一个概念，它是应对冷战后世界形势的一种解读。乌卡是由易变性、不确定性、复杂性、模糊性这4个英文单词的首字母所组成的。既然世界形势发生了变化，战略方针、战略行动、组织结构也应该随之而变，所以组织也应会应对这种战略、战术和组织结构做出相应的调整。个人应该做出什么样的转变呢？我觉得可能个人需要做到有愿景、有知识、有勇气和不断适应。 查看原文获取更多材料和音频

内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录 分享者：哈啰出行陈文博 关注本公众号回复“哈啰”即可获取本次分享的视频回放、下载PPT 非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！ 【正式分享之前，先上一个彩蛋】 查看原文 言归正传，今天的分享将分为两部分： 第一部分是我在哈啰做的一些敏捷实践，包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。 第二部分将给大家分享我在内部敏捷社区的一些做法，包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。 一、我的敏捷实践 首先给大家分享的是敏捷宣言的第一句话，”我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。” 分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。 查看原文获取更多材料

内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录 分享者：有赞效能改进工作者费解 关注本公众号回复”有赞”即可获取本次分享的视频回放、下载PPT OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。 OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。 管理是一门艺术，系统思考和组织设计，是两种底层能力，在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。 小调查 你在组织中处于什么角色？ 你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。 如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。 系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。实践敏捷也是如此，需要系统思考和更高维度的视野。 我的敏捷世界观 见山就是山 | 见山不是山 | 见山还是山 我的敏捷世界观： 见山就是山。最开始接触敏捷的时候，从课程中学到很多关于敏捷的方法、工具等，比如：三三五五。那时认为敏捷就是这个样子的，要实施敏捷的话，以它提供的框架，按部就班地来执行就可以了。这个阶段学到的是敏捷的形，没有参透敏捷的本质。 见山不是山。后来经历了很多项目管理、组织优化、效能改进的工作，不经意间会根据需求和场景，将学到的敏捷知识和方法加以变通，灵活运用到实际的工作中。比如：基于整个组织的现状，运用同理心，感受需要被引导和改进的部分，然后慢慢结合敏捷去实践。随着时间的推移，我们在更多领域中加入了敏捷的元素，也做了一些创新。这个阶段是领会到敏捷的本质，逐渐融会贯通的过程。 见山还是山。经过反思沉淀后我们发现，敏捷给出的方法论适用于很多工作场景，能解决很多问题，是前人经过无数实践总结出的方法。我们也会慢慢去反思：为什么要做敏捷？敏捷的本质是什么？ 我认为敏捷的本质有三个： 优先级。我们的优先级是否明确。在一个团队或大的组织中，有没有做事的方法？优先级是什么？人在同一个时间段只能做一件事，先做哪件后做哪件？ 高质量的交付。我们做事的目的一定是为了交付，为了产生价值，高质量的交付是敏捷的一种结果。 灵活变化。我们的组织或团队是否能够灵活应对外界的变化。如果是就是敏捷的，也不用刻意强调三三五五，僵化的敏捷不是敏捷。 一次灵魂拷问 你存在于组织中的价值是什么？ 前面问的是你在组织中的角色是什么。现在我们思考一下：你在组织中的价值是什么？是管理项目，还是作为一个敏捷教练带领敏捷团队？我们的出路在哪里？关注在哪个层面？ 敏捷之上的世界 大千世界 | 道法术器 | 价值在外 根据系统思考的原则，需要看到更高的维度。因此除了敏捷之外，还要看到敏捷之上的世界，看清问题的本质。 佛曰：三千世界。世界之外还有世界。在实行敏捷的同时还应该有更高维度的思考和实践。 道法术器。道法是指我们学敏捷不应只是学习它的方法，还应该理解其本质；器是工具，工具是管理的辅助手段，在工具的制定方面，一定是工具适应组织，而不是组织来适应工具。在敏捷实行过程中，即便工具设置得再好，如果实际操作起来完全不匹配组织的现状，使用起来也会很别扭。术包括敏捷方法提供的框架和工具，比如前面提到的三三五五之类的。在这里值得注意的是：要站在道和法的层面，从更高的角度来审视，是否需要用到所有的这些工具，避免生搬硬套，使敏捷变得僵化。 价值在外。不要以为敏捷团队的敏捷就是端到端的了，在敏捷团队之上还有更高维度的团队，比如：部门、业务线、事业部、甚至公司。我们要从全局看整体的目标是什么、以及是否达成。敏捷团队产生的价值是什么，包括对公司的价值和商业价值。 “价值在外”这个词是管理大师彼得德鲁克提出的，即：我们所做的任何事情都是在组织外部，才会被评价和被认可的。我们所做的动作，是帮助公司完成敏捷转型，还是是为公司创造价值？在做组织设计时，我们也需要面向是否创造外部价值。 查看原文获取更多材料