矫捷自组织团队，还需求QA吗，QA能为团队做/带来什么……？

雪中狐影ξ · 发表于 2023-2-24 21:16:14

矫健自构造团队，借需要QA吗，QA能为团队干/戴去甚么……？

rnlT · 发表于 2023-2-24 21:16:51

关注微信公众号【赛希咨询】，提前了解更多精彩内容！

敏捷开发模型现在已经被越来越多的公司熟知并使用，很多公司会选择敏捷开发模式的转型，其主要目的就是为了不断适应变化以及客户快速交付的诉求。为什么敏捷开发能够被诸多大众接受？可以从两个维度来看：
首先，从开发人员角度，他们肯定乐意接受这个变化，接受这种开发模式带来的益处。因为他们可以将部分精力从之前繁琐的过程和大量的文档工作中释放出来，更能够全身心地投入到代码开发的工作中。
其次，从客户角度，敏捷开发可以让客户不断看到新功能。相比之前开发模式到一段时间或者上线才能够看到完整功能，敏捷开发算是提升了一大步。这个模式能够尽早地让客户参与进来，并可以及时地进行纠偏。
看到上面的这些变化，我们会发现敏捷开发实际上对一类人的要求变高了，这类人就是QA人员。
为什么这么说？因为我们知道，目前大多数软件公司选用的开发模型是瀑布模式。对于瀑布模式，它的特点是在开发过程中，开发只需要提供一个稳定的测试版本和稳定的需求给到测试和QA。但是，如果按照敏捷的开发模式，你会发现没有所谓的稳定版本。QA需要对一个不断在变化的过程负责，没有大量时间部署和采取自动化的环境和架构，这无形中大大增加了QA的工作难度。
但对开发来讲，可以把精力从繁琐的文档和流程上释放出来，发挥想象和创意来提供更好的解决方案。所以这种高效运转，对QA提出更高的要求。
早期文章中我介绍过CMMI中的QA角色，在CMMI模型中我将QA看作是4类角色：老师、医生、警察、宣传员。在CMMI过程改进的历程中，我们需要这么一位QA，充分发挥QA的作用和职责，这是CMMI过程改进中质量管理体系良好运转的基础。QA在平时的工作中要不断地在老师，医生，警察，宣传员角色中进行切换，发挥各个角色的强项，并全生命周期的参与项目。
点击阅读文章—
赛希咨询：假如QA没有原则今天我们主要谈的是敏捷开发中的QA，如何看待他的地位和作用？
站在敏捷开发的角度看QA人员，也可以看作三种层级的角色，在敏捷开发转型过程的不同阶段，QA的角色定位和作用也是逐层深入：
1、质量保证

这个层级的角色职责是最基础的岗位要求，总体就是需要我们最终交给客户的软件产品是满足客户需求的，可以正常使用的，简单讲就是做好基础的质量保障工作。例如，在敏捷开发中参与单元测试的审查，审查单元测试的覆盖率，跟进审查的结果，调整单元测试以及检查后续接口测试和回归测试的覆盖率等。
我们知道大多数的敏捷开发中，单元测试用例和接口测试用例编写者都是开发人员，需要QA从他的维度来保证代码质量。那么如何保证？开发人员关注测试覆盖，QA关注的重点在测试的边界值，关注异常处理的解决等。
这个角色定位通常处于敏捷转型的初期，测试工作可能还是手工测试为主，QA人员也可能只是兼职参与。
虽然敏捷开发团队的交付周期缩短了，变成了2-3周一个周期，但团队成员还是喜欢原来瀑布开发模型固有的阶段式方式合作，任务一环扣一环，敏捷形式上变成了小瀑布，不同角色只关注自己不要出问题，缺乏团队质量认识，只关注自己跟前的一亩三分地，整体效率也不高。
在这样的情况下，需要把质量把控统一到一个角色上刻不容缓，需要有QA（质量保证）这个角色。敏捷 QA 流程必须严格遵守，从需求分析到生产环境，QA需要参与每一个环节，跟多个角色进行充分地沟通与合作，确保交付给客户的产品可以正常使用的。
2、质量分析

