需求优先级管理四步走需求优先级的管理，其实是为了帮助我们确定先做哪个需求后做哪个需求，从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理，或者更直接来说是优先级顺序管理，我们需要做到如下几件事情：确定优先级模型：优先级看起来像是一个简单直接的值，但实际上它是一个基于多种因素进行综合判断之后得出的一个值，这些因素和判断原则，就是我们所说的优先级模型；排定需求优先级顺序：将需求代入优先级模型进行计算，得出每个需求的优先级顺序；调整需求优先级顺序；改进优先级模型：如果经常发生需要调整需求优先级顺序的情况，那么最好是对这些情况进行一定的复盘分析，如有必要，修正或改进当前的优先级模型，让它可以适应实际情况，以避免调整优先级顺序的情况反复发生；另外就是需求可能已经交付或发布上线，但是该功能的实际用量或价值不吻合预期，则需要反思我们对这些需求的分析和判断，究竟是分析判断有误还是优先级模型有误，并进行相应的调整；一，确定优先级模型成本收益分析就是最简单的一种优先级模型，重要/紧急的四象限也是一种优先级模型，Kano模型也是一种优先级模型，它们都可以帮助我们去确定需求的优先级顺序。模型可以简单也可以复杂，根据企业实际需要来确定即可。务必切记优先级模型不应追求完美，以避免模型过于复杂，导致优先级管理的管理开销过高，喧宾夺主，反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要，就应该首选使用较简单的模型。企业可以从简单开始，逐渐完善，不需要也不应该在一开始就追求过于复杂的模型。简单可以体现在考虑的要素更少，比如成本收益分析只考虑两个要素，就比考虑更多要素的模型简单；简单还可以体现在要素的取值范围更窄或精度要求更低，比如预计利润只要求评估高/中/低，就比要求以万元为单位评估预计利润更简单；优先级模型确定后，可以进行存档管理，注意该模型宜供所有人或相关人员查阅学习，比如录入到DevCloud的Wiki知识管理系统就是一个很好的做法，如下图：二，排定需求优先级顺序比如成本收益分析，可以是把预期市场收入作为收益值，把预期研发投入作为成本值，计算差值，或计算ROI均可。假设需求A预计收益为10万元，研发投入按人天折算预计3万元，那么预计利润就是7万元，预计ROI是 233%；需求B预计收益为5万元，研发投入折算预计4万元，那么预计利润1万元，预计ROI为 25%。那么需求A的优先级顺序就要比需求B更靠前。这种相差悬殊的情况往往不难判断，我们假设还有需求C预计利润也是7万元、预计ROI是50%，以及需求D是预计利润1万元、预计ROI是500%。那么A、B、C、D这四个需求的具体顺序怎么排定呢？如果真的出现这种情况，那就更复杂一些了，需要考虑引入权重，然后计算出一个综合值，这个值按照某种规则（例如从大到小）排列出来就是最终的优先级顺序，比如：预计收入（万元）预计成本（万元）预计利润（万元）利润权重利润加权值ROI（%）ROI权重ROI加权值综合值优先级顺序需求A10370.10.7233%12.333.032需求B5410.10.125%10.250.354需求C211470.10.750%10.51.23需求D2110.10.1500%15.05.11 根据上述表格中所得出的结果，我们就应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序，在DevCloud中，可以使用工作项的“优先级顺序”字段来实现，该字段取值范围1-100，如下图所示。三，调整需求优先级顺序调整顺序本身非常简单，只要在DevCloud中重新设定该需求的“优先级顺序”字段的值就可以。但重要的是，需要将优先级顺序调整这件事情记录下来，包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来，同样，建议记录在Wiki知识管理系统中。用于后续的复盘回顾中作为参考信息，比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。四，改进优先级模型市场在变化，用户在变化，产品在变化，优先级模型自然也必须跟随着发生变化。我们可以定期或不定期的安排对需求优先级模型进行复盘分析，找出可以改进或优化的点，并跟进落实。可以是定期开展，例如每个月进行一次复盘，把这个月所涉及的需求都拿出来审视，或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可；也可以是不定期，以问题驱动的方式，比如某天进行了大量需求优先级的调整，那么当天或第二天就可以临时召集一次复盘会议，分析为什么会发生这种情况。复盘要有好的效果，就必须尽可能的复原问题发生当时的情况，所以前面提到的Wiki记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况，充分探讨。复盘过程中，我们要定位出正确的根因，是模型本身设计有问题（例如要素和尺度），还是取值、加权有问题（比如某类需求的预计收入就是非常难估算），还是过程管理的问题（比如过早进行估算，因为缺乏必要信息，导致估算得出的优先级顺序不准确），并进行针对性地改进。参考附录相关文章维基百科上的Kano模型词条：https://en.wikipedia.org/wiki/Kano_model相关书籍杰拉尔德·温伯格：《成为技术领导者》邱昭良：《复盘+：把经验转化为能力》

