时代亿信电子文档安全管理系统应用解决方案V3.0与鲲鹏桌面云V8完成兼容认证，测试结果表明两者兼容性良好、稳定运行、性能卓越。时代亿信电子文档安全管理系统可在X86和信创环境中实现涉密电子文件的全生命周期安全管理，支持文件集中存储管控、文件自动同步、数据迁移、基于密级标志的文件细粒度权限控制、文件操作日志等功能。系统兼容电子文件密级标志：兼容电子文件密级标志，可支持带标文件的使用和管控兼容电子文件密级标志显性密标兼容电子文件密级标志隐性密标
兼容电子文件密级标志的密级管控，禁止低密级用户打开高密级文件兼容电子文件密级标志的知悉范围管控，禁止知悉范围以外的用户打开带标文件文档集中管控：文件自动同步：数据迁移：细粒度权限控制：基于密级标志的文件细粒度权限控制，通过控制文件的阅读、复制、编辑、截屏/屏幕录像权限，以及分发、离线、外发等扩展权限，确保加标文件在限定范围内的受控使用，有效保护企事业单位的电子文件安全。
作为在信息安全行业深耕17年的企业，时代亿信建立了完善的身份管理和数据安全产品体系，目前全线产品（包括但不限于安全邮件、密级标志、文档安全、水印溯源及身份鉴别）均可跨平台兼容Windows和信创环境，便于用户实现平滑过渡。未来，时代亿信将继续加强与华为鲲鹏的深入交流、合作，持续扩大与鲲鹏云桌面的适配产品范围，共同推进信创生态的壮大、繁荣，为信创应用发展、国家网络空间安全贡献科技力量。

咨询行业作为智力密集型的知识服务型产业，以专门的知识、信息、经验资源，针对不同的用户需求，提供解决某一问题的方案或决策建议，业务范围广，内容丰富。在管理上也有其独特的行业特点：业务过程中以项目为中心展开；知识密集，企业内部文件量大；合伙管理，结算管理方式不同；项目绩效、结算有各自的体系。……因此，咨询行业企业信息化管理，需要以“项目”为业务核心，以“人员”为管理基础。泛微OA系统以协同办公、移动办公为基础，为咨询行业搭建了满足项目管理、知识管理、合伙管理与结算、绩效提成核算以及报表分析等需求的综合办公平台。（咨询行业协同办公平台架构）>>一站式办公入口：通过建立统一门户，随时推送公司信息、通知通告以及个人待办相关，帮助快速进入工作状态。通过公司门户、个人门户、报表门户、项目门户等多样化门户，帮助咨询机构按照各员工职能权限和岗位需求快速聚合办公信息。并且在门户中建立统一项目管理模块，能够快速查询个人项目信息；通过报表门户，实时查看重要统计信息图表和自定义建模形成报表。（一站式特色门户）以项目为核心，全面覆盖咨询行业日常业务一、投标管理（投标管理流程架构）投标申请审批：当有投标商机时，可发起内部投标申请流程，经部门及公司领导审批是否投标。当投标申请流程归档后，投标项目信息自动归集到投标项目台账。投标项目台账展示所有投标项目，并且可快速查看、筛选、统计不同状态的投标项目。每个项目形成电子投标项目卡片，详细地展示了当前项目的投标保证金、履约保证金、投标费用信息。投标保证金：为了确保投标保证金支付规范和安全，需要通过流程进行申请审批和支付。投标保证金支付时通过关联投标项目，自动带出相关项目信息，不需要二次输入。流程申请通过之后，形成投标保证金支付申请台账记录。并可按照预计退回时间到期对经办人员和其领导进行提醒。中标项目移交申请：投标项目中标后通过中标项目移交流程，表单中关联了投标项目和基本的项目信息、投标保证金和履约保证金信息。流程归档后更新投标项目台账是否中标为已中标，此流程归档时自动将数据写入项目台账中。投标终止申请：当有其他原因需要终止投标时，可以通过投标终止申请流程处理；流程归档时自动将该投标项目是否中标状态更新为“终止”。二、项目全过程管理咨询公司项目管理过程包括项目立项、任务下达、任务执行反馈、报告编制阶段、成果审核用印、竣工验收、项目结算等内容。项目立项：投标项目通过中标移交流程完成项目的移交立项、非投标项目需要通过项目立项流程完成项目立项。开工申请：项目开工时通过项目开工申请表确认项目负责人，分配项目任务、确认任务内容、任务责任人、任务开始日期、完成日期，分配专家；流程审批后抄送到相应的项目负责人、任务负责人以及专家。验收申请：项目成果交付之后项目负责人可申请内部进行验收申请；验收申请时需要将相关的项目资料上传归档；流程审批完成后将自动更新项目状态为竣工验收阶段。项目结算：项目结算审批主要是处理公司和项目的结算，不同类型的项目可能结算比例有差异，项目结算类型有阶段结算和最终结算。当结算类型为最终结算时，流程归档自动变更该项目的状态为终止。奖金分配：通过最终结算的项目负责人可通过奖金分配流程申请项目提成结算，如果该项目涉及多个人的可对奖金进行分配。项目开票：经办人员可通过项目开票申请开具发票，流程归档后形成当前项目的开票记录。开票流程归档后自动更新项目台账中的已开票金额。项目回款：由财务每天将项目回款记录登记到系统中、回款记录会更新项目的已回款金额和项目余款金额。三、财务管理财务统计数据：自动展示每个项目的立项日期、合同金额、开票金额、回款金额、结算金额、项目余款等。通过数据汇集，可按照不同的检索组合条件查看汇总公司项目的合同总金额、开票总金额、回款总金额、结算总金额以及项目总余额。项目成本管理：由日常费用报销、差旅费报销流程归档自动将项目类成本费用转到项目成本管理台账。将成本管理设置到项目卡片页面拓展中，通过项目卡片点击即可看到当前项目的成本费用合计及明细信息。项目卡片基本信息页面展示项目信息：合同信息、开票信息、收款信息、成本管理、发票登记、成果管理、项目结算、内部结算记录四、评审专家库实现项目评审专家库电子化管理，每位专家的个人信息，如姓名、联系方式、单位、专业方向、职称等信息一一记录，从登记到备案形成专家库，随时方便调用。五、知识管理统一存储：整个办公平台使用一套数据库，文档统一存放、多级管理，分权查询，数据综合管理，快速复用。统一知识库：文档管理按类分管，系统自动收集。既可以手动创建知识、上传文档，系统会自动收集各应用中的文件、表单、数据，按体系存入知识库。知识报表：通过强大的报表引擎，图文并茂地展现了著者文档数量、部门文档数量、分部文档数量、文档目录报表、阅读日志报表。（知识报表）六、证照管理公司荣誉证书、财税证件、完税明细、审计报告等公司日常需要使用的证照文件统一管理，通过流程进行查阅、借用，根据流程流转自动在台账中更新证照状态，有留痕，效率高且安全。同时实现了相关证照电子化，员工可随时按照需求下载使用权限内的证照。咨询行业专业人员多、人员证件多，泛微OA系统将人员证件形成台账管理，方便查询及调取。（人员证件信息卡片）OA系统咨询行业特色功能应用价值泛微OA系统通过建立一整套涵盖业务开拓与办理，投标管理、项目管理、合同管理、专家库管理、成本费用管理、项目结算管理、奖金分配管理等业务场景与应用的协同办公管控平台，全方位提升内部管理水平。

