小谈项目敏捷性(一)

我也来小谈下关于项目的敏捷,文章在我以前新浪博客里写的。
敏捷开发的克星：1. 需求持续变更。
2. 需求不清晰。
3. 对于需求不清晰且持续变更，开发有抵触心理，测试展开困难。但是，没有改进的方法。
4. 利用一些敏捷开发的概念，但没有正真落实敏捷实践。且没有意识到许多活动不符合敏捷开发。
5. 已经发现了问题的症状，试图改进。
当发现以上问题中的几项时，这个项目已经不符合敏捷开发

敏捷开发的补充：
敏捷开发即需要注重项目进度不拖拉，具备自觉完成力。
> 测试标准不明确
这是一个典型的与客户交流的问题，需要与客户一起解决。这是一个难题，没有一劳永逸的解决方法。建议：
1. 互相派驻员工，协同工作几个发布，建立工作上的相互信任关系。
2. 每天定时电话+视频会议，沟通协调。现在为了压缩成本，越来越多的分布式开发。

> 测试介入时间太迟
敏捷开发要求测试在需求阶段就介入。测试人员与客户一起制定需求，并写出验收测试用例。开发的成果需要通过验收用例，才算完成，此后测试人员进行更深入的测试。

> 敏捷开发本来就是需求变更大
敏捷开发有助于在变化的需求中交付高质量的产品，而不是敏捷开发会导致需求变更。此外，任何开发方法都不能处理需求的快速、剧烈变更。

> 敏感开发讲究的就是快
敏捷开发不是讲究快，而是追求“全员质量责任”。由于所有人都对质量负责，产品符合客户需求、缺陷少，所以自然能够快速发布。单纯追求快，只能是欲速则不达。

> case能写就写，不能写以后就得补
我觉得，在时间紧张的情况下，测试系统是第一位的，文案工作是第二位的。在测试过程中，可以简要记录测试了哪些、使用了哪些测试策略。这些简要的笔记可以看作“实验记录”和测试用例，在某种程度上，符合CMMI5的要求。

> 开发与测试的交流问题
这也是本行业的长期问题。有一个可能的策略是，测试者增强自身能力，获得开发者的尊重。只有彼此尊重对方的能力，才可能平等的交流，这有助于解决交流困难。

UI:颜色，字体，排列，大小，语言等等。
功能：首先保证正常流程测试，既然你们没有文档也没有测试用例，那么就假设是客户的角度，把所有的功能点都测到。注意检查a.明显的功能遗漏，b.界面错误，c.数据库错误（连接错误和数据错误），d.性能（似乎你们不要求），e.初始化和结束有没有异常。

另外，你自己列个简单的测试计划或者checklist。把要测的点都列出来，按照上面说的大类别先分好。针对每一项，列出测试用例。而测试用例的用例数量不用全部列出来，已保证效率为目标。