【报名预约课程】链接：https://developer.huaweicloud.com/signup/a279bccdd4c449e69f13a4c442f9360e

江湖茶馆是敏捷江湖桃花岛中一项话题讨论活动，通过华山论剑层层闯关后的江湖高人，才可获得登岛机会，与敏捷大咖面对面交流互动。 本期主题：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，也可直接扫描下方二维码添加小昭。

序  言随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。1          定义和特性说明1.1       定义故事点是表述一个用户故事，一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300，而要使用1、2、3。估算结果是比值，而不是绝对值。“当使用故事点来估算用户故事的大小时，并没有固定的公式来规定如何计算故事点的数值。故事点估算用于评估为了交付一个用户故事所包含的工作量（team effort），用户故事的复杂度(complexity)，风险，以及所有其他需要考虑的元素。——《Agile Estimating and Planning》, Mike Cohn.1.2       特性说明1.2.1        是相对单位它是一个相对单位。比如，不同的组织团队，对于同样的用户故事的故事点大小一般是不同的；即使同一团队，针对不同用户故事的故事点大小，甚至是针对同一用户故事的故事点大小，都允许是不同的。但同时提醒，不同团队不同用户故事的故事点的设定，有利于组织能力的积累和横向参考。1.2.2        不等同于工作量估算故事点估算不是简单等同于工作量估算。如Mike Cohn所描述，它包含工作量、技术含量、各方面制约等多方面价值因素。有时其他的这些因素，在故事点估算中占有比重会胜过工作量方面的考虑。1.2.3        考虑“完成的定义”故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。2    案例说明2.1       常见问题1)   在Sprint中如何估算故事点？2)   Sprint计划会议中估算不准，如何解决？3)   Sprint计划会议中估算时间过长，如何解决？2.2       解决方法1)    在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。同时也有另一种更新的估算方法－敏捷估算2.0（Agile Estimating2.0），也正被越来越多的敏捷团队采用。ü   计划扑克（Planning Poker）计划扑克由James Grenning在2002年首次提出。计划扑克集合了专家意见（Expert Opinion），类比（Analogy）以及分解（Disaggregation）这三种常用的估算方法，使团队通过一个愉快的过程快速而准确的得出估算结果。计划扑克的参与者是团队的所有成员。典型的敏捷团队规模推荐为7±2人，如规模比较大可以考虑拆分成为多个小团队各自独立进行估算。Product Owner也需要参加，但不参与估算。计划扑克开始时，每个参与估算的组员都会得到一副计划扑克，每一张牌上写有一个Fibonacci数字 （典型的计划扑克由12张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表信息不够无法估算，∞代表该用户故事太大）。开始对一个用户故事进行估算时，首先由Product Owner介绍这个用户故事的描述。过程中Product Owner回答组员任何关于该用户故事的问题。展开讨论时主持人(通常由Scrum Master担任)应注意控制时间与细节程度，只要团队觉得对用户故事信息已经了解到可以估算了，就应当中止讨论开始估算。所有问题都被澄清后，每一个组员从 扑克中挑选他／她觉得可以表达这个用户故事大小的一张牌，但是不亮牌，也不让别的组员知道自己的分数。所有人都准备好后，主持人发口令让所有人同时亮牌，并保证每个人的估算值都可以被其他人清楚的看到。经常会出现不同组员亮出的分值差距很大的现象。当出现有很多不同分值的时候，出分最高的人和出分最低的人需要向整个团队解释出分的依据。（主持人需要注意控制会议氛围，避免出现意见不一导致的攻击性言论。）所有的讨论应集中于出分者的想法是否值得团队其他成员进行更深入的思考。随后全组可以针对这些想法进行几分钟的自由讨论。讨论之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能得到一个全组统一的分值，但是如果不能达到全组意见一致，那么就重复的进行下一轮直到得到统一结论。ü   敏捷估算2.0（Agile Estimating 2.0）计划扑克是Scrum团队应用最广泛的敏捷估算方法，但是有时候计划扑克玩起来耗费比较多的时间，尤其是在十人左右的团队中。Ken Schwaber在他的书《Agile Project Management with Scrum》中指出，在进行迭代规划时，迭代计划环节应该控制为一个4小时的固定时间，但是从战术的角度看，如果一个会议持续4小时，大部分的参会者会有精疲力竭的感觉，并且很难保持持久的注意力。为了解决这个问题，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介绍了Agile Estimating 2.0技术。这个新的估算技术同样基于的专家意见，类比和分解，同样适用Fibonacci数列，但是它可以显著地缩短会议时间。n   第一步是由Product Owner向团队介绍每一个用户故事，确保所有需求相关的问题都在做估算前得到解决。n   第二步是整个团队一起参与这个游戏。只有一个简单的游戏规则：一次仅由一个人将一个用户故事卡放在白板的合适位置上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流移动故事卡，直到整个团队都认同白板上的故事卡的排序为止。n   第三步，团队将故事点（Story Point）分配给每个用户故事（列）。最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。n   最后一步：使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。例如，我们使用红色来表示那些无法被自动化测试脚本覆盖的用户故事，因此那些用户故事需要一个更大的数字来容纳手工回归测试的代价。在国内一些企业多次实践Agile Estimating 2.0之后，反馈的结果还是令人兴奋。据称，团队对于估算的准确性更有信心了，并且只耗费原先的1/2时间。2)    使用Planning Poker进行故事点估算。3)          使用Agile Estimating2.0进行故事点估算。通常耗费的时间会缩短。2.3       主要收益1)   使不同技术水平和工作速度的人在估算结果上保持一致。

序  言随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。定义和特性说明1.1       定义Scrum框架是目前在敏捷圈内比较流行的，图1-1展示了Scrum框架实践的全景图。在Scrum框架中，工作在建议时间长度（2周到4周）的迭代中循环做，这个迭代叫做冲刺。个个冲刺提交的工作内容必须是对用户和客户来说具有确定价值的交付物。个个冲刺有固定的开始和结束时间，也就是冲刺应该在一个时间盒（Time Box）内。冲刺要短，长度建议2周到4周之间，每个冲刺的Time Box建议保持一样。通常来说，在每一个冲刺中不可以对交付内容的人员和范围等目标做改变。个个冲刺要达到Scrum团队共同认同的完成定义，并且交付一个潜在的可以发布的产品增量。图1-1 Scrum框架实践全景图1.2       特性说明1.2.1        时间盒每个冲刺以时间盒这个概念为基础，用它来安排工作执行情况和管理工作范围。时间盒的优点为设定积压的工作（WIP, Work in Process）数量限制，强制排列优先顺序，展示进度，避免不必要的完美主义，促进结束，增强可预测性。时间盒的优点具体内容如下：1） 时间盒是设定WIP数量限制的技术。WIP是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。2） 时间盒可以强制排列优先级。我们需要先执行高优先级的工作，时间盒可以强制我们按优先级排序执行小批量工作，这样我们的注意力可以更集中于快速完成高价值的工作。3） 时间盒可以展示进度。时间盒可以展示我们需要多少个时间盒才能完成大特性的进度，帮助准确知道为交付整个特性还需要做多少工作。4） 时间盒可以避免不必要的完美主义。有时候团队会花过多的时间把事情做得“完美”。每个冲刺中，时间盒限定了一个固定的结束日期，通过这种方式强制结束可能无休止的工作。5） 时间盒可以促进结束。冲刺有明确的最后期限，这个期限不允许修改，这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制，Scrum团队成员就不会有完成工作的紧迫感存在。6） 时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。1.2.2        短持续期每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划，反馈快，错误有限，投入产出比（ROI，Return on Invest）高，有助于保持较高的参与热情，检查点多。具体好处如下：1） 持续期短的冲刺更容易规划。为短时间的工作范围做规划所需要的工作量比给长时间的工作范围做规划的工作量要小得很多，结果更准确，可执行性更强。2） 持续期短的冲刺可以产生快速的反馈。快速反馈可以去掉不适宜的产品路径和开发方法，避免产生更多的不良质量成本（COPQ, Cost of Poor Quality）。最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的商机。3） 持续期短的冲刺投入产出比（ROI）更高。持续期短可以更早、更频繁地交付，有更多的机会快速投入生产，产生收入。4） 持续期短的冲刺所犯的错误也是有限的。在短短1或2周的时间内，就算错了，全部搞砸了，也只是失去了短短的1或2周的时间，不会带来巨大的损失。坚持持续期短的冲刺能够进行频繁地试错，协调和反馈。5） 持续期短的冲刺有助于保持较高的参与热情。团队参与工作的热情，兴趣和兴奋程度会随着时间的拉长而越来越弱。如果一个项目时间过于长，人们看不到结果，那么显然人们会逐渐失去兴趣。持续期短的冲刺通过频繁快速的交付可用的工作产品，让参与者有满足感，操持较高的参与热情，便团队成员恢复兴趣并渴望继续完成冲刺的目标。6） 持续期短的冲刺能提供多个有意义的检查点。传统瀑布式开发有里程碑，例如分析、设计、编码、测试和运行。这些里程碑其实是一些不太靠谱的指标。Scrum在每个冲刺结束时会有一个有意义的检查点（冲刺评审会议），团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正，我们就能更好地应对复杂的项目。1.2.3        一致长度每个冲刺的长度建议保持一致。一致的持续期更有节奏感。冲刺中稳定的节奏感让团队中的成员进入最佳状态。稳定的节奏感使单调而必要的活动成为习惯，从而让团队成员留出心力，集中做有趣、增值的工作。比如，为期一年的开发工作中执行时间盒为2周的冲刺，那么对于接下来二十几个冲刺评审或冲刺回顾活动，我们可以在每个人的日程表发出一个重复发生的事件，否则每个冲刺评审或冲刺回顾需要额外花更多的精力去协调利益干系人的日程。一致的持续期还可以简化规划活动。长度一致的冲刺更容易计算出团队的速率，也可以简化剩余的计算活动。1.2.4        锁定目标每个冲刺需要锁定冲刺目标。Scrum框架有一个重要的原则：一旦制定冲刺目标，在冲刺执行开始后就不允许有任何变更对冲刺目标实际产生影响。冲刺目标是Scrum团队和产品负责人的共同承诺。Scrum团队承诺按时完成目标，产品负责人承诺在冲刺执行过程中不变更目标。虽然冲刺目标不应该有实质上的变更，但是允许澄清目标。在冲刺开始时，Scrum团队对PBI相关的细节不一定完全明确，在冲刺执行中提供更多的澄清是合理的。变更冲刺目标会引起浪费，损害团队的士气和信任。“锁定目标”是一个规则，并不是铁律。Scrum团队在遵守“锁定目标”的同时还要注实效。如果变更冲刺目标造成的经济后果远远小于推迟变更所造成的经济后果，那么就应该选择适时变更。假如冲刺的目标变得完全无效，可以选择终止当前冲刺，终止冲刺是不得已而为之的最后手段。终止冲刺后，Scrum团队应该决定下一个冲刺的长度，尽量考虑节奏重新同步。1.2.5        定义完成每个冲刺需要有团队共同认同的完成的定义（DOD, Definition of “Done”）。完成的定义可以随时间演变。如果，很多情况是软件开发的人说：“硬件总是很晚才到位！”像这种情况，如果一个团队构建软件而没有硬件做测试，不能声称在每个冲刺结束时产生的结果是潜在可发布的，需要灵活变通处理完成的定义。引入冲刺的每个PBI都应该有一组由产品负责人指定的完成的定义，或者称之为接收标准（AC，Acceptance Criteria）。这些接收标准在接收测试中进行验证，产品负责人会确认AC是否全部满足2          案例说明2.1       常见问题1)      如何增强团队工作紧迫感，完成冲刺内的任务？2)      团队无能力预测下一个冲刺可以完成的工作容量，如何增强预测能力？3)      只有在冲刺活动中才有时间盒吗？2.2       解决方法1) 强调时间盒的概念，团队成员有时间盒的意识，借助时间盒设定冲刺中WIP的数量，设定优先级，强制完成时间，防止无休止的工作。团队务必明确冲刺目标及完成定义。每个冲刺需要由团队共同确定目标，共同定义“完成”的标准。只要完成了定义的“完成”就可以认为完成了冲刺内的任务。2) 时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。3) 时间盒在Scrum中多处被体现出来，只是有的团队为了赶任务而被忽略。总结起来大概有如下时间盒或许更多，参见图2-1，通常建议如下：Ø   一个冲刺在2到4周Ø   冲刺计划会议控制在2到4小时Ø   站立会议控制在15分钟之内Ø   冲刺评审会议控制在2小时之内Ø   冲刺回顾会议控制在30分钟之内Ø   产品经理要提前准备1到2个冲刺的PBI图2-1 时间盒总结图另外想说，以上并不是绝对要求，只是阐述了通常情况下的选择。2.3       主要收益短期快速稳定节奏交付可以快速试错、协调和反馈，把握商机，降低COPQ，提高ROI,增强团队成员参与热情，提高可执行性，更好地应对复杂项目，并相对容易对近期工作做出预测和判断。