智慧园区目前已与多家伙伴的智能硬件设备完成集成认证， 大大方便了合作伙伴的解决方案构建速度，也为开发者在智慧园区应用构建上提供了更多的智能设备选择。今天我们来介绍捷顺的门禁设备与停车管理系统点击图片查看详情

什么是敏捷？（Agile）从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。另外，你也可以通过这个视频学习什么是敏捷（Agile）在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观我将之总结为：以人为本：重视个体间的合作互动目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档客户为先：理解客户需求，与客户合作拥抱改变：客户会在不断变化需求的过程中明晰真正需要的，因此敏捷需要拥抱变化尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了敏捷开发12项原则作为指导：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现。如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。怎么知道敏捷（Agile）和团队成员是否三观相合敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。所以在我们部署使用敏捷前，先来点前戏试试看。在使用前，我们可以先问自己5个问题：1.你是否会愿意接手目标不明确的项目？敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们会才会逐步了解他们的真实需求，这时候我们离成功又近了一步。2.你会如何规避项目风险？就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。3.你的团队能有多灵活？作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。4.公司阶层制度严格吗？敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？5.你怎么衡量进度？怎么定义成功？用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？研发团队如何使用敏捷读到这儿，我想你已经跃跃欲试，准备踏上敏捷之路了。敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：第1步：通过战略会议定义你的愿景每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：用于：（哪部分目标客户）需求：（用户的需求）类别：（我的产品是哪种类型）功能：（产品的价值、客户为什么选我们）竞品：（主要的竞争对手有哪些）差异化：（和竞品的差异化描述）即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。战略会议的参与角色都有谁？此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。战略会议该什么时候召开？项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时战略会议要召开多久？这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。第2步：绘制产品路线图当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。产品线路图谁来画？当然是产品经理，但我们也该听听其他利益相关者的想法，比如：客户、市场、销售、支持和研发团队的代表。产品路线图什么时候来画？路线图自然是要在开始实施迭代之前，当然最好是能在战略会后就着手开始。绘制产品路线图要多久？尽早实施，不是在前期纠结。虽然线路图看起来有点纸上谈兵，但当你的路线图能涵盖所有的目标时，我们也会更有信心去做好。第3步：制定发布计划当我们有了战略和计划，下一步我们就可以暂定几个时间节点。这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题，敏捷项目都会有多次发布的过程，所以我们只要优先发布核心功能的版本即可。举例来说，你的项目要在11月交付，而你可能在2月初就已经做好了最小模型，打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长（或者说每次达成目标需要的工作时长）决定。通常每次发布新版本都需要经历3-5次迭代。谁来制定发布计划？产品经理、项目经理和所有团队成员都该来参与其中。当然，邀请少数利益相关者来加入其中也是对其他成员的鼓励，让团队能够尽早开始。发布计划什么时候来做？越早越好，你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。制定发布计划要多久？一般来说会需要4-8小时，实际时长由具体情况决定，但不能因为它拖进度。第4步：制定迭代（Sprint）计划迭代（Sprints），我将其理解为通过短期研发完成具体任务来达到目标的一个过程，也是帮助产品经理和研发团队逐渐切入项目细节的方法。通常情况下，每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定，同时尽量保持每次迭代的时长相同。哪些角色参与制定迭代计划？迭代是整个团队的活，因此，产品经理、项目经理以及其他所有成员都该积极参与其中，表达自己的声音和想法。迭代计划什么时候来制定？在每次迭代周期开始前，我们就需要做好迭代计划。比如说，你的计划是每周迭代，那么就你就需要在每周一（或者你选好的某一天）告诉其他人迭代计划。制定迭代计划要多久？迭代计划是迭代周期的基石，虽然如此，我们也不要在这上面浪费过多的时间，通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。第5步：每日站会在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍，同时保证能准时完成既定目标。这时候我们就需要使用每日站会。每日站会，如同字面意思一样通俗易懂，每天花15分钟左右的时间来讨论下面3件事：昨天我完成了哪些事情今天我打算做哪些事情我有遇到哪些问题，如何解决或许讨论这3件事，可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作，主要依靠的就是团队快速响应和有让成员发声表达的空间。第6步：迭代（Sprint）结束了？那就进入评审阶段吧如果迭代中一切顺利，那么迭代周期结束后，我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。作为产品经理，你对产品功能有选择的权利。如果有哪步错误，尝试多问几个为什么？下次迭代时我该怎么调整才能让团队达成目标？敏捷是不断学习和迭代的过程，你的流程管控和最终产出也是同一道理。哪些角色参与评审？团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。什么时候执行评审？每次迭代结束后就可以开始。评审阶段要多长久？无需特意去准备PPT、功能说明，审查会最多1-2小时就够了。第7步：下一步？迭代（Sprint）回顾总结为了让敏捷项目管理能顺利运作，我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后，接下来该去决定下次要做哪些工作。我们需要回顾下，在迭代中是否发生了些事情改变了你的既定时间，甚至是项目愿景。谁来参加回顾总结会议？回顾总结是审查的延伸，这时利益相关者离开也没有关系，而其他团队成员则加入其中，给出自己的意见。什么时候来做？当然最好是在审查阶段结束后，立刻开始迭代回顾总结。这会花多长时间来做？概括下来大概几个词：简短明了、甜蜜温馨，最多花1-2小时来总结和大致规划下次计划。整个过程都结束了，接下来干啥？这时候我们可以选择发布新版本、获取用户反馈、规划新功能或者修复bug。持续性的发布、学习、再建，这一系列过程让敏捷在管理方法中异军突起。比起单纯的靠产品需求清单来执行项目，在敏捷指导下，我们可以通过不断发布新版本来看看客户的反馈。相比花一年时间来开发和发布，然后发现缺失核心功能的传统方法，敏捷能在每次迭代后迅速发现问题，并在下次迭代中及时调整。如何实施敏捷方法：Scrum和看板我想此时你已经跃跃欲试想把敏捷带给团队。但还有重要的一步，正如我们前面所说的，敏捷是项目管理的全新理念。为了能更好的执行，有些人研究出了一些敏捷方法。这些方法相似度很高，但从实施的角度来看，两者各有不同：ScrumScrum应该是最广为人知的敏捷方法，与看板并驾齐驱。其受欢迎的原因归功于操作简单、高效以及极高的可复制性。你可以观看这个7分钟视频，学习如何使用Scrum。我们来看下Scrum的工作原理：在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。看板（Kanban）看板作为敏捷方法的一种，提倡化繁为简，不让研发团队超负荷工作。因此它和Scrum有一定相似，都强调持续性交付，这个视频解释了看板管理项目的原理。当然看板也会有自己的三原则：1.工作流可视化当项目逐渐复杂的时候，看板工具用“白板”帮我们理清所有项目的进度和归属：代办、进行中、已完成，洞悉项目的关联信息，让事情逐步变得简单清晰。2.WIP原则WIP类似于Scrum的迭代清单，一旦制定后就不再加入新的需求（研发团队除外），团队需要依靠看板来了解他们在每次迭代具体的任务量。3.明确规划下一步为了更好的实施看板，我们需要知道下一个任务是什么。这也就意味着我们需要实时更新产品需求，重新确定需求优先级。实施敏捷管理最后的建议恭喜！你现在应该已经学会了敏捷的概念，和如何实施敏捷开发的方法，现在可以再自己的团队内推广了。但是值得提醒的是，由于敏捷开发中涉及到大量的计划、开发任务管理、时间进度和负责人，你需要使用一个项目管理工具，让整个管理过程更可控。一个项目管理工具可以这样帮助你做好敏捷开发：1.进度报告：你可以看到还有多人任务等待完成、有多少延期任务2.沟通：让每个人反馈任务中遇到的问题和进展3.分配：项目下的任务应该支持分配到具体的负责人转载自：明道云

