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

近期产品针对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的高密度的软件发布下，如果不配置上新型的智能化精准测试技术，如何有效支撑越来越复杂的软件应用的高可靠性和高可信化？ 自然语言的沟通，应更多体现在人文关怀上，庞大的软件帝国没有高度智能可视的精准测试管控，快速预警那些隐蔽很深的缺陷，必定有一天会像突发而至的疫情一样兜头而下、措不及防。借用最近事故频发后反思而来的金句：对于故障，没有借口。我们应认真复盘改进发布验证流程，研发人员应该敬畏每一行代码，测试人员应该敬畏每一份托付。我们每一个人都在有形无形中，构建人类信息世界的命运共同体。 

尊敬的各位云应用平台-DevCloud项目管理开发者    感谢大家对【华为云DevCoud项目管理】的关注与支持。    本帖为Codelabs咨询和问题反馈收集贴。如果大家在体验华为云DevCoud-项目管理 Codelabs的过程中遇到任何问题，均可以通过本帖进行反馈。我们会安排专人进行问题的收集与解答。请大家按照以下格式进行回帖：问题/咨询提交格式————————————————反馈类型（问题/咨询/建议）：华为云账号：问题出现时间：问题/咨询/建议描述：截图：————————————————    大家也可以移步华为云应用平台Codelabs活动主贴，探索更多玩法，赢取精美礼品：<点我前往应用平台Codelabs主贴>项目管理Codelabs体验链接：基于华为云DevCloud敏捷项目管理体验

达梦公司达梦数据库管理系统V8（DM8）与华为TaiShan服务器（TaiShan 200 型号2280），完成产品兼容性双向认证测试。测试结果表明，DM8数据库管理系统与华为TaiShan 200服务器的兼容性良好，可稳定运行，性能及安全性、可靠性满足关键性应用需求。产品介绍DM8是达梦公司在总结DM系列产品研发与应用经验的基础上，坚持开放创新、简洁实用的理念，历经五年匠心打磨，推出的新一代自研数据库。DM8吸收借鉴当前先进新技术思想与主流数据库产品的优点，融合了分布式、弹性计算与云计算的优势，对灵活性、易用性、可靠性、高安全性等方面进行了大规模改进，多样化架构充分满足不同场景需求，支持超大规模并发事务处理和事务-分析混合型业务处理，动态分配计算资源，实现更精细化的资源利用、更低成本的投入。一个数据库，满足用户多种需求，让用户能更加专注于业务发展。企业介绍武汉达梦数据库有限公司成立于2000年，为中国电子信息产业集团(CEC)旗下基础软件企业，专业从事数据库管理系统的研发、销售与服务，同时可为用户提供大数据平台架构咨询、数据技术方案规划、产品部署与实施等服务。多年来，达梦公司始终坚持原始创新、独立研发，目前已掌握数据管理与数据分析领域的核心前沿技术，拥有全部源代码，具有完全自主知识产权。达梦公司是国家规划布局内重点软件企业，同时也是获得国家“双软”认证和国家自主原创产品认证的高新技术企业，拥有国内数据库研发精英团队，多次与国际数据库巨头同台竞技并夺标。在跨越七个“五年计划”的发展过程中，达梦公司逐渐成长为国内数据库行业的领军企业，先后完成近60项国家级或省部级科研开发项目，取得50多项全球领先的研究成果，其中有30多项获国家级或省部级科技进步奖。达梦公司建立了稳定有效的市场营销渠道和技术服务网络，可为用户提供定制产品和本地化原厂服务，充分满足用户的个性化需求。达梦公司产品已成功应用于金融、电力、航空、通信、电子政务等30多个行业领域。

背景描述在《精益—敏捷项目管理》一书中，使用一个案例将Scrum和看板做对比：有两家公司，第一家使用Scrum进行项目管理，第二家使用kanban进行管理。当两个项目同时出现紧急任务，第一家公司的Scrum团队必须等本次迭代结束，才能将紧急任务插入待办事项的列表中，并一直向PM强调Scrum的原则；第二家公司的kanban团队可以提高突发任务优先级，让团队尽快处理新任务，并向领导传达插入新任务的弊端，提醒以后尽量不插入任务。讨论主题我所在的团队是Scrum团队，我们并不向书中说的那么固执：突发任务毕竟不是很多，当遇到新的紧急任务时，可以优先完成紧急任务，同时将当前迭代一些优先级较低放到下个迭代完成，形成一种任务置换，领导多半也是认可这种做法的。请问使用Scrum的团队，迭代进行中突然插入紧急问题（比如法律约束或其他因素必须尽快执行的问题），你们如何处理？

