【如何避免DevOps变革的六大“焦油坑”】

博文链接：https://bbs.huaweicloud.com/forum/thread-14506-1-1.html

【读书笔记】

    DevOps能给企业研发生产力和质量带来大幅的提升，而配备DevOps对大多数企业来说已是常态，DevOps也和敏捷一样，由文

化、实践、方法和工具组成，从理念到落地并非易事，同样也需要工具和技术的支撑，对大多数企业来说DevOps变革仍存在诸多挑

战。通过分析许多企业的DevOps实际应用方案，DevOps变革存在六大“焦油坑”：

无的放矢：未从客户价值出发

    一味的追求DevOps的落地，而忽略了DevOps的唯一目标--实现用户价值。而这却也是非常容易被忘却的，导致无的放矢。因此

在DevOps实施过程中，必须以客户为中心，以实现用户价值作为唯一的评判标准：保证产品功能及时实现、成功部署和稳定使用。

乌合之众：未有效地管理组织变革

    人或团队是参与DevOps变革的主体，是最大的挑战，不应该重心聚焦在工具上，而忽略了组织的变革，

各自为政：未充分地合作

    要通过进行组织文化上的变革，鼓励不同的个体与部门共同协作，减少“内耗”。

一蹴而就：未采用迭代方法

    选择增量迭代方法使组织聚焦于持续改进，避免了传统方法的巨大风险。

好高骛远：疏于管理期望值

    要明确组织近期的小目标或者较小的期望，然后迭代地实现当前业务目标，平稳的实现较大的期望，满足中远期的需求。避免期

望值过大而导致期望与它能够交付的内容存在脱节

沙上建塔：未清晰地管理需求

    需求的探索、分析与分解非常关键，清晰地管理需求，保证结果能够达到预期。

    六大“焦油坑”是DevOps变革中普遍存在的六大“坑”，而在实际过程中还存在其他细节性的阻碍，对于企业来讲，应该从客

户商业价值出发，选择合适的团队，合理地管理期望，并以增量迭代的方法，初始聚焦于单一价值流，夯实基础，逐渐扩展到其它

价值，实现DevOps规模化，最终实现企业的商业敏捷。

DevCloud · 敏捷智库：如何避免重要需求遗漏？

https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

在分别了解过CoAP/LWM2M协议和MQTT协议之后，我们可以得知，LWM2M协议是基于CoAP协议的一种具体规范，而MQTT协议是不同于CoAP协议的另一种传输协议。

CoAP/LWM2M协议基于UDP协议，服务器和客户端之间不保持连接；通信基于请求/响应模型，与互联网主流的HTTP协议相同，主要用于点对点的通信。CoAP/LWM2M协议针对物联网场景定义了各种类型和标签，支持内容协商与发现，允许设备相互探测以找到交换数据的方式；报文为极简的二进制报文，长度更短，对设备和网络的要求更低。

MQTT协议基于TCP协议，服务端和客户端之间保持连接；通信基于分布/订阅模型，可以简单实现多对多的通信场景。MQTT协议设计简单，易于理解和学习；报文消息基于文本，消息负载格式无限制，自由度更高，更便于调测和排障时查看和理解，但同时也需要服务提供商制定通信规范（接口文档），设备之间才可进行有效通信。

综上所述，CoAP/LWM2M协议和MQTT协议各有其特点，并不存在谁优谁劣，您需要根据自己的设备的应用场景选择最适合的协议。

DevCloud · 敏捷智库：如何避免重要需求遗漏？

https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

我们知道，分布在网上的知识常常以分散、异构的形式存在，传统的数据清洗抽取方式不一定适用于知识抽取，很多问题不能解决，因此需要针对知识来源格式和知识抽取目标有针对性的设计抽取工具能力。目前我们利用自研的基于正则表达的***化抽取工具TIE作为机器数据知识抽取工具；对于文档知识抽取，情况稍微复杂些，首先我们需要保留产品文档组织结构中的章节段落分类分层知识，利用文档元数据解析XML标签，获得段落句子级别的抽取中粒度知识，然后需要利用神经网络模型和NLP工具针抽取词级别的细粒度知识，包括实体词和特征词间的分类、关系等。通常抽取结果需要迭代和验证来提高新词发现准确率，这样来将不同源不同结构的数据融合成统一表示的不同颗粒度的知识，存入知识库中。

《敏捷&DevOps知识卡大全》阅读笔记

博文链接：https://bbs.huaweicloud.com/forum/thread-57121-1-1.html

华为云ID：zhanghui_china

