标签归档：敏捷

说好的团队为质量负责呢？

1条回复

问：谁应该为质量负责？
答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
问：那其他角色呢？
答：BA还好吧，跟质量的关系没那么大。
……

在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 …

为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。

因此，我们来看看质量到底是什么？

质量是什么

产品质量不是检测出来的，从产品生产出来后质量就已经在那了。
——著名的质量管理专家戴明

在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。

那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。

1. 外部质量

顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。

外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。

2. 内部质量

同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。

内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。

3. 内建质量

质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。

另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。

软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。

因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：

外部质量：用户反馈、Support的问题数量

内部质量：code review、结对编程、静态代码质量检查

内建质量：测试环境、生产环境缺陷，Support的反馈

了解了三个维度质量的含义，我们不难理解：

❌质量不是零缺陷，不是百分百的测试覆盖率，也不是没有技术债；
✅质量是快速反馈，任何改变能够快速验证，并且快速修复；
✅质量是把精力都集中在正确的事情上；
✅质量是团队在代码、设计和交付上有信心做出改变；
✅质量是团队对任何改变负责。

容易忽视的质量

从前面对质量的定义，广义的质量其实包括软件产品交付流程中的方方面面，每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容：

需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
忙于交付更多的feature，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
没有足够的测试覆盖，导致新增代码容易破坏已有功能；
Dev提交代码后，就投入新代码的开发，对所提交代码缺乏关注，CI pipeline红了不能及时修复，可能影响后面QA的测试进度；
大面积的重构发生在release前夕，无法全面回归，带来很大的风险；
项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
第三方组件评估不够充分，导致线上环境无法承载等；
开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引发问题；
开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
缺乏跨功能需求的关注，导致严重的安全或者性能问题；
对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
……

这样的问题还有很多很多，无法一一枚举。每个角色，每个环节都有可能出现纰漏，导致产品质量问题。

那么，谁该为质量负责是不是已经很清楚了？

谁该为质量负责

前面已经讲到，质量是贯穿项目整个生命周期的非常关键的部分，质量保障工作也是需要在每个环节加强关注，每个角色都需要为质量负责。

上表列出的是敏捷开发流程中的各个实践活动，它们都与质量有关，每个活动都要求多个不同的角色同时参与。

下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。

BA：Busines Analyst，业务分析师

BA主要负责业务需求的分析工作，要理解客户的业务，并将业务分解成便于Dev和QA理解的功能点，同时，还要能够帮助用户验证开发完成的软件系统功能，并展示给客户。需求作为软件开发的源头，是极为关键的。

BA视角的质量，主要是需求分析的准确性和清晰度，要帮助团队对需求有一致的认识，从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。

Dev：Developer，开发人员

Dev作为软件系统实现的主力，对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面，都有着不可替代的职责，每个环节都不可忽略。

因此，Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效的交付给最终用户。

QA：Quality Analyst，质量分析师

QA作为软件质量的倡导者，是唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作（手动、自动化、探索式、跨功能、非功能测试，以及生产环境的QA等）、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值，这些都是QA的职责。

三个主力角色中的BA一般都会有从用户旅程的角度去考虑，其实Dev和QA也需要同样的思维模式，不能把story或者AC割裂来看，而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。

除了三个主力角色，团队还有其他角色也都是要对质量负责的，比如：架构师要负责项目架构的健康，基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展，PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。

软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。

数字化时代的软件测试

1条回复

数字经济高速推动着一个无情的市场，所有利益相关者通过设备和应用网络进行交互，一个微观时刻足以让市场领导者摆脱优雅。这种对速度的痴迷能否淡化质量定性方法？这份《World Quality Report 2017-2018》带你来一探究竟。

现代QA和测试部门重点关注的领域

敏捷和DevOps已经成为数字化转型的重要工具，同时，质量保障和测试工作也随之发生变化：

中央治理和控制减少，团队选择方法和技术的自由度增大；
部署速度提高和应用程序日益复杂化，软件错误和故障的风险增加；
软件质量对品牌的影响巨大，但这已经不是最高优先级的目标，日趋成熟的尽早质量保障实践可以帮助纠正品牌和形象方面的缺陷；
最终用户的满意度和安全性是最重要的两个方面，要确保应用程序的功能和非功能质量，同时需要找到成本和风险的平衡点。

