专业做家政网站,微信开店小程序怎么弄,网站开发制作包括哪些的基本流程,wordpress如何注册团队成员协作#xff0c;利用项目数据#xff0c;分析根本原因#xff0c;制定纠正措施#xff0c;并立马尝试#xff0c;判断是否有效#xff0c;是改善的“基本功”。10-12章会探索里面的注意事项#xff0c;13章会看两家公司的实施情况和常见问题。
如果已经获得高层…团队成员协作利用项目数据分析根本原因制定纠正措施并立马尝试判断是否有效是改善的“基本功”。10-12章会探索里面的注意事项13章会看两家公司的实施情况和常见问题。
如果已经获得高层支持她也赞同目前返工工作量太多并愿意投入资源进行过程改进我们首先应该针对哪些方面进行改进呢
软件开发的特点是超过95%的成本都是人力成本。因此我建议利用二八(20/80)原则继续识别哪类工作的占比最高详见附件。
请把过去一年的软件开发项目按照不同工种占项目总工作量的比例从多到少排个序。 编码与代码设计。交付后的所有工作包括维护、更新与缺陷修正。交付前的评审静态扫描测试与缺陷修正。项目管理与监控。
可以参考软件开发度量专家卡铂斯•琼斯 (Capers Jones) 先生在2012年的研究详见附件中的“开发项目工作量(成本)分布”看看你的选择与典型分布有多大差距。 软件开发项目最大的工作量通常是花在找出与修正缺陷上开发里的“测试与评审”Capers Jones 发现对于一个超过10,000个功能点、计划使用25年的大型系统来说有接近一半的工作量是与找出并修正缺陷相关。 很多项目中的缺陷大部分还是到后期才发现这导致了大量返工。如果能提前发现并解决这些缺陷就可以大大降低研发成本(不仅仅是提升产品质量)。 对于一个软件项目来说发现缺陷最多的是在系统测试阶段其次是在验收测试阶段很多公司都是如此 但很多开发人员误以为编码是项目的主要工作却忽视了大量因质量问题引起的返工。所以只有当管理层意识到尽早发现并排除缺陷的重要性并引起重视公司才有机会改进。
有些偏业务的领导可能会质疑客户不一定关注缺陷密度只要达到可接受的水平就可以了。 我解释“在软件开发中减少后期测试才发现的缺陷不仅仅能提升产品质量更重要的是能降低研发的总工作量所以最终能帮助公司省钱减少开发人员加班。”详见附件“公司高层不一定关注质量”
怎样开始
没有度量便无法谈改进所以应先考虑如何采集修复缺陷相关的数据。然而在探索数据收集与分析之前我们更需要先确定度量分析的策略。
但在探索数据收集与分析之前我们更需要先想好度量分析的策略。
请问你会使用以下哪种度量分析策略 A由公司的过程改进组EPG专员设计并执行过程改进的度量计划包括收集哪些数据、如何收集以及如何分析。然后按计划收集各项目团队的数据进行总体分析并制定公司的改进方案。 B将数据收集与分析的任务下放到各团队让团队制定自己的改进方案。
如果你认为度量与分析需要专业知识要由专人来做就请选择A并考虑以下几点
提供数据的人需要很长时间才能收到反馈。例如从团队成员提交里程碑数据到项目经理填报再由度量分析人员收集、整理多个项目的数据可能需要一到两个月时间。再经过数据分析管理层评审最终到团队成员收到反馈可能共两三个月。由于每位提供数据者都希望尽快得到反馈如果反馈的时间很长那么团队成员还会有动力继续收集数据吗缺乏动力还会引发其他问题。无法确保数据的准确性导致分析没有意义。如果这些指标用于公司考核KPI情况会更糟。度量分析人员需要什么数据提供数据的人都会按理想的指标填写反正公司级的总体分析人员也无法验证数据的准确性。假定各项目的特性或问题根因都是类似的。
与某质量部经理的对话 经理从去年开始我们进行度量分析以来就发现员工会对数据造假导致结果失真。度量什么他们就造假什么所以我们想通过工具代替人工不仅能提升效率还能帮助判断数据是否合理。现在我们的主管很反感度量因为每次度量就会有人造假——大家了解算法原理后就开始造假。比如我们搞了红黑榜但很多人聪明得很就会想办法作弊。我们有很多数据统计分析比如看测试用例与需求的比例。尽管客户发现的缺陷比例降低了但由于我们对质量特别注重产品经过多年的逐步演化过程很复杂导致软件缺陷的修复很耗时客户不太满意。而且公司要求交付的频率要比以前高了很多我们团队做这些分析都忙不过来所以希望利用自动化工具加快速度。 我除了数据收集问题你们这种总体分析策略可能还有另一个问题没有考虑各个项目的特性并不一样。现在你们对几十个项目的总体趋势进行分析但每个项目的根本原因很可能不同。比如同样是测试用例比例数你们采集的数据范围从最低的0.3到最高的超过200但你们取平均值5.1来做分析。
但如果把数据分析下放到团队自己做便灵活多了也正因为他们有参与收集和分析讨论过程改进组便可以节省很多沟通数据收集成本与失真。反而应该重新定位自己是内部老师辅导团队怎么做好数据分析效果会更好。 你可能疑问“团队自己讨论便可以得到改进吗不需要领导监督” 如果团队有能力就应该放手让他们自己收集数据、利用数据进行分析并做出改进。质量经理应把自己重新定位为团队的教练去辅导他们如何收集与分析数据。千万不要以为这项工作会比以前自己做分析更轻松其实需要更熟悉整个过程才能真正辅导好团队。要公司从定性管理提升到定量管理最大的挑战并非数据分析反而是要让管理层了解并赞同需要让团队自主分析数据自己寻找纠正措施。
下一章会继续探索团队协作与分析根因团队如何利用迭代冲刺数据在敏捷冲刺回顾做好根因分析得到提升。
附件
二八原则(80/20)
帕里托(Pareto) 16世纪意大利威尼斯人他发现虽然威尼斯很富有但财富并非平均分布80%财富在20%手里他也发现很多其他分布都非平均。 因为过程改进需要公司额外的资源投入必须有针对性地找出最容易取得改进效果的原因才可能拥有最大的成功机会。所以应该利用二八原则去识别影响最大的几个因素. 以上图为例原本A类问题出现最多针对这类问题做过程改进之后 A类问题就少了很多下一轮便应针对最多的B类问题做改进。 有些人以为只需要对某个维度做分析即可并没有从多个维度进行分析。例如某纸制产品工厂会计数据显示8成的产品问题相关成本都归属于5类。
例如某纸制产品工厂会计数据显示因纸质量问题被客户退货类的损失最大共5560千美元占总损失的61%。针对这类损失发现里面八成是由6个产品引起共有53个产品共4480千美元占5560的 80%。针对这6个产品把损失按缺陷种类细分发现B产品容易断裂缺陷(Tear)的占比最高612千美元我们就应该针对这一问题研究如何改善。 开发项目工作量成本分布
参考Capers Jones先生2012的例子汇总成以下比例 测试与评审一般占开发工作量的30%测试与评审一般占总质量成本包括发布后维护与改缺陷工作的66%把所有工作量都加起来测试与评审还是占最大(26%)编码第二 (22%)。
注意测试与评审包括所有与缺陷相关的成本包括单元测试、静态扫描、评审与相关的缺陷修正而编码只包括设计与编写代码部分。例如有些人会觉得比例应该是开发30%测试和Bug修改25%需求和设计20%项目管理和沟通20%文档5%。但如果按上面的定义开发部分很可能已包括单元测试、静态扫描与改正缺陷工作如把这些都归到测试评审里会变回类似上图的比例。
公司高层不一定关注质量
QA 问在传统 IT的 公司无论是 缺陷(Bug) 率还是其他质量指标对业务的影响的相关性都不容易度量只有重大事件才会让公司在客户面前失去信任所以高层不会真正的重视质量。答理解但软件BUG的暴露越往后返工的工作量就越高而且是几何级数的增加例如在单元测试或评审发现都可以1人时内解决系统测试通常要花起码20人时客户使用后才发现便更高。但在很多IT公司大部分缺陷都是在系统测试、甚至到验收测试才发现。如果能把软件缺陷的发现前移把通过系统测试、验收测试发现的缺陷减半便可以大量降低质量成本提升开发生产率。所以我建议利用缺陷数估算返工的工作量来引起老板重视。而不是仅仅说降低缺陷率