黄隽 Charlie序  言随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱、文献，活跃于敏捷大咖们的议题讨论，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容分享给那些已经或者正准备踏上敏捷之路的朋友们，用于个人学习、研究和讨论，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。正常情况下的移动使用看板主要意图之一是控制在制品数量（WIP, work in process）,需要拉动式的移动，这样可以有效控制在制品数量，防止工作项过多积压。另外需要提示一点，在整个移动过程的前提是需要制定一套移动规则，具体什么样的规则这里不做过多的描述，根据团队自身情况定义就好，规则根据团队意见可以调整几次，最后团队满意就是合适的。需求变更情况下的移动不接受变更当一个Sprint的Sprint Backlog和Sprint 目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。 拥抱变更完成拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本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布置看板中的卡片就好。

为什么要进行需求结构化管理？首先，并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。以什么为依据进行需求结构化管理？需求结构化管理，应该以什么为脉络来建立这个结构呢？软件研发无非是分为项目型软件研发和产品型软件研发两种，项目通常来讲都是临时性的，或者说短期性的，而产品或者软件系统是长期性的，或者说我们会持续维护、更新其功能特性的。项目复项目，我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标，交付软件项目所要求的功能特性的。这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。使用DevCloud进行需求结构化管理的一种方式接下来，我们介绍推荐的一种方式。一、针对产品或系统建立DevCloud项目也即一个产品或系统，建立一个DevCloud项目，该产品或系统的所有需求，都在此DevCloud项目里面进行管理。二、确立Epic-Feature-Story的需求结构这个产品或系统的业务模块作为Epic，比如用户中心、购物车、配送管理等，比如一家货运云商，他们的油卡业务，就适合作为一个Epic，针对油卡的各种功能，就可以作为Feature展开；Epic要承载业务价值，也即Epic需要是对企业本身是有意义的；针对前面业务模块的具体展开、拆开，就可以作为Feature，也可以简单理解为一个业务流程、用户流程；以前面用户中心为例，用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature；或者以油卡为例，购买油卡、我的油卡等就可以作为不同的Feature；Feature要承载用户价值，也即对于用户来说，是可以理解这个Feature，且认可其价值的，通常Feature也是用户可以直接感知、可以操作的；Feature往往还是有些大有些复杂，那就需要拆成颗粒度更小的Story，用来承载一个具体的用户操作，例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能；再往下一级的Task，就主要是为了分工协作，也即是说，如果Story可以包干到人，那么不再拆分Task也是可以的；Task往往是关于工程师需要具体做的工作，也就跟业务价值、用户价值、用户单步操作都没有了什么关系，通常都是把Story按照具体的组件、模块进行拆分，例如前端、后台、数据库之类的，或者是按照工作流程分工来拆分，例如UCD、开发、测试、部署等；如下图所示，各层级为：Epic：用户中心Feature：地址管理Story：用户可以新建地址Task：【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现三、不同模块以及版本的管理可以通过工作项的属性来进行管理，如下图：模块：Web端发布版本号：1.0.1.2至于模块清单的维护，可以在工作项编辑状态，点击“模块”字段右侧的小齿轮图标，即可在弹出窗口进行操作，可以添加、修改、删除模块：在工作项管理的Backlog视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，当然也可以进行过滤：参考附录相关文章敏捷联盟网站上的Epic术语解释：https://www.agilealliance.org/glossary/epic相关书籍Mike Cohn：《用户故事实战》

