敏捷测试（6）--基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理（三）

（3）每日站会

站会的目的有三个：

（1）周知进度

仅从用户故事和任务的层面周知进度，任务进度只有两种状态：完成或未完成（完成百分比）。

（2）周知计划

你将会在下次会议之前做哪些工作？

（3）抛出问题

哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）如果遇到需要解决的问题，可以在每日立会之后处理。

实现一项目的必要前提：

1.站

2.敏捷项目必须提供能够“安全失败”的环境，团队成员不会因为没有达成任务承诺遭受惩罚。

大家要能够安全说出任务状态的真实情况，并且了解项目环境的现实情况。有时，我们的估算可能很糟糕（只是估算而已，又不是承诺），又或者某些事情的发生让某些成员无法完成任务，整体环境必须让他们能够说出真实情况，这样团队成员就能调整他们的日程表，将任务排序，并调整适应项目的现实。

站会的主要内容：

从PM、RD到QA，每个人发言，内容为：1. 昨天干了什么，2.遇到什么问题，3.今天准备干什么。如果有想要分享给大家的知识，也可以在此分享。

最后主持人总结一下，然后根据实际遇到的问题，少数人进行线下沟通、跟进、解决。

站会的时间尽量控制在十分钟左右。

开站会的一些技巧

（a）轮流主持

轮流主持能提高团队成员的参与度，且如果主持人临时有事，也不会因此无法开展，通常每次站会结束时指定下次站会的主持人。

（b）解决问题不放在会议中

会议中仅抛出问题，解决问题放在站会结束后，相关人参与。目的是避免浪费大家的时间。

（c）早上举行

可以让所有人按时来，按时工作。

可以让每个人更清楚今天自己该干什么。

晚上每个人进度不一，作息时间不一样，早上说昨天干了什么更准确。

（4）卡片墙

有了迭代的总体计划，还需要细化到对每个story进行管理，除了之前的估点外，我们使用卡片墙对其进行管理。

卡片墙如下图所示：

需求池：所有新建的story（一般为未经过估点的）卡片贴在此处。

待开发：所有待开发的story卡片贴在此处。

需求池->待开发：讲解沟通完需求、估完点、补充完验收标准后，移动

开发中：所有正在开发的story卡片贴在此处

待开发->开发中：RD将story拆分完task，并给QA讲解task实现思路，QA同意后，移动。

待测试：所有开发完成，等待QA测试的story卡片贴在此处。

开发中->待测试：RD开发完成story，且完成单测、集成测试编写，和经过仔细的自测后，移动。

测试中：所有QA正在测试的story卡片贴在此处。

QA singn off：所有经过QA测试，QA认为可以上线的story卡片贴在此处。

测试中->QA singn off：QA经过仔细测试，bug都被修复验证，认为story符合上线标准时，移动。

已验证：所有经过PM验收，可上线的story卡片贴在此处。

QA singn off->已验证：PM在验收环境中验收，认为符合需求后，移动。

加速区：所有需要加速解决的story卡片贴在此处。如卡片中有block测试的bug急需修复，等。

block区：所有被一些问题block的story卡片放在此处。

卡片：story卡、task卡（story编号、估点数、用户故事）。

角色卡：FE、RD、QA的名字，以不同颜色区分，分别写上人名，用于贴在story上。谁在做什么，谁忙谁闲，有多少剩余人力，一目了然。

上线时间：略。

（5）燃烧图

使用燃烧图，计划及其变化，以及每天进度一目了然。

燃烧图如下：

1、X轴为时间，一般是迭代周期的每一天；

2、Y轴为工作量，根据项目情况，可以用已完成估点或已完成story点数来表示；

3、最开始，计算出本次迭代要完成的所有工作量(作为y轴刻度，迭代天数作为x轴刻度)，然后，每天站立会议时，了解前一天已经完成的工作量，并计算出迄 今为止完成的工作总量。把其画在Y轴上，以此类推(并把y点连接成线)。如果计划比较(理想)准确，燃烧图的最后一天”燃烧“折线将和总工作量折线相交；

（6）总结

以上五项，简单易实现，用很低的时间成本就能做出“计划”，并保证计划的落实，且能快速适应变化！