““你还记得之前麦罗对Showcase的建议吗?”
“不记得了。什么建议?”
“咱们在‘我搞死你’项目的第一次Showcase,做的不怎么成功,事后麦罗跟大家说了两个词‘Professional’和‘Efficient’,也就是‘专业’和‘高效’。我觉得说的特别有道理!”我是别说记得这两个词,当时的场景都历历在目。
“哦...你是觉得咱们现在的Showcase有问题,对吗?”
“是的,我参加了几次Showcase,发现有的同学做的不够专业,也不够高效,不过有的同学就做的挺好,比如上次你们TL的showcase。”
“是的,我们TL还是挺有经验的,他做的不错。要不你把麦罗的建议跟大家分享一下吧?”
“可以,我正有此意。”
”
Showcase要求做到专业和高效
![](https://i-blog.csdnimg.cn/blog_migrate/1d2c4ea9cb81fc0b2e10cffadf48616b.png)
Showcase就是开发团队把开发好的功能给客户的Product Owner(产品经理,以下简称PO)等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发流程中的一个实践。其频率一般是一个迭代一次,也可以根据项目具体情况做调整。
Showcase的目标观众是客户的PO等业务人员,他们是决定是否认可开发团队所开发功能的至关重要的人物,因此,Showcase是展示开发团队面貌的关键时刻,我们在Showcase过程中表现出专业性和高效率非常重要。
Showcase之七宗罪以及正确做法
![](https://i-blog.csdnimg.cn/blog_migrate/0d7d35e71a42069feb88910a3203bfa9.png)
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,那么一定要在演示前做好对系统和业务的充分了解,以能应付和解答客户的挑战和疑问。