感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳：云享读书会《敏捷转型：打造VUCA时代的高效能组织》查看本期读书笔记   请戳：读书笔记征集【云享读书会-敏捷转型：打造VUCA时代的高效能组织】获取近期读书会活动安排，请私信小助手咨询哈~开发者，你好哟~欢迎参加云享读书会系列活动！本期云享读书会领读书籍为 - 中国第一部企业级敏捷实战著作《敏捷转型：打造VUCA时代的高效能组织》特邀作者王明兰进行领读！如果你已完成结业实践作业，请在此帖回复结果截图~01. 征集时间2019.9.5 - 2019.9.1602. 截图示例回帖时请务必留下你的微信昵称和华为云账号截图示例：03. 注意事项1. 截图提交后，小助手会在3个工作日内按续完成审核，并增加活动积分300分；2. 本次活动通过完成结业实践，可获得的积分上限为300分；3. 请务必按照上述要求提交内容，以免影响积分增加；4. 若积分值相同则以完成学习任务的时间先后排序，其中任务完成时间的判定优先级为：结业实践>读书笔记>自测题；5. 其他积分获取方式请查看活动社群公告；6. 其他未说明事项请参照 云享读书会《敏捷转型：打造VUCA时代的高效能组织》04. 关于云享读书会每期云享读书会活动，会选取一本技术相关的畅销书籍，由原作者或明星专家提炼书籍精华，在读书会的专属微信社群中，每日输出精华知识的领读视频，帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务，并根据活动结束后的积分排行发放活动奖励。05. 活动奖励

感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳：云享读书会《敏捷转型：打造VUCA时代的高效能组织》获取近期读书会活动安排，请私信小助手咨询哈~开发者，你好哟~欢迎参加云享读书会系列活动！本期云享读书会领读书籍为 - 中国第一部企业级敏捷实战著作《敏捷转型：打造VUCA时代的高效能组织》特邀作者王明兰进行领读！经过作者的视频领读，如果你有些敏捷相关知识收获，欢迎在此帖留下你的读书笔记~01. 征集时间2019.9.5 - 2019.9.1602. 读书笔记要求1. 每篇读书笔记字数要求≥300字；2. 内容要求与每日领读视频、《敏捷转型：打造VUCA时代的高效能组织》书籍或是华为云DevCloud产品优化意见相关；3. 内容原创不可抄袭；4. 回帖时请务必留下你的微信昵称和华为云账号。03. 注意事项1. 读书笔记提交后，小助手会在3个工作日内按续完成审核，并增加活动积分200分/篇；2. 本次活动通过提交读书笔记，可获得的积分上限为600分；3. 请务必按照上述要求提交内容，以免影响积分增加；4. 若积分值相同则以完成学习任务的时间先后排序，其中任务完成时间的判定优先级为：结业实践>读书笔记>自测题；5. 其他积分获取方式请查看活动社群公告；6. 其他未说明事项请参照 云享读书会《敏捷转型：打造VUCA时代的高效能组织》04. 关于云享读书会每期云享读书会活动，会选取一本技术相关的畅销书籍，由原作者或明星专家提炼书籍精华，在读书会的专属微信社群中，每日输出精华知识的领读视频，帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务，并根据活动结束后的积分排行发放活动奖励。05. 活动奖励

今晚开播！桃花岛小昭和姚冬“杠”上了？4大模块、16个环节拆解华为云DevOps转型的那些“套路”还有精彩1vs4，看姚冬如何突破连环PK参与互动问答还有机会获得《敏捷无敌之DevOps》新书试读内容！精彩不断，火花不断！扫描二维码锁定直播间，千万别错过哦~

要问2019年敏捷圈最大的事件是啥？那当然是横空出世的“敏捷江湖桃花岛”了！什么是敏捷江湖桃花岛？敏捷江湖桃花岛，是一个高价值的敏捷技术和人脉分享平台，其中包含华山论剑、江湖茶馆、江湖宝藏等多个重磅品牌活动，群内定期组织敏捷圈大咖进行线上直播和同城线下圈子沙龙。目前桃花岛内，已汇聚全国知名的敏捷大咖15余位，资深IT背景人员200位，其中覆盖企业家、CTO、敏捷教练、项目经理等，吸引上千位业内关注者。进入敏捷江湖桃花岛能获得什么？√1、和全国15+位知名敏捷圈大咖同群互动，零距离拜大神！√2、获得华山论剑直播连线资格，现场提问，现场PK！√3、获得独家社群福利，江湖宝藏不定时开启！√4、参与江湖茶馆专业话题讨论，解决工作实际问题，让敏捷溶于实践更多福利，正在开启……如何加入桃花岛呢？为保证桃花岛内用户和内容的质量，所有进群英雄均需通过测试扫描下图二维码，通过测试即可受邀入群注意！请正确填写您的微信号，否则我们将无法联系并邀请入群！快来加入我们吧~

要问2019年敏捷圈最大的事件是啥？那当然是横空出世的“敏捷江湖桃花岛”了！什么是敏捷江湖桃花岛？敏捷江湖桃花岛，是一个高价值的敏捷技术和人脉分享平台，其中包含华山论剑、江湖茶馆、江湖宝藏等多个重磅品牌活动，群内定期组织敏捷圈大咖进行线上直播和同城线下圈子沙龙。目前桃花岛内，已汇聚全国知名的敏捷大咖15余位，资深IT背景人员200位，其中覆盖企业家、CTO、敏捷教练、项目经理等，吸引上千位业内关注者。进入敏捷江湖桃花岛能获得什么？√1、和全国15+位知名敏捷圈大咖同群互动，零距离拜大神！√2、获得华山论剑直播连线资格，现场提问，现场PK！√3、获得独家社群福利，江湖宝藏不定时开启！√4、参与江湖茶馆专业话题讨论，解决工作实际问题，让敏捷溶于实践更多福利，正在开启……如何加入桃花岛呢？为保证桃花岛内用户和内容的质量，所有进群英雄均需通过测试扫描下图二维码，通过测试即可受邀入群注意！请正确填写您的微信号，否则我们将无法联系并邀请入群！快来加入我们吧~

要问2019年敏捷圈最大的事件是啥？那当然是横空出世的“敏捷江湖桃花岛”了！什么是敏捷江湖桃花岛？敏捷江湖桃花岛，是一个高价值的敏捷技术和人脉分享平台，其中包含华山论剑、江湖茶馆、江湖宝藏等多个重磅品牌活动，群内定期组织敏捷圈大咖进行线上直播和同城线下圈子沙龙。目前桃花岛内，已汇聚全国知名的敏捷大咖15余位，资深IT背景人员200位，其中覆盖企业家、CTO、敏捷教练、项目经理等，吸引上千位业内关注者。进入敏捷江湖桃花岛能获得什么？√1、和全国15+位知名敏捷圈大咖同群互动，零距离拜大神！√2、获得华山论剑直播连线资格，现场提问，现场PK！√3、获得独家社群福利，江湖宝藏不定时开启！√4、参与江湖茶馆专业话题讨论，解决工作实际问题，让敏捷溶于实践更多福利，正在开启……如何加入桃花岛呢？为保证桃花岛内用户和内容的质量，所有进群英雄均需通过测试扫描下图二维码，通过测试即可受邀入群注意！请正确填写您的微信号，否则我们将无法联系并邀请入群！快来加入我们吧~