引言：在“DevOps能力之屋（Capabilities House of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。本文阐述了企业A在实施DevOps过程中，如何一步步采用华为云DevOps平台。此客户成功故事，希望为采用DevOps平台的企业提供借鉴。为行文阅读，本文中企业A将以第一人称（“我”或者“我们”）来进行阐述。目前，在产品团队的不断努力下，从第一次接触华为云DevCloud开始，现在我们终于拥有了优雅、全面的一站式DevOps解决方案，团队成员不必再费心劳力地使用和维护多种工具及版本。然而回首过去，我们的DevOps持续交付流水线，就像大多数公司和开源项目一样，有很多混杂的产品、服务和脚本，都松松散散勉强一起使用。同时来自不同公司的不同DevOps工具并不总是能够很好地兼容，情况越发复杂。简而言之，我们有很多工作要做，但最终，我们决定要统一工具的行为和目标。采用华为云DevCloud，我们经历了6个关键阶段。我们希望这会给通往DevOps涅槃路上的企业提供帮助。第一步：找到你的痛点也许，对于大多数的企业，包括我们自己，DevOps转型的最大动力往往来自于“火烧屁股”，主动转型多数时候是奢谈。正如微软Donovan Brown在谈论到DevOps时经常说：“找到最伤人的东西，围绕它去做很多很多的事儿，使它越来越好，直到它不再伤人。”这也成为我们的座右铭。如果你打算采用DevOps，并且正在考虑使用DevCloud，那么首先审视一下自己：在我们的DevOps流水线中，最痛苦的事情是什么？没有足够的单元测试？部署新版本太多手工操作导致容易出错？即使你已经到达了DevOps的顶峰，即使你的发布是可以一键部署，你仍然可能在生产中中断某件事情。然而，你会发现你没有合适的工具来告诉你错在哪里；也许是某些事情遇到了瓶颈，或者只是没有按预期的方式工作。因此，让我们找出这些痛点并从那里开始。    第二步：源代码版本控制 “代码”作为软件研发的核心产物，因而源代码版本控制是DevOps的基石。在DevOps异地协同上，集中式的SVN远不如分布式Git，因此，很多公司（包括我们自己）将代码从SVN迁移到Git上。这样，你可以使用华为云DevCloud的代码托管服务。华为云DevCloud也提供了迁移指南通过工具或者脚本来帮助企业进行迁移，大大简化了相关工作。当然，如果你采用Git，应该充分意识：No Pains，No Gains。对于新手来讲，Git需要一个巨大的学习曲线，合并、推送、拉取，变基等很多操作有一点儿复杂。这儿有一个很好的建议，当你开始使用Git时，可以像对待以前的版本管理系统一样对待它，如果你把你所知道的相关知识转义一下应用到Git上，你就可以摆脱初始学习的困境了。对于其他复杂的操作，随着时间的推移，你将开始适应它，水到渠成地学会使用那些强大的功能。现在整个行业最近都在迅速采用Git，但愿你不会迟到。Git有一个真正具有变革意义的杀手级功能——轻量级分支。Git创建分支的本质只是只是创建一个指针。当然选用哪种分支模型（GitFlow、Gitlab Flow、GitHub Flow或者自定义flow），产品团队需要考虑团队生产力和个人生产力之间的平衡。建议从成熟的flow模型开始。第三步：任务管理任务管理是产品团队除了源代码版本控制外必须做好另一个基础工作。我们一直在使用业界某主流敏捷项目管理工具T。我们非常喜欢它的简单，在看板的工作跟踪时，只有“未完成”、“进行中”、“已完成”等3个状态。但是随着研发需求的增加，简单的状态跟踪无法满足我的需求。此外，我在拿到客户需求的初期，希望对产品做一个需求规划，让团队可以按照发布或迭代进行需求拆解。DevCloud的项目管理服务解决了这些痛点，例如思维导图可视化按层级进行需求规划、标准的Scrum方法、可以自定义工作项状态。当然这意味着你失去了简单明了的方式。                                             图1 在Scrum板视图中查看工作项状态    归根结底，你可以选择你钟爱的工具，例如至为简洁的敏捷项目管理工具T，它可以工作得很好，但是你将丢失可追溯性。而华为云DevCloud可以帮你在DevOps方面做得更多，例如需求工作项与代码提交的关联，需求工作项与测试用例和缺陷的关联等。第四步：拥抱CI/CD在使用华为云DevCloud前，我们使用的是某主流工具C。它实际上是一个非常好的持续集成产品，它提供On Premises与SaaS版本。使用DevCloud编译构建服务的一个好处是构建启动的速度变得飞快。对于工具C，每当我们需要一个新的构建时，就会提供一个VM，这可能需要5到10分钟。这个前置时间太久，变得很烦人。而华为云DevCloud拥有了一个热的、随时可以在云中构建的机器池，所以只要有人提交一个新的提交，构建就会立即发生。    以前，我们的部署过程是手动的，我们需要运行一堆批处理脚本。而使用DevCloud流水线是一种乐趣，它不仅仅可以支持一键全自动部署，将变更投入生产，而且提供了完美的可视化编排，可以将构建、部署、自动化测试等纳管起来，并根据实际需要定制多级流水线，加入质量门禁、人工审核等控制。第五步：Bug跟踪在此之前，我们使用Excel对Bug进行跟踪，随着团队人数的增加，分清Excel版本已经足够让我们头疼了。使用了DevCloud之后，简直给我们的工作带来了不可思议的改变。首先，Bug跟踪在早例会的直观展示。当我们开早会时，将Scrum缺陷跟踪板投屏，可以通过过滤筛选每个成员手中的Bug状态和等级，便于识别风险。其次，Bug跟踪与需求、测试的关联。DevCloud中基于需求创建测试用例，测试用例失败生产Bug，实现了需求-测试用例-缺陷双向关联。最后，多维度的Bug统计。在DevCloud统计报表中，预置了多种Bug统计报表，用户也可以根据自己的需要自定义统计报表。                 图2 在DevCloud预置的缺陷统计模板第六步：定制DevCloud适应项目需求不要陷入DevCloud希望你工作的方式中。如果有众多不同的状态，比如批准、已提交、已解决、已验证，请不要盲目屈从于产品对敏捷或Scrum的定义或者那些对你不起作用的东西。先问问自己什么是可能起作用的最简单的事情，然后在DevCloud上开展工作。最为重要的是，不要因为DevCloud产品经理想的太多而强迫自己过度思考，无所适从。自定义相对比较简单，因为DevCloud提供了工作项字段、模板、状态流转等的可定制性。你可以用它来增加东西，但你也可以用它来减轻东西。所以，把对你没有意义的东西拿走，只保持最低限度。你只需把它作为一个工具来了解你的团队在做什么，并传达优先事项，保持它的简洁与实用。采用华为云DevCloud最重要的是，它作为一个全面的解决方案所带来的聚集效应。你可以选择只使用其中的部分服务，然而如果你选择使用尽可能多的服务，你将发现令人震惊的积极变化。当然，这并非没有困难，一蹴而就。DevOps转型面临不同层面的变革，从改变企业文化，到整个组织的新的工具平台的投资，到团队成员的知识与技能水平。但请相信，这确实是一个短期痛苦、长期收益的改变！全面的解决方案无疑会是一个赢家。一旦我们采用了一体化工具平台，向我们的客户交付软件就变得更容易、更自动化，甚至是一个很好的体验。无论如何，采用华为云DevCloud会失去什么呢？我相信无论只使用部分服务，还是全部服务，它只会给你带来更多的业务效益，以及高效的交付体验。作者：伦语春秋  莫妮卡