书籍名称《如何构建敏捷项目管理团队》丽萨·阿金斯著 徐蓓蓓 白云峰 刘江华译讨论主题背景：经历过几个Sprint之后，敏捷开发团队一般都已经学习到一些敏捷开发的基础知识。敏捷开发框架的设计一般以简单为主，所以也易于团队早日上手，也易于精心辅导后的实践。用不了多久，这些敏捷开发流程就会让团队感觉陷入了一个永不停止的仓鼠滑轮中-总是从一个流程到下一个流程，一个Sprint到下一个Sprint，这样的循环一直进行下去，这样的仓鼠滑轮的循环会让团队感觉不停在冲刺枯燥无味。问题：如何能够避免这种情况的发生？书中建议要引导团队设定高绩效目标，去追求高绩效，调动起团队的积极性，激起他们朝着能共同达到的愿景去努力奋斗。这样公司和组织获得更好的成果，拥有了强大的团队，每个成员也掌握了高超的技能并实现了自己的目标，也就是说每个人都能从高绩效中受益。个人观点同意书中的观点，敏捷强调建立学习型组织，通过个人成长和团队成长，这样既能更好的完成任务，也实现了个人的进步，是一个双赢的过程。团队方面：通过回顾实现改进，让团队获得成就感，产生不断前进和改进的动力。个人方面：了解每个人的发展诉求，提供学习的资源，给予支持和鼓励，营造好的学习氛围。形式上可以有结对学习、兴趣小组等，建立在自愿基础上，成员之间技能的相互学习和分享，既提高了个人能力，也为建立全功能的T型团队打下了基础。还有一个大的前提就是团队的工作量是否已经过于饱和，是否有时间和意愿去进行学习和改进，一个迭代中既要求高压高质量完成任务，又要求学习改进有成效是不现实的。从团队培养和建设的角度，学习和改进是一个持续长久的过程，企业要愿意拿出资源去做这件事，这是一个长线的投资。你们的团队实施敏捷一段时间后是什么样的状态，团队有什么变化，欢迎大家留言交流。