微话题 “敏捷的本质到底是什么？”希望大家能够畅所欲言。如果大家有其他任何与敏捷相关的问题，也可以在本帖回复直接咨询MVP王立杰。=======【华为云·微话题】敏捷的本质到底是什么？ =======成功产品的特性就是要以用户为中心，快速响应市场变化。在进入移动互联网时代后，这种特性表现的更加突出；对应的项目管理必须能够适应这种变化，如果沿用传统的项目思路来管理，过分强调需求的完备化、WBS分解、甘特图、关键链、大而全的项目计划、按部就班的进度追踪，肯定适应不了当前变化多而快的市场环境。 敏捷项目管理，作为最近几年的热点话题之一，已经逐渐成为国内外各大互联网公司的标配，根据最新Version One公司做出的统计，90%的实施敏捷转型的公司，在采用敏捷项目管理方式后取得了非常好的改进效果，缩短了产品交付周期，提高了产品质量，提高了客户满意度，同时提高了研发效率及员工满意度。 那么，相对于传统项目管理模式，敏捷的本质到底是什么呢？期望看到大家精彩的评论：1. 敏捷强调快速响应变化，是不是根本不需要做计划？2. 唯一不变的就是变化，在敏捷模式，该如何掌控需求变化？3. 敏捷中，该如何写文档？PRD还有需要吗？4. 敏捷强调团队的自管理、自组织，对成员的能力要求到底是什么样的？如何促进团队成长？5. 如果用一句话或几个关键词来描述敏捷，你会怎么定义？微话题活动：参与本次微话题讨论，有机会获得优质评论奖，赢取书籍。活动时间：2019年7月8日-7月22日参与方式：直接在本帖回复关于以上5个问题中的任意1个或多个问题的理解或评论获奖方式：活动结束后，将由MVP 王立杰  选取出2名优质评论奖，各送出《敏捷无敌》书籍1本。评奖标准：回复话题数量和内容质量。优质评论：ecstatic：1. 敏捷强调快速响应变化，是不是根本不需要做计划？   计划是一个项目实践过程中非常重要的工作，它能够保证我们开发的方向性和可预期性，为此通常我们会制定一些文档和注意事项。敏捷开发也非常强调计划的重要性，但制定的过程却非常灵活。在敏捷开发迭代初期，开发人员会和客户一起按照需求的优先级和依赖关系制定一个2-6周的开发计划。这个计划的灵活性在于计划的构成不是按照任务数量来规定时间，而是根据时间来制定任务量，这就解决了需求变更导致的计划改变等问题。2. 唯一不变的就是变化，在敏捷模式，该如何掌控需求变化？    a.问卷调查、意见反馈、竞品分析，数据分析、同事反馈、用户观察等方式收集需求    b.把需求用用户故事表述    c.判断需求优先级    d.安排人员实现需求   3. 敏捷中，该如何写文档？PRD还有需要吗？   把文档拆分成好几个部分去写，最后才合在一起，   需要，PRD除了讲解需求的作用，还是产品历史功能追溯、记录的作用，用来保证需求设计、开发实现、测试验证的过程是在同一个基准的理解基础上的，避免出现各自的想法不一致导致的产品形态走样。4. 敏捷强调团队的自管理、自组织，对成员的能力要求到底是什么样的？如何促进团队成长？        a.能力要求如下：        初级敏捷团队    1、Team内PO角色清楚，PO负责管理Product Backlog；    2、PO是需求的主要来源，并负责并从各方收集需求，并对需求负责；    3、PO负责Product Backlog优先级的确定，当变动发生时也是如此；    4、Team中有一个人可以承担Scrum Master这个角色的工作，基本上由此人长期承担Scrum Master的工作；    5、基本能够协调Team解决在Sprint内遇到的问题。但是对跨Domain的问题解决推动能力弱；    6、由Scrum Master协助团队成员进行维护Sprint Backlog，并培养团队成员自行维护Sprint Backlog的习惯；    7、Scrum Master负责主导和主持站会，站会在固定地点和固定时间，在标准时长内结束，Scrum Master对团队每个成员的工作内容都很清楚，可以通过站会发现大部分问题和风险；    8、Scrum Master负责各种会议的如期进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；    9、Scrum Master负责主导和主持plan meeting，给出工时的评估方式，给出本次sprint的计划内容和优先级别，引导大家进行sprint内容的拆分，引导大家完成工时的评估；    10、Scrum Master负责主导和主持总结会议，主要由Scrum Master负责总结本次迭代的优点和缺点，并针对缺点制定出改进措施并进行跟进；    11、Scrum Master负责监控风险和进度，并能知会给利益相关人；    12、Team大部分情况下能够完成对DOD的承若；    中级敏捷团队    1、PO负责管理Product Backlog，Team认可Product Backlog内容；    2、Team会协助PO收集需求，也会积极提出需求，Team认可需求并对需求负责；    3、PO协助Team进行Product Backlog优先级的确定，当变动发生时也是如此；    4、Team中Scrum Master这个角色的工作有Backup，当Scrum Master不在时，Backup可完全承担该角色的工作；    5、完全能够协调Team解决在Sprint内遇到的问题。对跨Domain的问题解决推动能力较强，但对跨部门的问题解决推动能力较弱；    6、团队成员自行维护Sprint Backlog的习惯已形成，Scrum Master只需监督和提醒；    7、Scrum Master协助站会有效进行，站会在固定地点和固定时间，在标准时长内结束，团队成员对于其他成员的工作内容都很清楚，团队成员可以协助Scrum Master发现一些问题和风险，大部分问题和风险还是由Scrum Master发现；    8、Scrum Master协助各种会议的有效进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；    9、Scrum Master协助plan meeting有效进行，和团队成员共同商讨确定工时的评估方式、本次sprint的计划内容和优先级别，进而共同完成sprint内容的拆分和工时的评估；    10、Scrum Master协助总结会议有效进行，和团队成员共同商讨总结本次迭代的优点和不足，能够针对不足制定出有效的改进措施并进行有效的改进，而优点能够继续保持；    11、Scrum Master主导，团队成员参与监控风险和进度，并能定期通知给利益相关人；    12、Team共同完成对DOD的承若；    高级敏捷团队    1、Product Backlog由PO发起管理，由Team共同参与讨论完善；    2、Team共同提出和收集需求，共同对产品负责；        3、Team共同对Product Backlog优先级进行确定并负责，当变动发生时也是如此；        4、Team中任何一个人都可以承担Scrum Master这个角色的工作；    5、可以帮助Team跨越Sprint中遇到的一切障碍，对跨Domain和跨部门的问题解决推动能力均较强，保障DoD按约定完成；    6、团队成员自觉维护Sprint Backlog，Scrum Master定期检查团队成员维护Sprint Backlog的情况；    7、团队成员积极地参加站会，站会高效地效进行，站会在固定地点和固定时间，在标准时长内结束，团队成员对于其他成员的工作内容都很清楚，团队成员积极提出问题与风险，和Scrum Master共同发现所有问题和风险；    8、Scrum Master辅助，团队成员主导各种会议的有效进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；    9、Scrum Master辅助，团队成员主导plan meeting，Team共同对工时评估的结果，本次sprint的计划内容及拆分结果，优先级别确认结果负责；    10、Scrum Master辅助，团队成员主导总结会议，Team共同对本次迭代的结果负责，能够共同认识到不足的根本原因所在，后期所有团队成员都积极有效的改进，将不足逐渐转变为优点，而优点能够越做越好；    11、Team共同积极监控风险和进度，并能及时通知给利益相关人；    12、Team从专注功能实现专为专注产品实现，Team有能力识别产品的正确路线，共同促使产品不断被完善；        b.团队成长需要：    1、团队要学会在没有大而全的计划的情况下开始工作；    2、团队要学会在没有详细需求文档的情况下，通过用户故事和交流分析和理解需求，开始设计和编程；    3、团队要习惯于频繁递交代码和持续集成；    4、团队是在高度透明的环境下工作，每个人的进展被所有人都了如指掌；    5、团队需要进行结对编程，需要频繁的沟通和讨论；5. 如果用一句话或几个关键词来描述敏捷，你会怎么定义？       以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发建赟：1、 敏捷强调快速响应变化，是不是根本不需要做计划？个人认为是非常需要的，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。而由于产品需求的不确定性、甚至是未知的，敏捷项目团队很少能在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能。 2、唯一不变的就是变化，在敏捷模式，该如何掌控需求变化？       需求规划完成了之后，我们要确保这些需求能在敏捷开发的过程当中实现。相比较与瀑布模式，需求规划完成了之后，提供一份完整的PRD就可以逐项开始开发了，敏捷模式下需求规划中的功能清单首先有可能不是一次实现，会分多次，可能中间还穿插了别的项目，其次是每个功能清单还是再拆分成开发任务去分别实现，再加上中间的需求变更，所以在需求实现的过程当中是要采取一些措施去避免实现中的困难的，比如需求实现的连续性问题，需求拆分的方式方法，需求变更的处理，敏捷开发过程当中问题的解决等。同时一个好的计划会议可以将需求拆分成可在一个迭代内实现的几个部分，再加上每日站会的过程跟踪，发现问题及时解决，最后通过敏捷测试及时验证已开发完成的条目，这样的过程基本可以保证每个需求的实现都是按照原先的需求规划来的。            3、 敏捷中，该如何写文档？PRD还有需要吗？         在敏捷项目中，文档的价值不是通过数量或者是模板规范来体现它的价值。敏捷项目中的文档应该是有目的性的去编写，是为了解决某种问题，而不是为了文档而文档。为了达成不同的目的，不同的文档它的受众也是不同的。对于PRD，个人感觉是需要的。原因如下：稍微大一点的团队产品经理未必能向每个人传达产品需求，这就需要有一个文档的形式来向项目的所有成员来传达需求，这就是文档的来源；由于产品经理经常会变更需求，经常爱拍脑袋，容易变卦，所以程序员就想到用一个文档来约束产品经理；测试人员需要根据产品需求文档来验收产品质量；当你的项目有新人进入的时候，可以让新人更快的了解产品。当你离职的时候，继任的产品经理也可以根据你的文档来熟悉产品迭代的内容；有利于你装逼。你面试的时候拿着一份写的很规范的PRD文档，面试官会觉得你碉堡的，哈哈。      4. 敏捷强调团队的自管理、自组织，对成员的能力要求到底是什么样的？如何促进团队成长？      个人认为对成员的要求有三点：A very good team player很好的团队合作者。敏捷强调团队，如果只是个人能力强而不懂得合作，这样的人在敏捷团队里就没法混；Excellent communication skills优秀的沟通能力。这一点的重要性不言而喻，敏捷里最强调的就是沟通，最有效的沟通方式就是面对面的交流。那种只会埋头干活，不会沟通的不要；Open minded, pro-active, and self-motivated敏捷团队成员必须能够敞开思想，随时接受新事物，积极主动，自我激励   对于如何促进团队的成长，个人认为这不是几句话能讲清楚，明白的。首先团队需要充分发挥团队的主观能动性；应当适当放权，避免管的太细；对于版本一般两个星期会发布一个版本（可能是对内，可能是对外）；同时要以身作则：从自己做起，让团队看到真实的例子；平衡心态：别让团队的反应乱了阵脚；循序渐进：耐心，逐步改进；谨言慎行：注意言辞，说话要基于团队的立场； 边走边学：尝试，反思，从错误中学习。对于考虑可选方案的方式有暴露问题：让团队看到问题；公开讨论问题：和团队讨论这个问题；静观其变：搁置问题，如果情况变得更糟糕，团队也许自己会发现问题； 暗度陈仓：说服团队内或团队之外的其他人认识到问题；根因分析：寻找问题的根本原因；教育团队：提供更多信息帮助团队找到解决办法； 予人权责：将此职责转交给团队或某个团队成员；在受阻时，可以想象其他教练面临同样的情形时所采取的措施。等等       5. 如果用一句话或几个关键词来描述敏捷，你会怎么定义？        从字面上理解，顾名思义，敏捷一词包含了两层含义，一是“灵活”——闪转腾挪，游刃有余;二是“快速”——天下武功，唯快不破。在这两层含义里，都包含了一个核心——躲避危险的能力。当变化无可避免成为常态时，我们干脆勇敢的面对、拥抱变化。所以，需要了解实现敏捷的理念，才能创造开辟适合于自己的踏上向“敏捷”转化的道路。