#include <stdio.h>int main() {    int flag;    char input[15];    flag = 1;    scanf("%s", input);    int len = strlen(input);    if (len == 1) {        if (input[0] == '9') printf("11\n");        else printf("%d\n", input[0] - 48 + 1);    } else {        for (int i = 0; i < len; i++)            if (input[i] != '9') {                flag = 0;                break;            }        if (flag) {            for (int i = 0; i < len + 1; i++)                if (i == 0 || i == len)                    printf("1");                else                    printf("0");            printf("\n");        } else {            if (len % 2) {                int mid = len / 2;                input[mid] += 1;                if (input[mid] == 58) {                    input[mid] = '0';                    input[mid - 1] += 1;                    input[mid + 1] += 1;                    for (int i = mid + 1; i <= len - 1; i++) {                        if (input[i] == 58) {                            input[i] = '0';                            input[i + 1] += 1;                        }                        if (input[len - 1 - i] == 58) {                            input[len - i - 1] = '0';                            input[len - i - 2] += 1;                        }                    }                }            } else {                int mid = len / 2;                input[mid] += 1;                input[mid - 1] += 1;                for (int i = mid; i <= len - 1; i++) {                    if (input[i] == 58) {                        input[i + 1] += 1;                        input[i] = '0';                    }                    if (input[len - 1 - i] == 58) {                        input[len - 2 - i] += 1;                        input[len - i - 1] = '0';                    }                }            }            printf("%s\n", input);        }    }    return 0;}知乎@C语言编程俱乐部这个，困扰了我一整个学期的魔鬼，分享给大家!

引言：在“DevOps能力之屋（CapabilitiesHouse of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。在敏捷项目中，用户故事（User Story）是产品团队用来描述用户需求的主要方式。每个用户故事是小的、独立的行为，最好可以在一个迭代中增量式实现，并为最终用户提供价值。Bill Wake提出的INVEST模型，描述了良好的用户故事应该具备的特征，是用户故事应该遵循的原则：•     Independent：独立性•     Negotiable：可协商性•     Valuable：有价值•     Estimable：可估算性•     Small：短小•     Testable：可测试性将业务特性分解成为符合INVEST模型的用户故事，成为每一个敏捷团队的必备技能。LeffingWell在《Agile SoftwareRequirements 》一书中提出了分解故事的10种方法：•     Workflow steps•     Business rulevariations•     Major effort•     Simple/complex•     Variations in data•     Data entry methods•     Deferred systemqualities•     Operations •     Use-case scenarios•     Break-out spike不少人经常会说分解用户故事在增量式开发中既是艺术性又是科学性工作。敏捷产品团队可以参照10种方法进行故事分解，并使之尽量符合INVEST原则。然而敏捷产品团队如何在软件交付中记录故事分解方法，以更好地分享方法或者事后回顾改进或者统计分析呢？当然比较好的方式是采用敏捷项目管理工具，例如华为云DevCloud的项目管理（ProjectMan）。在华为云DevCloud的项目管理中Story并没有缺省字段来记录分解方法，因此需要通过“Story设置”特性来自定义此字段。用户可以在项目中通过“设置”-“项目设置”-“Story设置”-“字段与模板”进入工作项模板页面，如图所示：在工作项模板页面，点击“编辑模板”，并在字段配置处点击“+新建字段”，在下图中输入字段名称、字段类型以及字段选项等。将工作项模板编辑后进行保存。新建字段“故事分解方法”这样，在新建Story或者编辑Story的时候，团队成员可以记录故事分解方法。如下图所示在Story中记录故事分解方法随着敏捷项目的迭代进行，产品团队将不断积累此项目的故事分解方法，团队成员可以基于此数据进行分享与学习，将局部的、隐性的分解方法变为了全局的、显性的分解方法。这也正是DevOps三步法（Three Ways）在持续学习与实验中提倡的实践之一“将局部知识转化为全局知识”。一旦在项目迭代开发过程中，团队积累了故事分解方法的过程数据，那么团队可以在适当的实际进行相应的统计分析。对于故事分解方法的统计分析，目前华为云DevCloud的项目管理的自定义报表特性尚未提供基于自定义字段的维度分析，产品团队可以使用工作项导出特性，将Story导出到Excel进行统计分析，发现分解方法的一些规律，可以指导产品团队更好地有重点地提升分解能力。