一个好的文本编辑器和流畅的编辑体验，是管理协同领域必须的能力，Wiki的富文本编辑器的能力和体验也着实饱受吐槽。近期，开发同学对Wiki编辑器进行了优化升级，经过内部3个多月的调优和内测，预计会在本周五（2月28日）上线。我们的开发同学写了个文章，写的很好，一字不删，原封不动呈现出来--------------正文开始-------------Wiki本次的更新，我们在基本维持原有体验的基础上，做了大量细节体验上的优化和功能上的增强，并增加了一些实用的格式和功能。首先是对工具栏的视觉做了优化，在维持现有按钮顺序的基础上做了小小的调整，并增加了不少新的工具栏按钮。然后是对图片、超链接、表格3个核心模块进行优化。【平滑过渡】考虑到用户已经习惯的交互体验，我们并没有大刀阔斧地修改，而是采取平滑过渡的方案，维持整体交互和视觉，只对其中的不合理之处做微调。这主要体现在工具栏上：将加粗/斜体和文本颜色/背景色放在一起，并且增加下划线/删除线两种常用格式，放在斜体后面；在原有标题1/标题2基础上增加标题3，将标题由平铺改成下拉框形式，并将标题和字体/字号放在一起，放在清除格式按钮后面；将常用的超链接功能从插入下拉框中单独出来，放在表格后面，Wiki/Doc/工作项3个全局链接由之前单独打开的弹框，改成统一的全局链接面板，可在面板中切换3种全局链接。通过以上3个微调动作，在整体顺序不变的情况下，将相似的工具栏按钮放在一起，用户能更轻易找到。【体验优化】通过VoC和华为内部用户的反馈，我们发现一些功能的体验不是很好，因此我们将这部分体验做了优化，主要体现在图片、超链接和表格3个模块。图片的优化图片模块主要做了以下4点优化：优化图片两侧光标，使用户可以轻易地通过点击图片两侧的边缘，将光标定位到图片两侧，从而插入内容，创建图文混排的结构。优化图片对齐功能，将点击图片之后出现在图片下方的属性浮框移除，用户可直接点击工具栏的对齐按钮对图片进行对齐，和文本的对齐一样。优化图片的拉伸体验，支持固定宽高比拉伸，这样图片不会因拉伸而变形，另外对拉伸的宽度做了限制，最大不能超过编辑器的宽度，最小不能小于40px。增加图片预览放大的功能，将鼠标移到图片上将出现预览按钮，点击能查看图片大图，再次点击屏幕可以关闭预览。希望这4点细节上的优化，让图片编辑的体验更加流畅顺滑，用户再也不用担心自己的图片变形啦超链接的优化优化超链接的目的是提升插入和编辑超链接的效率，我们主要从以下几个方面进行优化：将阻断式模态框改成轻量的浮框，鼠标移到超链接上即显示浮框，用户可以轻易地在超链接浮框中修改超链接、访问超链接、删除超链接格式；支持选择文本，然后将该文本变成一个超链接；支持Ctrl+K快捷键插入超链接通过以上3个细节上的优化，能够有效地提升编辑超链接的效率，现在插入一个超链接只需要2s即可完成：选中文本 -> Ctrl+K -> Ctrl+V表格的优化旧版的表格功能其实已经比较强大了，不过还是有一些可优化的点，我们主要针对这些用户用得不爽的点进行优化：优化插入表格的交互，使用可动态扩展的表格面板替代之前的模态弹框；增加表格左右光标，可以更方便地删除表格；支持改变行高/列宽，支持整行/整列的快捷选择；支持多种选择连续单元格的方式，支持像Excel表格那样按住Shift快捷选择连续单元格；优化列比较多的大表格的体验，支持Shift+鼠标滚轮快捷水平滚动表格通过以上5点优化，表格的操作变得简洁、方便操作更高效我们主要从减少操作路径、增加快捷键等方式提升操作效率，主要体现在：支持更丰富的快捷键，比如Ctrl+K插入超链接，Ctrl+Z撤销等；插入表格时使用动态扩展的表格面板代替模态弹框；使用轻量的超链接浮框代替模态弹框，以提升超链接的编辑效率。功能更丰富本次更新增加了下划线、删除线、行内代码、引用这4种文本格式，并增加了撤销/重做功能，方便用户对自己的操作进行"反悔"。另外我们优化了全屏功能，将之前的普通全屏改成沉浸式全屏，让编辑器和工具栏占满整个屏幕，提供不受干扰的沉浸式编辑体验，并且可以听过Esc快捷键随时退出全屏。但是客观的说，从业解决角度看，Web端还无法完全达到和本地端文本编辑器的同样能力，Web端胜在简单轻量后续我们还会继续努力，持续优化，不断提升用户体验，让用户能够始终专注于文档内容本身，提升协同编辑的效率。也欢迎大家继续批评指正，可以在评论中炮轰或吐槽：）

