敏捷软件需求：团队、项目群与企业级的精益需求实践 阅读笔记一

敏捷软件的核心原则：

1. 个体和交互胜过流程和工具
2. 可用的软件胜过完备的文档
3. 客户协作胜过合同谈判
4. 响应变化胜过遵循计划

很多时候，不同的公司和项目会采用不同的测试计划和手段，但是这都需要遵循这几条原则。

回想E项目，我们也号称是敏捷开发，但是是不是做到了这几点呢？

1. 在项目内部，不光有白板来trace流程，而且还要redmine来额外记录。这一点确实会阻碍效率。至少我自己很反感在完成什么事情后还要在redmine里面记上一笔。如果是FA之类的虚拟team，用redmine记录工作任务还是不错的。在DP team中确实有画蛇添足之嫌。但是这点是小节，基本上，在我们现在的agile team中，交流方面还是不错的。
2. 这条原则应该怎么理解呢？这里应该是一个“比较”的关系。软件的高质量实现确实是要优于文档的。但是文档的重要性也是不容置疑的。在E项目中，就是文档方面的缺失，使得很多功能都不知道对错的标准了。而这种欠下的债，在以后的项目中无一例外地要加倍偿还。那么在还债的时候，cost是谁要buying呢？
3. 这一点可能就是E项目做的很不好的一点了。我们没有办法和客户直接接触，而作为PO，或者说是业务专家的SM们，也没有很好的反应出客户的真实的需求。这样就使得整个E项目的开发和测试都不清楚客户真正的需求是什么。而测试人员，在这样一种的工作环境中，自身价值大大降低。测试人员只能着眼于价值相对低的领域了。
4. 没有感受到E在响应变化中的特别之处。

敏捷开发，就我的理解来看，是面向价值的。最有效率地实现用户的需求。由于公司内部是PO代表客户和team交互。理论上是不错的，但是由于本身是一个公司的同事，在很多方面都打了折扣。最典型的是DDS和orchestrator，在solution不完备的时候通过了项目，如果是和真正的客户在交流，可能就不是这样了。