当今，DevOps能显著提升企业的商业敏捷与能力，因此在企业中广受欢迎。然而，对于大多数企业来讲，DevOps变革并非一帆风顺，此过程中会面临各种各样的挑战。为了提高DevOps变革成功的可能性，企业领导者亟需识别或者理解DevOps变革失败的常见原因，并采取一定的措施来避免。经过不断发展，DevOps逐渐演变为一种方法框架，使能企业综合运用人员（People）、流程（Processes）与技术（Technologies）等，从而将价值持续交付给最终客户与用户。基于DevOps的价值观（Value）、原则（Principles）与实践（Practices），分析许多企业的DevOps落地案例，DevOps变革会存在6大常见的主要原因，称之为六大“焦油坑”：§   无的放矢§   乌合之众§   各自为政§   一蹴而就§   好高骛远§   沙上建塔1      无的放矢：未从客户价值出发在DevOps热潮下，许多组织通常为了赶潮流而快速启动DevOps变革，常常为了DevOps而做DevOps（Doing DevOps for DevOps），而没有充分考虑DevOps的真正目标或者目的。员工只会关注为组织带来的价值，而不会单纯与DevOps术语、方法以及支撑工具产生联系。因此对于DevOps变革，无论变革启动时，还是变革过程中，都需要将为客户带来的商业价值作为目标，以便不断调整DevOps变革内容。这也与多数组织“以客户为中心”的理念相吻合，然而却经常被忽视甚至忘却，导致无的放矢或者向不正确的靶子放矢。为了使DevOps变革立足于客户价值、充分识别谁是客户、他们需要的价值是什么，组织应该经常思考如下问题：·           现有或者潜在的客户是谁·           客户看重或想实现的商业价值是什么·           企业能提供哪些offerings，仍有哪些差距·           客户期望的时间点·           企业能够多快进行发布·           客户前进的方向是什么，如何升级企业的offerings·           如何让客户了解到企业提供了什么企业组织在DevOps实施过程中，必须以客户为中心，持续地提高对客户商业价值的理解，来作出相应的改变，并提升自身能力。2      乌合之众：未有效地管理组织变革在DevOps变革中，企业组织应该认识到人或团队是DevOps变革的最大的挑战，因而应该充分重视组织变革的重要性，而不是将重心聚焦在工具上。企业应该从理解客户商业价值来发起组织变革，领导层必须清楚DevOps以及相应的组织变革是不可或缺的，员工必须认识到变革正在发生。在DevOps变革中，领导层应该理解，为了提升商业敏捷性，决策需要在信息产生的地方进行，并应该去身体力行此种决策理念。因此，领导层需要组建团队，并让团队自己决策应该做什么以及如何做。这就要求在组织内识别潜在的候选人，且候选人应该具有以下价值观：·           团队合作：确保候选人乐于团队合作，并且在团队内工作效率高；·           值得信赖：信任是DevOps的CAMLS理念中文化的基本要素之一，因此候选人必须可靠、可信；·           干劲十足：候选人必须能主动积极地追求目标；·           有责任心：对工作过程、工作产出能负起责任，而不是推三阻四；·           足够聪明：能理解必须完成的工作，并可以决定如何开展；·           经验丰富：经验可以使团队成员成长，当然不一定对DevOps有经验；·           有效沟通：及时准确地口头或者书面传递信息与知识；·           风险管理：与团队其他成员（例如PO）协同工作懂得如何管理风险；·           终身学习：DevOps并非一成不变，因此更重要的是，发现有正确态度的人并培训技术技能，而不是过分强调技术技能而忽略错误的行为。领导者应具备相应的技能与态度来激励员工，进行授权并提升他们的责任感。当然，对于拒不改变的员工，必须毫不迟疑地将他们安排到不会动摇变革的岗位上。3      各自为政：未充分地合作在DevOps变革过程中，比较现实的情况是单个职能领域（例如IT部门）来发起此变革，因此导致DevOps实施局限于单个职能领域，无形中增加了变革失败的可能性。因此即使单个职能领域发起DevOps变革，组织必须意识到成功的DevOps实施需要所有干系人共同合作以更全面地理解并系统地解决问题。为了加快价值实现时间，DevOps团队必须与其他团队及关系人合作。DevOps需要人们共同工作实现解决方案，打破障碍，并能像小型团队一样运作。因此，合作是至上的，团队的大小并没有绝对的限制，虽然业界有所谓两个比萨（Two-pizza）团队的说法。更为重要的是，企业级别的合作需要管理层的支持。在一开始，就应该获得管理层的支持与拥护。DevOps的拥趸必须相信DevOps的价值，并平衡组织内不同团队的激励方式，例如开发团队被鼓励快速变更和开发新特性，而运维被鼓励维持可靠性和稳定性，这样就难以形成合作。4      一蹴而就：未采用迭代方法全面的一揽子的DevOps变革，对于大多数企业组织来说，是非常有诱惑力的。然而，历史经验却无情地告诉我们，这种传统变革失败率非常高。DevOps要在一个大型IT组织中成功，涉及太多因素，并且组织越大越困难。因此，增量迭代方法成为组织的必然选择，一方面此方法使组织聚焦于持续改进，另一方面避免了传统方法的巨大风险。在进行DevOps变革时，组织聚焦于单一价值流，通过迭代与持续学习来持续改进，来得到合适的因素维持可接受的变革。迭代增量节奏也使组织确保团队分享与合作，并建立实践社区。这样，在此价值流学到的知识可以传递到下一个价值流，逐渐在组织中规模化DevOps。组织在每个迭代中需要仔细识别目标机会，并确保每个迭代满足以下3个关键条件：1.     政策友好性：干系人愿意给予DevOps公正的试验环境，在错误发生时，从中学习经验而不是责备；2.     可接受的价值：每个迭代产生足够的客户价值，来建立信任与获取支持；3.     可接受的风险：即使DevOps宣称具有显著降低风险的能力，然而人们更乐于看到实际效果，而不是简单听理论。5      好高骛远：疏于管理期望值俗话说，期望越高，失望越大。对于DevOps，许多组织的期望与它能够交付的内容存在脱节。与其讲企业组织将更敏捷或者快速，不如明确组织现在在哪儿以及需要到哪儿，然后迭代地实现目标。DevOps不是一次性投入，而是需要不断地尝试。因此组织需要达成一致的目标与度量指标来有效地管理期望。DevOps的度量指标非常多，建议可以从以下4个角度建立进度平衡视图：1.     市场目标：例如销售量、客户留存率等；2.     交付周期：价值实现的平均时间；3.     风险管理：宕机时间、业务恢复时间等；4.     客户满意度；需要指出的是，并非所有的不切实际的期望都来自于商业客户。例如，IT部门会认为工具链是免费的，实际上工具链需要持续的资源与投入。总体上，组织需要围绕客户价值、成本与风险来权衡建立合适的期望。6      沙上建塔：未清晰地管理需求由于受到DevOps成功案例以及CAMLS理念中自动化的影响，企业通常寄希望于自动化等技术与工具手段来加速产品上市周期，然而经常因诸多基础性工作没有做扎实导致DevOps实施效果未达到预期。在诸多基础性工作中，最为关键的是需求的探索、分析与分解。从DevOps的发展历史来看，DevOps继承了敏捷方法的诸多实践与理念，原则上默认DevOps团队较充分地掌握了敏捷方法与实践，也致使DevOps组织忽略需求的重要性。因此无论如何强调需求的重要性都不为过。DevOps团队必须清晰地管理需求，使需求以及Story满足SMART要求，在迭代周期内可以按时保质交付最小可行产品（MVP）。DevOps变革是一个系统工程，涉及到组织、文化、人员、流程、工具、方法等方方面面。对于企业来讲，应该从客户商业价值出发，选择合适的团队，合理地管理期望，并以增量迭代的方法，初始聚焦于单一价值流，夯实基础，逐渐扩展到其它价值，实现DevOps规模化，最终实现企业的商业敏捷。