所有混乱都是尚未被理解的和谐华为云敏捷江湖桃花岛力邀5位敏捷大神，为企业敏捷转型痛点把脉问诊！7月26日，敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连！第三期的华山论剑大连线下活动，就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。 本次线下活动为了最大程度保证用户体验采取了邀请制，参会用户来自大连本地的企业家，敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容：华为云DevCloud首席布道师 刘恒曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰IBM敏捷教练 14年IT工作背景 管婷婷管理3.0认证引导师&Co-owner Scrum联盟CSP，CSM，CSPO 侯伯薇华为云DevCloud敏捷专家、资深过程改善顾问 黄隽以下为本次活动文字实录：

华为云DevCloud助力中科方德列车运行监控与检修维护系统敏捷研发中科方德软件有限公司成立于2006年，是“基础软件国家工程研究中心”项目法人单位，该中心是目前基础软件领域唯一的国家级工程技术研究中心。作为国内为数不多的长期投身操作系统产业发展的企业，中科方德以保障国家党政军及重大行业信息系统安全、发展我国自主可控基础软件为己任，致力于提供可以信赖的国产操作系统产品、解决方案和服务。“列车运行监控与检修维护系统”是近几年研发的主要产品，该系统是针对列车运行状态监测、维修辅助、数据挖掘分析、故障预警和故障诊断等需求开发的一套软件产品，在保障列车的运行安全、提高维修效率和降低维护成本等方面发挥重要作用，实现列车检修维护的自动化和智能化。列车运行监控与检修维护系统平台展示随着公司平台业务覆盖范围的逐渐扩大，平台使用人数不断攀升，公司技术团队面临的压力也不断加大。2017年底，方德研发团队开始学习华为云DevCloud的操作及理念，随着时间的推移，华为云DevCloud已经得到了研发团队的广泛认可。DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台；面向开发者提供研发工具服务，让软件开发简单高效。git基础上的代码托管服务列车运行监控团队在使用软件开发云前代码托管工具上运用的是SVN，受连接服务器的限制，出差时无法提交，也无法查看之前的提交记录。项目人员在异地开发协同效率低、代码合并冲突频繁，无法满足客户需求。使用华为云DevCloud后在线代码阅读、修改和提交，随时随地，不受限制，解决了异地研发问题以及查看之前提交记录的问题，支持在线分支创建、切换、合并，多分支并行开发，提高了研发效率。华为云DevCloud代码托管功能使用截图简单高效的代码检查在接触华为云DevCloud之前，列车运行监控研发团队是开发完后自行检查或团队间交互检查，容易忽略潜在的代码缺陷且浪费大量时间。使用华为云DevCloud代码检查后，可快速检测出问题数量，华为云DevCloud提供近2000条华为典型检查规则；支持Java、JavaScript、CSS、HTML、PHP、C#、Android等常见开发语言； 提供多维度质量统计报表，包括质量星级和风险指数评估，华为云DevCloud帮助研发团队精确定位缺陷，提供修复指导，针对检测出的每个代码缺陷，提供了详细的缺陷影响说明、正确示例、修改建议；针对大量代码缺陷，团队可根据问题级别、问题分类、语言、文件目录等进行过滤，分级处理。缩短了处理缺陷的时间，提高了研发效率。华为云DevCloud代码检查功能使用截图快速的编译部署服务列车运行监控与检修维护系统之前项目建在公司自有的服务器上，采用本地编译构建本地部署，每次本地打包发布，不仅编译时间慢而且容易宕机，自从使用了华为云弹性服务器及，利用云端构建海量构建资源，采用多样化的云端构建加速手段，实现本地构建无法企及的构建速度，进行可视化、一键式部署，部署成功后，客户通过外网直接快速访问。极大减少了宕机问题。华为云DevCloud编译部署功能使用截图在未来中科方德将继续与华为一起，迈向云计算时代，实现软件研发过程可视、可控、可度量，研发能力提升有章可循。缩短产品上市周期，减少产品缺陷。

 7月2日下午，在中国信息通信研究院举办的可信云大会上正式发布了《中国DevOps现状调查报告（2019年）》，并由中国信通院云大所云计算部运维研究员车昕对报告进行了解读。此次2019年的中国DevOps行业调查活动，由中国信息通信研究院牵头，华为云DevCloud提供调研与报告平台，以及南京大学一起联合举办，历时5月和6月共两个月，收集到1549份有效问卷。对这些问卷进行分析后，我们编写了这份《中国DevOps现状调查报告（2019年）》，从中我们可以对国内DevOps行业的现状有所了解。首先，我们要了解1549份问卷这个数字意味着什么：DORA的全球DevOps现状调查，2018年是其第5次调查，共收集了约1900份问卷；VersionOne的全球敏捷现状调查，2018年已经是第13次调查，共收集了1319份完整问卷；中国DevOps行业调查：华为云DevCloud参与了联合举办，共收集1549份问卷；2019年的调查（链接）已经结束，但其中的DevOps成熟度评估的功能在华为云DevCloud上面向注册用户持续免费提供，如果您对此感兴趣，可以前往体验，只需要打开如下链接即可：DevOps能力成熟度评估（需登录华为云DevCloud）：https://devcloud.huaweicloud.com/expert/assessment/home 本帖福利：车昕研究院在可信云大会上的解读材料；完整的《中国DevOps现状调查报告（2019年）》；《研发运营一体化（DevOps）能力成熟度模型》第3部分 - 持续交付；华为云DevCloud HE2E DevOps实施框架；2018年DevOps中国调查报告； 如下是观点摘要内容： DevOps 接受程度半数企业认为 产品质量、 按时交付、客户满意度和研发效率的提升是判断 DevOps 是否成功实践的重要标准 。占比分别为 50. 23 、 49.19% 、 47.58% 和 41.13% 其次 是交付的业务价值（ 26.61%26.61%）、过程改进（ 24.19%24.19%）、项目可预测性 23.39%23.39%）和项目可见度 22.34%22.34%）。尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。调查结果显示，仅有 31.65% 被调查者认为自己组织的 DevOps 实践是成功的， 28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。DevOps 应用现状DevOps 已经在国内逐步落 地实践。 调查发现， DevOps 在国内落地的情况，基础级和全面级占到整体的 6 成左右，其中，部分企业在一些方面取得了局部的收获但是离较好的程度还有一定距离，这部分占比为 46.65% 。敏捷开发管理在企业应用广泛。 调查发现，采用 DevOps 的企业中，近 7 成企业的敏捷开发管理成熟度达到了基础级以上 。企业普遍采取业界成熟的敏捷开发方法以提升研发效率。 Scrum 、看板方法、自定义混合敏捷方法是最受企业欢迎的前三种敏捷开发方法，占比分别为 45.41% 、 41.23% 、 31.46% 。当前 企业使用敏捷技术普及率不高，多数企业研发管理流程严谨性不足。 据调查显示，普及率最高的敏捷技术 是 每日站会，选择率为 50.93% 。超半数企业使用敏捷工程实践管理开发项目。 调查显示，近 6 成企业选择了编码规范、单元测试和 持续集成，占比分别为 59.48% 、 55.39% 和 45.89%Scrum of Scrums 是企业选择最多的大规模敏捷开发方法。 调查结果显示 27.46% 的企业选择使用Scrum of Scrums 在组织内部 大范围 推广、扩展敏捷开发 。大规模敏捷的成功主要取决于团队使用一致的实践和流程。 受访者普遍认为成功实施大规模敏捷的因素主要是团队使用一致的实践和流程，选择比例超 4 成 。持续交付是 DevOps 的核心工程实践，贯穿软件开发全生命周期。 实现了健全的版本控制系统、基于主干开发、自动化构建、自动化测试、自动化部署、每天多次集成和组织级度量等能力 都对软件开发产生正面的影响 。 调查发现， 超 8 成企业采用持续交付实践并获得研发效率的提升。版本控制系统使用的熟练程度与企业持续交付 能力 成熟度呈正比。 调查结果显示，持续交付能力成熟度为基础级的企业， 8 成以上均使用了版本控制系统 持续交付能力成熟度达到全面级的企业，近半数具备健全的版本控制系统 持续交付能力成熟度达到优秀级的企业，超 7 成以上实现了版本控制系统的自动化操作；持续交付能力成熟度达到卓越级的企业，实现将软件全生命周期的所有配置均纳入版本控制系统管理，并可完整回溯软件交付过程。持续交付 能力 成熟度与自动化构建和部署方式的采用率 呈 正比。 调查发现，自动化构建和部署的水平对持续交付成熟度的影响很大 ，持续交付成熟度 达到全面级的企业中， 7 成都实现了自动化构建和自动化部署。持续交付能力成熟度较高的组织普遍实现了持续交付流水线自服务 。根据调查报告显示，近 4 成企业实现了可视化的持续交付流水线，使用者可按需选择 任意 环节 。缩短进入市场的时间是满足客户需求的关键因素， 部 署频率和集成频率从侧面反映了企业快速响应市场需 求，满足客户要求的能力 。 根据调查报告显示，已经实现按需部署和按需集成的企业比例为 12.40% 、 11.29%11.29%；实现 1 天多次部署和集成的企业比例为 28.45% 、 23.69%23.69%；实现 1 周之内部署和集成的企业比例为 21.14% 、 15.45%15.45%；实现 1 个月之内部署和集成的企业比例为27.89% 、 29.45%29.45%；分别有 10.12% 、 20.12% 的企 业部署和集成频率超过了 1 个月。自动化测试整体 覆盖率 偏低。 DevOps 提倡测试前移，测试用例编写和代码开发同步进行，增加代码级和 服务 级测试 ，提高自动化测试比例。 目前仅有 5 成被调查企业实现了自动化的接口测试、单元测试和功能测试，占比分别为 55.58% 、 52.97% 和 52.79% 。具备清晰、明确的变更管理系统的组织，平均变更前置时间也相对较短。 本次调查中，近 6 成 的组织能够将变更前置时间控制在 1 天之内，其中小于 15 分钟占比为 17.66% 15 分钟 ~1 小时占比22.30% 1 小时 ~1 天占比为 24.16% 。众多持续交付工具中，持续集成工具 Jenkins 和构建工具 Maven 最受欢迎。 调查结果显示，超5 成企业使用 Maven 和 Jenkins ，占比分别为 51.34% 和 43.90%企业 技术运营能力有待提升。 据调查结果显示，近 7 成企业技术运营能力离较好还有一段距离其中 30.11% 的企业技术运营能力成熟度处于初始级， 35.50% 的企业技术运营能力成熟度达到基础级 。RTO 、 RPO 标准是企业对潜在风险的管理，从侧面反映出企业的业务连续性。 3 成被调查企业表示目前公司具备 RTO 、 RPO 标准，但并未严格执行；超四分之一企业认为公司已制定 RTO 、 RPO标准，整体 RTO 可达到 99.90%99.90%，同城 RPO>5 分钟 。多数 企业的应用设计水平有待提高。 6 成被调查企业的应用设计水平位于 初始级 和 基础级，比例分别为 28.81% 和 31.97%31.97%；其次是全面级 22.30%22.30%）和优秀级 13.01%13.01%），仅有 3.90% 的组织达到卓越级。目前，企业尚未给 予 安全管理足够的重视。 调查结果显示， 7 成企业安全管理成熟度位于 初始级和 基础级 安全管控手段有待加强； 2 成企业安全管理成熟度达到全面级，安全检测基本覆盖软件开发全生命周期中；仅有 5.2% 被调查企业安全管理成熟度达到优秀级。专业的安全团队比例相对较低。 被调查企业中， 近 4 成 企业建立专业的安全团队参与到研发过程中； 6 成以上 企业目前尚未建立专业的安全团队。代码安全性 和 设计是否符合安全规范 已经作为企业最关注的安全问题被予以高度重视 。据调查结果显示， 7 成 以上 企业更关心代码的安全性，占比达 73.05%73.05%；近 6 成企业认为设计是否符合安全规范比较重要， 占比达 59.11% 。企业 集成 安全检测 的阶段逐渐左移。 4 6. 84% 的团队已经将自动化安全分析集成到代码开发阶段；41.26% 的团队在测试阶段集成了安全检测；从关注到落地，还需要企业切实投入。 调查显示， 企业 对 代码安全的关注度高达 73.05%73.05%，却只有 46.84% 的企业在代码开发阶段添加了自动化安全分析； 对 设计是否符合安全规范的关注度有59.11%59.11%，在代码结构设计阶段添加了自动化安全分析的 企业 只有 41.26% 。市场已具备多种相对成熟的安全检测工具。 调查结果显示， Nessus 和 Snort 是 企业首选的安全检测工具，占比分别为21.36% 、 18.02% 。 DevOps 实践存在的问题和挑战超半数企业认为需求的频繁变更 是 阻碍软件按时交付的主要原因 。调查结果显示， 59. 6 8% 企业认为需求的频繁变更阻碍软件按时交付； 38.71% 企业认为集成问题太多阻碍 了 软件按时交付。多因素造成企业难以推行 DevOps ，其中各部门之间目标的不同是企业首选 的 主要原因 。 近半数企业认为各部门之间目标的不同是导致 DevOps 推行失败的主要原因。近 3 成企业认为 个人优先效忠于自己的部门其次才是组织、不同行业的限制、缺乏 DevOps 专业知识和相关人才是阻碍DevOps 推行的原因，占比分别为 31.35% 、 29.84% 和 27.42% 。 未来DevOps 投入的趋势企业对 DevOps 的未来投入有非常明确的计划。 对企业未来对 DevOps 投资的 调查 结果显示，各企业普遍增加对 DevOps 的重视度，超 六 成的企业非常明确的计划对 DevOps 工具或培训进行投入 。 企业对 DevOps 工具和技术的选择云计算助力 DevOps 实践落地生根。 本次调查结果显示，近半数企业表示正在开发的主要应用程序或服务已托管在公有云平台上；近 3 成企业选择了混合云和私有云，占比分别为 16.36% 和15.24% 11.52% 的企业选择了多种类型共存 。企业采取多个云供应商的比例有所提高。 调查结果显示， 47% 的被调查企业选择了单一云供应商，39% 的被调查企业选择了多个云供应商提供的云服务， 12% 的企业没有使用任何供应商。微服务架构已被广泛的应用到企业的软件开发中 。 据调查 目前最受企业欢迎的微服务框架是 Sprint Cloud 和 Sprint Boot ，占比达到 45.91% 和 44.24% 。易用性、可伸缩性和性能是企业选择微服务框架最主要的因素。 超过半数的企业出于易用性、可伸缩性和性能考虑而选择微服务框架，占比分别为 46.10% 、 46.10% 和 41.26% 。容器的出现使 DevOps 落地实践相对容易 。 调查显示，大部分企业均表示通过使用容器技术提升了软件交付的效率，降低了IT 成本，其中 64.02% 的企业选择了 Docker 25.91% 的企业选择了Kubernetes 8.23% 的企业选择了 Rancher 1.83% 的企业选择了 Mesos 。灵活的可 移植性和保持跨环境的一致性是企业选择容器的主要因素 。被 调查 企业中，超过半数的企业均认为容器最受欢迎的特点是灵活的可移植性和保持跨环境的一致性，占比达到 54.28% 和44.42% 。采用适当的 DevOps 工具可以提高 DevOps 落地实践的成功率，对企业成功实现 DevOps 转型起到事半功倍的作用。 目前，市场上已经有很多成熟的商用 DevOps 工具。在被调查企业的选择中，需求和项目管理工具 JIRA 高居第一位，占比为 52.31% 。工具安全性和产品服务的价格是企业选择 DevOps 工具最关注的因素。 占比分别为 52.59% 、47.41% 其他几种比较受关注的因素分别是工具自动化程度、功能易用性、是否开源、功能丰富性和 DevOps 工具商知名度，占比分别为 38.08% 、 37.31% 、 35.23% 、 32.64% 和 32.12% 。 企业对政策资质的需求软件开发能力和 DevOps 能力成熟度方面的评估认证备受企业用户重视。 据调查，多数受访企业认为第三方软件开发成熟度体系评估有助于 DevOps 更好的落地实践， 45.97% 的企业认为CMMI 软件能力成熟度认证比较重要； 41.94% 的企业认为 DevOps 能力成熟度评估是项目开发中实践 DevOps 能力应当具备的资质；另有 39.52% 和 18.55% 的企业认为 ISO 体系认证和中国信通院开展的金牌运维评估 是 企业实践 DevOps 应当具备的资质。 