一个好的文本编辑器和流畅的编辑体验，是管理协同领域必须的能力，Wiki的富文本编辑器的能力和体验也着实饱受吐槽。近期，开发同学对Wiki编辑器进行了优化升级，经过内部3个多月的调优和内测，预计会在本周五（2月28日）上线。我们的开发同学写了个文章，写的很好，一字不删，原封不动呈现出来--------------正文开始-------------Wiki本次的更新，我们在基本维持原有体验的基础上，做了大量细节体验上的优化和功能上的增强，并增加了一些实用的格式和功能。首先是对工具栏的视觉做了优化，在维持现有按钮顺序的基础上做了小小的调整，并增加了不少新的工具栏按钮。然后是对图片、超链接、表格3个核心模块进行优化。【平滑过渡】考虑到用户已经习惯的交互体验，我们并没有大刀阔斧地修改，而是采取平滑过渡的方案，维持整体交互和视觉，只对其中的不合理之处做微调。这主要体现在工具栏上：将加粗/斜体和文本颜色/背景色放在一起，并且增加下划线/删除线两种常用格式，放在斜体后面；在原有标题1/标题2基础上增加标题3，将标题由平铺改成下拉框形式，并将标题和字体/字号放在一起，放在清除格式按钮后面；将常用的超链接功能从下拉框中单独出来，放在表格后面，Wiki/Doc/工作项3个全局链接由之前单独打开的弹框，改成统一的全局链接面板，可在面板中切换3种全局链接。通过以上3个微调动作，在整体顺序不变的情况下，将相似的工具栏按钮放在一起，用户能更轻易找到。【体验优化】通过VoC和华为内部用户的反馈，我们发现一些功能的体验不是很好，因此我们将这部分体验做了优化，主要体现在图片、超链接和表格3个模块。图片的优化图片模块主要做了以下4点优化：优化图片两侧光标，使用户可以轻易地通过点击图片两侧的边缘，将光标定位到图片两侧，从而增加内容，创建图文混排的结构。优化图片对齐功能，将点击图片之后出现在图片下方的属性浮框移除，用户可直接点击工具栏的对齐按钮对图片进行对齐，和文本的对齐一样。优化图片的拉伸体验，支持固定宽高比拉伸，这样图片不会因拉伸而变形，另外对拉伸的宽度做了限制，最大不能超过编辑器的宽度，最小不能小于40px。增加图片预览放大的功能，将鼠标移到图片上将出现预览按钮，点击能查看图片大图，再次点击屏幕可以关闭预览。希望这4点细节上的优化，让图片编辑的体验更加流畅顺滑，用户再也不用担心自己的图片变形啦超链接的优化优化超链接的目的是提升新增和编辑超链接的效率，我们主要从以下几个方面进行优化：将阻断式模态框改成轻量的浮框，鼠标移到超链接上即显示浮框，用户可以轻易地在超链接浮框中修改超链接、访问超链接、删除超链接格式；支持选择文本，然后将该文本变成一个超链接；支持Ctrl+K快捷键新增超链接通过以上3个细节上的优化，能够有效地提升编辑超链接的效率，现在新增一个超链接只需要2s即可完成：选中文本 -> Ctrl+K -> Ctrl+V表格的优化旧版的表格功能其实已经比较强大了，不过还是有一些可优化的点，我们主要针对这些用户用得不爽的点进行优化：优化新增表格的交互，使用可动态扩展的表格面板替代之前的模态弹框；增加表格左右光标，可以更方便地删除表格；支持改变行高/列宽，支持整行/整列的快捷选择；支持多种选择连续单元格的方式，支持像Excel表格那样按住Shift快捷选择连续单元格；优化列比较多的大表格的体验，支持Shift+鼠标滚轮快捷水平滚动表格通过以上5点优化，表格的操作变得简洁、方便操作更高效我们主要从减少操作路径、增加快捷键等方式提升操作效率，主要体现在：支持更丰富的快捷键，比如Ctrl+K新增超链接，Ctrl+Z撤销等；新增表格时使用动态扩展的表格面板代替模态弹框；使用轻量的超链接浮框代替模态弹框，以提升超链接的编辑效率。功能更丰富本次更新增加了下划线、删除线、行内代码、引用这4种文本格式，并增加了撤销/重做功能，方便用户对自己的操作进行"反悔"。另外我们优化了全屏功能，将之前的普通全屏改成沉浸式全屏，让编辑器和工具栏占满整个屏幕，提供不受干扰的沉浸式编辑体验，并且可以通过Esc快捷键随时退出全屏。但是客观的说，从业界来看，Web端还无法完全达到和本地端文本编辑器的同样能力，Web端主要还是胜在简单轻量，云端协同，Anywhere & Anytime后续我们还会继续努力，持续优化，不断提升用户体验，让用户能够始终专注于文档内容本身，提升协同编辑的效率。也欢迎大家继续批评指正，可以在评论中炮轰或吐槽：）