DevOps组织的成功，很大程度上来自于聚焦培养强有力的DevOps团队。然而随着DevOps深入实施，DevOps组织却面临窘境，在交付团队与流程中无法为应用架构师定义相应的角色与活动。DevOps组织努力引入应用架构看护，却发现与DevOps价值观、目标与实践难以协调一致。同时，由于缺乏应用架构指导，DevOps组织难以将DevOps行动规划化推广。DevOps组织面临的应用架构相关的窘境，概括来讲，主要体现在以下3方面：1.     应用架构师与DevOps团队间关系越发失调，同时缺乏沟通基础与机制，难以有效沟通；2.     开发流程中没有阐述何时寻求应用架构指导，导致应用开发缺乏架构指导，同时难以协调浮现式架构（Emergent Architecture）与前期架构需求；3.     产品管理中没有定义应用架构角色，跨应用影响（例如协同与依赖）可能没有被有效识别。针对应用架构相关窘境，在现代化的应用开发中，DevOps组织需要定义应用架构师职责，使应用架构师与DevOps团队各角色更有效的沟通，交付更有价值的产品。在多数情况下，应用架构师不是DevOps团队的成员，因为架构技能非常稀缺，必须服务多个团队。架构师应该成为具有独特视角的领域专家、在团队内提升架构知识与技能的教练、帮助团队做出最佳决策的指导者。具体来讲，应聚焦以下3方面：1.     建立DevOps团队与应用架构师的沟通机制，使DevOps团队将应用架构师视为SME、教练和指导者。2.     让应用架构师提供架构原则和模式来指导单个解决方案的浮现式设计（Emergent Design）3.     让应用架构师维护产品backlog的高层次视图以及跨DevOps团队协调来发现系统之间的影响，例如接口、重用等。1      应用架构师与DevOps团队不同角色有效地沟通通常情况下，DevOps团队最初先使用敏捷框架（Agile Framework）（例如Scrum）来定义以开发为中心的角色和活动，然后增加面向运维的角色和活动，以帮助团队成员更好地协同工作。DevOps团队的主要角色如下图所示：图1 典型DevOps团队角色DevOps团队的成员每天面对面一起工作。随着时间的推移，通过持续改进，DevOps团队形成了透明、信任、高效的工作氛围。DevOps这种以团队为中心的方法很难容下外来者。例如， ScrumMaster的职责之一就是保护团队免受外部打扰。DevOps应该确定并促进DevOps团队与应用架构师之间的关系，使DevOps团队将应用架构从干扰者转变为合作伙伴，应用架构师成为领域专家（SME）、教练（Coach）与指导者（Guide），来共同负责有价值软件的成功交付。在传统软件开发实践中，应用架构师可能只与开发团队的技术领导人或者项目经理进行沟通交互。然而，在DevOps团队中，应用架构师需要理解典型DevOps团队的角色，并与之建立关系，形成有效沟通。·           ScrumMaster：ScrumMaster是团队的教练（Coach））、促进者（Facilitator）、保护者（Guardian）和指导者（Guide）。他们可以确保所有人理解并且遵从开发流程的应用架构的方方面面，并与团队和应用架构师一起优化流程，促进团队和应用架构师的交互。应用架构师应将ScrumMaster视为非常有价值的联盟。·           Product Owner：PO是客户（或者业务）的代表，保证应用中包含了有价值的特性。他们与应用架构师一起工作确保backlog中涵盖了应用架构需求。PO和应用架构师合作来识别并理解跨团队影响以及调整backlog。·           Developers：将应用架构师视为指导者和潜在的教练和顾问。如同与任何SME工作一样，开发人员应该在必须的时候寻求应用架构师的输入和澄清。在故事的开发与设计中，开发人员可与应用架构师讨论架构重要性或者影响。拥有架构知识的开发者可以作为应用架构师的代表和代言人。·           Platform团队：与架构师确保应用更合适地使用平台的服务。反过来，架构师为平台的演进提供反馈。例如，架构师可以建议将功能创建为应用服务，而不是应用本身的一部分。在多个平台选择的情况下，架构师帮助确定哪个平台是合适的。·           Operations团队：与应用架构师共同工作来识别方法最大化应用的可运维性、弹性、可持续性与安全。这些方法包括增加度量、增加或者修改工具链组件、与安全事件监控等管理工具集成、为应用行为提供可配置选项。·           Support团队：是架构师的关键反馈来源，这些反馈包括设计决策的实际的、生产有效性。除此之外，应用架构师通常与产品价值流的总体解决方案有关，因此应用架构师能够以更广的视角来识别DevOps团队间的协作，并提供权衡方案；同时可以帮助DevOps团队充分理解只有应用组合更强大，客户才能获得最大化的价值。2      应用架构师为解决方案持续提供原则与模式，并拥抱反馈在传统的软件开发组织中，应用架构师一直致力于提供大量的前期设计，为开发团队提供应用架构输入。在DevOps组织中，DevOps团队通常会引用敏捷宣言，特别是 “最好的架构、需求与设计出自自组织团队” 这条原则。DevOps团队采用迭代增量方式来构建应用，不断演进解决方案，以不断增进和改善对干系人需求的了解以及如何最好地满足需求。因此，应用架构师交付的大量静态架构规范无法演进，也无法提供价值，从而变成了浪费的源头与价值流的一种约束。这不意味着应用架构输入对DevOps团队没有帮助。如果没有应用架构输入，DevOps团队创建的应用将缺乏重要特性（例如缺少安全性、扩展性或可靠性等），无法为客户提供足够的价值；同时应用也可能因基础平台不同及集成性弱等而无法很好地与产品组合中的其它产品相匹配。此外，如果团队不能利用可重用模式中的知识，将增加SME的负担，因为SME不得不重新发明轮子。最终，导致专家将用完容量，阻止规模化扩展。尽管被视为深思熟虑架构的障碍，浮现式架构使敏捷团队参与到应用架构的创建中，并且更好与应用架构匹配。应用架构师和DevOps的团队目标是统一的，即为客户创建有价值的应用，但是他们有不同的视角。DevOps团队主要聚焦应用本身，而应用架构师更关注应用在企业应用组合中的位置，并在应用组合间提供一致的客户体验。因此，DevOps团队与应用架构师之间的紧张关系是不可避免的。然而，应用架构师必须愿意摒弃先入之见，并将架构决策延迟到最后时刻。为实现持续的指导，应用架构师不被鼓励事先为敏捷团队提供大量的应用架构工件。敏捷团队会没做好使用的准备，或者会视为控制应用设计的尝试。相反地，应用架构师应该每次输入一些，按照敏捷团队的节奏，随着应用创建过程中出现的问题和机会。这需要应用架构师持续与DevOps团队沟通。应用架构原则形成了持续指南的基础。应用架构师需要从基础中提供指南。应用架构师应该全面理解企业应用架构原则，并且一致地运用这些原则。应用架构师应该准备好传递基于原则的理由，来阐明为什么需要引入给定的需求，或者推荐某个特定模式的使用。实际的应用架构在应用架构师和DevOps团队的讨论中浮现。定期的反馈应该在整个过程中收集。团队创建应用过程中浮现的实际的应用架构，不但与应用架构原则保持一致，而且经常会揭示这些原则新洞察。应用架构师领导者应该使用这些洞察来演进应用架构原则和实践。应用架构领导者应该考虑使用敏捷“回顾”技术，与应用架构师团队来增强反馈回路。3      应用架构师维护产品待办事项的高级视图并影响事项待办工作列表（Backlog）是DevOps团队活动的主要驱动力。待办工作列表中的工作项初始是粗粒度的，DevOps团队会分解为更细粒度的故事（Story）。随着工作的开展，待办工作列表越来越大，导致不同团队的跨单个Backlog的影响难以识别。反过来，这导致了某些冲突只能在生产环境上发现，需要昂贵的重复工作。也导致重用或者协同的机会没有得到实现。发现这些冲突与机会，同时采取行动避免或者利用他们，是应用架构师的作用之一。通过持续地指导应用开发团队，应用架构师将维护Backlog视图，此视图既有广度又有深度。这样，他们就可以相应地影响Backlog。当敏捷团队需要应用架构指导时，理解并监控Backlog是准备提供指导的关键。应用架构师可以在3方面影响Backlog：Item优先级、跨团队影响和DoD（Definition of Done）。应用架构师应该评估每个待办工作列表中工作项与应用架构相关的方方面面，并且聚焦高优先级的工作项。这样做的目的是准备刚刚好、即时的指导，避免backlog变更时的重复工作。某些工作项应用架构意义更大，更复杂或者不确定，将需要应用架构师相应地与敏捷团队更多交互。某些工作项是更好的机会使团队探索替代的应用架构，或者重构现有软件。应用架构师应该与PO讨论，如何对这些item进行优先级排序。一些PO会为应用架构需求创建单独的工作项，而另外一些PO会将应用架构需求作为其他工作项的一部分。无论哪种情况，应用架构师与DevOps团队必须协商解决最重要的应用架构需求而牺牲其他需求，但是应该使DevOps团队意识到这将导致技术负债。应用架构师应该看护所有敏捷团队的backlog，同时对应用组合有共同理解，以便来识别跨团队的影响和协作，这些主要包括接口、用户体验一致性与重用。重用对于DevOps团队来讲，是一个问题泛滥成灾的领域，因为重用设计会引入额外工作，而不会交付即时价值。应用架构师与DevOps团队可以使用Pay Twice模型来达成协议来减轻这种影响。增加与敏捷团队的交互将使应用架构师的已经很紧张的安排雪上加霜。一些合规性和安全的需求经常出现并影响大部分团队。与其投入时间去持续重新介绍这些需求，不如考虑将他们纳入到DoD（Definition of Done）中。DoD是所有工作完成前必须满足的标准集合。这种方法是非常有效的。DevOps团队可以结合自动化测试和静态代码扫描工作，减少人工评审、耗时的低价值的应用架构工作。长期来讲，客户不仅仅满足于软件立即提供的新特性，更需要持续的可靠性、可用性、性能和安全。因此，DevOps组织需要在软件交付中重新定义应用架构师角色，使应用架构师成为SME、教练和指导者，保障应用架构原则在DevOps团队落地，实现DevOps价值观、原则与实践能够规模化应用，最终为客户提供有价值的软件。 