【参赛须知】使用华为云App Cube新型开发平台，0代码基础的小白也能无压力体验一个全能APP的诞生！（本次赛题提供手把手操作指南，提供样例代码）【赛事背景】       山东省是全国啤酒产量最大的省份，天气逐渐热起来，啤酒的需求量在持续增加，各烧烤店、酒吧、大排档等店铺啤酒是不可缺少的饮品；啤酒的及时供给，有助于提升食品领域的消费能力，为促进经济的恢复贡献一份力；特别是新鲜可口的生啤，需要尽快配送到店铺里面；华为云DevCloud聚焦啤酒预约、配送管理系统的开发与配送需求，邀请开发者为提高啤酒配送效率贡献一份力量，给逐渐炎热的天气送去一份清凉。 【赛道二报名】本次大赛2个赛道分开报名，可以同时参加竞赛，2倍获奖机会！1、赛道二报名地址：https://competition.huaweicloud.com/information/1000041230/introduction（一定要报名才行！）2、报名时间：6月1日9:00~9月30日23:593、提交作品时间：9月10日 00:00 ~9:月30日 23:59前重要！参与前，请确保已报名加入活动群（大赛qq群：见下方）活动小助手微信号：HorizonDPService）【赛题详情】本赛道包含主赛题与附加题两个环节，主赛题+附加题1+附加题2=总分，排名按照总分高低排序。请见报名地址 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance。【应用效果体验】1. 啤酒需求方体验下单购买的二维码：                                                                                2. 啤酒供应方与啤酒物流方体验说明表1 啤酒供应方体验通道说明用户名/密码体验url备注supplierUser/Xiao_1204supplierUser1/Xiao_1204https://cas.e.huawei.com/cas/login?service=https%3a%2f%2fstudio.e.huawei.com%2fbaas%2fauth%2fv1.0%2fsso%3fredirect_url%3dhttps%253a%252f%252fstudio.e.huawei.com%252fapp%252fportal.html啤酒供应方只能看见啤酒供应方的菜单表2 啤酒物流方体验通道说明用户名/密码体验url备注deliverUser/Xiao_1204deliverUser1/Xiao_1204https://cas.e.huawei.com/cas/login?service=https%3a%2f%2fstudio.e.huawei.com%2fbaas%2fauth%2fv1.0%2fsso%3fredirect_url%3dhttps%253a%252f%252fstudio.e.huawei.com%252fapp%252fportal.html啤酒物流方只能看见啤酒物流方的菜单登录时，遇到此图请忽略。3. 啤酒供应方将生成一个啤酒供需数字化管理监控大屏：表3 啤酒供需数字化管理监控大屏---体验url备注https://studio.e.huawei.com/magno/render/DVBeerMgtDMAX172550dd7e2_0000000000Wgees5R7LN直接单击URL就可以查看    【评分说明】主赛题+附加题1+附加题2 = 总分请见 报名地址 链接中的 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance【提交说明】请见 报名地址 链接中的 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance【奖项说明】【交流互动】大赛官方交流请在本论坛发帖或QQ**群或微信咨询。~~~~~~~还有什么不清楚的快来咨询我们的小助手哟，加小助手微信 ~~~         

如何结合企业业务实际去提升项目管理效率，有没有详细案例？

如何结合企业业务实际去提升项目管理效率，有没有详细案例？

自从Gartner宣布云将成为数据库管理系统(DBMS)的实际解决方案以来，已经快一年了。那时，技术界一直在争论这种方法与传统本地模型的相对优点，似乎得出的广泛结论是，尽管云确实提供了一些优势，但它本身并不能充分支持企业今后的需求。根据一些专家的说法，云为DBMS未来需要发生的事情奠定了基础，但只有更高级别的架构才能真正带来灵活性和高级服务水平，这将定义互联数字服务和物联网(IoT)时代的未来企业模式。重要的是要注意，这种观点并不与Gartner关于DBMS和云的观点相矛盾，只是严格地关注基于云的基础架构并不能说明全部问题。Gartner的AdamRonthal在去年6月发布的题为“DMBS市场的未来就是云”的博客文章中指出，基于云的DMBS的采用已经开始普及，并将在短期内占据主导地位。主要是由于以下事实：云是进行大量创新和成本优化的地方，而本地部署很快将降级到需要传统兼容性的专业应用程序和工作。虽然这在一定程度上可能是正确的，但是像Altinity这样的服务提供商注意到这些事实需要一点背景。首先，显示资本支出下降但运营支出保持不变或仅略有增加的定价模式在现实世界中并不奏效。事实上，随着环境的扩大，云架构往往会对运营支出造成相当大的打击。此外，在云创新令人印象深刻的同时，DBMS市场也在受到开源、KUBERNETES、AI等可以部署在云或本地的发展的影响。据Altinity称，至少二十年来，开源一直是DBMS创新的温床。许多最具破坏力的数据管理技术都是在开源项目中开发的，并且不断有风险资本流入这一市场，这确保了这一过程将持续一段时间。对于任何打算改变其数据管理策略的人来说，云无疑是值得关注的，但是如果没有健康的开源资源，云可能很快就会消失。因此，DBMS就像其他任何应用程序一样，成功并不仅仅取决于迁移到云上，还取决于您如何实现。Aiven的GiladDavidMaayan建议基于云的DBMS遵循以下五种最佳实践：1. 先制定策略，然后进行迁移IT领域充满了失败的云计划，因为人们过多地关注了最终的工作方式，而不是如何平稳过渡。2. 加密和标记静态数据黑客可能更喜欢以静态数据为目标，因为目前没有人关注这些数据。但它仍然包含有价值的、有特权的信息，如个人财务和商业秘密。3. 通过身份和访问管理(IAM)保护安全标准的授权程序对于确保数据和基础架构的保护至关重要，尤其是在必须不断更新访问权限的大型环境中。4. 通过加密和VPN保护传输中动态数据也会被盗，因此安全、加密的数字隧道是保护其安全的高效方法。5. 自动监测繁琐而重要的工作最好由自动化处理，自动化可以围绕报告、测试和集成等监控流程的关键方面进行配置。云管理的噩梦?德勤(Deloitte)的DavidLinthicum说，企业也应该意识到，如果没有适当的控制，云很容易变成管理噩梦。实际上，许多云都迁移到了一个充满孤岛的基础架构中，该基础架构目前限制了数据中心的工作流，尤其是当单个业务部门在没有IT监督的情况下创建和管理自己的云时。要解决这个问题，可以考虑采用主数据管理计划、数据虚拟化和其他方法来联合环境，以便为整个组织结构创建一个单一的事实来源。他说，归根结底，企业应该为“自我识别数据”而努力，使数据本身充满了智能，以了解数据是什么以及如何使用。如果正确实施，则可以使数据复杂度降低20倍。最后的想法从所有角度来看，将云视为一辆全新的皮卡车。当然，它更大，可以载得更多，并具有后备摄像头和WiFi等各种功能，但最终要由驾驶员充分利用并保持清洁和良好的工作状态。将DBMS放到云端是很容易的。要让它正常工作需要付出更多的努力。

