【敏捷开发每日一贴】敏捷实践Showcase的七宗罪

敏捷实践Showcase的七宗罪

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

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, QualityAnalyst）通常是团队跟业务打交道最多的，是最了解业务的，而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一定能做好。

【敏捷开发每日一贴】敏捷实践Showcase的七宗罪相关推荐

《深入核心的敏捷开发：ThoughtWorks五大关键实践》读书摘记
深入核心的敏捷开发:ThoughtWorks五大关键实践肖然张凯峰简介价值驱动的精益研发转型实录愿景:打造招行端到端的精益研发管理体系,价值驱动.质量为先,以行业领先的科技能力驱动创新与变革 ...
【IPD】敏捷开发与IPD结合的实践培训课程「3月11-12日」
课程名称敏捷开发与 IPD结合的实践 (Agile Development - IPD and Agile Development Practice ) 参加对象企业总工.技术总监.系统架构师.研 ...
敏捷开发 - 每日站立会议
每日站立会议是敏捷流程scrum中的很重要的一个制度之一. 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展. 2.给每个人一种精神压力,信守承诺.这是一种面对 ...
敏捷开发的Scrum晨会实践
hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会.从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思. 11年12月,hursing开始在自 ...
【敏捷开发每日一贴】敏捷教练和团队引导
谈谈敏捷教练和团队引导敏捷教练在不同的组织中,在不同的场景下,可以是:教练.咨询顾问.引导式培训师.导师.过程引导师,并且可以根据不同的情况切换角色.熟练运用各种技术.技巧.工具.(这里说的敏捷教练 ...
【敏捷开发每日一贴】：猪和鸡的故事
猪和鸡的故事关于鸡与猪的故事有很多种版本,被用在各种不同的场合,管理的.营销的.敏捷开发的,大体相同,但稍有差异. 故事一:有一只鸡和一头猪合伙开饭店,双方各占50%股份.鸡对猪说:"我每 ...
《敏捷开发绩效管理》扩展阅读（敏捷开发绩效管理，敏捷团队绩效管理）
本文长期更新,请常来看看. • 序言 – 从代码行到故事点敏捷估算:故事点与直接估算天数的差异 – 下一步? • 敏捷团队绩效管理 – 谁来管理团队中的个体? 同行压力(兼谈敏捷团 ...
快速交付敏捷开发的特点_敏捷开发的那些事
"敏捷"这个词近几年非常火,经常会有人问:"我们应该怎样开始做敏捷?"或者:"能不能来帮我们推一下敏捷?敏捷有很多实践,管理的.工程的都有,但敏捷绝非 ...
敏捷开发（一）敏捷开发和Scrum
一.敏捷开发 "敏捷"是一种思想,与"瀑布"式(即传统开发模式)相比,敏捷开发有如下宣言个体和互动高于流程和工具:意思是敏捷开发中每个人都可以提出自己的见解, ...

【敏捷开发每日一贴】敏捷实践Showcase的七宗罪

【敏捷开发每日一贴】敏捷实践Showcase的七宗罪相关推荐

最新文章

热门文章