标签：
最近产品出现了几个不大不小的问题，时间点却偏偏是在距离产品发布不到一个月！！在解决完问题后，不禁要思考一下：到底哪里出了问题？
下面是对最近出现的问题的反思和一些改进办法：
敏捷团队中需求的获取有很多种方式，大体的来源分为：
a. 最终客户（需求和反馈）
b. 行业标准
c. 竞争产品
d. 团队贡献和创新
e. 其他
我们遇到的问题是有一部分客户对域里的用户权限限制很高，不是我们常用的有域管理员权限，这是我们没有考虑到也从来没接触过的的使用方式，以至于产品根本无法在一些客户真实环境中使用，从而导致了产品在将要发布的关头进行大修。那么这个问题为什么之前没有发现呢？有几点原因：
1. 需求分析阶段没有充分挖掘需求（只关注了大部分客户，忽略了一些特殊客户需求）
2. 未及时向客户展示产品（每个迭代结束后，客户很少参与评审会议）
3. 产品优先级设置不合理，造成直到产品非常后期才能进行端到端的测试
4. 未及时交付客户试用（也有一部分3的原因，造成产品时时不能进行客户试用）
那么有了原因，就开始找改进办法：
1. 需求分析阶段，尽量让不同的客户参与，避免对一些重要需求的遗漏 （PO协调）
2. 邀请客户参加每个迭代的评审，客户的反馈非常重要（PO协调）
3.用户故事优先级必须要明确，首先保证主要功能完成，能进行端到端的调试运行，然后进行主要功能周边的修饰工作（PO主导，PO和team共同完成）
4. 3明确了以后，就可以尽快让客户进行产品试用，得到第一手的反馈，即使有需求的以后，也会有大把的时间来改进 （PO主导与客户接触）
这个问题有多方面的原因：
1. 一些重要的测试放在了太后期执行（如升级测试，这一块发现了不少defect）
2. 产品太大，跨3个敏捷团队，每个团队对其他团队做的模块了解不深，以至于有些测试必须跨团队完成，沟通效率低，容易遗漏
3. 每个敏捷团队所关注的测试部分不同，容易忽略其他敏捷团队比较明显的问题
4. 测试人员少，对开发人员的测试培训不充分（开发和测试都会负责一些测试工作）
针对这一部分，需要改进的方面:
1. 对于大的产品，在做几个迭代之后，各个团队对产品进行纯测试迭代，尽可能早的发现问题（SM主导）
2. 各个敏捷团队的SM进行定期的碰面会议，协调进度，尽量做到步调一致（SMs）
3和4. 敏捷团队之间进行一些必要的培训，如模块介绍，实现技术或者测试技术，帮助提升团队技能。创造机会让团队跨team进行测试，或者进行结对测试，帮助对其他模块的了解（Team）
总结
这两个问题主要还是由于流程引起的，包括客户在敏捷团队中所占的比重，跨敏捷团队之间的沟通等方面，这就要求我们在每个迭代回顾会议（包括敏捷团队内部或者跨敏捷团队的回顾会议）认真分析我们的不足，及早提出解决办法，并且添加相应的Action Item和Owner，这样才能做到持续改进，更加敏捷。
标签：
原文地址：http://www.cnblogs.com/AlwinXu/p/5440962.html