大家好，我是华为DevCloud 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f） 作为布道师和产品经理，出差各地接触客户是常态，线下和华为云的客户交流、布道、技术沙龙。 但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和实践。 <研发不是请客吃饭，恒少出品，必来自实践一线>  ----------------------------------------------------------------------------------------------------------------------------开篇语：使人有乍交之欢，不若使人无久处之厌——摘自明代书画家陈继儒（号眉公，也称陈眉公）《小窗幽记》 Wiki在我看来，第一眼一般不会有“乍交之欢”的感觉，尤其是我之前一直使用Office在写作各种需求设计、方案文档。但是，Wiki也大概率会成为“无久处之厌”。 我在四处布道，介绍华为这些年研发转型实践时说过，华为对研发能力的重视和建设已经形成了一种可闭环的持续机制，Wiki在国外开始出现的时候，华为就已经引入到了企业内部。 维基百科，这个基于Wiki的全球最大的多语言，内容自由，任何人都能参与的百科协作计划，可以认为是全球范围最知名的Wiki产品。 第一个Wiki的产品，也是Wiki的发明者沃德·坎宁安推出的“波特兰模式知识库”。 Wiki一词来自于夏威夷语的“wee kee wee kee”，翻译过来“快点，快点”（有一部美剧叫Hawaii Five-O（中译：天堂执法者），对于夏威夷的风土人情、语言是一个很好的了解渠道） “快点，快点”非常形象的描述了Wiki是为什么而生的，就是“快点”。最初是面向社区的在线的多人协作工具，定位决定地位，Wiki的定位最早是：  1.   多人在线协作，群策群力；开放，参与者平等，每个人都可以针对共同的主题进行扩展或探讨；简单，创建，编辑，更改，发布的代价越低越好，于此相对比的是早些年比较难编辑发布的HTML文本。为共享、沉淀知识而生   如果拿Wiki和博客，微博，公众号文章来对比的话，后面这些你只能去评论，但是你不能去改别人的内容，只有作者才能修改。而Wiki是授权范围内的任何人都可以去编辑内容。   业界也有人常用这个例子来形象描述Wiki是什么：设想一群人（志趣相投），围在一个白板前，任何人都可以添加自己的内容，修改，甚至抹掉，也可以修改别人写在白板上的内容。  介绍了这么多，有些同学一旦联想到自己常见的文档/内容的写作或协作场景，就会觉得Wiki这样也太松散了吧？谁都可以编辑，会不会失控。所以很多同学不会有“乍交之欢”。华为作为一个营利性的企业，碰到Wiki这样近乎无控制的产品，也会觉得有点莫名无感。  但是，华为还是引入了Wiki，经过多年的内部沉淀，发现不少的同学开始“无久处之厌了”，Wiki在华为内部也有了不少坚定拥抱者。从我们和其他很多企业的交流看，Wiki在很多企业都有比较高的使用量。  现在分析想来，Wiki作为一个20多年的产品，为什么依然还在很多企业内部有着强大的生命力呢？我们统计分析了一下，发现这些年的一些变化，使得Wiki反而更有生命力：组织结构趋向扁平和自治，团队得到充分的授权。随着敏捷/DevOps的深入人心，扁平化的组织形态逐步普及，团队内部全栈的工程师，相对比较平等，少了很多的评审和过程中的控制，不需要写个设计文档还需要领导审批才能发布，Wiki这种自由开放的在线协作自然会更受欢迎交付节奏越来越快，按周甚至按需可以发布。比如像华为云的DevCloud团队，常规迭代周期做到了1~2周，而且每个迭代都是上线生产环境，甚至做到了按需随时发布。这么短的时间内，不会再追求重型的需求设计文档，更关注内容本身而不是文档的格式。也不再是那种写完了，再发给大家评审的重型评审过程，而是迭代写完，大家都可以直接使用wiki进行编辑，快速对需求和方案达成一致即可。企业越来越重视知识管理。知识需要供给，需要分享，需要让更多人参与，并回馈给知识的内容提供者。软件开发的那么多坑和雷，不经过知识的总结与提炼，只能是炸了一批人又一批人，而各个项目或产品团队，日常开发过程中的知识积累是最朴实，最宝贵的一线知识积累，来自于实践，而项目或产品团队都非常忙，为了让大家的知识共享能简单，Wiki自然就是最好的选择，编辑轻量，多人可以一起协作。云端协作，AnyWhere&AnyTime成为刚需和常态。随着云基础设施的大规模应用，很多企业都陆续把自己的IT系统/工具搬到云端，开箱即用，不需要再通过邮件发送文档。Wiki这种又轻量，又可以并行协作的云端写作也就再次得到了很多用户的欢迎。与客户的联合敏捷、众创进入探索。以前客户和供应商的关系是严肃的合同，SOW（工作任务书），达标答复，重要客户会议纪要通常都是严肃的，都以特定模板的Office文档来承载。但是我们惊喜的发现，很多客户和供应商之间的关系不再是严格的甲方乙方，而是采取了联合敏捷，众创的探索，在合同框架下，快速达成一致，赶紧开始干活，一起缩短TTM（Time to market）。所以我们和某些客户的会议纪要，需求的澄清，都是使用Wiki来共同协作的，客户在我们的基础上可以修改，在线达成一致，然后赶紧排需求开发。据说在美国，这样的形式更普及。  不过，客观的说，Wiki目前还替代不了严谨性文档的协作，比如专利啊，给客户的重要文档。Wiki提供的格式（无论是富文本还是Markdown）都比不上Office这样专业的文档工具。因为定位不同，格式的支持多少也不同，所以市场上的Wiki都很难无缝的支持所有的Office的格式，所以从Office拷贝到Wiki，往往会有些格式不支持。 华为云DevCloud 一早就把Wiki作为一个基础服务商用提供，近期，DevCloud上线了新版的Wiki，在用户交互体验上进行了比较大的优化，秉承“Eat your own dog food”的经验，DevCloud团队内部已经使用了新版的Wiki长达了2个月。 作为一个对Wiki已达到“无久处之厌”的老Wiki用户，我们做了如下的优化：1. 预置了更多沉淀华为实践的Wiki词条模板，接地气，实用为先2. 改成左导航，右内容的布局，词条的切换不用再像以前那样需要返回。如下这个也就是我所负责的产品域日常交付的Wiki：），我们是真的“吃狗粮”哦：）3. 分段编辑，支持快捷的并行编写（可以一人写一段，不冲突），一级标题的快捷导航窗口，快速在段落间定位4. 自动缓存到后台，即使异常关闭，也可以自动恢复之前编辑的5. 父子词条可拖动调整，点击词条，拖动可以把子词条升级为父词条，也可以把父词条降级为其他父词条的子词条6. 更多富文本和Markdown格式的支持和完善7. 词条的变更历史  DevCloud团队目前已经大部分基于Wiki来在线文档协作，现在的PRD（产品需求文档），方案设计，数据库设计，接口设计，ReleaseNotes，沟通矩阵，产品服务的规定，回溯报告，重要会议的纪要基本全部基于Wiki来轻量级的管理，大家都可以开放的编辑，丰富完善。   写在最后：任何产品都有自己的最适合的场景，这是个丰饶的时代，根据自己的场景选择合适的工具。DevCloud自身选择了Wiki，也希望能给我们的用户带来一些启示和帮助。   恒少 写于 2018-12-29

 大家好，我是华为DevCloud 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f） 作为布道师和产品经理，出差各地接触客户是常态，线下和华为云的客户交流、布道、技术沙龙。 但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和实践。 <恒少出品，必妥妥干货，必理论联系实践> -----------------------干货分割线--------------------------------------开篇小段子：In preparing for battle I have always found that plans are useless, but planning is indispensable - 德怀特·大卫·艾森豪威尔。艾森豪威尔，在第二次世界大战期间，担任盟军在欧洲的最高指挥官，同时也是美国第34任总统。他有不少经典的名言，这句话的意思翻译过来就是：计划书往往是无用的，但是计划的过程是不可缺少的。艾森豪威尔的这句话，是很多文章里用来引述“计划”的名言，我也不能免俗。哈哈。我个人对《人月神话》这本书有着很强的执念，早期坚信软件天生就有易变性，不可见性，软件的计划都是没有什么实际意义的。但是时间累积后，我也终于悟出来，其实做计划的过程是关键。迭代计划会议是团队级敏捷的三个基础会议形式的一个，按软件开发的时序，这个是第一个会议，我之所以放到最后讲，是因为这个会议很重要，非常容易陷入误区。（其实也是我懒，先挑简单的写）迭代计划的初心：团队全员对接下来的迭代要做哪些UserStory、每个UserStory的责任人达成一致团队成员对本轮迭代的完成标准，计划的开始结束时间达成一致团队成员更认真的对待自己充分参与过的承诺。一张图看懂迭代计划：本文，我们使用产品经理和开发团队Leader这两个角色名。这两个角色是目前互联网企业和软件产品企业常用的角色名。产品经理负责产品的定义、规划和需求，开发团队Leader负责带领整个团队完成需求的交付和上线。迭代会议的预先准备阶段：1. 比较强烈的建议1：产品经理应提前将特性、大颗粒的需求细化为单个迭代可以交付的多个UserStory。这是一个避免产品经理被拍砖的良心建议，你如果拿着“我要做一个社交功能”的所谓Story去迭代规划，估计场景会有点尴尬。其实迭代Backlog里面装的只能是UserStory（有时候也可以装上个迭代的遗留Bug）。2. 比较强烈的建议2：产品经理和开发团队Leader，提前从产品Backlog中挑选接下来迭代可以交付的UserStory的备选。产品经理对需求的价值、优先级和期望交付的时间比较清楚，而开发团队的Leader通常对于需求交付的技术依赖，团队的能力，团队的人力管道容量比较清楚。产品经理和开发团队Leader互相交互意见，挑选出预期应该放到下个迭代交付的UserStory，也可以叫做备选的迭代Backlog。这个阶段，备选UserStory的工作量也应该做一个初略的估计，这个时候就是资深开发Leader和小白的区别了。同时产品经理也应该将备选的UserStory都标明优先级，比如使用Must-Cloud的方法，必须做的，可以做的，对应中文也也就是高优先级和中优先级。便于后面根据人力实际容量选择最终的迭代交付内容。一般的迭代会议指导中，并没有特别提到这个预先准备阶段。之所以笔者特别强调，是因为，在华为之前的实践中，直接进入迭代会议，会出现产品经理和团队成员耗费大量的时间，从产品Backlog中，确认哪些UserStory可以放到这个迭代中，迭代计划会议通常是全员参加的，这样会导致耗费全员大量的时间，特别低效。之前在华为内部，有过一种思路，觉得产品经理无需和进行沟通，直接指定优先级和计划时间就可以了，开发团队无条件执行。这是强产品经理导向的，但是正如网上经常看到的段子一样，这样容易导致产品经理和开发人员矛盾激化，“动手拍砖”。我们还是认为，产品经理和开发团队应该有一个双向的沟通和理解，有些需求可能确实存在技术的难度。3. 比较强烈的建议3：开发团队Leader应该预先了解团队接下来迭代的人力容量，是不是有同学可能要请假，是不是有同学要调动到其他工作等等。上个迭代团队的人力容量是多少，接下来的迭代团队是不是有一些架构、技术优化方面的工作要预留，预计可以有多少人力容量可以投入到业务需求上。我们也非常推荐，每个迭代里面预留一定的人力容量用于技术，架构的改进，业务需求和架构技术优化保持一个比例，保持产品的的健康。这也是持续改进的体现大家要铭记一个事情：团队的人力容量每个迭代一定是变化的，迄今为止，软件的开发活动还是个智力指导下的双手活动，开发人员心情不好也是会影响人力容量的：）迭代会议的输入：备选的迭代Backlog：一个经过产品经理和开发Leader预沟通的备选迭代Backlog，初步的需求优先级排序迭代的目标：目标包括很多类型，是这个迭代的“教堂”，比如这个迭代要交付的重大特性，重大的市场发布等，让全员能够感知自己在这个迭代完成的UseStory的价值，迭代目标通常由产品经理向全员传递。团队自身架构、技术的重大优化，也可以是迭代的目标。团队在质量、效率上的改进目标，比如缺陷下降多少都可以是这个迭代的目标。迭代会议的过程：颁布会议规则，比如限定会议时间，别人发言的时候，其他人禁止讲话，每人发言限时多长时间，产品经理首先给大家介绍备选的Backlong中，有哪些UserStory，这个迭代的重大特性及其价值，或者要交付的重大市场发布，或重点客户，介绍Must的UserStory有哪些。开发团队Leader给大家介绍一下技术、架构，研发环境，获取其他的团队自我改进的目标，团队成员全员参加，从Must UserStory开始进行Story的工作量估计，对于有些UserStory，还可以进一步拆分为Task，给出每个Task的估计团队成员全员参加，看看当前计划的UserStory重估计和人力容量是否相配，不能超出人力容量的100%。或者团队根据情况，定一个范围，90%，80%都可以，因为毕竟工作量至少预估计。随着团队越来越默契，估计值越来越准，可以提升到100%。如果有超出，产品经理和团队成员一起，重新调整，首先去掉Could的UserStory。这时，基本上这个迭代要交付的UserStory范围就确定了。开发团队Leader带领团队成员，开始分配认领UserStory，我们建议鼓励团队成员主动的Pull（认领） ，而不是被动的接收Leader的Push（被动接收）。当然有些UserStory可能需要某些成员开发更好，团队Leader可以再调整，我们也可以叫做Pull&Push。开发团队Leader统一审视每个成员的实际工作量，避免对有些成员的工作量不均衡，并进行相应的调整。进行简单快速的头脑风暴，团队成员发表自己对于接下来迭代的风险，对于是一般性的风险问题，快速记录，团队Leader会后解决，避免耽误大家时间全员对这个迭代的目标进行信心投票，5分信心最高，1分信心最低，如果平均分低于3分，应该让投比较低的成员再讲讲他们的考虑，看看要不要再调整需求的优先级。会议结束，开始为这个迭代的目标而冲刺。迭代会中的一些雷和坑。迭代会议预先准备是非常关键的。团队成员那么多，如果预先不进行备选UserStory的识别和排序，拿一堆颗粒度很大的需求直接去迭代会议，大概率要失败，会议也会及其冗长，那么多团队成员，时间哗哗的就流失了，研发不是请客吃饭，这是要让你们老板倾家荡产啊。工作量的估计方法。有绝对估值法（人时/人天），或者相对估值法（斐波那契数列的故事点，T恤 Size）。关于为什么比较流行使用斐波那契数列我写了一个短文：https://bbs.huaweicloud.com/forum/thread-13153-1-1.html业界在各种敏捷，DevOps培训中，用的比较多的是相对估值法，而且通常有个故事点估计的卡片。但是从我们的实践来看，早期的迭代，团队刚刚成立，团队成员的能力和容量没有基线，团队成员对于产品，架构、技术还在掌握中，研发环境和工具链刚刚搭建，还有些工作需要投入，这种状况下用相对估值法更适合。当团队磨砺一段时间后，团队成员比较稳定，团队成员的能力和对技术架构的掌握越来越好，团队成员的估计越来越准，使用绝对值更接地气，理解起来比较直接。华为云DevCloud同时提供绝对估值法的人时/人天，用户只需要选一个计量单位，系统会自动计算另一个计量单位的值，目前按不加班的1天=8小时的工作时间，是的，没有算加班时间：），如下图：当然，我们也提供了相对估值法的故事点，如下图：               4.  关于Task的使用误区。         a）把什么都当Task。Task是为这个迭代服务的，是必须有产出。学习了什么这个不可以算作这个迭代的Task。         b）把有些不当做Task。搭建环境，准备代码库或代码分支，验收，刷新自动化测试用例，这些都是要算Task的，不是只有写代码才算Task。    5. 准备会议时，Must的UserStory的总量不能超过备选Backlog总工作量的80%，如果备选Backlog都是Must的UserStory，失去了优先级排序的意义了。    6. 准备会议时，Must的UserStory的总量不能超过团队容量。    7. 整个迭代会议，建议使用专业的敏捷协同管理工具，大家看到内容一致，大家刷新调整后的内容也一致并即刻生成，会议结束的同事，一份本迭代的UserStory/Task列表就生成了，也不用会后再去整理。下面是我们所在的团队最近的一个迭代计划列表例子：         写在最后的要点总结：迭代会议事先准备很重要过程中鼓励团队成员自主Pull，而不是一味着的Push相信团队，相信团队对工作量的估算，给团队以尊重，工作量不要压得那么慢，超出人力容量的迭代，质量很难得到必要的保证。   4. 如上的三个原则其实不仅仅适用于迭代计划会议，其实也适用于软件开发过程中的很多活动和会议。希望能帮助大家开一个开心，高效，信心满满的迭代会议：）至此，软件迭代开发中三个最基本的活动：迭代计划会议，每日站立会议，迭代回顾会议，都介绍完了。我一时没有想到要分享些啥，大家还想了解些啥，可以评论中留言。