知识卡大全系列文字（其实是图片），采用了视觉笔记的方式，将Devops中几个重要的知识点做了阐述，现看图识字如下：

1.每日站会18key

每日站会怎么做？有18个要点，其中跟人相关的3条（需要有主持人做引导——他可以不是SM，可以是任何人；团队人数够吃2个披萨就可以了——记得准备会后餐点，每个人发言不宜太长，总体上10分钟开完会最好）；跟工具和设备有关的4条（发言棒，backlog，任务板，燃尽图）；跟过程和方法有关的11条（站着开会，准时开始，严格时间盒，同时同地，预留缓冲时间；通过眼神支持。强调目的，最多聚焦三个问题，跟踪风险，回顾改善；会后再讨论细节）

2.用户故事该如何拆分？

先梳理业务，如果搞不清，就做探针尝试。

如果业务简单，使用INVEST原则（I独立的，N便于沟通的，V有价值的，E可估算的，S短小的，T可测试的）

如果业务复杂，先定义MVP(最小可行产品），再做探针尝试，并从简单到复杂，按流程拆分，按操作种类划分，按业务规则分类的方式进行扩展，拆出主要的工作，并且延迟性能实现。

3.如何避免6大焦油坑？

这个有专门的读书笔记，参见第六楼。

4.用户故事的INVEST原则。

参见本篇读书笔记第2条。

5.敏捷回顾有啥用。

回顾是为了持续改进。改进的方式就是使用戴明环PDCA（Plan-》Do-》Check-》Act）。会前会中要做好P，保证计划的质量。会后要做好DCA，保证执行的效果。

6.SM如何搞定刺头？

因人制宜，因地制宜，因时制宜。对于技术高手，要捧他（让他有成就感），对于内向型成员，要多沟通多搞活动（给他得到实惠），对于有心事的成员，有什么不是一两杯啤酒不能解决的？如果不能，换白酒！

《如何避免DevOps变革的六大“焦油坑”》读书笔记

博文链接：https://bbs.huaweicloud.com/forum/thread-14506-1-1.html

华为云ID：zhanghui_china

传统的瀑布型软件开发的企业，如果想转型到Devops，会遇到很多问题，作者从6个角度对此进行了分析，本人也从对应的6个方面谈一下看法，供大家参考。如有不对，还烦请批评指正：

1. Devops的目的是实现客户的商业价值。一切不以实现客户价值为目标的Devops实施都是耍流氓。

2. Devops的实施一定会引起人员的变革，这会使得既有人员的职责和利益得到改变（当事人没准会认为是损害），故而后者不见得会全力支持。所以需要找到价值观一样的人进行实施。或者努力去营造价值观，引导这些人员进行观念的转变。

3. Devops的实施不是IT一个部门的事情，从Dev到Ops涉及到营销，市场，产品，研发，测试，运维交付等多个团队或者职能部门的人员的协助，更是需要得到各部门领导的支持，一旦有部门领导抵触，实施会得不到好的效果。所以，合作共赢应该是部门间协作的基本原则。

4. Devops的实施是个长期的工作，最怕实施者希望明天就变天，必须采用迭代的方式逐步更新，从思想，行为，能力，文化等各方面将Devops落到实处。

5. Devops的实践必须基于当前的现实，不能有大多高于期望值的幻想。脚踏实地的去做，比起夸夸其谈的谈目标更有效。

6. Devops实践中使用了很多敏捷开发方法，但是会让人忽视需求本身的重要性。其实，从某个角度上来说，用户故事地图等其实是需求表述的另一种方式。抓好用户故事，切实搞好需求，才能使得Devops不再是空中楼阁，而真正的将其落地。
   

https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

在DevOps热潮下，许多组织通常为了赶潮流而快速启动DevOps变革，常常为了DevOps而做DevOps（Doing DevOps for DevOps），而没有充分考虑DevOps的真正目标或者目的。员工只会关注为组织带来的价值，而不会单纯与DevOps术语、方法以及支撑工具产生联系。因此对于DevOps变革，无论变革启动时，还是变革过程中，都需要将为客户带来的商业价值作为目标，以便不断调整DevOps变革内容。这也与多数组织“以客户为中心”的理念相吻合，然而却经常被忽视甚至忘却，导致无的放矢或者向不正确的靶子放矢。

为了使DevOps变革立足于客户价值、充分识别谁是客户、他们需要的价值是什么，组织应该经常思考如下问题：

·           现有或者潜在的客户是谁

·           客户看重或想实现的商业价值是什么

·           企业能提供哪些offerings，仍有哪些差距

·           客户期望的时间点

·           企业能够多快进行发布

·           客户前进的方向是什么，如何升级企业的offerings

·           如何让客户了解到企业提供了什么

企业组织在DevOps实施过程中，必须以客户为中心，持续地提高对客户商业价值的理解，来作出相应的改变，并提升自身能力。

【DevCloud · 敏捷智库】如何避免重要需求遗漏？

https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

阅读笔记：

    回顾的作用是改进，有点类似于控制系统中的反馈，没有反馈的系统是不可能稳定的，所以回顾的作用至关重要。

但是有时会在回顾上花费大量的时间，原因可能有如下几点：

            1.形式主义歪风盛行，这也是社会上的共同问题。不过要想回顾快而有效，必须纠正形式主义歪风。

            2.回顾后没有改进，相当于反馈断了，花费大量时间总结回顾的漏洞、不足，统统在回顾过后就放过了，麻木不仁。

想要做好小而精的回顾，要按如下的方法进行：

            1.做好回顾会议前的准备工作。预习是至关重要的，只有在回顾前自己先总结，先思考，才能在回顾会议上

                节约时间。在会议上思考，浪费的就是全部人的时间。

            2.要让所有与会人员都参与到会议流程的制定过程中，不能什么事情都让领导一个人决定。

            3.做好回顾会议后的贯彻落实工作，不要让所有人的心血白白浪费。

                具体来看：可以利用华为云平台来把一些问题添加到待办中，让贯彻落实的过程可视化。至于奖励和惩罚机制，相信领导比我们更懂。

【DevCloud· 敏捷智库】如何避免重要需求遗漏？ 

博文链接：https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

读书笔记：

在团队项目开发过程中，常常回出现临近交付时发现某个重要需求被遗漏，导致交付推迟，令人很恼火。

好在版主深知我辈疾苦，整理了如何避免这个问题的一些措施，

我对核心整理如下：

事前规划: 就是要做好需求的结构化管理和需求的优先级管理，以及做好相关规范的宣导、人员的动员和能力的培养，

事中: 

1、不紧急需求遗漏：考虑是否是需求分析和规划的实践做法有问题，才会导致问题持续出现，

这种情况，应强化需求结构化管理，从全局出发进行思考和规划，避免因为思考的片面化和局部性导致的遗漏；

2、紧急需求遗漏：首先调整当前开发工作的顺序，把这个遗漏的重要紧急需求排进开发环节， 然后考虑从需求的优先级和需求的结构化管理两个方面入手复盘，并切实改进，避免类似情况再次发生

事后：借助MOI模型进行复盘。

1、是否人员动力不足；

2、是否组织纪律混乱，人员不清楚自己的职责；

3、是否人员缺少解决问题的思路和创意；

秉持持续改进的心态，可以先落实当前已经比较明确的改进措施，后续再观察效果，持续复盘、持续改进即可。

另一方面我们也可以先采取一些临时措施，先保证团队的稳步改进。

【DevCloud · 敏捷智库】如何避免重要需求遗漏？

https://bbs.huaweicloud.com/forum/thread-24444-1-1.html

阅读笔记：

操作方法分三个阶段：

事前：做好需求的结构化和需求的优先级管理、相关规范的宣传、人员的动员以及能力的培养

事中：可以根据遗漏的需求重不重要、紧不紧急进行分类，逐个解决

    1.重要，不紧急：按照常规做法增加进去，经常出现遗漏，针对需求分析和规划，强化需求结构化管理，避免思考的片面化和局部性导致的遗漏

    2.重要，紧急：调整当前工作的顺序，安排此需求的增加工作，考虑复盘时，可从需求的优先级和结构化管理两个方面入手，改进

    3.不重要，不紧急：按照常规做法处理，必要时可以让这个需求插队；考虑复盘时，分析需求的结构化管理，改进

事后：可以参考MOI模型：

    M：激励（Motivation），动力，实践

    O：组织（Organization），纪律，目标

    I：想法或创意（Idea/Innovation），点子，创意

    复盘时无法得出一个准确的结论和必然有效的解决方案时，可以先落实已经比较明确的改进措施，再观察效果，持续复盘、持续改进。此外，可以采取预留时间和需求拆细的措施：

    预留时间：采取较为模糊的应对方式，固定预留出一定的时间，应对极有可能会出现的突发需求

    需求拆细：将颗粒度比较大的需求拆分为较小颗粒度的需求，增加调整需求工作顺序时的灵活性