作者：黄隽（Charlie）八月的最后一天中国DevOps社区在大连举办了第二届Meetup。关于本次Meetup将从社区活动介绍、活动内容和流程、分享的主题、心得等几个方面来小结一下。先分享活动后对专业人士的采访吧…社区活动简介中国DevOps社区大连Meetup是一年一度的大连本地DevOps社区聚会，旨在传播DevOps文化，落地DevOps实践，帮助大连本地的IT从业人员共同学习和进步，也是帮助有需求的企业培养更多的DevOps人才。到今年已经举办了两届，这次由DevOps社区主办，敏捷江湖桃花岛社区协办，邀请了大连本地著名公司的DevOps和敏捷专家为大家分享和现场答疑。中国DevOps社区中国DevOps社区由一群拥有相同价值观和理念的志愿者们共同发起，并于2018年7月正式成立。社区的目标是推动DevOps在中国的蓬勃发展。社区设有理事会和专职运营人员。社区使命：传播DevOps文化，落地DevOps实践社区愿景：成为中国DevOps运动的领航人与催化者社区核心价值观：开放、专业、使命感 敏捷江湖桃花岛社区敏捷江湖桃花岛社区是19年1月成立于美丽的浪漫之都大连。由最初单纯的敏捷分享交流演变而来，《华山论剑》是社区的金牌活动。由开始的华为云DevCloud敏捷专家组和运营组以及邀请的圈内几个好朋友一共十几个人组成，现在已经发展到二百多人。主要成员为敏捷教练、DevOps工程师、企业家、高级项目管理人员、出版社的朋友们。社区努力打造高价值的技术和人脉分享平台，共建敏捷生态圈。 内容和流程本次活动上、下午共计一百人左右，从上午10：00持续到下午6：20。主要进行了DevOps和敏捷相关实践、主题分享。上午DevOps动手操作，下午DevOps和敏捷主题分享和最后的Open Space互动。第一部分：上午进行了DevOps实战工作坊。来自IBM的明星DevOps团队，为大家带来为期2小时的DevOps实战工作坊！你有机会在专家的指导下，模拟项目实景，亲自上手体验DevOps的工具链操作，用最短的时间，最快的路径，获取DevOps的知识和实操经验！ 该工作坊是国内首次由经验丰富的一线DevOps专家设计的，基于项目实景环境，帮助参与者直接获取实操经验的工作坊，机会难得。第二部分，下午上半场进行了DevOps&敏捷大咖心法分享。本次Meetup活动汇集了来自IBM,、埃森哲、东软、华为云DevCloud的资深实践专家，为大家分享DevOps&敏捷在实施过程中的宝贵经历。参与者可以获取一手经验，了解到DevOps&敏捷在团队层面的操作，以及在部门和公司等更高层级上的应用和影响。同时一窥大连本地的各主流公司对DevOps的应用情况，及各公司内部的DevOps生态环境。 第三部分，下午下半场进行了“开放空间”活动。由各位主讲嘉宾带队，每位参与者都有机会提出或选取自己最感兴趣的关于DevOps&敏捷的问题，获得大咖的深度解答，同时可以和参会的其他同行进行深入讨论，互相学习。主题分别为：如何进行CI\CD？---埃森哲架构师 刘玉森如何保证DevOps的安全性？---IBM DevOps应用安全架构师 于湍(Nick)敏捷团队如何做绩效管理？---IBM 敏捷教练管 婷婷(Lisa)如何快速落地敏捷？---东软敏捷教练 巩敏杰敏捷站会你开对了吗？---华为云 DevCloud敏捷专家 黄隽(Charlie)分享的主题在最后2个小时左右的Open Space环节，对大家感兴趣的几个话题中选出了“如何正确开站立会议”进行了引导、分享，同时介绍了我们DevCloud敏捷专家组日常站会。 会上大家关于站会的问题集中在：    总结的18Key如下，得到了很好的验证，具体关于18Key内容可以参考【DevCloud专家智库】中的“何如玩转每日站会”： Key 1: 主持人会议主持人（比如Scrum Master，也可以团队成员轮班，轮流感受下站会的节奏）确保会议的举行，并控制会议时间，团队成员进行简短有效的沟通。Key 2: 两个比萨大小的团队在《Scrum敏捷软件开发》一书中，作者麦克.科思提出了一个简单的方法用来辨别什么是合适的团队规模，那就是，如果两个比萨够整个团队成员吃的话，那么这个团队的规模比较适合。因为两个比萨大小的团队跟家庭的规模相似，站立会的目标可以轻松达成。当团队是家庭规模大小时，人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺，以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大，一般为7-9人左右。最后再强调一点，并不是要求团队一定要按以上15key进行开站会，15key只是在很多实践中总结出来的一些经验，曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用15key,没有绝对的对与错，只有适合和不适合。Key 3: 限制发言团队外成员也可以参与，但没有发言权。Scrum中曾经使用过术语“猪”和“鸡”来区别在每日站会中哪些人应该参与发言，哪些人就站在旁边看就行了，不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话：“在早餐吃的火腿鸡蛋中，鸡是参与者，猪是全部投入了。”显然，Scrum使用这些术语是为了区分参与者（鸡）和为了实现冲刺目标面全力投入的人（猪）。在每日站会中，只有猪应该发言，如果有鸡参加例会的话，应该作为旁观者。Key 4: 预留缓冲时间建议开发团队在上班时间后的半小时或者1小时后开每日站会。这样可以给堵车、喝咖啡、查看邮件、去卫生间或其他每天上班后的例行工作提供一些缓冲时间。晚点开会还可以给开发团队一点时间来检查前一天的工作（比如，前一天晚上开始运行的自动化测试工具所生成的缺陷报告）。Key 5: 同时同地每日站立会议应尽可能在同一时间、同一地点召开，最好的方式是在团队的可视化的任务板前面召开。同一时间和地点也可以有效帮助团队成员形成固有的节奏，不用在找地点和确认当天的开会时间浪费时间。Key 6: 准时开始所有的团队成员需自觉按时到场，会议主持人要按照预定的时间按时开始会议，而不管是否有人还没到。对于迟到的人员要有一些惩罚措施，比如缴纳罚金或做俯卧撑等。惩罚措施和数量由团队成员事先共同商定，如果是罚金，如何支配也由团队共同决定。如果团队成员就是不自觉按时到场怎么办？关于更多这方面的解决方案请参见下面的了解更多中的“成员迟到的解决方案”。Key 7: 站立开会团队成员一定要站着开会，这也是会议的名字叫站立会议的原因。站着开会确实比坐着开会简明扼要，让人更想快一点结束会议，开始一天的工作。坐下容易使人放松，精神不集中，不易控制时间（相信很多人有体会）。Key 8: 强调站会目的经常强调站会目的，特别适合刚刚启用站会的团队。可以由Scrum Master来强调，如果没有Scrum Master也可以由其它Leader（轮职的主持人也可以）来强调。然后询问团队成员“站会对你们来说怎么样？你们得到了什么成果？”几次以后，团队成员可能选择目标声明作为每天的度量，在每次站会之后，团队成员对自己的表现做出相应的评价，是一种强有力的自我管理工具。Key 9: 聚焦三个问题站会期间，团队成员就说那典型的三个问题（昨天…今天…障碍是…），其它事情不说。只讨论已完工和即将开始的工作，或者在这些工作中碰到的问题和障碍。目的不是向领导汇报工作，而是团队成员之间相互交流，以共同了解项目情况和共同解决问题。Key 10: 眼神支持这是一个好玩的游戏：当一个人站在前面发言时，要求其他团队成员都直视发言人，并进行眼神交流。别让发言人抓到你在看别处。这个游戏帮助发言人的发言简洁，同时可以加强成员对发言人所讲内容的理解。这样可以帮助团队加速完善每日计划。Key 11：严格时间盒站会是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久，对于5-9人的团队来讲15分钟的会议时间足够。Key 12: 会后讨论某位团队成员在发言期间，其他人员应认真倾听，如有疑问可简短确认，但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助，任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。Key 13: 问题风险跟踪将站会成员遇到的问题和风险做概要的记录（不必详细，只要说明重点即可，不需要在记录上花费更多的时间），然后保留到wiki，或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环（例如，问题和风险可以会后按排专题讨论、跟踪，直到关闭）。Key 14: 回顾改善本身每日站会就是最小化的戴明环（PDCA），另外团队在回顾会议上时也可以对站会开的效果进行回顾，哪些地方做得好，哪些地方做得不好，有哪些改善点可以在下一轮迭代中改善等。（站会只是回顾会议中一个回顾点，如果没有问题不用做专题回顾）Key 15: 发言棒站会时可以利用一些小道具来保证会议不会超时。团队可以找一只笔或者一个娃娃（女生多的团队）作为发言棒仍给一位成员，让他拿着发言棒陈述完“三个问题”，然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长，建议把发言棒换成一个水桶（当然是盛满水的）让他托起，直到托不动为止。如果他想说就让他说，要么会议很快结束，要么我们的开发人员练成强大的臂力，按经验，一般都会挑重点说，会议按时结束。Key 16: 冲刺待办列表站会中，成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展，需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时，同步可以展示冲刺待办列表给团队。Key17: 任务看板在站会期间，通过任务板，团队中每一个人都可以知道哪些工作正在进行，哪些工作已经完成。团队关注事情的完成，一直处于进行中的任务为被发现，成为当前的焦点，这样团队就可以尽快把这些焦点问题解决掉。Key 18: 燃尽图燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量（小时、故事点或工作项个数），横轴表示冲刺时间（一般单位为天）。  开站会时，发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态，进展情况非常清楚，看出工作是否在按计划进行，状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项，并在冲刺早期做出明知的决定。使用燃图易达成如下效果：高可视性，直观展示进度情况和剩余工作；快速识别风险；帮助团队建立信心，了解自己的能力；了解团队成员工作步调；了解团队冲刺计划；和任务墙能非常高效地匹配使用。关于18key，这里想强调一下，并不是站立会议时要把所有18key都要执行一遍，这里的18key只是提供了一些参考实践和关键点，18key来源于大量的实践，也解决过团队站会的问题，所以大家在站会遇到了问题时，可以先想到这个18key，然后选择适合自己团队的key。没有绝对的对与错，只有适合和不适合。举一个例子，这里有四个key是关于工具的，这些工具我们都要使用吗？当然不一定。敏捷宣言里提到“个体和互动高于流程和工具”，工具是为团队服务的，不是团队的负担，更不能被工具所绑架。所以团队一起选择适合的，才是正确的做法。心得1.促进人才交流，更多的小伙伴们有着共同的爱好走到了一起。助力DevOps和敏捷人才的培养，更多的人才加入到DevOps和敏捷的队伍中，为需要的企业做人才储备。2.了解最新行业动态，一窥大连本地的各主流公司对DevOps的应用情况，及各公司内部的DevOps生态环境，良性促进行业发展。3.高校志愿者学生提前感受IT前沿管理和技术内容，明确日后学习和发展方向。