调查结果表明，现代QA和测试部门需要重点关注的领域是以下三个方面：

1. 智能测试自动化和智能分析

智能测试自动化和智能分析将成为支持测试的关键，因为它们可以实现智能决策，快速验证和自动调整测试套件。测试自动化的范围从简单地将测试活动（计划、设计和执行）自动化发展到自动化测试环境和测试数据配置。

然而，调查结果显示目前自动化还处于不足的状态，尽管从自动化中获益的组织数量在增加，但产生的价值没有根本变化，测试自动化水平仍然很低（低于20%）。

速度将推动更智能的自动化需求，需要找到提高自动化水平的方法。

2. 智能测试平台

智能测试平台需要应对测试环境、数据和虚拟化日益增长的挑战。真正的智能测试平台的远景超越了生命周期自动化，需要实现自动配置的完全自我感知和自适应环境，以及支持自动化测试数据生成和测试数据管理。

测试环境、测试数据和虚拟化是三大挑战，同时也为自动化提供了巨大的机会。结合智能生命周期的自动化，将使QA和测试进入下一个演进阶段，称之为智能QA，这已经成为行业重要的关键成功因素。

3. 适应敏捷开发流程的QA和测试部门

组织需要关注的第三个领域是适应敏捷开发流程的QA和测试部门。在敏捷和DevOps模型中，测试从中心部门转移到分散的团队。未来的测试组织需要将灵活性与效率和重用性相结合，提供测试环境、测试数据、测试专业知识和技能的测试中心将分散到各种业务线的IT团队。

QA和测试的现状与挑战

从调查结果，总结出以下关于质量和测试现状的发现：

1. 回归对应用程序质量的关注，表明在敏捷环境的新上下文里，测试已经成熟

面对开发和测试环境的复杂性以及数字化转型的速度，关注点正在回归到整体产品质量上来，这是一个进步的迹象：

参与这次调查的受访者中QA和测试人员明显多于其他角色，由2016年的37%上升到2017年的41%；
2016年被引用最多的目标是在上线前发现缺陷，这个数字从40％下降到2017年的28％；
最终用户满意度从39％下降到34％。

客户体验和增强的安全性处于IT战略的前两位。从2016年到2017年，增强安全性需求从65％大幅下降到35％。 IT成本优化进入今年IT战略的前三位，证明QA和测试能够应对过去几年的快速变化。

其他一些对IT战略意义重大的领域包括对业务需求的响应、实施软件即服务以及实施敏捷和DevOps。敏捷和DevOps实施需求的减少幅度超过一半，从38％的受访者减少到17％，这表明这些开发方法正变得越来越主流。

2. 测试自动化正在通向智慧、智能和认知QA之路

自动化尚处于待开发阶段，测试活动的平均自动化水平约为16％。自动化产生的价值在很大程度上没有变化。测试自动化不仅应该复制现有的手动测试过程，38％至42％的组织将认知自动化、机器学习、自我修复和预测分析视为测试自动化未来的有前途的新兴技术。

智能解决方案是DevOps、移动和物联网中的新趋势。通过增加智能自动化，企业适应快速变化的业务环境能力将得到增强。

3. 敏捷开发中测试的挑战不断增加

99％的受访者在敏捷开发测试中面临某种挑战
46％的受访者认为缺乏数据和环境是最严峻的挑战，这比2016年的43％有所提高
在敏捷迭代中重复使用或重复测试的难度排在第二位，由2016年的40％增加到了45%
挑战数量下降的唯一领域是：难以确定测试的重点以及测试团队在计划或初始阶段的早期参与。

测试和测试环境的自动化将帮助组织解决敏捷和DevOps开发模式给测试所带来的大部分挑战。这些智能测试解决方案使得质量保障的速度能够适应日益复杂的集成IT环境。

4. QA组织不断演进以满足双峰要求

2017年，集中式的测试组织和分散式模型之间的分配更加均衡。在许多组织中，以前的卓越测试中心（TCoE，Test Center of Excellence）已经过渡到更加灵活的测试卓越中心（TEC，Test Excellence Center），其重点在于支持和赋能，而不是实际执行测试活动。

瀑布式开发仍将在未来很长时间内实施，形成与敏捷和DevOps混合的局面。例如，组织选择定位软件开发测试工程师（SDET）的位置时，其中敏捷Scrum和TCoE分别是36％和47％。