亿图项目管理软件（Edraw Project）是一款功能强大的项目管理软件，具有界面简洁、操作简单、功能强大的特点，只需单击鼠标即可完成甘特图的创建。项目管理人员可以用它绘制甘特图，用于制定计划、为任务分配资源、跟踪项目进度、管理预算，以及分析项目的资源状态与分配情况。亿图项目管理软件有助于项目安排和管理，从时间、预算、资源等多个维度，提供项目层次结构和任务报告关系的总体情况，以便进行人员管理、深入了解预算计划和资源分配等。亿图项目管理软件允许根据特定视角生成各种报告，并支持与他人共享报告文件，进行项目分析。用户可通过时间轴和多角度报告掌握当前进度，快速提供适当的变更解决方案。亿图项目管理软件核心功能：1、甘特图绘制可轻松增加任务名称、开始结束时间、资源、进度条等，通过快捷键快速创作甘特图，将难以理解的复杂项目信息转换为一目了然的甘特图。2、资源管理支持自定义资源，可以增加工时类和非工时类的资源，并且每个资源都可以设置相关的费用。资源管理可以在绘制甘特图的时候调用，便于准确生成相关的报表信息。3、一键报表软件集成报表功能，可生成任务、成本、工时等多种类型报表。一键报表功能有助于项目管理人员跟踪项目进展，把控项目的整体情况。亿图项目管理软件适配鲲鹏云桌面应用，有助于进一步推进全球市场对中国办公软件的认知，提升中国办公软件的国际知名度，让全球用户看到包括万兴科技在内的国内优秀企业在鲲鹏软件生态上的布局与发展。