【产品经理-全连接系列 之006】华为敏捷/DevOps实践一点一滴_如何从Excle管理软件的方式中走出来 大家好，我是华为DevCloud 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f） 作为布道师和产品经理，出差各地接触客户是常态，线下和华为云的客户交流、布道、技术沙龙。 但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和实践。 <恒少出品，必妥妥干货，必理论联系实践> -----------------------干货分割线--------------------------------------开篇小段子：业界有个小段子，研发不是请客吃饭，是倾家荡产。是的，研发人员，尤其是从事软件的工程师门，普遍是比较傲娇的，在软件产品没有卖出去形成收入前，软件工程师的投入都是刚性成本。所以，为什么很多软件企业的老板对于敏捷，DevOps其实并没有深入了解，但是依然很欢迎呢，因为“快”这个词吸引了他们，早一点把软件交付给客户，形成收入，才能让他们早点给软件工程师付工资和薪水啊。对了，软件工程师需要的基础设施（空调，办公位，服务器，计算机，云主机，云存储，各种研发工程工具）也都是很大的一块刚性成本。交付晚了，可能真的倾家荡产，血本无归的。。。 软件工程师是宝贝，所以华为其实一直坚持，尽量让这些傲娇的宝贝疙瘩们，不要做一些低价值，重复性的工作，浪费钱，也浪费软件工程师建造数字化世界的激情。^_^ 我相信，没有哪个软件工程师希望整天整Excel表格的（可以参考我前面的那个文章，请运营同学附一下之前的文章链接），因为整Excel表格其实挺无聊低效的。 如果不幸在用Excel管理软件项目了，本文希望能提供一些方法来一步一步迁移 根据笔者的经验，可以分场景来看看现在专业的敏捷协同管理的工具具备哪些能力，是如何替代覆盖Excel的。 如果正在使用Excel管理需求。软件产品的需求永远是需要管理的，而需求往往是需要分配给不同的成员去交付，并且希望跟踪需求的进展，是不是在开发中了？是不是可以部署到现网了？因此这个场景是一个多人协作，集中呈现管理的场景，需求管理切忌你看到的和我看到的不一样，所以不能使用本地的任何文件来管理，因为你改了，别人可能就不是最新的。因此这个时候，应该优先选择一个云端的敏捷需求协同管理软件，不要小瞧现在业界的主流需求协同管理工，类似excel的列表模式，早就非常普遍了，比如可以像Excel那样过滤，排序，还可以多字段过滤，过滤条件可以保存为常用，换任何电脑都能继续使用；需求作业流是可以流动的，可以从一个状态换到另一个状态，一个处理人再交给另外一个处理人，这个用Excel这样平面表格处理起来有些麻烦；需求的分解很轻松，快速新建子需求/子工作项，父子需求关联，需求依赖一览无余，通常还预置了业界通用的需求类型（Epic/Feature/Story/Task）;修改需求的状态，分配成员，简单勾选即可，自动联想或搜索，很高效；还可以在线的社交评论，对需求的意见都可以公开在线讨论；需求的状态变化，处理人或项目经理还可以收到站内信或邮件通知；同时还可以查看操作记录，谁在什么时候改了，改的啥一目了然。这样，办公室再也听不见“那谁谁，你最新的需求Excel给我发一下了“，因为最新的永远在云端，你在任何有浏览器的地方打开就可以了，也包括手机。无图无真相，以华为云DevCloud为例，有可拖拽的需求卡片模式，还可以随心切换列表模式。--------如果正在使用Excel管理迭代计划。无论敏捷迭代，还是瀑布里程碑，软件的开发总是需要一个计划的，给老大，投资者，客户以期望，在这个Big      Bang的时代，软件工程师好贵的时代，不可能让你一个劲的放飞自我。计划管理无非就是什么时候交付什么需求或解决那些问题，软件的计划至少得有个开始时间、结束时间和计划交付的内容。Excel可以做的，但是每个计划时间内的需求或缺陷，要引用其他Sheet页，表格引用挺麻烦的，而专业的敏捷软件，很简单的，建立项目的迭代计划，将需求安排到迭代计划，很简单就知道每个迭代计划要交付哪些了。我使用一个华为云DevCloud的迭代图当例子，如下。作为曾经的Excel的扫地僧，我是真喜欢这样的迭代计划：）如果正在使用Excel管理缺陷。软件的不可见性和复杂性，决定了软件缺陷是软件生命周期管理永远需要妥善管理和跟踪的。<插个话，不知道AI出来后，能不能破软件不可见性和复杂性的这个百年困局，啥时候有集中的大段时间，是可以写写AI对于软件开发可能带来的正面和负面影响>。扯回来，一般用Excel管理缺陷，就是一行行的记录缺陷，列都是描述定义缺陷的字段：谁发现的？什么类型的缺陷？计划什么时候解决？由谁解决？缺陷当前的进展。如果正在使用Excel开回顾会议之类的。记录一些遗留问题啊，风险啊。这还是一个多人协作的场景，遗留问题总得跟踪解决吧，Excel只有进入多人协作场景就会有些不便利，这时候，可以使用wiki这样的多人协作，轻量级的在线文档协作，团队成员看到的都是同一份，遗留问题的进展自己更新自己的。当然也可以使用很多敏捷协同管理软件提供的看板，建个跟踪任务，管理团队的日常事务也妥妥的方便。华为云的DevCloud也提供很丰富华为实践的Wiki模板，有了通用的模板，格式和标准就可以批量继承重复使用了，如下图：如果正在使用Excel管理测试用例。测试用例至少需要用例名称，编号，执行用例的责任人，前置条件/后置条件，测试步骤，测试预期结果等，而且很多时候自动化的测试用例要能快捷的生成测试执行的脚本的，运行一个测试用例很多时候需要执行很多测试脚本，因此通过Excel管理的测试用例除了记录测试用例外，几乎不具备执行的可能。所以测试管理使用Excel其实并不是适用，现在很多研发工具软件都有专业性很强的测试用例管理，并和测试执行打通。如下图是华为云DevCloud提供的手工测试用例截图，肯定还是比Excel管理起来要人性化多了如果正在使用Excle管理代码提交。通过Excel管理代码提交，我最初听到时，是非常震惊的，绝不夸张，下巴还好没有掉。我这大半年跑了国内很多软件企业的客户，还真听说有客户就是在用Excel管理代码提交的，因为没有专门的代码配置管理工具，开发人员也不多，就直接把代码合并到代码文件服务器上，因为是文件服务器，不知道谁提交了哪些代码段/代码行，就让开发人员填写Excel。毫不留情的说，我个人是非常反对这种做法的，应该尽快使用专业的代码配置管理工具或代码托管的云服务。代码是软件的核心，代码的关联是严肃、严谨、严格、严苛的。任何商业化交付的软件，都应该尊敬代码。别再用Excel管理的代码提交记录，来吓我了：）写在最后，诚然Excel依然是目前最好用的表格办公软件之一，但是在软件研发这个专业的领域内，把自己花费在Excel上的时间交给更专业软件工具，是更尊重自己这么多年摸爬滚打的正确姿势。 而且，时代真的在变化，现在市场上的各种专业的敏捷、DevOps的工具服务，已经在很多企业得到广泛的应用了，如上面介绍的主要Excel场景，都已经稳稳的支持得更好了。 为了让你的价值得到更大的发挥，可以尝试从Excel中一步步走出来。 软件工程师是数字世界的构建者，加油，致敬！