黄隽 Charlie江湖茶馆是敏捷江湖桃花岛中一项话题讨论活动，通过华山论剑层层闯关后的江湖高人，才可获得登岛机会，与敏捷大咖面对面交流互动。 本期主题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.黄药师微信：65983808。

黄隽 Charlie背景一个人数为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在每个冲刺结束时会有一个有意义的检查点（冲刺评审会议），团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正，我们就能更好地应对复杂的项目。 参考文献    Scrum指南（2017-Scrum-Guide-Chinese-Simplified），2017年11月版。

   KANBAN被人擦掉了怎么办，Scrum之前几个版本的迭代丢失了怎么办，XP把人培养出来人跳槽了怎么办，针对这些问题看敏捷开发汪珺老师是如何去解决的？                    全部

敏捷领域KANBAN方法如果具体去操作，在敏捷领域做计划也是一种浪费，应该不拘泥形式与流程，具体如何去看待KANBAN在敏捷领域的优势，请看王立杰老师如何回答？                    全部

MVP敏捷开发许舟平代表Scrum流进行“反击”，Scrum跟极限编程不一样，更关注的是如何利用好节奏去做编程，即制定周期性的迭代冲刺计划具体就让我们来看看许舟平老师是如何进行答复的吧

长久以来，敏捷开发领域有多种不同的流派并存，华为云MVP徐磊走的就是XP流，他指出XP是敏捷的前身，创造了很多提高开发效率的实践想了解更多吗？

