提高工作效率的方法不正确的是wordpress分类设置seo

提高工作效率的方法不正确的是,wordpress分类设置seo,城乡建设网站证件查询系统,热狗seo优化外包1.引言软件开发方法#xff0c;尤其是敏捷开发方法#xff0c;正在越来越多地借鉴精益生产中的管理理念#xff0c;其中主要的核心就是持续改进。要想持续改进#xff0c;除了对改进方向的经验性认识以外#xff0c;可以量化的改进目标也是一个无法回避的环节。在大规模实…1.引言软件开发方法尤其是敏捷开发方法正在越来越多地借鉴精益生产中的管理理念其中主要的核心就是持续改进。要想持续改进除了对改进方向的经验性认识以外可以量化的改进目标也是一个无法回避的环节。在大规模实施精益管理的过程中如何找到合理的度量并合理利用这些度量始终是一个难题。度量是在一个特定组织上下文中形成的一系列共识。在一个软件开发组织里度量统一的不仅仅是度量单位、度量对象、度量手段更重要的是统一对目标的认识。度量是将经验模型向量化模型进行匹配的尝试。量化模型有个非常重要的优势——方便进行比较1)跟自己比较持续改进持续超越自己就需要比较自己发生的变化2)横向比较是激励大家提升效率的手段也可以知道公司在行业中的位置。但是软件开发中的很多信息都难以用量化模型来描述当前流行的各种成熟度模式如CMMI模型都是将经验模型向量化模型匹配这种量化模型本身具有局限性度量的结果来源于对大量上下文信息的汇总、过滤和抽象这种简化容易让人们在度量中失去了度量发生的场景细分以至于为了度量而度量。度量是包含人、流程、组织和工具的一个动态系统。如果把软件开发组织看作一个动态的系统度量实际是作为反馈机制来对这个系统产生作用。度量不是软件开发固有的活动作为一个组织来说应该积极地评估当前的度量活动的成本分析是否真正为达成业务目标发挥着价值从而确保运行度量体系的投入产出是在一个合理的水平。软件开发中并不所有的目的都要有度量来达成度量也不是帮助达成所有目标的灵丹妙药。2.度量对象为了更加系统地对度量的对象做出分析需要对交付对象的粒度有个合理的定义。合适的粒度首先需要寻找一个合适的方式来拆分度量的对象软件。怎么去评估一个功能是否完成需要对完成做出清晰的定义使开发和管理人员对完成有统一的认识。建议使用一个重要的概念——DoDDefinition of Done。DoD是软件生产所需活动的一个检查列表这些活动包括需求澄清、功能设计、编码、单元测试、功能测试、联调、集成测试还有一些暂时没有考虑的活动如前期的需求发现、体验设计后期的部署、线上反馈等。DoD的计划分成3个层面1特性/用户故障DoD2迭代DoD3发布DoD。对于一个软件开发组织而言定义不同层面的DoD分别包括什么活动取决于多项因素例如产品本身的复杂度、业界适用的开发和测试手段以及团队和组织本身的复杂度。团队对DoD定义达成共识并将其明确地记录下来严格执行。随着团队交付能力的提升DoD应该逐渐演进。3.指标体系3.1价值可以从两个角度来提高交付的价值1识别和拆分高价值特性小批量交付2减少和消除低价值特性。提升软件交付的价值首先在于优先交付高价值的产品和特性。精益软件开发提倡使用拉动pull的方式尽可能以小批量的方式交付市场已经发出强烈、确认需求信号的特性。较大的需求粒度和批量交付会带来的一系列潜在的问题“绑架”高价值特性导致高价值特性很难“加塞”。从交付价值上看排队加塞并一定是坏事。环境会发生变化团队也会由于获得了更多的信息和知识而改变先前的判断这些不可避免的因素都可能导致在交付过程中发现更高价值的特性插队行为在大粒度、大批量的交付模式下就会导致项目延误甚至导致许多半成品。增量投入方法试图将系统分解程基于客户价值的单元——最小可销售特性MMF一个能快速交换给客户并提供一定市场价值的相对独立的特性。依据价值排序小批量、高频率地交付是提高一个组织价值交付速度的有效途径。交付价值的度量可以把产生价值的速度作为指标分为发布前和发布后。1发布前评估待开发的特性。价值的量化手段时通过估算在产品各个阶段的投入以及产出以贴现现金流的方式来计算产品生命周期或是路线图中产生的净现值NPV。准确地度量价值的绝对值很难实施也不是度量的目的是为了引导开发组织更快、更早地交付价值而度量。这是一个定价模型。在每个阶段、开发部门、支持部门和产品管理部门或是市场销售部门一起协商对下个阶段要开发的产品、版本、特性和子特性进行定价。评估过程应该要包含非特性类工作如软件可靠性、可用性的改造性工作。2发布后进行价值验证度量特性在生产环境中产生的价值。价值可以是收入、用户增加、用户粘性等方式体现也可以是品牌声誉、技术竞争力等无形资产的提升。通过分析产品和特性的价值我们能够识别出潜在的问题发现潜在的高附加值产品和特性产生有根据的行动。3.2响应速度交付周期的定义是一个流程或项目启动到其结果显现所需的时间。关注交付周期的缩短是精益理念的一个重要组成部分。提升市场响应速度应该关注版本、特性、用户故事和缺陷这四个层面交付单元的周期数据。1版本发布从项目立项到发布的时间是端到端的发布周期其结果通常是交付速率和响应速度的一个权衡。2特性发布在特性层面上从需求定义到集成测试、验收测试、回归测试完成的周期基本上代表了一个开发组织响应市场需求的最快速度。3用户故事平均周期从用户故事被纳入迭代计划经过分析、开发、测试等环节到被验收的时间这是一个最小的端到端工作单元在一个团队中流转的时间。4缺陷生命周期缺陷的平均生命周期代表团队对测试、运维的响应速度。缺陷定位和修复周期通常也意味着代码的可维护性还有自动化测试保护网的完善性。对于版本发布层面通常使用价值流图VSM-Value Steam Mapping如下图来分析一个流程端到端的效率。1识别目标产品或是共享流程的产品系列。2定义流程的范围使用标准的符号描述当前实际运行的价值流图加工环节、等待队列、信息流等3评估分析当前价值流图尽可能到现场去观察并获取信息识别出是哪些浪费在阻止系统形成理想的流动Flow状态分辨潜在的改进点。4绘制未来理想情况的价值流图。5引入各方干系人通过结构化的方法讨论并寻求接近理想价值流的解决方案从而制定行动计划。6定期召开干系人会议通过评估初始的价值流图、最新的价值流以及期望的价值流讨论行动进展。对于特性、故事、缺陷层面关注的是开发执行过程中的状态通过观察在软件开发生命周期中某个时间点的指标数据分析影响交付响应速度的因素累积流图Cumulative Flow Diagram如下图是一个颇为有效的手段。累积流图早期出现在排队理论里用来呈现在一段时间范围内处于不同工作环节或阶段的工作队列的大小。通常把软件开发的工作队列称为backlog队列中每个工作单元的生命周期一般会包含分析、开发、验证等不同的阶段和状态。开发团队通过记录工作单元状态变化的各个时间点并基于这些信息绘制累计流量图。没有完成的工作是半成品 WIPWork In Progress WIP的数量直接影响到交付周期和交付时间点的确定性。交付周期和交付时间点对于当前版本来说是个结果数据处于半成品状态的工作量就成了预警交付周期和交付时间点的有效信号。在迭代交付模型中半成品的增多意味着交付时间点的不确定性增强。以上的价值流图VSM和累计流量图CFD两种手段很容易就能帮助我们发现开发过程中的瓶颈、等待、返工、库存以及一些对最终产品没有价值的活动对响应周期的影响。3.3 交付速度交付速率是单位规模组织在单位时间内所能交付的软件规模度量包含两个方面1)迭代速率团队在一个迭代中完成的用户故事点数。实践中通常用连续2~3个迭代的平均值来指示一个团队的速率。为了确保速率计算结果能比较真实地反映未来的风险只要没有通过DoD质量保障手段检验的特性其工作量都不应当被计算在当前迭代完成的速率里。2节奏指标代码合入频率核构建频率。只有成功通过自动构建里的各项验证活动的代码才能被计入速率的统计。节奏代表了代码速率的稳定性和可靠程度稳定的节奏通常也意味者进度的稳定和质量的稳定。节奏还代表了反馈的周期快速合入代码并验证意味着更早地发现存在的问题减少由于把问题留到后面所带来的更加高昂的定位和解决成本。如果把软件开发组织的活动看作是一个动态的系统提高交付速度就是要提高系统能力方法主要有3个方面1提高个体的交付能力2优化系统的结构3减少交付活动中的浪费。3.4质量精益专注在缺陷发生的源头将其发现并解决通过减少缺陷在价值链上流向下一个环节的可能性从而减少缺陷带来的成本。为了达成目标每个工作环节都应该有最低的质量要求。质量属性分为功能质量和结构质量1功能质量衡量的是软件符合客户、用户的需要和期望也就是对其使用场景、使用目的的符合程度此外还包括软件在特定硬件、操作系统、浏览器等环境上运行相关的性质2结构质量属于软件的静态性质衡量的是在代码、设计层面上软件是否符合非功能的需求比如可靠性可维护性、可移植性等。这些属性又分为外部质量和内部质量两个大类。提升内部质量的动力来源于对于生命周期较长的产品降低其持续开发的成本对于当前版本来说提供开发进度的可靠性降低后端测试周期长度和工作量的不确定性。影响到内部质量的原因之一是技术债。技术债指的是软件开发组织或个人在开发和设计的时候选择了权宜之计以取得短期的方便快捷却给日后带来额外的代价。用债务这样一个财务术语来隐喻不良的软件架构和代码所带来的后果目的是为了引入“利息”的概念。技术债指的是增加或维护新特性带来的成本问题这些成本通常随时间而增加。可以用一个公式对技术债带来的成本进行一个大致的计算作为一个趋势性的度量指标为相关人员决定是否要采取干预性措施提供有效的信号。综合技术债(10%轻微问题数25%普通问题数50%严重问题数)*平均修复时间(小时)*成本/小时。另外一些节奏性指标也能对产品的质量趋势提示指示性的信息构建成功率构建成功率高意味项目后期的风险降低分解到构建的各个环节包含了编译通过率、代码规范通过率、测试通过率、集成频率等。开发速率趋势大幅波动的开发速率通常意味着开发过程中的瓶颈或是技术/过程中的障碍我们可以通过观察迭代速率来了解这方面的情况。外部质量涉及到产品质量的度量和开发过程质量的提升。产品质量的度量包括满意度是产品交付到用户手中用户直接使用之后的感觉和反应通常有直接和间接两种方式来度量。直接方式是试图直接度量用户正面和负面的反应。间接方式可以以用户感知的产品可靠性和故障成本来衡量。开发过程的质量是产生可预见的产品质量的基础提升的方法有缺陷防范、更早地发现缺陷、减少回归缺陷。1缺陷的防范是一个反馈的过程应该定期从测试或用户报出的缺陷中抽样选取一些典型或严重缺陷运用5why等技术分析是否可以通过某些方式来防范而要度量在多大程度上防范了缺陷实际就是度量反馈机制的有效性。2缺陷的排除也是一个反馈的过程大多数组织当中发现缺陷的时间通常都比较滞后通过评审、走读等方式能评审发生变化的一部分代码但很难判断出系统其他部分可能受到的影响最后的结果就是仍然把测试作为最主要的缺陷发现方法。更早地发现和排除缺陷意味着必须加快反馈速度。迭代开发模式地一个重要意图就是缩短从问题产生到发现到排除的时间从而降低成本和项目风险。3)想以稳定的节奏达成快速反馈、快速发布的交付目标前提条件就是能够以低成本快速地进行全面有效地验证自动化测试的价值日渐突出。3.5能力如果把软件开发活动看作一个动态系统提高系统能力的一个方面就是提高团队中个体的交付能力。个人能力主要关注三个方面1技术能力解决问题并完成任务的能力也就是我们常说的把事情搞定的能力。2首创能力产生想法并将其实现的能力这项能力跟主动、创新相关。3社交能力与其他人协作过程中运用并发挥其技术能力的能力比如协作、沟通、主动、辅导、领导力。当产品复杂到一定程度需要大规模团队协作的时候组建有端到端交付能力的全功能团队培养覆盖多项能力-学习型组织项领域能力的多面手是减少开发瓶颈、提升交付效率和质量的关键。4.结语《代码大全》作者史蒂夫·麦康奈尔说过“不要指望任何单个维度的生产力指标能够给你一个关于生产效率的完善图景。”简单的度量数据并不能将我们直接引向结论更多时候是帮助组织和团队观察开发过程中实际发生的活动将观察结果和预期相对照提出有价值的问题以做出判断产生有效的行动。通过这样的一个正向反馈持续学习持续改进我们的开发方法。成功的度量体系建设一定是演进式的。本文内容摘至《精益软件度量-实践者的观察与思考》。