人类生存于一个虚拟的、数字化的生存活动空间，在这个空间里人们应用数字技术从事信息传播、交流、学习、工作等活动，这便是数字化生存。”--尼葛洛庞帝!21年前，尼葛洛庞帝在写下《数字化生存》一书时，谁都不会想到，书中所描绘的未来生活方式与今天如此相似，预言已然成真。如今，数字化转型已经成为席卷全球的新趋势，人人都在讨论数字化转型，因为数字化转型并非是一种选择，而是唯一出路。据Gartner的预测，到2017年25%的公司将因数字化能力不足而丢失业务。IDC的预测，到2027年，标准普尔500公司中将有75%被顶替出局。普华永道在调研了全球350位CEO后发现，80%的CEO认为企业数字化转型是第一考虑要务。当年诺基亚在最风光时期市值高达2540亿美元，让人大跌眼镜的是，最终却被微软以70亿美元左右的价格收购。究其原因，只因为这个世界在变，它却没有紧跟数字化转型的脚步。显然，企业必须确保比竞争对手更加敏捷、快速地响应迅速变化的数字化市场，才能赶上或者超过竞争对手，才可以在新时代下的市场中称雄。如果企业忽视数字化的作用，那么它将不可避免的陷入被淘汰的命运。敏捷和DevOps是数字化转型的关键什么才是“数字化转型”的正确姿势?CA Technologies的一项最新全球调查结果显示，89%的中国大陆受访企业同意敏捷及DevOps方案是致胜数字化转型的关键。当前，数字化大时代下企业面对的商业环境瞬息万变，各种新技术突飞猛进的同时，新业务形态越来越复杂、需求变化越来越快、软件规模越来越大、交付周期越来越短、开发和维护成本越来越高，产品交付的风险急剧增加，传统研发模式无法适应快速变化的市场需求。为了应对这些挑战，业界软件开发模式经历了持续的改进和变迁，从20世纪60年代作坊式开发，到80年代过程控制模型，到2001年敏捷、DevOps模式探索。敏捷开发就是最适合应对转变的最优软件方法论，并被微软、华为、BAT等公司的开发人员广泛使用。而整合企业IT部门的软件开发与运维，实现开发与运维的一体化DevOps，则变得比以往任何时候都来得重要。敏捷和DevOps落地需要成熟工具的帮助虽然敏捷和DevOps是近几年来软件开发领域最火的词，但网上搜索，其实真正成功的案例并不多。显然大多数企业还徘徊在外，不得其门而入。总结各种失败的原因，要推动敏捷和DevOps的落地生根，不仅要有相融的企业文化、领导支持、客户配合，还需要一系列成熟的工具平台来帮助企业的转变，否则数字化转型就只能是空中楼阁。目前，网上敏捷和DevOps工具非常多，但大都比较分散单一，缺乏统一的一站式解决方案。不过，好在去年开始，国内企业终于不再缺席这个领域了。华为软件开发云(DevCloud)就正是这样一个工具平台。众所周知，作为排名第129位的世界500强公司，华为在研发管理方面非常领先，而DevCloud正是基于华为近30年的研发实践，结合敏捷、精益、DevOps等先进研发理念，面向中小软件企业、软件外包企业、双创企业、互联网企业、高校和广大的软件开发者提供的一站式云端DevOps平台。这套工具可以大幅度提升软件研发的效率：以前华为每个月1亿行代码的编译时间，由原来的25分钟缩短到7.5分钟，版本级的编译速度也由94分钟缩短到31分钟。从产品层面来看，软件开发云提供了“项目管理-配置管理-代码检查-编译构建-部署-测试-发布”等全生命周期服务，不仅能帮助企业实现一次开发、快速部署、快速迭代、快速反馈、持续开发集成与发布、多版本共享等数字化转型需要的敏捷开发能力，还能让企业获得开发与运维的高效融合，从而实现真正的开发与运维一体化，即DevOps，是真正的一站式服务。DevCloud上敏捷和Devops特性的具体表现说了这么多，DevCloud到底提供了哪些手段来保证企业能够实现敏捷/Devops开发?这是个关键性的问题，而回答这个问题需要从华为敏捷项目管理实践说起。(注：PD，是Project Director的缩写，项目负责人)通常我们熟知的敏捷开发流程可划分为准备、计划、开发、反馈四个阶段。一、准备阶段(可选敏捷模式)：使用软件开发云为敏捷项目管理工具，项目的开发流程可选创建“Scrum流程”项目或“精简流程”项目两种。精简流程项目是比敏捷模式更简洁的模式，适合小、微团队和个体开发者。二、规划阶段(Story划分)：Story划分是敏捷开发的标志之一，一个需求的接收，就是从Story的划分开始。Story划分并不是告诉开发人员一个需求怎么做?更多的是告诉开发人员一个需求为什么要做?需要做成什么样?实现什么样的价值。软件开发云支持“Story” 创建，“项目规划”下创建的“Story”会同步到“Backlog”的需求列表中。在每个Spring启动前，按照优先级排序的Story制定迭代计划。三、开发阶段(代码质检、自动化持续交付)：软件开发云可在线进行多种语言的代码静态检查、代码安全检查(如未授信访问)、编码问题(如空指针引用)、圈复杂度、重复率、编程风格，只有在问题清零才允许构建出包。与传统敏捷模式强调持续构建CI不同的是，融合了DevOps理念的新型敏捷模式，通过云端自动化的持续交付流水线，实现持续构建、持续测试(功能、接口、性能、可靠性等，据说能实现100%自动化)、持续部署(包括脚本自动下发、比对、蓝绿部署)、持续发布(灰度发布)、持续反馈，可将Ops端手工操作的时间减少80%，全功能团队可以聚焦于业务分析、开发交付及运营上，显著提升效率和产品质量。代码提交时按照规范备注Story ID，即可将代码关联到对应需求上。创建测试用例和缺陷时，也需关联需求，这样就实现了“需求-代码-用例-缺陷”的双向追溯。四、反馈阶段(质量回溯)：通常反馈阶段主要开展验收和回顾活动。这里需要重点提到质量回溯会议，对应于敏捷迭代回顾会议，是华为持续改进的实践精华。质量回溯，这个词，在华为是一个高频的词汇，华为为了持续改进质量管理体系、提高客户的满意度，在公司内部提出了质量回溯的概念。质量回溯重点在于分析问题根因，并识别出管理、流程、技术、工具上可落地的改进点。这些改进点每一个都必须符合Smart原则，是可落地、可执行的，不能出现大话空话套话。而且这些问题都要求最晚在下一个迭代中，执行落地，以避免问题再次出现。小结总的来说，企业数字化转型，关键就在于敏捷和DevOps的落地。在工具平台选择上，相比企业基于开源工具或者商业工具建立工具平台，不仅成本高昂，可靠性难以保障，还存在安全的隐患。DevCloud对中小企业而言，显然会是一种更好的选择。不过，虽然软件开发云是华为基于本身长期实践的成功结晶，是神器级工具平台。但是，并不是使用了平台，就可以期待奇迹的发生，它毕竟只是个工具。敏捷和DevOps的落地是需要企业做出真正的组织变革。否则敏捷和DevOps也就无法实现。据悉，未来几年，华为将重点推进软件开发云3个“1”工程落地，3个“1”指的是服务100万个软件开发者、服务于10万家软件企业来使用软件开发云、服务1000家院校、培训机构。就华为实力及影响力而言，这显然并非太困难的事儿。也许未来某一天，华为软件开发云真会成为国内企业级主流软件开发工具。

什么是 DevOps如今 DevOps 已经成为一个流行词，很多公司都在说自己在做 DevOps，但是每个人、每家公司理解的 DevOps 又不尽相同，从 DevOps 诞生的第一天起，如何定义 DevOps 就是一个争论不休的话题。这里有一篇文章，笔者认为基本诠释了 DevOps 的定义：DevOps 是什么不是什么如果你没有耐心把这篇文章看完，维基百科还给出了一个太长不读版：DevOps (a clipped compound of “development” and “operations”) is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals.It seeks to automate the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.归纳成三点：DevOps 是一种强调沟通与协作的软件交付过程。它包括产品管理，软件开发及运营等各个方面。DevOps 自动化软件集成，测试，部署以及基础设施的变更。它的目标是建立一种文化和环境，使得软件的构建、测试、交付更快，更频繁，更可靠。这里我想多提一句的是持续交付和 DevOps 的关系和差别，参照维基百科 对 DevOps 和持续交付的区别进行解释，DevOps 涵盖的范围比持续交付更宽，它包含了文化，强调团队协作和自动化；而持续交付侧重于频繁、快速 地执行交付流程，两者相辅相成，却又有所区别。Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery.Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.DevOps 理论框架因为 DevOps 源自草根，缺乏自上而下的理论支撑，所以如何定义 DevOps 成了 DevOps 社区里面的一个大难题。一些 DevOps 从业者，纷纷设定自己的 DevOps 框架。其中比较有名的框架有Damon Edwards 所定义并被 Jez Humble（持续交付作者之一） 所修订的CALMS，和 Gene Kim 所定义的 The Three Ways。The Three WaysThe First Way： System Thinking （系统思考：强调全局优化，避免局部优化）The Second Way： Amplify Feedback Loops （经过放大的反馈回路：创建从开发过程下游至上游的反馈环）The Third Way： Culture of Continual Experimentation And Learning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通）CLAMSCulture – 文化：公司各个角色一起担当业务变化，实现有效协作和沟通；建立包括运维在内的跨职能协作文化,具有共同目标的一体化团队。这是DevOps运动的根本Automation – 自动化：在价值链中尽量除去手工步骤；自动化一切可以自动化的步骤，降低部署和发布的难度Lean – 精益：运用精益原则更频繁地交付价值；以精益的方式小步快跑，对过程与技术进行持续改善Metrics – 度量：度量并使用数据来优化交付周期；通过建立有效的监控与度量手段来获得反馈,推动产品和团队的持续改进, 支持业务决策Sharing – 分享：分享成功和失败的经验来相互学习。为什么要实践 DevOps更短的交付周期，生产环境部署频率越来越快，简化生产部署流程，且自动化不停机部署更高的价值，形成特性提出到运营数据、用户反馈验证的实验**付闭环，基于实际用户反馈调整计划和需求更好的质量保障，在代码检查，功能和非功能验证，以及部署各方面建立较完善的质量保障体系，尤其是自动化测试集更高绩效的团队，包含业务，开发测试，和运维职能在内的一体化团队，以产品交付为共同目标紧密协作，共同承担责任DevOps 在技术领域的实践DevOps运作包括文化（全功能，自运维）和技术（自动化，度量反馈）两方面，而技术能力的改进主要关注以下六个领域：内建质量体系通过持续代码评审，静态分析，自动化测试，自动部署验证等手段构成一套有效的质量保障体系。主要实践包括：TDD：测试驱动开发的思想，保证代码质量和不偏离业务需求的技术实现结对编程和代码审查，依靠团队的自治性让团队成员互相监督和审查代码质量自动化测试，高自动化，且高频率运行的测试，保证测试用例质量的同时保证了交付软件的质量持续部署通过自动化的构建，部署过程快速频繁地将软件交付给用户，提高吞吐量；同时保障过程的安全，平滑，可视。主要实践包括：在已经做到持续集成的情况下，引入持续部署，每次提交均会出发构建并执行部署蓝绿部署，用于实现零宕机发布新版本金丝雀发布，用于使应用发布流程具备快速试错的能力持续监控持续对运行环境在系统，应用层面进行监控，及时发现风险或问题，保障系统运行的稳定性。主要实践包括：监控预警，在项目开始初期就引入监控，让整个团队实时能够收到关于产品各个维度数据的反馈日志聚合，便于错误追踪和展示分析，利用搜集到的数据实时分析，利用分析结果指导开发进度度量与反馈通过对用户行为或业务指标的度量或反馈收集，为产品的决策提供依据。主要实践包括：持续集成反馈，对代码构建质量，代码质量审查的反馈测试反馈，对软件质量，功能性的测试，给到业务的反馈运营数据反馈，新功能上线后对业务影响的反馈，用于指导业务人员提新的需求环境管理通过对服务器环境的定义，自动化建立和配置、更新等提高基础设施管理的效率，一致性，并更有效利用资源，可伸缩的架构，保证服务的健壮性。主要实践包括：弹性架构，保证服务的吞吐量和具备灵活变更的能力自动化部署脚本，想胶水一样，用于解决一些工程实践不够完善的流程之间的衔接基础设施即代码，用代码定义基础设施，便于环境管理，追踪变更，以及保证环境一致性松耦合架构对传统应用架构进行领域组件化，服务化，提升可测试性和可部署性。主要实践包括：采用弹性基础设施，比如公有云服务或是 PaaS（Platform as a Service） 平台构建为服务应用引入契约测试未来 & 趋势DevOps 话语权越来越多被平台厂商掌握在 DevOps 实践的第一阶段，往往会是 Jenkins, Nexus, Ansible, Shell 等一系列工具的拼凑组合，上手难度大，维护成本高，开发体验不好。随着 DevOps 日渐成熟，以 AWS、Pivotal、RedHat 为代表的一些公司分别退出自己的 “DevOps产品”，或是一套完整的工具链，或者直接整合到一个 PaaS 平台，甚至一些产品直接将“敏捷”，“精益”的概念也整合到产品中，直接可以把一家公司的全部业务放到平台上，这和最近大热的“数字化平台战略”也是相吻合的。不管怎样，这些平台厂商一边卖自己的产品一边重新定义着 DevOps，随着平台的完善，DevOps 已经变得越来越不重要，我一直觉得最好的 DevOps 团队应该是“润物细无声”的，就是一个团队不用提 DevOps，整个团队很自然地就能关注到业务价值的交付，且能有序地按照高质量，高效率的要求去做，平台或许能帮助我们做到这一点。容器化 & 微服务仍然是 DevOps 应用和发展的主要领域容器化、微服务天然适合小而全的功能团队，且一个个自治的服务也很复合 DevOps 端到端交付团队的设计，近年随着容器化技术（Docker）的发展，容器管理（Kubernetes）的日渐成熟（据悉，github 已经将它们的一部分产品环境灰度发布到了 kubernetes 上，京东也将他们的服务百分之六十采用了 kubernetes 管理），DevOps 和微服务成为了相辅相成的两个趋势。安全成为推动 DevOps 全面发展的重要力量安全是 DevOps 永远绕不开的话题，也往往是新技术在传统行业（例如金融和电信）应用中的最大阻碍。一方面，组织结构的转型迫使企业要打破原先的部门墙，这意味着很多原先的控制流程不再适用。另一方面，由于大量的 DevOps 技术来源于开源社区，缺乏强大技术实力的企业在应用相关技术时不免会有所担忧。DevOps 全局优化的特点与安全社区提出的 “Build Security In”也特别吻合，加之越来越多安全易用的工具涌现，DevOpsSec 会越来越被人们熟知。出处：杜屹东的博客来源：https://www.duyidong.com/2017/07/14/what-is-devops/