5. 环境和数据仍然是QA和测试的难点

调查结果显示有73%的组织采用云环境、15%的组织采用容器化来执行测试，使得测试的生命周期缩短。然而，仍有50%上下的受访者分别表示在测试环境管理、测试环境利用率、适用于敏捷开发的开发和测试环境，以及早期进行集成的环境方面存在挑战。

在测试数据管理方面，分别有超过50%的受访者存在以下挑战：管理测试数据集的规模、创建和维护合成测试数据、遵守与测试数据相关规定。

6. 测试预算下降，但预计会再次上升

专门用于质量保证和测试的IT总支出的比例为26％，它已经从2016年的31％和2015年的35％下降。

但是，随着组织采用敏捷和DevOps来支持数字化转型，未来两年质量保证和测试预算将会增加，企业必须确保IT应用程序的数量和复杂性，以及随之而来的QA平台解决方案的质量。

再谈敏捷QA

发表评论

曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下，QA如何参与从需求到测试的每个阶段，在每个实践中如何跟不同角色的合作，以及敏捷QA跟传统开发模式下的测试人员的区别等。

这些内容在今天依然适用，但在真实项目中往往情况比较复杂，总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后，我想跟大家一起再来聊聊这个话题，下面逐个来分析我所见（听）到的质疑或困惑。

敏捷QA流程必须严格遵守

“如果QA没有参加Kick-off，我们拒绝做Desk Check；如果没有QA参与Desk Check，我们拒绝测试。”

从需求分析到生产环境，推荐QA参与每一个环节，跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨，觉得不管怎样都不能漏掉某个环节，但难免有特殊情况。比如，由于QA请假或者开会等，错过了某一次Desk Check，一定要求等有时间了（甚至第二天或第三天）再补上，没准那个时候代码都已经上到测试环境，完全可以直接测试没必要在折腾大家来做一次全面的Desk Check了。

QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足，做到Bug的预防。如果已经错过了这个“早”，那就没有必要再纠结非要严格进行每个环节了，不然不仅没有意义，还带来浪费。

QA不用了解太多的业务上下文，一样做的很好

“需求来的晚，QA手头忙着测试当前迭代的Story，根本没有时间去参与需求分析，不过这样也不影响，测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷测试的原则之一是优化业务价值。如果连业务上下文都不清楚，如何做到优化业务价值？了解业务上下文的重要性不言而喻。

那么，真的忙的没有时间如何来破解呢？这其实是进入了一个恶性循环，需要找到突破点，打破这个不良环路，让其变成一个良性循环就好了。

不破不立，对于这个循环，就是需要减少测试Story的时间。可行的方案是：加强Desk Check，确保单元测试的覆盖，保证开发验收完成到最终交付的代码在自动化测试的保护下不被后续环节破坏；同时QA参与技术方案的设计讨论，这样测试的时候就可以有针对性的测，必要时候辅助以Bug Bash，由此节省出时间。经过两三个迭代的调整，情况定会有所改善。

技术方案讨论跟QA没什么关系

“技术方案，那是Dev们的事情，QA的重要任务是如何做好测试，参与技术讨论浪费时间。”

知己知彼，百战不殆。如果完全不了解技术实现，很难做到有的放矢。正如前面提到的，QA参与技术方案的讨论，了解更多技术细节，知道技术方案可能的风险，就能更好的指导测试，使测试更有针对性、更高效。

比如，对于微服务架构，了解了服务的熔断和降级机制，测试就能有效覆盖到相关方面。

单元测试Review没有价值

“单元测试还挺复杂，Dev新人写起来都不容易，QA更看不懂。QA Review单元测试，提不出有价值的反馈，感觉是在浪费时间。”

敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元测试，其目的是两个方面：

帮助发现漏掉的或者需要修改的测试，QA更好的了解测试覆盖情况
帮助开发人员增加测试Sense，同时也能帮助QA提高代码阅读和理解能力

我理解对于单元测试Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况，但并不能因此否认这个实践的价值。

这时正确的做法是DEV跟QA解释每个测试所测到的内容，而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合，我相信Dev的测试Sense和QA阅读代码、理解测试的能力都会得到提高。

必须严格Review每一个单元测试