序  言随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。  目  录序  言1     正常情况下的移动2     需求变更情况下的移动2.1      不接受变更2.2      拥抱变更 1          正常情况下的移动使用看板主要意图之一是控制在制品数量（WIP, work in process）,需要拉动式的移动，这样可以有效控制在制品数量，防止工作项过多积压。另外需要提示一点，在整个移动过程的前提是需要制定一套移动规则，具体什么样的规则这里不做过多的描述，根据团队自身情况定义就好，规则根据团队意见可以调整几次，最后团队满意就是合适的。2          需求变更情况下的移动2.1       不接受变更当一个Sprint的Sprint Backlog和Sprint 目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。2.2       拥抱变更完成拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况：1)    无价值需求与PO沟通协商，对于无价值需求果断拒绝，当然是与PO协商后的结论，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做引申了。2)    变更少，影响小的需求高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程,然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理:一种是移回到Product Backlog列,这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。当然第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。3)    变更多，影响很大的需求高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。

背景一个人数为7人左右的团队采用Scrum框架工作。Sprint的长度，团队目前采用时间盒为1周。团队经常会出现在Sprint结束时不能完成当初设定的Sprint目标，很多工作项需要跨Sprint才可以完成。问题分析目前Sprint中存在的主要问题是Sprint目标完成不好，解决掉障碍，Sprint目标按承诺完成即可。团队成员的工作内容中包含很多探索性工作项，对工作内容领域不熟悉，需要投入一些学习成本，导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大，多数超过24小时。PO对工作项完成标准的要求非常高，评审严格，不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周，并且四大事件按照Scrum框架执行，其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。从分析中归纳影响Sprint目标完成的几个主要因素如下表：影响Sprint目标因素表（一）。影响Sprint目标因素表（一）序号影响因素具体分析1探索性工作项多无法改变现状，学习成本的投入是必须项。可以考虑团队成员间知识共享，随着能力提升学习成本会逐渐减少。2工作领域不熟悉，需要学习成本  3用户故事比较大由于工作项的特殊性，用户故事普遍比较大，可以考虑拆分为更小的故事，或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。4PO完成标准高进一步理解PO完成标准，在计划会议上需要明确验收标准（AC, Acceptance Criteria） 和 (DoD, Definition of Done).5Sprint周期短团队初始确定的周期长度为一周，经过几轮Sprint后，如果Sprint目标完成不理想，根据工作项特殊性考虑到周期有点短，适当调整周期。6Sprint计划会议和Sprint回顾会议持续时间略长每项会议其实是有建议的时长，正常一个月的Sprint周期，建议Sprint计划会议为8小时，那么按比例一周的Sprint，建议计划会议为2小时时长。同样，一个月的Sprint周期，建议Sprint回顾会议不超过3小，显然，对于一周Sprint时长的回顾会议用掉2小时是严重超时的。解决措施针对以上问题的分析，建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短，团队成员会忙于准备计划会议、评审会议及回顾会议，真正完成工作项的时间较少。对于突发事件的应对能力减弱，不利于形成团队稳定的节奏。Sprint的时间过长，失去了短时间盒的优势，失去了时间盒的意义。因此，如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标，可以试着把时间盒调为两周。同时要注意优化用户故事的大小，提高四大事件的效率。Spring的时间盒由一周改为两周后影响因素会有所改善，具体如表：影响Sprint目标因素表（二）影响Sprint目标因素表（二）序号影响因素Sprint由一周改为两周后的相应缓解1探索性工作项多有相对充分的缓冲时间应对学习、探求性工作以及突发情况。2工作领域不熟悉，需要学习成本  3用户故事比较大时间相对宽裕后，计划会议开得更充分，用户故事拆分为更小的故事，或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。4PO完成标准高时间相对宽裕后，理解PO完成标准更加充分，在计划会议上明确验收标准（AC, Acceptance Criteria） 和 (DoD, Definition of Done).5Sprint周期短调整周期后，团队成员氛围更加好，每个Spring目标完成度得以改善，成员更加自信。6Sprint计划会议和Sprint回顾会议持续时间略长时间相对宽裕后，每项会议质量有所提高，在合理的时间范围内可以高质量完成会议内容。计划会议其它情况Sprint的时间盒长度建议如下，需要说明的是以下情况不是绝对的，需要根据团队现况选择适合的就好，没有绝对的对与错，适合的就是最好的。·        一周到两周新产品研发团队，产品具有时效性的特点，业务需求迎合市场随时调整，灵活多便，快速响应业务需求，经常性的自检。·        两周团队节奏相对稳定，故事点较大，不好拆分，需要更多的时间评审和返工修正。·        三周到四周节奏稳定，团队稳定，需求稳定，团队有固定的节奏，浪费较少。了解更多：什么是时间盒？在Scrum框架中，工作在建议时间长度为一个月或者更短的迭代或循环中进行，这个迭代或者循环叫做冲刺。冲刺在一个时间盒（Time Box）内，也就是冲刺有固定的开始和结束时间。时间盒的优点具体内容如下：1） 时间盒是设定WIP数量限制的技术。WIP英文全称为work in process是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。2） 时间盒可以强制排列优先级。我们需要先执行高优先级的工作，时间盒可以强制我们按优先级排序执行小批量工作，这样我们的注意力可以更集中于快速完成高价值的工作。3） 时间盒可以展示进度。时间盒可以展示我们需要多少个时间盒才能完成大特性的进度，帮助准确知道为交付整个特性还需要做多少工作。4） 时间盒可以避免不必要的完美主义。有时候团队会花过多的时间把事情做得“完美”。每个冲刺中，时间盒限定了一个固定的结束日期，通过这种方式强制结束可能无休止的工作。5） 时间盒可以促进结束。冲刺有明确的最后期限，这个期限不允许修改，这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制，Scrum团队成员就不会有完成工作的紧迫感存在。6） 时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划，反馈快，错误有限，投入产出比（ROI）高，有助于保持较高的参与热情，检查点多。具体好处如下：1） 持续期短的冲刺更容易规划。为短时间的工作范围做规划所需要的工作量比给长时间的工作范围做规划的工作量要小得很多，结果更准确，可执行性更强。2） 持续期短的冲刺可以产生快速的反馈。快速反馈可以去掉不适宜的产品路径和开发方法，避免产生更多的差产品质量成本（COPQ,Cost of Poor Quality）。最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的商机。3） 持续期短的冲刺投入产出比（ROI）更高。持续期短可以更早、更频繁地交付，有更多的机会快速投入生产，产生收入。4） 持续期短的冲刺所犯的错误也是有限的。在短短1或2周的时间内，就算错了，全部搞砸了，也只是失去了短短的1或2周的时间，不会带来巨大的损失。坚持持续期短的冲刺能够进行频繁地试错，协调和反馈。5） 持续期短的冲刺有助于保持较高的参与热情。团队参与工作的热情，兴趣和兴奋程度会随着时间的拉长而越来越弱。如果一个项目时间过于长，人们看不到结果，那么显然人们会逐渐失去兴趣。持续期短的冲刺通过频繁快速的交付可用的工作产品，让参与者有满足感，操持较高的参与热情，便团队成员恢复兴趣并渴望继续完成冲刺的目标。6） 持续期短的冲刺能提供多个有意义的检查点。传统瀑布式开发有里程碑，例如分析、设计、编码、测试和运行。这些里程碑其实是一些不太靠谱的指标。Scrum在每个冲刺结束时会有一个有意义的检查点（冲刺评审会议），团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正，我们就能更好地应对复杂的项目。参考文献1.    Scrum指南（2017-Scrum-Guide-Chinese-Simplified），2017年11月版。