点击下载完整版PPT《华为云DevCloud大咖分享汇总（附PPT下载）》

【产品经理-全连接系列 之005】华为敏捷/DevOps实践一点一滴_如何开好一个敏捷回顾会议      大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）       作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上 -----------------------干货分割线--------------------------------------开篇小故事：前几年，一本叫《沉思录》的书在国内突然曝光度很多，因为前某国家领导人“摆案头，读百遍”。《沉思录》是古罗马皇帝马可·奥勒写给自己的书，内容大部分是在鞍马劳顿中写的。其实有一句“我们所听到的不过只是一个观点，而非事实     我们所看到的不过只是一个视角，而非真相” 全员都参加的回顾会议，其实就是希望能通过全员视角，全员的观点来回顾做的好的，做的不好的，改进之。从敏捷宣言，到敏捷的诸多实践（如Scrum），到DevOps，都一直提倡回顾这种形式。 其实回顾这种形式，并不是敏捷/DevOps专属的，在华为最早的CMM流程中，也有类似的活动。有时候团队碰到域郁闷，痛苦的时候，还会主动自发的开。 所以，回顾，我一直认为这是人类作为一个智慧物种相比其他生物的一个重要区别。我有的时候回通过回顾会议来判断这个团队会不会成功。最极端的，如果甚至都没有人想着要约大家一起回顾，这个团队极大概率要88了。 华为内部不仅研发交付团队，连一线的市场团队，在重大的市场项目，交付项目的过程中都会定期进行回顾会议，算是华为内部这么多年积累的一个很好的实践。 必须鲜明表达的观点——回顾有三个不是不是“回溯”。“顾”和“溯”一字之差，在中文的语境中，却会导致变成刨根问底。不是“批评与自我批评”。“批评与自我批评”是一个很好的形式，但是会导致团队陷入一种不必要的紧张和犯错感。不是“问责和处罚”。软件的不确定性，不可见性，复杂性，易变性决定了软件开发过程总会有些磕磕盼盼，我们提倡的是改进，不是惩罚从华为这么多年的实践来看，上面的三种情况都出现过，所以提醒大家要小心。 这么些年实践过来，我们发现出现以上情况，也是因为步子走得太快，低头玩手机^_^，忘了“回顾”的初心：For a better future;Learn from past;Take action in present. 回顾会议的基本原则对事不对人。举个例子，我们可以说“代码评审不充分，所以代码缺陷较高”，不能说“某帅哥评审不认真”，当然夸人帅还是可以的哈^_^。聚焦于下次能否做得更好。还举同样的例子，我们可以说“这个迭代代码评审不充分，下个迭代我们怎么才能保证更充分的评审”。从系统角度思考改进，而非个人。我们可以说“团队的工作安排上，导向上是不是不重视代码评审？”。 回顾会议的Step by Step确定参与人（Who）团队所有成员都参加。领导是否参加，试情况，如果领导参加利大于弊，就邀请，否则还是算了^_^如果是重大的项目发布或项目结束的回顾会议，还应该叫上所有对项目有付出的成员。建议指定一个会议引导人，可以是敏捷教练，也可以是团队成员轮流（团队成员建议熟读本文）选择合适的场所（Where）如果条件允许，离办公位尽可能远一点，避免有同学中途又回去处理工作了尽可能不要使用传统会议室的布局，围坐一个大桌子那种不好。可以拉几把椅子围成一个半圆形。需要有白板，或者墙壁可以贴个大白纸   3. 准备回顾的内容（What）      a) 准备上个迭代的客观数据，特性、需求、缺陷等数据，如果使用了像DevCloud这样的敏捷管理工具，准备数据其实很快的，甚至不用特别准备，现场打开就可以，类似如下这样           b) 团队成员上个迭代的感受，可以认为是主观数据的收集。      c) 每日站立会议的要点。每日站立会议中都会提出并跟踪解决一些问题，回顾这些问题也可以帮助我们审视过程中的情况。恒少之前专门写过如何开好站立会议的实践文章（此处应附上对应渠道的链接），可以参考      d) 准备一个规则，会议开始前贴出来或打印出来或投影仪投出来。规则是为了保证会议的纪律和效率，比如不能随便打断别人讲话，每人发言时长，会议时长（建议10~12人的团队，限定在1小时内）  4. 回顾会议的过程（How）        a) 准备和引导——明确目标。重申回顾会议的目标和原则，让成员重拾回顾的“初心”，发布公示如下的回顾宣言，重申会议纪律，时长。准备和引导环节是让大家放下手机，进入回顾会议状态的必要环节，无论开过多少次，都不应该省掉。                b) 数据、过程的回放——建立共同的全景。展示本迭代的度量数据，如果有使用类似DevCloud的敏捷管理工具，可以直接打开系统。全景的数据展示回顾，让视角更全面。对于一些“历经劫难”的迭代，可以画一个时间线，把这个迭代发生的重大的一些事件按照时间顺序展示出来，帮助团队成员回顾都发生了什么        c) 提出见解——我们如何才能做得更好。可以通过头脑风暴，全员参与，有很多种分类的方法，如下图中是分为“Good”（下个迭代哪些好的方法可以继续保持），“Could Better”（下个迭代可以哪些地方可以做得更好），Improvements（新的改进的具体想法）。可以采用“有限投票”的方式，每个成员有5票（比如小磁贴或直接记正字），大家共同团队层面需要重点改进的。其实投票未排进Top的改进，如果不需要组织和团队来推动，个人也可以实施的改进，也应该支持。              d) 确定措施——想清楚就干，才有诚信。识别了重点的改进项，为每一个改进项指定计划，执行的措施，需要更高层面去解决的措施需要单独列出来，项目Leader会后要发挥“死缠烂打”的精神去骚扰领导了，同时每个改进措施都应该明确一个责任人，如果没有明确的责任人，大家都会认为是别人的事情。       e) 结束会议——果断结束，绝不拖泥带水。将会议中达成共识的措施和计划整理记录下来，如果使用了敏捷管理的工具系统，可以直接输入到系统中，记录为Story或者任务。 来自实践中的一些坑和雷不持之以恒。那什么几天打鱼，几天晒网的可不行。恒少，恒少，就是能持之以恒，哈哈。理想主义。团队级的回顾会议应基于现实，而非理想，或者说理想可以有，诗和远方也可以有，但是回顾会议还是应接地气。沉迷于细节。程序员有的时候特别认真，容易把问题引入到技术细节，这样会导致议题发散。只开会，没有吃的，好饿。皮一下，为了调节会议氛围，可以准备些吃的，补充能量，大脑才能激发 最后的最后，每个迭代回顾会议，都不要忘了感谢辛苦码代码的自己，也不要忘了感谢为了心中教堂而努力的所有团队成员的。