这个层级的QA工作重点是质量分析，敏捷开发的核心就是小版本迭代，快速出版本，所以项目一般会延续多个版本。
项目过程质量可以在每个sprint结束后均有对应的质量数据输出，经过一系列迭代后，可以看出这个项目的质量趋势。如果同期有多个项目在进行，那么也可以通过质量数据的对比，得出各个项目的质量优劣，同时辅以图表来直观分析对比。例如：常见的有质量趋势分析，质量波动对比等。
当然，质量分析离不开工具的支持。例如，我可以使用了项目管理工具进行项目管理，管理需求和开发过程；使用QC工具计划测试时间和测试次数等，在迭代结束后只要花少量的时间就可以进行快速统计质量数据，迭代质量数据也可以呈现出来。包括：开发效率、版本不良率、上线BUG遗留数等，QA在很短时间内就可以统计出项目的质量分数并进行后续分析。
这个职责定位通常处于执行期，到了这个时期，随着硬件设施、软件工具的不断投入，团队成员之间合作不断默契，整体研发效率稳中有升。
敏捷团队有了QA这个角色来负责项目质量，测试工作范围及频率相比之前大大增加。这个阶段的QA，工作压力比较大，总担心进度延误，影响迭代周期。工作中会不断思考：过程中如何更精准地执行QA；如何从已有缺陷的规律中让开发人员吸取经验，从而提升开发的稳定性；怎样才能前瞻性地预防问题发生？因为这些实际的需求，QA职责中慢慢增加了质量分析师的内容，肩负起更多的质量分析的重担，他可以通过测试、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，确保交付的质量是合格的。
3、质量传导及改进

第三个层次的 QA 不再局限于只关注质量，在敏捷开发中更多是充当质量宣传员作用。不断传播质量意识，持续关注产品质量，了解产品的质量视图，培养流程持续改进的思维模式，引导整个团队构建质量第一的工作方针，并坚定的执行下去。
由QA去监督项目团队，例如：站立会议规范性；迭代计划规范性；更新任务状态和燃尽图规范性……更多地偏向全过程的敏捷活动指导，让所有人意识到质量在心中。
这个角色职责定义通常在稳定期。敏捷也需要一个持续改进过程，在这个阶段很多的规章制度、开发流程、沟通机制、绩效考核等基本制度都已经完成并在组织内已经执行，这个阶段的敏捷团队关注的是质量如何再提高，项目的反馈周期如何再进行缩短。
在这个阶段，质量传导者不仅仅是QA一个人的事情，他更需要借助团队里每个人的力量，快速反馈，持续跟进，这正是QA在质量传导者职责上的重要工作方针。QA通过培养对流程持续改进的思维模式，了解改进的整体质量目标和持续关注质量的意识，引导整个团队构建正确的项目和产品目标，持续改进。
<hr/>通过上面对敏捷QA职责及工作定位的详细讲解，你还觉得他可有可无了吗？答案是显而易见的，他的价值和作用也是敏捷团队公认的！敏捷QA的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。
敏捷QA工作职责能够被有效履行是保证敏捷开发持续有效的重要基础，也是缺一不可的。QA与团队通力协作，在整个敏捷开发周期中为客户创造并实现价值，同时也可以增加内部团队的凝聚力和自信心，在敏捷开发的道路上乘风破浪，最终可以实现个人、团队、组织的价值所在！
关注微信公众号【赛希咨询】，了解更多精彩内容。

vFSKOoqYwI · 发表于 2023-2-24 21:17:27

敏捷组织转型“利器” – 重构核心经营单元
编者按
应对新形势下的挑战，企业的战略与业务需要灵活响应市场变化，组织的敏捷能力也就逐渐成为企业必备的生存技能之一。而矩阵式、平台式、合弄制等概念层出不穷，敏捷组织的终极意义是什么？不同类型的企业应从何处入手？为化繁为简，从实操角度践行敏捷理念，我们将陆续推出敏捷组织系列文章，与大家分享我们的观点、方法与实战经验。
敏捷体系构建与应用（书籍+报告+案例+模型）一、问题的提出 – 为什么我们的组织永远不够敏捷？

原因一：加速变化与永远滞后

在管理学课堂上，我们常常听到企业的组织架构要适配战略，而战略要适配外部环境。环境、战略、组织三因素需要不断调整和匹配，才能支撑企业的可持续发展。而现实中，面对瞬息万变的市场与客户需求，这样的适配却往往滞后。
我们已经看到越来越多的企业更加频繁地召开战略研讨会，随时调整甚至颠覆自身战略，然而对于组织架构的调整却往往“计划赶不上变化”。新的组织变革方案还没落地，企业的战略重点和业务模式却早已变化，导致前期投入大量人力、物力和财力精心设计的方案只能束之高阁。如何以更快速度，更低的成本适应变化，是所有组织面对的永恒课题。
原因二：管理视角而非客户视角

企业在制定愿景和价值观的时候都会提到“以客户为中心“，但在设计组织架构的时候往往采取“管理视角”而非“客户视角“。企业总部的管理者在设计组织变革方案时远离客户一线，自上而下思考“管什么”和“怎么管”，而没有从一线的客户经营团队的视角出发，了解他们在服务客户时“需要什么能力”和“需要什么帮助”。以管理视角设计的组织架构经常造成一线团队得不到足够的授权与赋能，缺乏主动经营的激情，进而导致组织整体对外界反应迟缓，失去适应变化的韧性与生命力。
启示：

