【IT168 分析评论】

    最关键的是解决短木板

    管理学中有一个短木板理论，通俗的说就是：发展空间有多大，不取决于你有多少的优势，而是取决于你的最大劣势。目前实施Scrum，有很多已经在不错的进行，例如有了正式的PO，有了backlog，有了各种planning meeting，有了demo，有了burn down_ chart，daily Meeting等等，但有一个最大的问题没有解决：质量。我们现在由于业务的需要，一个月提交一个版本改为一个星期提交一个版本，这样如何保证产品的质量特别突出，因为每一次提交是要正式部署在产品服务器上的。上两个sprint的情况看，质量问题非常突出，直接影响了所有人对Scrum管理项目的信心。质量问题表现在：

    *** 测试的覆盖率不够，功能有问题，例如报表数据的准确性有问题 ***

    究其原因，在于：

    1. 迫于时间的压力，设计很仓促，实现逻辑不清晰，特别在异常流程中。

    2. 没有足够的时间做系统测试。

    目前正在做的：

    1. 和PO沟通后达成共识：鉴于目前研发组的实际情况，前两期sprint表现的Velocity明显有问题，需要较大程度的降低以提高质量。与其仓促提交没有质量保证的10个功能，不如认真提交可以保证质量的5个功能。

    2. 加大力度在sprint前期的设计讨论，集中在接口、正常逻辑、异常处理三个方面，并保留文档（文档的内容只包含时序图和最简单的文字说明）

    3. 我以前的Scrum经历都是一个月的sprint周期，无论怎样都会有比较详细的系统级测试，目前在一个星期的周期内如何做测试，我还没有一个很好的办法。TDD、自动化测试都是可能的解决方案，但是否还有更好的办法？我想可能会从Lisa的著作“Agile Testing”中找到一些答案。抓紧时间看书！！！！