近期产品针对Scrum项目类型的工作项页面进行了一个优化，相比以前有所提升，但是最近有部分用户反馈有些不习惯，特意写个文章整体阐述一下，也希望听到大家的进一步反馈和指正【本次优化希望命中的靶心】以前项目管理服务下的“工作”菜单包含内部比较多：需求规划，Epic，Feature，Backlog，缺陷，统计，报告。随着新特性不断增加，部分用户和我们都觉得子菜单越来越多，显得臃肿以前Epic、Feature，Backlog，缺陷本质而言都是某种或某几种工作项类型的聚合，更直白一点的说，就是不同工作项类型的过滤条件过滤出来的项目管理服务一直没有一个“所有工作项”的选项，能够默认看到所有的工作项。项目管理服务也一直没有单独的Story页面，也没有Task虽然3&4，都可以让用户自己来通过高级过滤器去按类型过滤筛选，但是这个其实不符合“高级过滤”的定位，从产品角度，高级过滤应该是低频操作，只有“高级”的时候才需要使用才对，尽可能通过列表就能过滤或者直接选到自己要的对于不同用户场景，不同的用户角色，如果都能有一个他们的专属“空间”，会让他们更有一点点专属感，比如对于产品经理角色，从大的层面去管理需求，那么他可能会更多时间用在Epic或Feature，对于开发人员或者开发Leader，他们更多时间会专注与Story和Task，而之前story和task是没有单独呈现的，需要从backlog中去过滤筛选，所以导致开发人员没有自己的专属工作感，感觉是和其他角色混用在Backlog中的。工作项的导出。之前的工作项导出一直被诟病，是全量导出下的各种混杂，也没有用户一直希望的父子工作项关系的连并导出，同时工作项也不支持多选导出，只能批量全导出。【本次优化的几个点和背后的逻辑和纠结】在保留原先Epic，Feature，Backlog，缺陷页面的同时，增加“全部”，增加“Story”，增加“Task”单独的三个预置工作项类型的工作页面，想看所有工作项的可以直接选择“所有”，想只看Story的可以直接选择Story，想只看Task的可以选择Task，如下图所示：为什么图上的全部下拉框不包含缺陷呢？这是我们的一个历史纠结，从业界对于工作项的定义而言，缺陷也是一种工作项类型，但是由于对很多用户而言，尤其是很多企业的测试团队而言，缺陷又是他们的主要管理对象，因此之前把缺陷单独列出来了，如果这次为了按所有工作项来统一，那么把缺陷折叠到所有及其以下，会让很多一直工作在“缺陷”页面下的用户不方便，觉得被忽视了，因此我们还是把Backlog和缺陷单独放在和全部一个层级。为什么这次要把Epic和Feature折叠起来呢。我们通过埋点发现，其实这两个工作项页面之前的使用程度不高，为了节省一些空间，更加简洁一些，我们折叠了一下，当然如果选择了一次，系统会自动记住，这样登陆进来还是上次选择的Epic或Feature顺便解释一下Backlog。其实站在一个相对专业的敏捷角度，之前单独剥离一个Backlog（默认包含Story，缺陷及其Task）本身是有些问题的，从专业角度而言，Backlog是个待办池子，这里面放什么工作项其实都可以，比如如果放Epic或Feature，可以叫产品Backlog，如果放迭代的Story和缺陷可以叫迭代Backlog，甚至用户可以自定义不同的Backlog放不同的工作项，就是一个自定义过滤器用到了Backlog名字而已。但是由于历史原因，项目管理服务的Backlog写死了工作项类型，而且当前用户已经习惯了，去年我曾经想去掉这种Backlog，刚一灰度，就被很多不明真相的同学炮轰为“删除了Backlog”，呵呵：）我们后面会考虑在保护用户对于已有Backlog习惯的同时，去优化，让Backlog成为真正的Backlog，比如分成产品Backlog和迭代Backlog等。不过动静太大，我们这次先不折腾了我们调整了一下列表上方的操作区分布，把我们通过埋点得出的高频操作尽可能放在左中侧，比如新建按钮，比如搜索，把一些低频一些的操作放在右侧，比如显示字段（显示字段通常设置一次，就不再设置了），当然这个高频，低频对于不同用户可能还是有些差异的。导出支持了父子工作项连并导出，在导出时，选择“是否包含子工作项”导出后，我们会把父子工作项连在一起导出，这个地方有个纠结点，为了更易于用户看出树形的层次感，我们在子工作项的标题增加了一些空格，我们借鉴了一些其他的产品，发现有些产品也是这么在导出的，当然这个可能有些用户会有不喜欢：），我们之前征求了部分用户意见，有的觉得OK，有的觉得不喜欢，呵呵，我们暂时先决策使用当前的形式8. 另外，本次新增了多选导出，可以选择几个工作项导出，当然也可以选择是否包含子工作项【关于两个显示模式的逻辑】本次也微调了一下两个显示模式的定义和逻辑，这个目前也是咨询量比较集中的地方。需要单独讲一下，就是如下红色框中三个按钮：从左到右的第一个按钮就是卡片显示模式。其实这个显示模式体验并不好，不如新看板项目的卡片展示，比如卡片展示就不应该用列表模式一样的分页，就应该用懒加载瀑布流，不断往下滚动，这个替换，可能还需要一些时间，开发同学们在弄了第二个按钮和第三个按钮都是针对列表的显示模式，如果把鼠标放到对应的按钮上，会有Tips提示第二个按钮：显示满足条件的所有工作项。以下用俗称“平铺显示”来代替第三个按钮：显示满足条件的所有工作项工作及其所有子工作项。也可以用俗称这两个模式的区别在什么地方，我们用两个截图来看，就能很好理解了我们选择“全部”，希望过滤显示所有出于“新建”状态的工作项，显示模式选择“平铺”，那么就会把状态为“新建”的各种工作项类型都显示出来，可以看到没有层次关系，都是并列显示如果我们在不改变其他条件的基础上，把显示模式改成“树形”，就会发现之前的工作项都在，但是会把有子工作项的给显示出来，也就会出现“加号”当然，树形模式有两个场景也是一直被纠结的满足条件的子工作项要不要在“树形显示模式”下，把其父工作项给显示出来？也就是往父追溯显示？满足条件的父工作项在“树形显示模式”下，其子工作项到底要不要也套用父工作项的过滤条件呢？这两个问题，不仅我们，其实业界对于树形显示，也有一些纠结，我们采用的逻辑是：我们认为不应该把父工作项反向显示出来，因为这样会导致切换“树形显示模式“后出现一堆不满足本次过滤条件的工作项，和之前”平铺模式“显示完全不同，用户会先莫名其妙，需要花时间才明白原来是反向显示了父。我们觉得这种体验不好，如果要看父点击详情查看更好的效果我们认为其子工作项应该全部显示，而不是套用父工作项的过滤条件，加入套用父工作项的过滤条件，会出现子工作项显示的数目少于所有工作项，会让用户首先吓一跳，以为丢失了子工作项，这种很意外的体验让用户感知也不好，而且由于父子工作项可以自定义的字段，可以自定义的状态都是不一样的，父工作项的过滤条件是无法完全适用于子工作项的。对于如上的两个问题，其实无论系统采取哪种，都可能会导致某部分用户觉得体验不好，我们目前还是进行了一些取舍，确实可能会对某些用户造成困扰：）不过，我们做这个取舍，也不是拍脑袋，其实这次工作项的整合和优化，在我们内部也内测和吃狗粮了将近2个月，如上的两个问题，我们内部也讨论了很久，最终大部分用户在习惯后，更多倾向于我们现在采用的方案毕竟我们视野和使用场景有限，肯定会对部分用户造成困扰，欢迎大家批评和补充您的场景，我们继续思考改进谢谢哦：），另外DevCloud深色模式上线了，我们埋了一个切换深色模式和浅色模式的小彩蛋。

      精准测试是近年来行业内流行的新测试技术体系，它通过建立功能用例与代码的关系，使得计算机可以通过智能算法对测试进行深度的辅助分析和提效。精准测试可以轻松的对接原有的功能测试流程，最新的静默方式工作可以确保用户完全不用改变原有测试流程，强大又没有额外的运行成本，得到了广大企业的好评并逐步开始全面流行。 如果一个软件系统的行为总是与预期相一致，称之为可信（trustworthy），目前对于可信软件的测试主要集中在对其进行可靠性、可用性、可维护性、动态测试方法等。由于现在企业大多执行的是黑盒测试，软件无法保证逻辑测试的完整性，约有30%的潜在缺陷在黑盒测试方法下无法被实别，所以，非常遗憾很多企业测试不属于可信测试范畴。 首先软件测试本身的目标标的物是一个未知数，这和开发有着本质的区别。一个程序是否存在缺陷，存在多少缺陷，这些都是相对未知数。软件测试的工作有一个缺陷数量不相关原理，即：发现的缺陷多，并不说明剩下的缺陷就少；同样发现的缺陷少，并不说明剩下的缺陷多。这个缺陷数量不相关性，给我们实际测试带来最大的困惑就是：无法明确判断测试后的程序交付的质量，进而导致测试的成效处于一种不可信状态。其次，不可信性来自于数据执行的不可追溯性。传统测试采用的测试管理系统类似于一种MIS系统，它只是在展示和分析人为填入的数据，测试是否真正被执行？测试是否充分？我们无从分辨。这个问题在这次“新型冠状肺炎”疫情爆发后显得格外明显，因为疫情原因，远程测试管理变得非常松散，测试的有效性成为一个很大的疑问。其实，这也是众包测试模式难以发展的最大瓶颈：发包方仅凭执行列表，完全无法识别真正被有效运行的功能，质量验收形同虚设。由于没有合理的考核办法，导致测试人员在企业内部的发展同样遭遇困境，经常容易被质疑并且很难和研发获得一样的待遇和地位。而个别团队却又把不可信性反过来当作挡箭牌来用，拒绝使用覆盖率等技术暴露工作的不足。 今天我们的主题是讲一下精准测试如何实现可信测试这个主题。 精准测试让功能用例和对应的代码之间实现了精准无误的追溯路线可视化，从技术底层解决了测试可信性的问题。星云测试“测试用例与源码的双向追溯技术”，如同全景调试器一样，记录了每个测试用例对应的程序内部的执行细节，细致到每个条件，分支，语句块的执行情况。它的所有测试数据均是在测试执行过程中，由软件自动分析并录入的底层代码运行原生数据。由于用例和执行代码之间信息被完整跟踪，并且细分到测试用例级别，因此整个测试数据都可以在代码层面可视化出来，人工无法介入修改。使每个业务功能与相应的源码如同“量子纠缠”一样具备强关联性。一个发生变化，另一个必定发生相应变化。它真实再现测试现场情况，从技术上确保所有数据精准无篡改，彻底解决了“黑盒”执行过程、质量度量和实效分析等难题。使测试的衡量点回归到计算机程序的本质-“代码”上来。 精准测试通过软件示波器采集数据，用例如何运行，就如何记录程序运行的路径信息，当用例没有被正确运行，或者没有被执行的情况下，示波器就不会采集和记录相关信息。所以星云精准测试在众包远程零监管的众测模式下，测试用例的有效性和被执行状态，很清晰地被记录下来。测试覆盖率是测试界公认的最佳的是测试结项的可用指标。每一行代码或者分支跳转理论上都是在实现某些特定的业务功能，因为某些原因没有被覆盖到的部分是必定蕴含着风险的。在传统测试中，我们可以用人工确认的方式表达某个用例已经执行过，但在精准测试中，没有被执行的用例对应的代码覆盖就是0或者是异常的覆盖，这个信息是没有办法伪造的。这实际上已经解决了测试众包业务验收难的问题：测试用例设计能力如何、有没有被执行、执行结果如何、调整增补后的代码及用例的运行结果如何等，在各剖面报表上展示得非常清晰。精准测试可以把每个测试用例进行量化分析和统计。在本次疫情中，大家都可以深刻的感受到由于因隔离而产生的团队人员变动，给项目造成巨大不确定因素。星云精准测试有一系列的算法，可以根据管理者对项目质量的要求，对验收指标进入深度回溯，快速定位BUG所牵涉到的业务逻辑、测试用例等要素，从而大大减小了人为影响。这些量化数据既可以用来对测试结果以及测试过程进行审核，也能帮助测试人员从数字化分析角度反观测试用例设计是否合理、执行的测试用例是否不足。极大弥补了由于测试人员自身的经验、能力、精神状况等因素，影响到的测试质量。管理者们也可以对症下药，拟定有针对性的学习计划、快速培养，使不同水准的梯队成员在有限的时间里，得到迅速提高。精准测试的覆盖率每日增长趋势图，对于团队的质量控制和整体测试进度情况具有很好的指导意义。它能够让高级管理人员对测试进度进行预判，也能够对测试效率进行有效的识别，例如通过对覆盖率增长曲线的拟合，可判断按照目前进度能够在上线日期到达前能够一个合理的测试水准。星云精准测试从各个角度提供可信化的测试数据，使管理者有效地把控测试节奏，主动地进行测试策略的调整。对数字化管理进行有效的数据采集，企业可以很自然的实现分布式测试，不同区域、不同任务分配的测试人员可以实现协同测试与协同管理，最终达到多人同地测试、多人异地测试、数据实时汇总共享与追踪、测试过程与完成度有理有据、测试结果一目了然。精准测试能自动识别测试设备、测试人员、测试用例等，并自动关联对应信息。在没有采用可信的精准测试之前，通常一个测试主管一般只能管理5名左右的测试工程师，管理人员需要投入大量的精力帮助测试人员审核用例，甚至监督用例的有效执行。应用星云精准测试以后，工作就简化了很多：每个项目的覆盖情况，每日增长情况都很直观，每位工程师的用例设计和执行的充分度也很清楚。项目管理者可以站在更高的角度，充分了解整个项目的资源使用、测试人员任务分配、测试进度等情况，并做数字化分析、管理和调度。因此精准测试非常适用于外包和众测领域，管理人员不用再特别花费时间去考核测试人员考勤、工作态度等主观因素，很容易看出不同团队、人员的业务水平。 精准测试可以基于可信的数据、依靠有效的算法计算出来的实施自动化回归测试。星云精准测试(www.teststars.cc)可以实现自动化的版本对比，分析出修改、增加、删除的代码以及这些代码相关联的测试用例，快速做测试用例回归测试、快速补充测试用例、删除无效测试用例。它大大减少了回归测试的时间、降低传统人工回归分析产生的测试盲点、精确计算回归用例的权重。测试人员在时间有限的情况下，可以重点回归受改动影响最大的用例，适应庞大的工程项目的快速版本迭代需求。 精准测试通过静态、动态指标的综合分析，快速筛选潜在的高危测试漏洞。测试人员可以通过星云精准测试漏洞分析，直接针对高危的核心模块功能与开发合作完成补充测试；也可以通过漏洞分析可视化的图形，检查出核心模块的测试遗漏点，进行测试用例补全，消除测试遗漏点与盲点。与此同时，亦可对无用的代码进行相应的注释与删除，提高软件的后期维护性，大大提高了废弃代码的排查率。 可信化的精准测试，解决了大量的传统测试的盲点与痛点。目前全行业都在逐步认识和推进精准测试，我们相信未来在新技术的推动下，注定会迎来远程松散式测试众包（外包）一个新的爆发点。这次疫情，让大家进一步深刻意识到，信息化让我们每个人都生活在软件的海洋里。疫情期间，大量用户涌入线上服务，让很多软件系统暴露了很多不足，在996和007的高密度的软件发布下，如果不配置上新型的智能化精准测试技术，如何有效支撑越来越复杂的软件应用的高可靠性和高可信化？ 自然语言的沟通，应更多体现在人文关怀上，庞大的软件帝国没有高度智能可视的精准测试管控，快速预警那些隐蔽很深的缺陷，必定有一天会像突发而至的疫情一样兜头而下、措不及防。借用最近事故频发后反思而来的金句：对于故障，没有借口。我们应认真复盘改进发布验证流程，研发人员应该敬畏每一行代码，测试人员应该敬畏每一份托付。我们每一个人都在有形无形中，构建人类信息世界的命运共同体。 

设置完Atlas 500的管理密码后，每隔一段时间登录  边缘管理系统时   都要求修改密码，造成不便；请教！  有没有办法关闭这个定期要求修改密码的设置？