最近听说好多项目都在做敏捷，无论是开始还是测试都在尝试敏捷，毫无疑问地，这是一件好事，说明大家在意识上都意识到敏捷的重要性。
我们来看一些有关敏捷的宣言：
* 个体和交互 胜过 过程和工具
* 可以工作的软件 胜过 面面俱到的文档
* 客户合作 胜过 合同谈判
* 响应变化 胜过 遵循计划
下面笔者来谈一谈个人的看法：
1． 可能敏捷的最终目的是能够帮助软件高效迭代，更具质量，更满足用户需求。
2． 虽然我们强调交互胜过工具和文档，但请大家注意，它只适合团队成员不超过10个人的时候，当具备10人以上团队时，请慎重，或者通过架构将产品解耦成关联性较小的component.
3． 如果你的燃尽图：
* 不能让团队每个人了解
* 不能起到跟踪产品状态的作用
请延迟使用敏捷，因为可能现在的团队还不具备这种能力
4． 如果你的业务逻辑复杂，而测试又大部分是手工而非自动化，请慎重考虑，因为这样很可能最后是一些开发人员在敏捷，而使测试人员游离于团队之外，因为测试人员根本没办法敏捷起来，手工测试的任务重，还要和每个人员沟通，最终这将会是整个团队的一个短板
5． 敏捷强掉的是minimal document, 但绝对不等于没有文档，试想一下，在任务压力比较紧的情况下，如果不通过文档这种能深入思考的方式，PD和开发人员很可能会漏掉一些重要的业务分支，最终产品是按期开发完，可大量的工作又会堆到测试这边来。
6． 每天的站立会议，请记得把需求人员involve进来，敏捷强调沟通，这里个人觉得更应该强调与客户的沟通，即与需求的沟通，如果需求变化，应及时调整团队方向。
最后，笔者想说的是：
* 敏捷只是宣言，Scrum只是形式，是不是敏捷，能不能敏捷，要看产品实际情况和团队人员的能力。
* 沟通的最终目标是尽量避免沟通，文档的时间成本和人力成本大，采取了沟通，如果沟通比文档时间和人力成本更大，得不偿失。
* 产品的设计者应该尽量采用契约式设计，降低大家的沟通成本，程序员天生的执拗和固执通过代码可能会更好的去表达，如果出现问题，大家再来沟通一下
* 需求人员和测试人员一定要参加会议，提出自己的看法，不能把敏捷只看成开发的敏捷
* 测试人员要在业务上强于开发，技术上约等于开发，这样才会提高整个敏捷团队的战斗力
* 鼓励尝试，没有尝试，永远也不会有经验积累，不过要因人因事因物而异。
以上文字仅是个人意见，若有偏颇，望指正…
相关链接：