书籍名称《如何构建敏捷项目管理团队》丽萨·阿金斯著 徐蓓蓓 白云峰 刘江华译讨论主题场景描述：一位经理向敏捷教练说：“我想团队最近有些士气低落。在昨天的站例会上，我注意到他们没有什么活力。我们得做些什么。也许带他们玩一天来帮助他们充电？”作为敏捷教练要不要阻止？注：敏捷经理指的是团队成员的直属经理、团队所在的开发项目或者平台的管理者、其他具有合作关系的团队的经理，或者整个公司范围内的利益相关人。书中建议告诉经理把这个问题交给团队自己解决，而不是由自己插手代劳。敏捷工作方式中，发现问题和解决问题都应顺其自然。旁观者不需要通过额外干预而让一些事情发生。团队可以通过回顾来解决问题，不要让经理从团队之外的角度“修复”问题。个人观点书中建议是完全从敏捷的角度出发，让团队自组织和自管理，重点强调的是把问题留给团队。在敏捷实施过程中，有些团队不具备自组织和自管理的能力，需要逐步培养和形成，因此关于是否要把问题留给团队要分阶段分情况进行。向敏捷转型是有一个过渡的过程，在初期需要敏捷经理的干预，等到团队真正成长起来后逐步放手。

1      软件介绍conda是一个开源的软件包管理系统和环境管理系统，用于安装多个版本的软件包及其依赖关系，并在它们之间轻松切换。 Conda是为Python程序创建的，适用于 Linux，OS X 和Windows，也可以打包和分发其他软件。版本：1.0.0.2      预置条件服务器类型：TaiShan 2280OS: Centos 7.63      下载安装包安装包有arm版本和x86版本，本节介绍的为ARM版本安装和配置https://github.com/jjhelmus/conda4aarch64/releases/download/1.0.0/c4aarch64_installer-1.0.0-Linux-aarch64.sh4      编译安装4.1      ARM版本4.1.1        安装bash c4aarch64_installer-1.0.0-Linux-aarch64.sh4.1.2        配置source /root/.bashrc在安装的过程中会提示安装配置的文件，source配置对应的文件。5      运行安装成功后即可用conda。conda：conda list查看conda支持的包。如下为ARM版本：