“我对Dev写的单元测试总是不放心，不严格的Review根本不行。”

另一个极端情况就是，不管花多少时间，认为必须严格Review每个测试，认真的去检查测试的每个实现细节。

对于复杂一点的Story，严格Review每个单元测试，我见过最长的是花了两个小时，到最后大家都已经筋疲力尽…这显然是一种浪费！

QA Review单元测试更多的是关注测试的覆盖情况，而不是关注每个测试的实现细节，后者更多的是属于Code Review范畴。更重要的是，任何实践都不能只关注形式，要看其价值，具体问题具体分析。对于新的团队新的人，可能刚开始需要多花时间去了解所写的测试。而对于成熟的团队，或者是非常有经验的Dev，这个Review过程可以简化，只看测试的标题，或者只是听Dev说一下测试覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在15分钟以内，对于特别复杂的Story，最多也不要超过30分钟。

没有发现Bug的测试不是好测试

“这些自动化测试从来没有发现过Bug，ROI太低，没有存在的必要！”

图片来自：https://www.netsolutions.com/insights/wp-content/uploads/2016/08/Why-You-Need-Automation-Testing-For-Mobile-Apps-Th.jpg

由于有些测试执行起来太耗时、测试实现成本和维护成本都很高，大家在讨论要不要去掉这些测试的时候，总能听到上面那样的声音。

其实，自动化的回归测试并不是用来发现Bug的，有数字表明自动化回归测试发现Bug的比例仅有15%。自动化测试只是形成一道保护的屏障，增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识，在制定测试策略的时候需要综合考虑多方面因素，要真正理解每个实践、每个活动背后的真实价值。

敏捷QA该怎么做？

关于QA的定义，有下面三个层次：

QA = Quality Assurance质量保障
第一个层次QA的要求是做好质量保障工作，确保我们交付给客户的软件产品是正常工作的。
QA = Quality Analyst质量分析
第二个层次的QA通过测试、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，和团队所有成员一起确保交付的质量是合格的。
QA = Quality Advocate质量倡导者
第三个层次的QA不再局限于只关注质量，通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识，引导整个团队构建正确的产品，并且正确地构建产品。

敏捷QA需要做到第三个层次，通过分析软件风险并制定相应实践，确保软件在其整个生命周期中持续工作并创造价值，为业务和团队提供信心，从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作，也是随着团队成员的了解程度、配合默契度不同而有变化，并不是要求一成不变的。

敏捷实践Showcase的七宗罪

发表评论

Showcase介绍

Showcase就是开发团队把开发好的功能给客户的Product Owner（以下简称PO）等业务相关人员演示，以获取他们对所开发系统的反馈，是敏捷开发流程中的一个实践，一般频率是一个迭代一次，也可以根据项目具体情况做调整。Showcase是做功能演示，同时也是展示开发团队面貌的时刻，其重要性不言而喻，但据我经历的项目，总能看到一些不是很理想的地方。

Showcase之七宗罪

1. 准备工作没做好

所有人就位，准备开始showcase的时候，突然发现环境没有ready，连不上了！

好不容易把环境弄好了，开始showcase，可是数据又没有ready，还要临时创建，花了大半天时间（创建、准备数据）才终于show到了真正要演示的功能……

主讲人手忙脚乱，而其他人都要在这种忙乱中等待，浪费了很多宝贵的时间，尤其是对于PO那些重要人物来说。

###### 正确做法：充分做好准备工作

确定要做showcase的功能后，需要提前把以下事情提前做好：

从业务的角度把整个要演示的功能尽可能的串起来，准备好showcase演示的步骤；
演示数据也需要准备好，showcase的时候可以直接使用，只需要操作所演示功能部分，不需要临场创建准备数据；
演示环境要提前准备好，包括部署好需要演示的应用程序版本，而且要告诉团队不要破坏了准备好的环境。

2. 没有上下文铺垫

着急忙慌的准备好一切之后，就开始页面操作了，也不先介绍一下要演示功能的来龙去脉，不说一下这个功能是干嘛的。这样，那些日理万机的PO等业务人员，他们很有可能没见过这个系统功能的样子，容易被搞得云里雾里、不知所云……

###### 正确做法：开始演示前要先介绍上下文

根据自己对所演示功能的理解，先介绍该功能的业务价值，满足了用户的什么业务需求，让在座的各位业务人员能够更容易理解后续showcase的内容。