江湖茶馆是敏捷江湖桃花岛中一项话题讨论活动，通过华山论剑层层闯关后的江湖高人，才可获得登岛机会，与敏捷大咖面对面交流互动。 本期主题：Scrum四大事件之一：每日站会本期主讲嘉宾：黄隽（敏捷江湖桃花岛——黄药师）话题概要：本期话题根据江湖人士关注点，共围绕六个问题开展话题讨论，分别是：问题一：站会时间长？问题二，PO是否必须参加站会，如果参加，该怎么参加？问题三：我们没有发言棒啊，主要就是天天都开……放下一切工作去开站会，隔一天一开不行么？问题四：站会用物理看板还是电子看板？问题五：站会需要维护team的burndown图吗？问题六：还有个更难解决的问题：会上每个人只关注自己task的状态，没人关心story这个整体，如果有业务等外来变化，影响现在的story，没人关心？以下内容为本期话题的精品沉淀： 问题一：站会时间长？ 会议上每个成员需要回答3个问题：1、昨天都完成了哪些工作？2、今天准备完成什么？3、工作中遇到了什么问题？回答的形式与目的不是向领导汇报工作，而是团队成员之间相互交流，以共同了解项目情况和共同解决问题。 会议主持人（比如Scrum Master、轮值者、教练、团队协调者）确保会议的举行，并控制会议时间，团队成员进行简短有效的汇报。 另外要注意时间盒，也叫timebox，是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久，对于5-9人的团队来讲15分钟的会议时间足够。 团队外成员也可以参与，但没有发言权。某位团队成员在发言期间，其他人员应认真倾听，如有疑问可简短确认，但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助，任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。并且在发言时可以利用道具，比如话筒，谁拿到话筒谁发言，限制频繁打扰发言人的情况。问题二，PO是否必须参加站会，如果参加，该怎么参加？Scrum Guide 中建议，站会由开发团队参与即可，如果其它人员参与，有听的权力，建议不要给干扰团队开会的权力。就是说禁言，以确保会议高效问题三：我们没有发言棒啊，主要就是天天都开……放下一切工作去开站会，隔一天一开不行么？没有什么不行，也没有绝对正确的。如果团队所有成员觉得站会隔日开，那么SM要判断一下。我一般的做法是，尊重团队成员想法，给团队试错的机会，如果发现问题，引导团队自行改善。当团队成员有了对比，开与不开，或者天天开，和隔日开是有感觉的，打在自己身上才有疼的感觉，不给团队尝试机会，我不建议。当然SM要及时引导，服务，和排除障碍。问题四：站会用物理看板还是电子看板？电子看板优势1) 历史数据积累方便可以很方便的对数据进行度量与分析。2) 异地协作可视化可以方便的实现异地团队工作内容的可视化。3) 管理人员方便查看电子看板不受地域的限制，管理人员随时可以查看项目进度。4) 信息记录完整可以在卡片中增加更多的重要信息，比如验收标准等。还可以关联更多的内容电子看板劣抛1) 更改慢这里指对电子看板功能的制定化需求，新增加功能性需求需要开发团队配合完成，不能在第一时间随时按团队的想法自行更改。也就是说，团队的流程规划受电子看板功能制约。2) 仪式感弱团队成员在同一地点还好，如果分布在不同地点（包括在同一个办公室不同座位的情况）仪式感会弱化。物理看板优势1) 成本低几乎不需要成本。办公室允许粘贴的玻璃墙、白墙或者白板均可。再准备点便签和笔。2) 入门快只要团队想好了怎么做，立刻可以做到工作的可视化，特别适合刚刚使用看板的入门级团队。3) 更改方便对于看板的规划，只要有新的想法就可以灵活的变动和快速的实现。比如，列的变化、泳道的变化。同样，特别适合刚刚使用看板的入门级团队。4) 仪式感强每日站会的仪式感很强，这个是电子看板无法取代的。物理看板劣势1) 数据无备份历史数据不能备积累，无法对历史数据度量与分析。2) 异地同步难如果团队成员分布在异地，信息的同步是很大的问题。3) 记录的信息量少受便签空间制约，书写的信息量有限，但是同时也约束了内容的简洁性。我的建议：敏捷流程有了认识，一些敏捷的习惯已经养成。要引导团队的改善活动，看板从开始到稳定要经历过几次进化，最后达到团队理想的流程管理和最佳的可视化状态。这个时候建议再引入电子看板，让敏捷习惯持续传承。如果团队成员分散到多个地域，毫无疑问电子看板是最适合的。有些团队会两种看板同时存在，这种情况多见于看板的管理规则不同（多数情况是更喜欢物理看板的仪式感及精简版的管理和内容），如果规则相同，建议用一种看板就好，否则两种看板之间的同步也是一种额外的工作量。问题五：站会需要维护team的burndown图吗？建议更新，而且认真做好团队中每个成员的每日燃尽和团队整体的每日燃尽。问题六：还有个更难解决的问题：会上每个人只关注自己task的状态，没人关心story这个整体，如果有业务等外来变化，影响现在的story，没人关心？我估计，你的团队人数比较多，Scrum中建议团队人数为5-9人。你的团队中的成员应该不是特性型团队Feature, Story, Task要区分好，团队是一个整体，要强调Sprint目标完成，团队才胜利，个人目标完成Sprint也是失败。另外，发言顺序团队经过几次站会，你会发现很巧妙，顺序好像自然固定了，建议业务耦合度高的放在一起发言。以上为本期江湖茶馆的全部精品内容，如果您也想加入敏捷江湖桃花岛与大咖切磋问道，可添加 桃花岛助手小昭微信：devcloud08，也可直接扫描下方二维码添加小昭。