智能自动外呼机器人集成设计参考1    业务场景业务管理员在OIAP上编辑好自动外呼问卷，然后通过外呼任务管理系统，导入外呼样本，创建外呼任务。       系统执行外呼任务，电话接通后直接转接到外呼问卷。       业务管理员导出外呼结果，分析外呼结果。2    逻辑组网                                               3    业务逻辑时序4    二次开发关键点参考4.1  关键注意点4.1.1  IVR在线编排-OIAPOIAP在传统GSL流程的基础上屏蔽了底层复杂的业务处理，提供了简单易用的在线图形编排功能，方便业务管理员快速进行业务流程编排，提供了放音识别、意图处理、条件判断、接口调用等能力。关于ODFS前台获取compainID的关注点：1、SCE流程是直接获取随路数据数据包，将其保存在transin_data这个入参中，会透传给ODFS2、从上次HPS测试看，随路数据格式如下：82333,84,0,,1,44,,TEST_HPS3,T_C0000000000000052_63452,,,1,0,0,075536560389,1,60,15062283276,38,0,0,8275017第一个就是compainID3、然后ODFS通过简单函数来实现：FLOW.transin_data.substring(0,FLOW.transin_data.indexOf(","))4.1.2  自动外呼接口-HPSHPS提供了创建外呼活动、节假日策略等功能，方便ISV快速开发自动外呼管理系统。某ISV基于HPS接口开发的外呼管理系统参考界面：4.2  AICC接口文档地址https://adcloud.sd.huawei.com/dsv-portal-frame-service/#/portalFrame/frame/aicc  

    新型冠状病毒疫情牵动着每个人的心，春节假期临近尾声，基于防疫要求，许多企业陆续启动远程办公。在这个特殊时期，华为云DevCloud限时免费开放项目管理，代码托管，代码检查三大软件开发利器，协助企业远程办公，实现企业员工跨地域软件开发高效协同。使用中有任何问题需要求助，请直接添加DevCloud小助手，我们将一对一实时响应。只需3步，轻松创建需求。第1步：注册华为云账号1.    访问华为云官网，单击页面右上方“注册”按钮。2.    根据界面提示填写基本用户信息并完成注册。已完成注册的账号即为企业管理员。更详细操作指导请参见账号注册第2步：创建项目1.    进入华为云首页，单击“产品 > 开发者 > 项目管理”，进入项目管理产品首页。2.      单击“立即体验”，根据提示输入已注册的账号，进入项目管理首页3.      单击右上角“新建项目”。项目类型包括“Scrum”、“看板”和“DevOps全流程样例项目”。选择不同项目类型，会自动生成对应样例模板，供用户参考和使用，用户也可以新建自己的开发任务。这里以“Scrum”类型为例。4.      设置完项目信息，单击“确定”即完成了一个项目的创建第3步：创建需求进入“Backlog”页面，默认显示“所有工作项”，点击“新建”，选择“Story”在新建页面填写标题、内容及右侧必填的字段，点击“保存”，即可创建需求。  【更多操作】l  帮助文档：n  https://support.huaweicloud.com/productdesc-projectman/devcloud_pdtd_10001.htmll  简介视频：n  教学视频：https://bbs.huaweicloud.com/videos/100748n  项目管理整体简介：https://bbs.huaweicloud.com/videos/100647n  新版看板项目介绍： https://bbs.huaweicloud.com/videos/101825【常见问题及解决方法参考】如何使用Scrum项目？如何使用看板项目？为什么“浏览者”角色可以修改用户标签？为什么管理控制台项目列表中仍显示删除的项目？是否有项目置顶功能？需求规划将Story拽成Feature，是否可以恢复？迭代的百分比是如何计算的？分配或变更任务时，是否可以通过第三方IM提供通知？Backlog中数据为什么为空？被指派的处理人可以修改工作项的哪些内容？如何设置成员查看对方项目信息？Scrum项目如何导出全部类型的工作项？如何限制用户“新建项目”？项目经理如何修改某个任务的预估时间和实际时间？DevCloud项目管理的工作项怎么分配给多个人员？已添加的项目成员登录后查看不到项目？Epic、Feature、Story、Task有不同状态，为什么仪表盘显示数据都是0？为什么仪表盘个人工时中每个人的Story工作量显示0？如何了解项目管理中是什么项目在扣费？ 【更多帮助渠道】1、 通过华为云DevCloud VOC系统反馈：https://devcloud.huaweicloud.com/voc/add2、 人工服务，扫码加微信公众号交流： 3、 通过华为云论坛发帖交流：https://bbs.huaweicloud.com/forum/forum-682-1.html