3. 逐条过AC

Showcase的过程就是按照用户故事（story）的验收标准（AC, Acceptance Criteria）一条一条的过一遍，没有连贯性，这样的演示过程很难让观众把每条AC跟整体的系统特性、真正的业务场景联系起来，容易迷失，因此，常常会有演示完了一个story，而客户却问这是实现了什么业务需求……

正确做法：以功能为单位演示

不要一个一个用户故事演示，而是将整个功能串起来，最好定义出一个一个的业务场景演示给客户看，并且尽量使用业务语言描述。这样，让客户的业务人员感觉更有亲切感，看到开发团队的人员能够用业务语言描述和演示，他们一定会留下好的印象。

4. 企图覆盖所有路径

系统功能通常会有不同路径实现的是同一个相同或类似的功能，比如一个上传文件的功能有多个入口，但到达的上传文件页面是相似的。有人在演示这个文件上传功能的时候，企图把所有入口进去的文件上传都要完整演示一遍，到后来根本没有观众愿意关注，都在私下讨论了，有时也会有客户业务人员直接出来制止继续下去。

正确做法：只演示最关键路径

对于多个路径实现相同或相似功能的时候，对其中一条最复杂/重要的路径进行详细演示，其他路径提到即可，并指出其他路径不同的地方，不需要一一演示，以节省时间。

5. 过多提及跟演示功能无关内容

有人天生能聊，showcase的时候也是喜欢啰啰嗦嗦的说一大堆，经常会提及一些跟正在演示的功能无关的东西，或者提及团队采用的技术方案等业务人员不感兴趣的内容，导致showcase过程不能按时结束，甚至有些重要的反馈反而没有收集到。

正确做法：只提及要演示的功能

有时候一个showcase周期内可能开发了一个主要的功能，还有一些小的feedback的改动等，这时候showcase可以考虑只演示最主要的功能，那些小的feedback就不需要show了，也不要提及任何还未完成的功能模块，而且对于团队正在开发的技术卡或者还不成熟的技术方案等，一定不要提及，因为对方是业务人员，不会对技术相关内容感兴趣。

6. 认为showcase仅仅是BA或QA的事情

业务分析师（BA, Business Analyst）和质量分析师（QA, Quality Analyst）通常是团队跟业务打交道最多的，是最了解业务的，而showcase就是给客户的业务团队做系统演示，于是团队其他角色就会有人觉得showcase仅仅是BA或者QA的事情，跟自己无关，也不关注。

正确做法：人人都可以showcase

Showcase不是某个角色独占的，团队所有人只要对业务、对要演示的系统功能足够了解就可以负责showcase，通常可以采用团队不同人员轮换负责showcase方式，以增加团队成员在客户面前的曝光率，同时也能增强团队不同角色人员熟悉系统、熟悉业务的意识。另外，就算不是主导showcase，团队人员也可以尽量的多参加showcase会议，这是一个了解系统、听取客户反馈的非常好的机会。

7. 不熟悉的新人负责showcase

既然showcase不仅是BA或QA的事情，常常也会有其他角色来参与负责这件事情。从团队能力建设的角度考虑，PM有时候会让一些比较junior的同事或者新来不久还没有好好了解系统的同事来做showcase，结果就是演示过程非常生硬，甚至会有很多说不清楚的部分，而在一旁听着的BA/QA着急的只好上来帮忙解释。

正确做法：showcase前先充分了解系统和业务

虽然人人可以showcase，不建议利用给不熟悉的新人提供showcase的机会来提高能力，如果是要给新人锻炼机会，可以让新人在结对编程、Story Kickoff、Desk Check的时候多多的主导，等到对系统和业务有了一定的了解再给客户展示比较好；或者新人非常有意愿直接主导showcase，那么一定要在演示前做好对系统和业务的充分了解，以能应付和解答客户的挑战和疑问。

总结

前面关于showcase的正确做法都是围绕两个词“专业（Professional）”和“高效（Efficient）”展开的，showcase的目标观众是客户的PO等业务人员，他们是决定是否认可开发团队所开发功能的至关重要的人物，我们在showcase过程中表现出专业性和高效率非常重要。因此，只要记住这两个词，并严格遵循，showcase一定能做好。