我参与了公司的一个老产品从瀑布转向敏捷的过程，也参与了一个完全新的APP从无到有使用敏捷开发的过程。在这些实践的过程中，我们遇到过各式各样的问题，既有通用问题，也有自己项目上的特殊难处。做为团队中的一员，我也深刻地体会到大家同心同力克服困难，在磨合中配合得越来越默契，沟通上也越来越高效。当然，随着对scrum这种敏捷模式的不断深入理解，我也感受到一些困惑。这里给大家分享一些我们常遇到的问题，以及一些解决问题的建议。
　　问题1：沟通语言的互相融合
　　当我们一起开grooming meeting时，开发人员往往根据代码量来评估point，给出的解释一般也是技术上是否有难度，代码量是否大，而测试人员是从业务的复杂度来评估，所以有时候会出现比较大的分歧。比如开发人员认为工作量很小，而测试人员认为业务复杂，和别的模块交互比较多，测试工作量大。随着后来在团队内部开始评审测试用例，开发人员慢慢能理解测试的工作量。而作为测试人员，我也在课外积极的补习coding方面的知识，尽可能地去理解并参与到团队的讨论中。
　　问题2：团队组建初期需要热身环节
　　Scrum团队强调每个人都能独挡一面，都能无障碍地领取任何任务，但是学习或练习不擅长的技术本身需要时间，在学习和产出之间该如何平衡呢？在项目早期，我们提倡大家尽量多地尝试不擅长的任务，这是一个团队成长学习的过程。不仅仅是学习一项技能，更重要的是让大家体会团队工作的方方面面，为团队建立一个互相体谅，友好合作的工作氛围打下坚实的基础。但在项目的后期，这种尝试应该尽量避免，因为一个不熟悉该领域的人去做，不仅时间可能翻背，质量可能也不能保证。
　　问题3：用户故事或任务过于庞大
　　Scrum的一个原则是希望团队集中在一个或两个用户故事上，完成后再转移到下一个用户故事，争取价值的快交付，但带来的问题是当很多人都集中在一个用户故事上时，彼此之间有依赖关系，大家不得不等待。这种现象的症结在于用户故事太大，解决办法是把它进一步分解，在具体实现时，避开这种依赖带来的浪费。对于传统开发模式，经常一个或两个开发人员人从头到尾把这一块功能做完，现在却需要向切肉一样，把它分成更小的一块块拆开做，这样一块功能可能需要多个不同开发人员分多次才能完成。对测试人员来说更是痛苦，我们需要测试很多中间产物，测试量显著增加。为了避免测试量像雪球一样疯狂增加，同时避免后期的集成测试压力，我们对每个迭代周期里完成的用户故事尽可能地自动化，同时也对当前迭代周期的用户故事和之前已完成的用户故事之间的集成测试实施自动化。
　　问题4：每个迭代周期后期，滞留大量测试任务
　　开发人员完成编码工作并不意味着用户故事做完了，在scrum团队中形成这样一种共识需要一个慢慢转变的过程。经常出现的情况是每个迭代周期后期，滞留大量测试任务，测试人员在后期不得不加班加点，显然这不是一个正常的状态。如果这个时候发现了很多问题，开发人员也不得不加班修复。为了解决这个问题，一方面整个团队要慢慢培养一个共同的意识：只有测试工作结束了才意味着这个用户故事真正结束了；另一方面，如果一个用户故事计划用少于一周的时间能完成，但实际上在第5天站立会议上评估仍然完成不了，要加派人手，集中力量保证它的进度。如果是因为技术难题陷入困境，可以留下一个或两个人员继续攻坚，其他人员要及时撤离出来，以保证其他的用户故事能正常进行。
　　问题5：评估会议上遇到需求不清楚的用户故事
　　一个庞大的系统，无论是开发人员还是测试人员，都有不熟悉的地方。在评估会议上如果遇到了这些生僻领域的需求，大家开始各种猜测，后也无果而终。既浪费了时间，也没有取得任何进展。针对这种情况，测试人员要利用自己的业务知识，主动地担当起需求澄清的任务，而这些事情好能够提前进行。终，我们会在当前的迭代周期内，预留一部分时间去发现这类用户故事，并通过各种途径去澄清，以便在后续的评估会议上能有效地评估它。虽然这种做法并不完全符合敏捷的风格，但现实工作中有效地解决问题才是重要的。
　　问题6：用户故事的编码完成之前，测试人员做什么？
　　刚进入scrum团队，在一个迭代周期开始时，开发人员刚开始编码的工作，那么测试人员这时候干什么呢？很多人会想到，编写测试用例。但是很多时候我们编写完测试用例后，编码工作还没结束。这时比较好的做法是开始编写自动化脚本，如果被测产品适合的话。这样做不仅提高了测试人员的编码能力，也拉近了开发测试的距离，大家在互帮互助中齐头并进。有时候测试人员也会去写单元测试脚本。尽量的培养自己成为多面手，虽然比较艰辛，但还是要尽大努力去做。
　　问题7：测试用例何时评阅更有效？
　　早期测试人员会先编写测试用例，开发人员开始编码，这两项工作几乎是同时进行的。等编码进行一半或者快结束时，测试人员完成测试用例的设计，并邀请相关组员来评阅。评阅过程中，开发人员发现有些测试点没有考虑进去，严重的情况下可能导致已完成的部分需要从头来做，这样造成了许多浪费。为了实现测试驱动开发，为了让测试人员充分发挥自己的优势帮助开发在编码之前考虑得尽可能全面，降低缺陷率，我们采取了测试先行的策略。在前一个迭代周期，测试人员会预留一部分时间设计当前迭代周期要完成的用户故事的测试用例。这个时期完成的测试用例着眼于一些要点，比较粗略。在实现用户故事前，测试人员邀请相关开发人员一起评阅，所有参与人员踊跃补充，尽可能地在编码开始之前考虑周全。这种做法对降低后期的缺陷率很有成效，也能帮助测试人员在测试之前充分了解那些不易自动化，复杂的测试场景。
　　问题8：如何帮助开发人员做测试？
　　测试人员习惯从业务的角度来组织自己的测试用例，我们使用脑图来记录这些测试点。由于开发测试人员的比例差距，很多时候开发人员也要参与到测试任务中来，看脑图上的那些测试点对他们来说是一个大的挑战。我们采取的解决办法是把脑图转换成excel文件，并打印粘贴在白板上，这种做法受到开发人员的青睐，他们喜欢这种清清楚楚，一条一条独立的测试用例。初我很反感这种做法，觉得从一种形式转换成另一种形式是极大的浪费，后来发现这种做法可以帮助我们进一步理清思路，有时候可以合并一些用例，减少测试用例数量，有时候还可以帮助我们发现一些遗漏的测试点。
　　从这个实践来看，测试用例的形式并不重要，无论是传统的一步一步详尽的测试步骤集合，还是发散性的脑图，亦或是excel文档也好，只要能帮助scrum团队高效地开展测试工作，我们完全可以不拘一格。