其实详细工时的特性已经上线好几个月了，一来确实比较忙（瞎忙），二来从产品经理的角度看，一直觉得详细工时是个很小的功能，算不上华为语境下的Tier 1特性好吧，以上都是借口，其实是我比较懒。。。呵呵但是，有些意外的发现，用户对工时的使用挺多的，很多用户甚至还夸奖了这个特性，不少用户最近还提了很多需求，大大超出我的预期，当然也有用户对于这个功能有些不解，觉得增加了门槛。那么就不能偷懒了，恰好最近因为左脚骨折，虽然还在坚持上班，但是同事们看我都觉得这是个病人，所以就有些可以自己支配的时间了，趁今天把我对工时的理解，和近期工时的功能介绍一下。Part1. 研发人员的工时之我见预警：如下言论主观意识非常浓烈，写的非常没有条理。，完全是个人心路历程的废话，如果大家希望看到“详细工时”的功能介绍，可以直接跳转到Part2.从我个人的工作经历看，我其实个人非常不喜欢工时这个机制，尤其是对于软件研发人员，我的主观看法，一直认为软件研发活动是个智力活动，不是机械劳动，也不是重复性的工作，可能有的时候一天也写不了一行代码，因为一直在琢磨，也可能一天写的代码狂多。而工时这个机制，来源于最早的制造业，计件计时付工资的模式，这种模式因为是这种工作的产出是机械的强可重复性的。这儿也顺便**一下，华为的研发工时，华为其实也有研发工时这个机制，最早也非常的复杂填写机制，一天多少小时写代码了，多少小时写设计了，开会多长时间了，我个人一直非常抵制，公司的研发员工也反对意见非常大，随着公司的氛围和管理机制变化，工时这个机制后面经过好多次优化和简化，虽然还要填工时，但是已经变成后台自动了，根据你的角色和项目，根据你考勤到岗自动填写，工时的分类（写代码，还是设计，还是产品管理）都固定几类。比如我是云服务产品经理，那么我每天的工时类型都是一类，也就是8个小时等，就不去细分你这8个小时具体是做什么的....我一直觉得工时是公司在监视你，是**裸的资本主义雇佣关系(呵呵，其实本来就是这样啊)，所以很反感。但是因为我有一段经历是弄公司的整体研发变革，我有机会深入的了解为什么华为这样的公司，还要用工时这个我觉得落后的不适用于软件开发的机制。其实道理也不复杂，还是为了项目预算和成本的一些考虑。所以，我在做项目管理服务产品经理后，也一直希望劝服我的客户们，应该弱化使用工时这个机制，给软件开发人员予以信任，所以总是不厌其烦的在各种布道中去传递软件开发是智力活动。项目管理服务最早提供的工时功能是在每个工作项上有一个实际工时字段，一个预计工时字段。业界类似的产品也是这种为主。但是，后来很多客户都灵魂拷问我一个VoC（Voice of Customer）：一个工作项有多个人处理，由于不是按每个人花费在这个工作项上的工时填写的，每个人的工时花费都被抹了啊，这样不公平啊。同时后面我们上线自定义统计报表后，很多用户满心喜欢，因为可以统计成员的工时了，结果发现报表是有，但是统计到的那个成员是当前作为处理人的成员，相当于之前处理人的花费工时都被记录到最后一个处理人那儿了。由于工时的诉求特别集中，我也开始反思，我于是和很多用户开始联系（当面或电话或微信），我逐渐明白了，很多企业是真的需要通过项目成员的进行成本、预算、项目收益，甚至成员绩效的管理。很多企业的管理者都让我换位思考一下，如果你是一个项目经理，一个企业的管理者，怎么核算每个项目的投入成本，怎么评估每个成员的绩效。我开始理解了，华为和很多我们的企业用户不一样，我们的不少企业用户都还在生存爬升阶段，规模不算大，产品线单一，扛风险不强，而软件研发人员往往是这些企业最大的成本。我后来利用有些机会，也和很多同行类似产品的产品经理交流，因为他们也是大厂出身，他们一早也是和我们类似的认识，觉得研发人员就不应该填写工时。可是他们和客户交流后，也跟我一样产生了反思感。痛定思痛，我们在开发团队人力管道有限的情况下，还是决定调高详细工时的优先级，大概在去年10月份就上线了，悄然上线，部分用户使用后持续给我们反馈，我们也持续迭代改了几版，也补齐了大家最想要的成员工时统计分析。Part 2. 详细工时的功能使用说明 产品设计的基本逻辑。我们不是做一个独立的工时系统，我们的工时还是基于现有的产品功能，依托于工作项。我们认为工作项就是你需要完成的工作，你把你花费在这个工作项上的时间填写为工时即可。因此还是主要面向使用软件开发的企业使用。我们定位于是工作项的详细工时，原先工作项上的“实际工时”其实是这个工作项的总工时。如果一个工作项不填写任何的详细工时，用户可以直接填写工作项的“实际工时”，如果一个工作项填写了详细工时，那么工作项的“实际工时”字段就会自动累加所有的详细工时，同时用户也不能再直接改“实际工时”这个字段了。      2. “详细工时”的使用说明   2.1 通过工作项的详情页，进行详细工时的填写。    选择填写工时     选择工时的时间：可以选择一个时间段，从某天到某天，也可以选择是否包含周末（周末也填工时，这是996还是997？：），希望大家都不勾选这个） 填写工时记录：这儿有两个工时选项，如果是选择“总数”，那么系统会被你填写的工时值平均分到你填写时间范围的每一天。举个例子，如果你选择的时间是01-16 到 01-17，你填写的工时值是10，那么系统会自动生成两条记录，01-16 5人时，01-17 5人时如果选择“每天”，那么系统会认为你每天都是这个值。举个例子，如果你选择的是01-16 到 01-17，填写的工时值是10，那么系统会自动生成两条记录，01-16 10人时，01-17 10人时。（每天工作10小时？：））填写 可选填工时类型：系统预置了一些研发领域常见的工时类型，如前端开发，后端开发，测试验证，缺陷修复等可选填工时内容。可以填写更多工作时间花费的描述下图是我填写的一个样样例，我选择了“总计“，填了工时值为1 。       2.2  列表模式快捷填写工时。在各个工作项的列表模式下，如果修改工作项状态时，也可以及时填写工时。因为通常一个处理人修改工作项状态，也通常是他要把工作项传递给下一个处理人的时候，因此这个时候也可以顺便把自己花费的时间一并填写列表模式下，修改工作项状态，在原有的弹窗中新增了“是否填写工时”的选项勾选填写工时的选项后，会增加类似的工时信息填写3. 详细工时的覆盖规则详细工时的记录是可以改的，也可以删除，对于同一天的同一个人的工时有一个基本规则：同一天的同一个人的相同工作项类型的工时，只能有一条记录，会使用最新的值覆盖前值如下图，我在1-17有两条工时记录，但是因为工时类型不同，因此是允许的道理很简单，同一天基于同样的工作就一条记录就可以了。4. 详细工时的填写权限我们遵循统一的权限控制机制：如果一个项目成员拥有这个工作项的编辑权限，那么他就可以填写这个工作项的详细工时，不同的企业可以配置不同角色的权限。系统默认的“开发人员”角色举例说明一下。如果项目成员的角色是默认的开发人员，那么根据默认的角色机制。这个项目成员对于在他名下的工作项是可以编辑的，因此他可以填写这些工作项的工时。但是默认权限他没有编辑其他处理人的工作项权限，因此他无法填写其他工作项的详细工时。如果企业使用了这种角色配置，项目成员应该在切换处理人或状态时，及时填写自己花费的工时，避免一旦移交给其他处理人后，自己就没有权限填写了工时。当然企业也可以调整一下“开发人员”的权限，在项目设置中可以修改。5. 工作项的“实际工时”前面介绍了，一旦填写了详细工时，为了避免工作项的总实际工时被修改，而导致大家每个人的详细工时无效了，因此一旦有了详细工时，工作项的“实际工时”字段就会自动变成禁止修改的自动计算状态，会自动统计累加本工作项的详细工时的值，这样也方便大家的工作项实际工时统计，如下图所示：当然，如果没有填写详细工时，那么这个工作项的实际工时也还是可以像以前那样手工修改。6. 有子工作项的 “实际工时”如果一个工作项有子工作项，且它自己也有详细工时，那么这个工作项的“实际工时”= 其自身的详细工时累加 + 所有子工作项的“实际工时”我们来看个例子，如下Story下有一个Task，这个Task也填写了详细工时，这个Task的实际工时等于两条详细工时的累加值。那么对于父工作项的Story，它的工时就变成了3小时，它自己的1个小时 + 子工作项Task的2个小时。7. 项目成员工时的统计报表如果使用详细工时后，那么项目成员工时的统计就会非常准确的统计到每个人在每个工作项的时间花费，进入项目的“统计报表”菜单，我们这次特意为详细工时增加了一个可自定义的项目成员工时统计报表进入后，可以选择要分析的成员清单，可以全选也可以按角色也可以按照不同维度进行对比，比如迭代，重要程度，比如选择了“重要程度”，就不仅可以看到每个成员的工时，还可以看到这些成员的工时在不同重要程度工作项上的分布，比如下图，我在一般级别的工作项上的工时是11，在提示的工作项上的花费工时是31柱状图的下面还有汇总表格也可以选择导出统计值或者导出明细表，进行更详细的线下分析Part.3 写作最后1. 当前我们只在Scrum项目类型提供了详细工时，我们近期会在“新看板项目类型”也补充上这个功能特性。2. 针对开始有客户希望能通过API获取成员详细工时的需求，我们也在规划，当然这需要客户自己进行一些基于API的二次开发了。欢迎大家在评论中反馈给我们更多的意见本文写于 1-17日，也提前祝大家新春快乐！一个左脚骨折打着石膏的恒少