7月10日晚，最新一期的江湖茶馆活动**了大名鼎鼎的无敌哥：王立杰，以《敏捷需求与焦糖布丁》为主题进行了一场生动有趣的交流活动，下面我们一起来回顾一下吧!本期嘉宾：王立杰本期主题：敏捷需求与焦糖布丁问题一：你经历的项目中出现了什么问题？根据调查显示Top3 问题有： 1.时间太紧  2. 后期需求变更 3. 干系人沟通问题。这里奇怪的是，大家居然认为需求理解都很正确。然而，另外一个流传很久的漫画却有不同的含义。再分享另外一个官方机构曾做过的一个调查，应该也有很大的启示意义。 直觉来讲，包括我个人的实践来看，很多时候我们对用户的原始真实需求理解是有问题的，而且这个问题比例非常大。问题二：为什么会出现需求理解偏差的问题呢？很多时候，可能是因为我们只是关注于把东西做出来，而没有去考虑做出来的东西真正价值，帮客户真正解决了哪些问题。这也就是 output 是我们的关注点，而没有去做outcome的度量。就是大家可能并没有觉得我们原始的需求理解有问题。大家一直在讲价值，但是却没有去度量价值，没有去跟踪价值，没有去看价值是不是实现了？所以大家在最开始选择的时间紧，更多情况可能是时间紧交付压力下，无暇顾及价值，先交付了再说，抱有不行再改的心态。 用户故事在说三个关键要素，但是我们是不是真的把第三个要素挖掘出来了？不一定！问题三：你为什么想吃焦糖布丁？有人因为好吃，有人因为没吃过好奇，有人因为直播挣钱……这么多的答案说明了什么呢？也就是说，每个人做这件事情的诉求是完全不一样的，达成这个诉求是不是只有这种手段？当然不一定！这就是为什么叫焦糖布丁呢？我要拿焦糖布丁来举例子，就是让大家容易记住。焦糖布丁的拼音=JTBD= JOB TO BE DONE用户需求的背后，也就是用户真实的意图，这里边有很多很多不同的焦糖布丁。这里边有三类，刚刚大家讨论的那些理由都可以，分别归类到哪一类呢？有些是非常直接的，譬如功能性的，例如，饿了；有些是情感类的，例如，分享，信任；不属于这两类的，就是其他的。这里给大家分享这么一个原则，这里意味着什么？当消费者用了某个焦糖布丁(JTBD) 解决方案，便会停止使用其他方案 。对于一项焦糖布丁，一名消费者一次只喜爱一种解决方案。背后其实就是挖掘真实的需求，如果挖掘错了，用户就跑了，因为对用户没有价值，没有价值的东西做了再多也没有用，所以我才强调一定要关注结果，而不是产出OUTPUT。挖掘错了需求，也就是没搞对焦糖布丁； 这就是为什么我们会做好多没有用的功能，我称之为镀金功能。所以很多团队会用用户故事地图的形式来梳理需求，这个是非常好的一个实践，也很有效，容易促进沟通，让大家对需求的实现达成一致，但是，却没有深究用户的焦糖布丁。以上为本期江湖茶馆精华内容摘录，更多精彩问答请关注敏捷江湖桃花岛社群！下期见！ 拓展阅读：王立杰知识星球：敏捷创新@无敌学院https://wx.zsxq.com/mweb/views/joingroup/join_group.html?group_id=142424154852&secret=0p0qnudnnmcqpkwwut7k2wcc7nxmpapz&user_id=15281112825452&share_from=ShareToWechat 江湖茶馆第一期：江湖茶馆——Scrum四大事件之一 “每日站会”https://bbs.huaweicloud.com/blogs/1cb2b5f293f511e9b759fa163e330718加入敏捷江湖桃花岛方式：添加华为云助手：小昭二维码，通过测试即可入群