DevOps VS 敏捷     当我们面对敏捷和DevOps的时候，总会不可避免的思考下面这些问题：  敏捷是什么？DevOps是什么？两者有什么区别？持续集成不是XP里面的么，怎么DevOps也有持续集成？我们团队之前在做敏捷转型，现在又开始DevOps转型，这两者有什么区别？            其实这些问题并没必要太过纠结，因为敏捷和DevOps两者都在不断演进，两者也的确越来越像。      这个话题注定讨论不清，也注定会有不同的意见。本文也仅从方法论和实践的角度，为开发者简单论述敏捷与DevOps。希望每位读者都会从本文中得到自己的理解与启发 ，帮助大家在敏捷与DevOps这两条路上走的更远。先说说本文的观点：▪ 敏捷与DevOps初衷、目的是为了解决问题，而不是为了树碑立牌，更不是为了占领地盘。▪ 两者并非泾渭分明，也没有一条线能够划出来，说哪边是敏捷，哪边是DevOps。▪ 讨论敏捷与DevOps，目的是为了了解两者之间的内在联系，而不是为了划清界限。▪ 常常在讨论的，是狭义的敏捷与DevOps概念，而广义的敏捷与DevOps，已经趋同。▪ 两者都是试图去解决相同，或相近的问题，只是还没有能一招解决所有问题的办法出现。       接下来， 让我们从狭义的角度，看看二者的区别。       传统的敏捷是为了解决第一个鸿沟，即业务与开发之间的鸿沟。通过敏捷宣言中强调的个体和互动、可工作的软件、客户合作、响应变化，以及12条原则中的尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等，以及包括Scrum、Kanban、XP在内的众多管理和工程实践，来实现开发与业务之间的频繁沟通，快速响应变化。       而DevOps的出现，是为了解决图中的第二个鸿沟，即开发与运维之间的鸿沟。前端的敏捷的确是快了，却发现因为Dev与Ops之间的隔阂，无法真正的将价值持续的交付给客户。       开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定、安全和可靠的服务。更重要的，两者的KPI度量指标，绩效考核激励机制不同，决定了如果为达成各自的局部目标，势必存在无法调和的根因冲突。      DevOps的出现，就是为了打破开发与运维之间的部门墙，从这点上来说，“DevOps是敏捷在运维侧的延伸”这一说法也不无道理。只是，敏捷与DevOps，都已经不再是原来的那个敏捷和DevOps了；世界变化太快，问题域发生了变化，解决方案域自然也要随之变化。        敏捷的好处是，有一个敏捷宣言，宣告其诞生。敏捷的缺点，也许也是因为有敏捷宣言。敏捷宣言并不应该被拿来约束和限制敏捷的范围，敏捷宣言也说拥抱变化，宣言诞生于2001年，时至今日，应该也当然会与时俱进，只是后来再没有这样的一个标志性的事件来做声明。        DevOps的不好之处，是没有一个明确的定义。DevOps的好处，却也正是因为没有一个明确的定义做限制，所以拿来主义，一切好的东西，都可以为我所用。         DevOps是个筐，什么都可以往里装，敏捷又何尝不是呢？        通常人们对DevOps的理解有两方面，即D2O和E2E。D2O，Dev to Ops，即经典、狭义的DevOps概念，解决的是Dev到Ops的鸿沟。E2E，End to End，即端到端、广义的DevOps，是以精益和敏捷为核心的，解决从业务到开发到运维，进而到客户的完整闭环。DevOps的6C概念，即Continuous Planning、Continuous Integration、Continuous Testing、Continuous Deploy、Continuous Release、Continuous Feedback，也是端到端广义的DevOps。       维基百科中总结到，DevOps的出现，有四个关键驱动力：互联网冲击要求业务的敏捷虚拟化和云计算基础设施日益普遍数据中心自动化技术敏捷开发的普及        从种种概念可以看出，业务敏捷、开发敏捷、运维侧自动化、以及云计算等技术的普及，几乎打穿了从业务到开发到运维（当然里面还有测试），所以虽然字面上是Dev到Ops，事实上，开玩笑的说，已经是BizDevTestOpsSec了，即从狭义的D2O，前后延伸到E2E，端到端广义的DevOps了。       下图是DevOps能力成长模型，是多位DevOps大师，基于多年DevOps现状报告的基础上，汇聚出来的能力模型。       从能力模型上来看，所有的连线汇聚点，也就是最终的目的，是组织效能。软件交付和运维效能，是敏捷与DevOps共同的目标。        其中持续交付是狭义DevOps的核心理念，横跨了架构、开发、测试、运维等角色。持续交付的核心开发实践，也涵盖了架构管理、版本管理、分支策略、测试自动化、部署发布、运维监控、信息安全、团队授权、数据库管理等多个维度，其中不乏我们常说的传统的敏捷相关实践，尤其是下图中XP极限编程的很多实践，半数以上在DevOps里都能找到。        能力成长模型，除了持续交付，还包括精益领导力、精益产品开发、精益管理、组织文化与学习氛围。DevOps已远远不是CI/CD那么简单，CALMS原则也横跨了文化、管理、精益与技术。        敏捷宣言的十二条原则、SAFe的九大原则、以及DevOps的CALMS原则，也是彼此相互融合。SAFe有借鉴DevOps的理念和方法，DevOps又采纳敏捷的思想和实践，大家又都以精益为思想核心。到底谁包含谁，谁比谁大，彼此的界限在哪里呢？       由此可见，方法也好，实践也好，其价值应该由客户价值来体现。对客户而言，需要解决的问题，是端到端的，是全局而不是局部优化。       所以，是什么，不重要。能解决什么，要解决什么问题，很重要。              DevOps是集大成者，是各种好的原则和实践的融合，敏捷又何尝不是如此。2001年的17位雪鸟大师，各自在践行着不同的敏捷框架和实践。敏捷宣言和原则，原本就是一次融合。2003年Mary Poppendieck和Tom Poppendieck的精益软件开发方法，即便是已经有敏捷宣言的前提下，也一样纳入敏捷开发的范畴。敏捷也是在不断前行，DevOps与敏捷殊途同归，是同一问题的不同分支，最终汇集到同一个目标。       一个好的方法论，应该是与时俱进，兼容并蓄的；应该是开放的，演进的而不是固化的。      方法论如此，学习和实践方法论的人，更应该如此，以一颗开放的心态，接纳一切合理的存在。              最后，让我们来看看DevOps在工具链上的要求。DevOps要实现：自动化、标准化、配置化，就意味着一定要有能够实现端到端打通的自动化研发工具链。理论为我们指明实践的方向，而工具则是我们落地实践的基础。       华为云DevCloud提供软件开发全生命周期的云端DevOps工具链，帮助团队真正实现自动化、标准化、配置化。       DevCloud提供基于Git的版本控制系统，不只将代码版本化，而是版本化管理一切与环境有关的配置。       可自定义的自动化部署流水线，提交代码自动触发，帮助团队实现持续交付，为团队带来自动化、标准化。本文参考资料：https://www.linkedin.com/pulse/devops-explained-j%C3%A9r%C3%B4me-kehrli/《Accelerate》维基百科

