敏捷开发，QA面临的10个挑战

敏捷开发，QA面临的10个挑战

1.没有MRD，如何管理好需求？2.没有需求评审，怎样保证需求质量？3.研发模式变更，怎样掌控进度？4.没有详细设计如何保证设计没有问题？5.没有测试设计如何保证测试质量？6.什么时候提测？提测频繁，如何下降提测本钱？提测时间不固定，如何分工？7.如何提高RD代码质量？8.没有准入，怎样保证提测质量？9.如何避免新增story影响已有功能造成质量问题？10.上线频繁，如何下降上线的本钱？

1.没有MRD，如何管理好需求？（1）使用story模式来管理需求，将庞大的MRD划分为一个个适合粒度，且可独立交付的story（通常每一个story能在1~5天内完成，包括设计、开发、测试），需求清晰明了，易达成一致，且可节省大量的需求评审时间。

（2）要求PM在第i个迭代上线前一天，完成所有第i+1迭代的需求拆分，和RD、QA达成理解一致，且辅助QA一起补充完验收标准，在第i个迭代启动前完成所有story的相干工作。

（3）每一个story都有自己的优先级、估点（即预计花费时间），以此为根据判断是不是纳入某迭代。

（4）PM随时待命，快速响应，答疑解惑、修改设计不足。

2.没有需求评审，怎样保证需求质量？challenge：需求不评审了？开发时遇到一堆问题怎么办？测试时发现一堆问题怎么办？作为质量的监督者，QA面临着很大的冲击和挑战！

虽然没有需求评审会议，但每一个story都是经过仔细斟酌和沟通过的。

（1）首先，一个story被PM提出时，需写好用户故事卡片和详细描写；

（2）接着，PM会找RD、QA的leader进行讲授，并交review，review人提出问题及改进意见；

（3）然后，PM和负责具体开发RD、测试QA进行讲授和讨论，RD、QA提出问题、疑问，PM解答，并对详细描写进行修改。

（4）最后，所有参与者觉得没有问题后，PM辅助QA补充详细的验收标准，RD对其进行review，并作为自测和自动化case编写的参考。

（5）另外，在开发和测试的进程中，若发现新问题，PM随时响应，答疑解惑，修改设计的不足。

上述每个步骤都被落实后，不但需求质量被保证了，QA也成了需求管理的核心。即便有未考虑到的问题，敏捷团队也能够很快消化，在下个迭代迅速优化。

3.研发模式变更，怎样掌控进度？challenge：没有详设计划？没有开发计划？甚么，连测试计划都木有？QA怎样保证项目保质保量按时上线？

（1）定期发布

定期发布上线，把全部项目划分为一个个迭代，每一个迭代时间大小固定，迭代结束时上线交付一次。

（2）迭代计划

迭代计划相当于全部迭代的计划，帮助我们管理并保证每一个迭代的交付。

A.迭代计划的条件：

story沟通及验收条件的补充完成。

PM给出story的优先级

RD、QA给出story的估点，估点可取范围为（1、2、3、5），若有大于等于5点的story，尽可能拆分成更小的story。

B.迭代计划

估算团队交付能力（通常经历几个迭代，团队的交付能力就会很明了了）：基于“昨天的天气”（极可能他们在当前迭代完成的工作量与上一个迭代相同，除非工作环境或是团队构成产生重大变化）和常识，估算自己能够在当前迭代中完成多少工作。然后团队就会基于自己的工作交付能力，选择当前迭代要开发的工作。

有了团队交付能力值，便进行以下步骤安排本迭代的工作：

依照优先级顺序，列出story，并注明它们的故事点数大小。

判断一个迭代中可以交付多少故事点数。

斟酌团队需要完成的非用户故事工作可能产生的影响，比如在初期的迭代中，由于工具和工作环境不到位，工作效率会遭到影响。

向计划中加入一个新的迭代。

向迭代中加入故事，直到用掉所有的工作能力。

询问：是不是所有的故事都已解决、版本发布目标是不是达成。

如果没有，那末向计划中加入新的迭代，并重复步骤5和步骤6.

一旦所有的故事都已分配完成，与大家就计划进行交换，并征求他们的反馈，看看这些计划是不是现实并且可以完成。

PS：通常只会进行到第五步，剩余的stroy放入需求池，下个迭代启动时再计划。

（3）逐日站会

站会的目的有三个：

（1）周知进度

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

（2）周知计划

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

（3）抛出问题

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

实现一项目的必要条件：

1.站

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

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

站会的主要内容：

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

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

站会的时间尽可能控制在10分钟左右。

开站会的一些技能

（1）轮番主持

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

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

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

（3）早上举行

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

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

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

（4）卡片墙

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

卡片墙如下图所示：

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

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

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

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

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

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

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

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

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

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

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

QAsingnoff-已验证：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）总结

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

4.没有详细设计如何保证设计没有问题？challenge：如何让设计上的问题在开发前暴露出来，并解决？

在敏捷开发中，我们认为沟通交流胜过四平八稳的文档，相对编写详细设计文档，RD更愿意给相干人员讲授他的设计，乃至给QA讲授代码，因此对详细设计不做要求。

那末，没有详设，如何让设计上的问题在开发前暴露出来，并解决？

我的解决方案以下：

增加详设交换环节，且由RD推动

1）在开发之前，增加详设交换环节，RD进行task拆分和详设讲授。

2）由RD推动此环节，在开发之前主动给相干QA和