外部环境加速变化，组织架构如何以更快速度，更低的成本适应变化，是所有企业面对的永恒课题。设计组织也要像制定战略一样“以客户为中心”。
二、敏捷组织的转型“利器” – 回归业务场景，重新定义并激活“核心经营单元”

构建敏捷组织的基础单元是什么？我们认为，在调整企业战略与业务模式的同时，还需审视和重新定义组织中的“核心经营单元”。先别急着绘制组织架构图，我们来回答一系列基本问题：我们的客户是谁？向客户提供什么产品？服务客户的真实场景是什么？场景中包含了哪些核心环节？只有在新的业务场景下准确定位组织的核心经营单元，才能作为敏捷组织的出发点，延展设计出完整的组织蓝图。我们来看两个实际案例：
案例一：to B转型to C，核心经营单元下沉

国内某大型企业为寻求第二增长曲线，明确了新零售战略，业务模式也由to B向 to C转型。这意味着客户服务的场景将发生根本性变化，即从以区域公司为主体服务企业型客户，转变为以城市公司为主体服务C端个人客户。
为适配新业务场景，该企业也重新定义了组织中新的核心经营单元，即城市公司下设的“社区私域团队”，其中包含三个关键角色：负责触达和经营一线客户的社群运营岗、负责为客户搭配产品和解决方案的产品经理岗、负责管理客户交付及满意度的客户服务岗。三个角色高效协作，服务当地客户的差异化需求，推动了企业新零售战略在每个城市的落地生根。
总部一方面可以将整体经营指标分解至一个个敏捷精干的“社区私域团队”，并对其赋予充分的经营权限，另一方面可为一线“社区私域团队”提供数据分析、基础保障和专业支持，形成前端客户化、后端平台化和平台数字化的平台型组织架构，推动企业成功实现组织的敏捷化转型。
案例二：分散能力的敏捷统筹，核心经营单元上升

核心经营单元被定义的越小越好吗？越下沉越好吗？我们来看下面的案例。
国内某大型物流企业业务模式传统，以城市划分的“城市公司”地理位置分散，经营范围同质化，经营网点之间缺乏协作，面对客户难以形成合力。在新战略中，企业明确提出了两个方向：新业务集中打造经营能力并快速拓展市场，传统业务加强网络化协作并拓展全国性大客户。
为支撑新战略的落地，敏捷调动组织内的现有资源，企业选择将核心经营单元设定在总部层面，设立了“新业务拓展事业部”和“大客户经营协同事业部”。前者聚焦于产品的创新和市场的集中拓展，后者聚焦于全国性大客户的攻坚和跨城市的经营协作。这两类事业部有着共同的使命，在总部层面敏捷调动一线网点资源，承载企业战略转型的核心指标。组织调整后，在事业部的统筹下城市公司连点成网，充分整合并借助组织内的现有资源，实现了整体组织的敏捷转型。
三、从何处着手

1、准确找到组织的“核心经营单元”

从上述两个案例不难看出，核心经营单元并非被分解的越小越好。我们认为核心经营单元须具备以下三方面特征：

体现新战略重心：不是所有的经营单元都能成为“核心”，只有体现战略重心，承载关键业务目标的经营团队才能作为设计敏捷组织的起始点；
以客户为中心：核心经营单元必须能够直面客户，提供产品和服务，才能像生命体一样快速反应外界变化，自我调整和适配；
端到端经营闭环：对“经营”单元的基本要求是为利润负责，意味着其对价值链各环节有着足够的掌控权，形成端到端的经营闭环，为最终价值而非单一环节负责。

2、紧随战略，高频审视和迭代组织

要像重视战略一样重视组织。企业战略都会经历规划制定、执行监控、回顾检视、迭代调整的完整闭环，且每个环节都会由企业的最高领导层通过一系列会议研究讨论。我们的建议是，在这些会议中都要增加一个独立的环节，去审视组织是否匹配战略的调整，及时对组织和关键人才做出必要的调整。过程中值得强调的是，CEO必须把自己看作“首席组织官”，缺失一把手规划和推动的组织变革往往无疾而终。
3、机制先行，低成本试错

必须承认，大规模的组织调整往往伤筋动骨。敏捷组织需要两个方面的支撑，既要有高度稳定的平台、完善的结构和流程，也要有快速行动和应变的能力。在对稳定架构调整之前，我们应优先考虑设立虚拟团队，灵活调整授权，倾斜考核与激励机制等方法。积极稳妥推动组织变革，实现低成本试错。
启示：

忘掉概念，回归业务场景，敏捷转型第一步要找准组织中的“核心经营单元”，重构敏捷组织的基础细胞。
566、敏捷体系构建与应用（书籍+报告+案例+模型）

原文链接：
敏捷体系构建与应用（书籍+报告+案例+模型）
矫捷自组织团队，还需求QA吗，QA能为团队做/带来什么……？