微话题 “敏捷的本质到底是什么？”希望大家能够畅所欲言。如果大家有其他任何与敏捷相关的问题，也可以在本帖回复直接咨询MVP王立杰。=======【华为云·微话题】敏捷的本质到底是什么？ =======成功产品的特性就是要以用户为中心，快速响应市场变化。在进入移动互联网时代后，这种特性表现的更加突出；对应的项目管理必须能够适应这种变化，如果沿用传统的项目思路来管理，过分强调需求的完备化、WBS分解、甘特图、关键链、大而全的项目计划、按部就班的进度追踪，肯定适应不了当前变化多而快的市场环境。 敏捷项目管理，作为最近几年的热点话题之一，已经逐渐成为国内外各大互联网公司的标配，根据最新Version One公司做出的统计，90%的实施敏捷转型的公司，在采用敏捷项目管理方式后取得了非常好的改进效果，缩短了产品交付周期，提高了产品质量，提高了客户满意度，同时提高了研发效率及员工满意度。 那么，相对于传统项目管理模式，敏捷的本质到底是什么呢？期望看到大家精彩的评论：1. 敏捷强调快速响应变化，是不是根本不需要做计划？2. 唯一不变的就是变化，在敏捷模式，该如何掌控需求变化？3. 敏捷中，该如何写文档？PRD还有需要吗？4. 敏捷强调团队的自管理、自组织，对成员的能力要求到底是什么样的？如何促进团队成长？5. 如果用一句话或几个关键词来描述敏捷，你会怎么定义？微话题活动：参与本次微话题讨论，有机会获得优质评论奖，赢取书籍。活动时间：2019年7月8日-7月22日参与方式：直接在本帖回复关于以上5个问题中的任意1个或多个问题的理解或评论获奖方式：活动结束后，将由MVP 王立杰  选取出2名优质评论奖，各送出《敏捷无敌》书籍1本。评奖标准：回复话题数量和内容质量。