Scrum领航员培训后感

　　3天的Scrum培训课程结束了，学到了好多东西。感谢公司给予这次培训的机会，感谢徐讲师对知识的分享。

　　一开始讲师就突出本次参与培训的人员是有史以来最多的，可想而知，大家重视的不仅仅是编码一个阶段了。

　　刚开始，我没有重视这次培训，本着听听看的态度。Scrum嘛，不就多次迭代瀑布模型嘛，有什么了不起的。是这样吗？对于传统企业，传统的商业模式，他们有着固定不变的企业文化，要求员工必须按照规定工作。我们做这样企业的项目，你可以说Scrum就是把大瀑布拆分成好多小瀑布迭代。但随着社会的发展，传统行业已经无法满足新兴行业的需求，现代企业喜欢与众不同，喜欢打破常规，而事实证明这种创新模式比传统模式更能适合现今的市场。我们做这样企业的项目，采用瀑布模型，V模型开发，成本和风险都很大。采用螺旋模型，我们可以估算出风险，但降低风险却需要大量成本。企业不会给你一个明确的需求，好多问题需要在无数次沟通之后才能敲定。所以我们就得持续的与客户进行沟通，提供原型，明确需求，然后不断迭代。Scrum不仅仅是多次迭代的瀑布模型。Scrum告诉我们，需求不明确的时候，我们可以快速做出个原型出来与PO沟通，不断的沟通，直到需求明确；Scrum告诉我们，自己自主去做事情，比别人指挥着做事情效率更高；Scrum告诉我们，迭代频繁，可以提前暴露出问题，及时补救，降低风险；Scrum告诉我们，通过时间控制成本；Scrum告诉我们，一个高效的团队，其内部成员对整个团队现状了如指掌。

　　测试，在国内项目中是最不受重视的，特别是对于开发来说。这种意识是大错特错的，开发出来的代码，你怎么告诉别人，怎么证明你的代码是正确的。编译通过吗？那好，怎么证明你的代码逻辑是正确的。编译？一个合格的开发人员应该写出一段负责任的代码，而不仅仅是通过编译。怎么写出负责任的代码呢？我们不应该完全依赖测试人员，我们应该有自己的一段测试代码来证明我们的逻辑是正确的。相信大家会说，这样开发的成本就会高，要花费好多精力来维护测试代码。我之前也这么认为，后来在实际项目中，我去修复别人的一个bug时，却带动引发出了好多新的bug，而测试组却在好几天之后才发现的这些bug，然后我又花费了好几倍时间来调查这些新的bug。这时我才意识到问题的严重性，如果当时有段代码或有自动测试用例，那么就能及时发现问题，后期也就不会浪费更多时间来检测bug。开发人员测试自己的代码是必要的，特别是遇到复杂业务逻辑的时候，有段测试代码更是必不可少的。TDD，测试驱动开发，微软为我们提供了许多工具，框架来帮助我们开发人员更好的实现高效率开发。我们该行动起来了。

　　Scrum虽然好，但我们也要结合实际项目特定环境，不能套用或滥用。毕竟美好的事物都是一把双刃剑嘛。期待VS2012 DSL新特性。