朴素的DevOps价值观：原则、方法与实践最后让我们来看看原则（Principle）、方法（Method）和实践（Practice）这个维度：Principle matters...Method doesn't.       敏捷的方法有很多，讲了很多年也还任重道远。       丰田TPS被各大车企学习了30年，没有哪家能学到真经的。有人说，丰田生产模式，最重要的是背后的KATA，即丰田套路，如何使得改善和提高适应性成为组织日常工作的一部分，而KATA的书出版到现在也快10年了，好像依然没有多大改观。       敏捷的方法有很多，SCRUM、精益看板等，SAFe是大规模的敏捷，DevOps也有很多种模型。比模型更重要的是背后的原则，虽然这些模型从表象上相差甚远，但其背后的原则却十分相似，比如敏捷宣言的十二条原则、SAFe的九大原则、以及DevOps的CALMS原则。       方法论的表现形式有很多，具体落地执行又根据不同企业千变万化，但不变的、相通的，是背后的原则。好比张三丰教张无忌自己新创的太极剑，张三丰教的快，每次的招式还都不同，张无忌学的快，忘的更快，“不坏，不坏！忘的真快”，武功招式始终是下乘的，心法精髓才是上乘，守住了心法，招式就可以随时创新，不必拘泥。Method matters...Practice doesn't.      《雷神3》里的桥段，奥丁的女儿海拉轻易的就捏爆了雷神之锤，索尔灵魂出窍，一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁：索尔，你是锤子之神吗？那锤子，是为了让你控制你的力量，让你更专注，它不是你的力量的来源，你才是。        DevOps原本就是偏实践层面的，有很多实践归纳，比如下图的Gartner的DevOps模式和实践图，还有DevOps地铁图。但这些实践都只见树木不见森林，缺少彼此之间的关联和依赖，需要方法将其串起来。这也是为什么一套辟邪剑法的剑招，缺了葵花宝典的心法，就稀疏平常沦为三流一样。     从Practice，到Method，到Principle；也就是是从Doing，到Thinking，到Being的过程。Being DevOps并非一蹴而就的事情，需要从实践做起，心里要有方法论，过程中始终严守原则。但又不能固守着那把实体的锤子，方法也好，实践也好，都只是达成目标的途径，而原则才是指南针。朴素的DevOps价值观最后，本文的DevOps朴素价值观殊途同归，不管是CALM/CALMS，还是SAFe的CALMR，或者是Nicole Forsgren/Jez Humble/Gene Kim的《Accelerate》中的能力成长模型，都只是对同样问题的不同解读。首先，业务、架构、技术，人、流程、工具，原则、方法、实践，这九大元素不能孤立的来看，原本就是相辅相成，密切相关的。Principle背后，其实是人的Mindset思维模式，而一堆人遵循同样的Principle，就演化成了文化Culture。方法Method也好，流程Process也好，最终都由实践Practice通过工具Tool落地。DevOps、微服务和容器的三剑客，也是方法、架构与技术与工具的极佳结合。其次，所有这些元素都重要，缺一不可；但不要舍本逐末，需要了解什么是根因，什么是手段。技术、工具、实践，都是服务于方法和流程的，需要遵循核心的原则，最终的目的是为了商业的诉求，为了快速的价值交付。方法、实践、工具，都是形；原则、Mindset、人，才是根。以上是本文对于DevOps思想的阐述；DevOps是什么，DevOps有很多面，每个人心中都有自己的DevOps，这里的所谓朴素的价值观，只是一种解读方式。只希望能为各位开发者，在读后带去更多的思考，找出更适合自己的道路。本文参考资料：许峰 “一文收录16张DevOps ”拍照神图”

