从故障复盘看需求实例化

今年团队在需求方面做的一个尝试是需求实例化，针对特性级的需求去做，而不是针对story级去做。这里的前提是，把特性作为更大颗粒度的需求载体，由特性再去拆分出用户故事，把特性作为产品交付的最小单位，而把用户故事作为团队和项目迭代交付的最小单位，以及迭代过程中，团队内、团队间需求交流协作的载体。
特性做需求实例化的过程，就是用户场景的梳理过程，梳理出不同用户场景的，预置条件和验收准则。场景梳理出来后，AC自然就明确了，同时用户故事自然而然根据场景也能被拆分出来，QA同步也可以根据需求实例化的结果来做MFQ，在计划会上，根据实例化需求的场景和MFQ进行需求的澄清。计划会后，DEVer根据实例化需求和MFQ去做开发，QA根据MFQ去编写TC，最后再串起来，从多维度保证用正确的方法，做正确的事。
今天复盘一个故障的时候，发现是一个紧急需求引入的，紧急需求因为其时间要求太紧，没来得及做实例化，简单做了需求方案设计，和编写验收准则，没有来得及做需求场景的拆分和细化，所以在开发过程中不断遇到各种坑，虽然大家都用尽洪荒之力，最终还是难免留下一些小问题。复盘过程中，对需求实例化这件事情，有了新的认识，在拆分场景的时候，更进一步是需要考虑测试方案。在什么样的测试环境中去覆盖这些场景能够最大程度的保证场景的全面性。
同时，在做MFQ时，也需要特别关注一些边界数据的构造和场景的覆盖。
实例化需求，只是摸索着在做。做的过程中能够通过故障复盘活动，发现里面的不足，再去做有针对性的改进，这样的反馈很好。我们的任何一项尝试，都需要尽可能选取一些反馈点。再比如，今天故障复盘的时候，再回过头看看，这个需求的优先级，似乎也并没有当初外部反馈的那么高，我们当初为了响应他们的高优先级的要求而错失的前面一些关键活动，也直接对我们的后面环节产生了深远的影响。后面再有该领域的紧急需求时，就需要根据实际情况，总结这次的经验教训，把控住我们自己的节奏，不能完全受制于外部的要求，这样的反馈也非常重要！

图片发自App