大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上-----------------------干货分割线--------------------------------------例行的开篇小故事：在西方的传统传说中，狼人可以说是比较可怕排行榜靠前的，除了破坏性大，还有出乎意料性，传说月圆之夜，会出乎意料的从熟悉的正常人变成可怕的怪物。软件从诞生那一天前，就注定是个“狼人”。比如，好好的程序内测测试环境验证OK，可是一上线到生产环境，问题不断；再比如，项目规划的好好，需求分解得好好的，每个人的任务都安排的妥妥的，可是就是延期，延期，延期….—— 软件是狼人，来自《人月神话》的《没有银弹，软件工程的根本和次要问题》正文开始啰嗦 很多小型的软件企业，都比较喜欢用excel类似的办公工具来管理软件项目的需求，缺陷，进展，风险和人员。所以，时不时有些同学会觉得，Excel也是可以妥妥的制服软件这个“狼人”。但是从我个人的经历来看，很早之前的我可能会认同这个观点，但是现在的我，比较大不认同这个观点。有人会说，你又在装“老红军”：）嘿嘿，就从我在华为亲身经历的，参与的，旁观的，变革的众多软件项目的一些经验，不成系统的扯扯。首先，必须得100%承认，几大平台的主流办公工具，都是异常优秀的，如微软的office系列，Google的Docs系列，，Apple的办公套件（Keynote，Numbers，Pages）。基本的办公软件相当长时间都是是刚需，在各个行业都有非常广的应用。Excel早期在华为也有比较多的应用，华为内部有不少Excel高手，可以通过Excel内嵌的功能，做成非常强大的数据透视，数据报表，牛逼的不行不行。连我这样的小咖，都会玩各种Excel的小工具，让我得了不少华为的QCC奖励（Quality Control Circle，一种从基础组织发起的自我改进）。当时业界还没有专门用于软件管理的工具，我们的项目运作，也确实主要通过Excel的，记录所有的需求以及需求的分解，需求的责任人，需求的进展，缺陷的进展，风险的进展，甚至形成了大量的Excel模板，下个版本或项目通常还可以继续使用。后来，随着华为开始集团级的引入敏捷开发，工欲善其事必先利其器，业界也与之匹配的出现了更专业的敏捷协同和管理工具，承载了敏捷的思维（Mindsets），价值观（Values），原则（Principes）和实践（Practices），华为的敏捷，乃至DevOps变革之路，也伴随着研发工具的变革<插个话题：我经常叨叨：从IPD，敏捷，DevOps，每个跨代的研发理念和实践的落地，在华为内部都是当做变革（Transform）去对待的，变革最难的是什么，变革最难的是“对既有利益集团的破局”，中国的**这样，研发的变革也是如此。>所以，客观的说，我们还是花了些时间，最终实现了越来越少使用excel、越来越多使用专业敏捷、DevOps工具的变化的，现在华为内部无论大小项目，首先使用专业的敏捷管理工具服务是一个默认的习惯<华为内部早已经实现了工具的云化/服务化，一站式使用，Web访问/App访问即可，Anywhere, Anytime, 非常便利>这个过程的变迁，发生的悄无声息，也从没有想过为什么，因为有论坛用户问，我就整理了一下，分享几个可能比较片面的观点：因为专一，所以精彩。随着敏捷在全球的应用，用户越来越多，敏捷实践越来越来丰富，专业的敏捷协同和管理工具也在持续的完善，越来越懂敏捷软件开发，越来越懂开发者。因为通用，所以无法在每个细分领域都做到最懂。Excel多年的发展，功能越来越强大，尤其是Office365 云端提供后，便利性更好，但是它始终是个通用的表格数据软件，它甚至很多时候更懂财务，但是始终谈不上最懂软件开发。不是最懂又会导致什么呢？体验不到软件开发新的理念、方法和实践。大量的新的软件开发实践，无法通过Excel来体验，比如看板的方法，Scrum的燃尽图，思维导图的规划需求。如果外面的世界更精彩，去软件行业其他企业应聘，经验中有通过excel管理开发项目或被Excel管理，在业界总不能算是一个应聘的加分项。开发人员会觉得管理方式比较Low。Excel管理软件开发，通常会把开发人员当成一个萝卜一个坑，开发人员会觉得自己只是一个绿色表格中的一个选项，而缺少开发人员的主动反馈和互动，这也是为什么很多的专业工具都让开发人员可以评论，可以@，大家对于需求的安排、需求的进展可以动态的反馈和社交讨论。敏捷的理念，重视协同，看板的价值观中也在推荐开发人员Pull任务，而不是Leader 单纯的Push任务。软件开发至今还是智力活动，智力活动需要激发，需要协同，交流，软件开发人员不能当成生产线的装配机器人，虽然很多企业管理者都梦想这样。。。：）单机版不利于团队共享试用。“那谁，最新的需求Excel表格给我发一下”，“那谁，你刚刚更新的缺陷Excel表格发给我没有？”，“那谁，你这个表格不对吧，我昨天更新的需求状态被你覆盖了”，“那谁，你这个表格不是不是最新的”，“最新的风险表格在哪儿？”，“项目例会上，这个表格不是最新的，最新的在我电脑那儿，你等一下，我发给你，然后大家都等啊等”，“张三，李四，王五，你们更新一下表格中的需求状态，邮件发给我啊”，“张三，李四，王五你们更新的表格没有发给我啊，等等，哦，我收到你昨天邮件了，哦，李四你没有使用张三最新的啊”……..，如果团队超过5个人以上，使用Excel管理需求和项目，以上场景很常见吧？我不知道你会不会烦，我当时做项目经理，带团队时，最讨论，最烦就是这个，因为Excel是文件传递，只能通过邮件或者社交软件传递，经常冲突，经常使用得不是最新的，我还得从邮件拆附件，从社交软件拆附件，从其中挑选最新的行，一个个的合并为最新的Excle表格。我觉得这是在浪费生命，也对不住公司聘用我的成本啊，公司聘用我不是让我整理表格的啊：（。不利于并行协作。Excel文件可以以云盘或者文件服务器的方式或者代码库集中存储，团队成员可以修改同一个地方的文件，虽然可以一定程度解决上面的问题，但是通常而言，是文件级的锁，一个成员修改，其他成员是无法并行修改的，如果某个成员编辑一半，没有提交，其他人就等啊等啊。而专业的工具其实基于工作项粒度（Epic，Feature，Story，Bug，Task，需求）来控制并行修改的，这样并行修改的效率更高，即使不同的人修改同一个工作项，基于数据库的事务性，也会让用户基本无感知且保证事务性和一致性。微软最新的Office365，是云端协同，华为内部也使用了，但是从解决多人协同的冲突上，依然还是无法适用软件开发过程，因为它始终理解的只是一个表格中的行，列或者格子，而专业的敏捷工具它们理解的是工作项、迭代这样的软件对象。不利于自定义、升级和统一。如果需要增加需求的一个属性，得修改需求的Excel 模板，修改后还得通知所有的团队成员，更新为新的模板，尤其是单机版的Excel，让团队统一为新模板，劳神劳嗓子也劳键盘。而现在的云端的敏捷管理工具服务，都提供了丰富的自定义字段的功能，一次修改，全员都可以马上使用，不用耗费时间在统一新模板上了。不利于形成研发作业流。软件开发就像一个流，规划，需求分析，方案设计，代码编码，测试，缺陷解决。。。，而Excel只是一个或多个文件，本身也不是作业流，也没有承载作业流。久而久之，会让所有软件开发成员，认为软件开发就是围绕着几个Excel文件在工作，无法畅快的体会作业流，无法体会到需求不断交付上线的感觉。不利于和周边系统的集成。一般软件企业里面总有一个集中的员工管理系统，通常也有编译构建的工具系统，Excel作为一个办公工具，和这些系统的集成有许多天然的困难，无法通过Excel看到需求有哪些测试用例，这些测试用例执行的情况如何，员工的新增或离职，Excel中业务无法自动同步，Excel需求分配任务给这些员工就会失效或者找不到人。诚然，很多高手，可以把Excel这样的办公工具发挥到极致，无限接近，但是这样的高手其实还不如让他去投入真正的产品的开发与交付呢：），能把Excel玩出高水平的软件工程师，大概率都是高水平的程序员：）当然，并不是敏捷管理工具说可以完全替代Excel，Excel这样的工具在数字的统计分析上，有着其强大的功能，对于纯粹数字的分析、归类、透视，可以把需求、缺陷等数据从专业的敏捷工具中导出，在项目结束后，加以数字的分析，也是一种很好的互补。华为这么多年研发效能的持续投入，积累了丰富的实践经验，这背后有一个基础的理念：软件研发工程师是宝贵的（说直白点，成本挺高的，真贵o(*￣︶￣*)o），学历都不低（说直白点，还很傲娇，^_^），吸引优先人才竞争还激烈（不爽就键盘党狂吐槽，或者另谋高就(#^.^#)）。所以应该让广大的软研发工程师去专注业务的规划、交付，让他们做有价值，有挑战，让他们感觉有成长的事情，而不是让他们成为工具的仆人。始终给他们装备最懂软件开发，最懂开发者，最高效的，最少操心的研发工具，才是正道。如果把研发团队比作作战团队，应该让他们使用最先进战场装备，而不是让他们自己去研究定制一个坦克，他们只需要提需求给专业的服务商就可以了。像华为这样想的企业，越来越多。所以现在业界有很多像DevCloud这样的专业的敏捷管理工具服务，运行在云端，Anywhere and Anytime 可以使用，同时还有专业的团队来提供专业的服务，他们更懂软件研发，更懂开发人员的苦恼，更懂敏捷/DevOps。随着云成为新的基础设施，云上的敏捷管理也必然会越来越会成为软件管理的基础设施。啰里啰嗦的，我自己都嫌弃自己，视野有限，读书少，观点片面，如有不对，还望大家指正、交流、讨论：）

      大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）       作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上-----------------------干货分割线--------------------------------------理论总是美好的，现实却又是骨感的，很多华为云DevCloud的客户特别想知道How to，接下来恒少会陆续分享一些非常小的华为敏捷/DevOps的实践，点点滴滴。开篇小故事：巴别塔，也叫通天塔；是《圣经·旧约·创世记》第11章记载，当时人类联合起来兴建希望能通往天堂的高塔，高塔越来越接近天堂，上帝紧张了，他看到人们这样齐心协力，统一强大，心想：如果人类真的修成宏伟的通天塔，那以后还有什么事干不成呢？一定得想办法阻止他们；为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，并让人类分散世界各地，最终巴别塔没有建成。————以上摘自互联网：）这个小的宗教故事，揭示如果语言相通，目标一致产生的巨大作用，都可以建成一个通天塔：）。而软件开发的过程却又是一个离不开协作、沟通的过程。一个缺乏良好协作，沟通、理解和目标一致的软件团队，是很难高质高效的交付的。敏捷的众多实践中，有一个为了提升团队协作的经典实践：站立会议，本篇即介绍一下，融入华为的一些具体实践和“坑”和“雷”：）站立会议的关键词：每天，例行，简短（15mins内必须结束），全体成员，站立站立会议的目的：增进互相了解，互相理解，及早暴露风险，促进沟通和协调，建造“通天塔”站立会议的过程：全员到场轮流发言，记住是轮流，轮流，轮流（重要的事情说三遍）每个同学的发言简短，可以参考下面的提纲昨天我负责的工作项的进展；今天我计划开展，或可以完成哪些工作项；我遇到的困难、风险，是否需要帮助，需要谁的帮助；我收获的经验，快速分享发言时，可同步刷新工作项的进展（可以通过任一敏捷管理工具，比如华为云的DevCloud）会议上识别的新的工作项，Leader应该记录增加到Backlog中。华为站立会议实践的经验（keng）教训（lei）：Leader叽叽哇哇，成员一片沉默拘谨，觉得不自在，无话可说，不愿意先说总有同学打断别人的发言变成“批斗”会议，你怎么又延期了？你怎么不早说？变成一言堂和Push任务的会议。那谁谁你今天做这个，那谁谁你今天必须把这个交付了。变成了汇报会议，议题得提前申报，甚至还要准备PPT变成进度检查会议，只关注进度有没有完成变成一个小时的会议，讨论技术，讨论方案，发散不受控变成了不愿意参加的会议，不仅浪费时间，提出的风险和求助也得不到跟踪和解决，久而久之就失去了参加的主动性....以上摘自华为这些年常见的一些现象，所以华为其实也不是高高在上的，华为的研发也很很多企业是一样的，都是一把鼻涕一把泪的。华为站立会议填坑排雷的一些小点滴1. 站位，不要走101火箭少女的C位，也就是不要如左图这样围着C位，而是推荐围成圈或围着Backlog（如有条件可以使用电子白板），这样可以保证每个成员的发言都是面向整个团队，而不是面向C位2. 发言棒（**ing Stick）。可以用个简单道具、玩具，或者尖**都可以，接力传棒，拿到发言棒的同学才能说话，其他同学闭嘴，为了活跃气氛，避免机械，可以将道具抛起，落到谁那儿谁发言。总体就是创造轻松，舒服的氛围3. 团队成员提出的困难、风险、求助，应得到跟踪并解决，下次的站立会议持续更新，让团队成员感受到效果，也更愿意参与这个会议，因为有帮助4. 尝试Pull，而不是Push，对于一些新的工作项，风险，挑战，鼓励大家Pull任务，而不是由Leader Push任务。5. 使用工具系统，当场刷新进展，记录新的工作项，而不是后续把卡片再记录到系统，容易遗忘和遗漏6. 对了，华为DevCloud在wiki内嵌了站立会议的纪要模板，可以参考，使用wiki简单记录站立的纪要和要点，也是我们常用的，如下：最后，为什么要站立开会呢？因为站在累，所以时间久了，就开不下去了，哈哈哈。。。愿大家能够更好的开好站立会议，提升团队成员的协同，建造自己的巴别塔：）本系列未完待续，To be continued.....