影响地图影响地图是一个简单却极高效的协作性的策略规划方法。有的产品，它还活着，却已经死了；有的产品，还没发布，就已经死了。太多的产品失败的案例，源于方向性错误，基于错误的假设，功能与业务目标/价值之间缺乏必然的关联与一致性，在做的事与期望的目标南辕北辙。影响地图试图通过结构化、可视化、协作化的方式来从源头解决上述问题。影响地图是一门战略规划技术，通过清晰的沟通假设，帮助团队根据总体业务目标调整其活动，以及做出更好的里程碑决策。影响地图可以帮助组织避免在构建产品和交付项目的过程中迷失方向，确保所有参与交付的人对目标、期望影响和关键假设理解一致。同时，影响地图可以有效的评估交付，作为质量反馈的标准之一：如果一个需求没有有效的支持期望的行为影响，那么即使在技术上正确，功能交付给用户了，也仍然是失败的。影响地图试图去解决组织面临的范围蔓延、过度工程、缺乏整体视图、开发团队和业务目标不能保持一致等困扰。影响地图的结构简单的讲，影响地图是这样的一个思维逻辑和组织结构：为什么（*Why）-->谁（Who）-->怎样（How）-->什么（What*）也就是：我们的目标是什么（Why），为了达成目标需要哪些人（Who）去怎样（How）影响，为此我们需要做什么（What）。影响地图通过构建产品和交付项目来产生实质影响，从而达到业务目标。为什么（Why）？“我们为什么做这些？”也就是我们要试图达成的目标。找到正确的问题，要比找到好的回答困难得多。把原本描写在文档中，更多的是隐藏在高层利益干系人头脑中的业务目标，定性定量的引导出来。目标描述要遵循SMART原则，确保每个人知道做事的目的是什么，帮助团队协作，针对真正/合适的需求设计更好的方案。Specific 明确Measurable 可度量Action-Oriented 面向行动Realisitc现实的Timely有时限的。谁（Who）？“谁能产生需要的效果？谁会阻碍它？谁是产品的消费者或用户？谁会被它影响？”也就是那些会影响结果的角色。考虑涉及到的这些决策者、用户群和生态系统，注意角色同样有优先级，优先考虑最重要的角色。角色定义应该明确、避免泛化，可以参考用户画像Persona的方式进行定义。怎样（How）？“考虑角色行为如何帮助或妨碍我们达成目标？”也就是我们期望见到的影响。在这里我们只需列出对接近目标有帮助的影响，而不是试图列出所有角色想达成的事。影响是角色的活动，是业务活动而不是产品功能。理想情况下应展现角色行为的变化，而不仅仅是行为本身。不同的角色可能通过不同的方法，帮助或阻碍业务目标的实现，这些影响彼此之间可能是相互参考、相互补充、相互竞争，或者相互冲突的。既要考虑到正面的影响，也要考虑负面或阻碍的影响。注意：业务发起方应该针对角色Who以及影响How，而不是交付内容What进行优先级排序。什么（What）？“作为组织或交付团队，我们可以做什么来支持影响的实现？”包含：交付内容，软件功能以及组织的活动。理论上这里是最不重要的一个层次，我们不应该试图一开始就将它完整列数，而应该在迭代过程中逐步完善。同时注意，不是所有列出来的东西都是需要交付的，它们只是有优先级的交付选择。"永远不要试图实现整个地图，而是要在地图上找到到达目标的最短路径。"影响地图足够简单、操作性强、又有足够的收益：能够帮助创建更好的计划和里程碑规划，确保交付和业务目标一致，并更好的适应变化。影响地图的首要任务是展示相互的关联，次要任务是帮助发现替代线路。通过以上论述我们可以看出：影响地图符合软件产品管理和发布计划的发展趋势------包括面向目标的需求工程、频繁的迭代交付、敏捷和精益软件方法、精益创业产品开发循环，以及设计思维。如果你认同上述趋势，那么影响地图会是你的菜。影响地图的特点结构性：从业务目标到交付的结构化梳理和挖掘的方法，目标--角色--影响--交付物。整体性：连接目标和具体交付物之间的树状逻辑图谱。协作性：利益相关人一起沟通讨论协作，把隐藏在个人头脑中的默认的思维逻辑挖掘共享出来。动态性：动态调整、迭代演进、经验证的学习。可视化：统一共享的视图，结构清晰易读。影响地图将各个部门/角色不同的视角、不同的思维逻辑、不同的前提假设，通过可视化和协作的方式进行梳理、澄清和导出。通过连接交付内容、影响和目标，影响地图显示了之所以去做某个功能的因果链，同时也可视化了各利益相关人做出的假设。这些假设包括：业务交付的目标、涉及目标干系人、试图达到的影响。同时，影响地图沟通了两个层面的因果关系假设：交付会带来角色行为的变化，产生影响。一旦影响达成，相关的角色会对整体目标产生贡献。影响地图的分层是否可以将影响地图分层？ 答案当然是可以而且合理的。在《影响地图》这本书中也提到建议计划两次会议：第一次定义预期的业务目标和度量，第二次来制作一张地图。第一步是确定使命，而一个战略目标往往太大，无法快速见效，需要拆分成可短期达成的战术目标。根据优先级排序的战术目标，逐次进行影响地图分析，期间动态调整更新，定期决定是否需要继续。因此可以有两层的影响地图："一份针对整体产品愿景，一份针对中期交付。"同时，通过分层，也可以有效的控制参与两个会议的人员组成。高阶的领导者未必需要参加所有的影响地图活动，尤其是战术影响地图会议。参与人员决策者，技术人员，业务人员。注意一定要有决策者参与，包括：商业决策、技术决策、营销决策。如果发现一个问题讨论很久没有决定，也许是因为缺乏合适的参与人员，应该找更高阶的人员决策。参与人数：原书的建议是将第一次会议人数限制在不超过5-6人，确保关键的业务决策者和技术人员参与进来。随后的会议可以适当扩大规模分组讨论，随后汇总，但人数越多，会议的节奏和范围就越需要控制。

