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个英文单词的首字母所组成的。既然世界形势发生了变化，战略方针、战略行动、组织结构也应该随之而变，所以组织也应会应对这种战略、战术和组织结构做出相应的调整。个人应该做出什么样的转变呢？我觉得可能个人需要做到有愿景、有知识、有勇气和不断适应。 查看原文获取更多材料和音频