用户故事驱动的敏捷开发之四——如何使用DevCloud支撑用户故事驱动的敏捷开发DevCloud中提供对用户故事的分级管理，可在“工作 > 需求规划”中，将影响地图中根据划分好层级的用户故事输入到DevCloud中，与影响地图的层级进行对应。需求规划视图以树形结构列出了“Epic > Feature > Story > Task”的逐级关系DevCloud支持工作项模板，在“设置 > > 项目设置”中，可以看到如何将用户故事的三段式预置在Story的工作项模板中，也可以根据需要自行定义描述信息。在“工作 > Backlog”中，可以通过新建工作项，或进入已创建好的工作项，对需求的具体描述信息进行编辑。同时，DevCloud也遵循3C原则。卡片是用户故事的展现形式，用户可以切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。在进行需求讨论会后，会议纪要记录到wiki中，并可进行版本管理。同时，需求讨论会的交付物可上传至文档管理统一管理。以上是如何使用用户故事来驱动产品规划和设计的过程，以及如何通过DevCloud管理用户故事。希望本文中的内容，会对读者产生一定的启发，帮助大家在日常工作中更好的完成相应的工作。

用户故事驱动的敏捷开发之三——如何组织需求讨论会？讲故事的过程一般通过需求讨论会的形式来进行，确保以上应该参与的人员都到场。既然是个会议，我们就必须确保会议的高效，这里可以参考三星高效会议的8点原则：凡是会议，必有主题。凡是主题，必有议程。凡是议程，必有决议。凡是决议，必有跟踪。凡是追踪，必有结果。凡是结果，必有责任。凡是责任，必有奖罚。凡是奖罚，必须透明。针对需求讨论会，我们至少需要有以下安排：会议主题：XXX产品需求讨论会，目的是在4小时内对XXX产品的XXX内容进行讨论。会议议程：组织者：产品经理XXX或者项目经理XXX。参与者：业务方或最终用户、产品/项目经理、团队技术人员（架构、开发、测试等）。讨论内容：按照优先级排序的故事列表。会议分工：主持人：由产品经理和项目经理轮换组织。需求记录人：由技术团队内某人承担，负责在讨论过程中将用户故事和所产生的功能点进行详细记录，形成文档或者录入系统。问题记录人：由技术团队内某人承担，负责在讨论过程中将无法现场确认的问题进行记录，形成文档或者录入管理系统。会议交付物：针对议程中的每个用户故事所产生的文档或者管理系统记录。讨论过程中所记录的问题列表或者管理系统记录。针对用户故事文档的下一步操作，如：制定开发计划，预算等等。针对问题的跟踪方式，如：问题列表的状态由谁负责维护，每个问题由谁负责解决跟进，每个问题预计解决的时间。需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程，我们可以按照以下流程进行：讨论会前期准备可以在进行正式的需求讨论会前先进行一次头脑风暴，邀请用户和技术一同参与，在这个过程中大家可以自由讨论，目的是让大家现对产品的大致情况有所了解。讨论会过程首先由主持人（产品经理PO/项目经理Scrum Master）向团队列出会议所要讨论的故事列表，这个过程不用讨论细节，目的是让大家知道会议的内容和目标，便于控制进度。根据所列出的故事列表优先级，从第1个故事开始梳理故事主线，分解功能点，并由专人负责记录。重复以上过程直到完成列表中所有故事的讨论。注意事项一定要按照故事列表逐个讨论，每个讨论都要细化到功能点并完成记录，再进入下一个故事的讨论；不要先讨论所有故事主线，在一并分解功能点。这样做的目的是让团队可以聚焦，避免多条线索交织造成干扰。在讨论每个故事的时候，不要讨论与当前主线无关的内容，特别是技术团队容易从一个功能点扩散到其他功能点，因为这是技术团队对产品的视角，这种扩散会降低效率。主持人在看到这种情况的时候应该适时制止，告诉团队其他的功能点可以留到其他故事中讨论，只要的产品的一部分，我们在后续的故事中肯定会涉及。完成每个故事的讨论后可以进行短暂休息，在讨论过程中要确保每个参与成员都集中精力，避免形成小组讨论的形式，建议每个故事的讨论都站立在白板前进行。主持人可以由PO和Scrum Master按照故事进行轮换，主持人的主要职责是确保过程的顺畅，团队精力的集中。待确认事项：建议在白板上开辟一片区域，对讨论中出现的团队无法当场确认的问题进行记录，避免在这些问题上纠结太久，影响会议效率。