公司作为设备提供商，不断开发新的产品，升级旧的产品，解决产品使用过程中发现的问题；我们作为网管研发团队，不断把新产品纳入网管系统，增加新的网管功能，协助解决工程应用问题。本质上说，这是一种以增量开发为主的模式。但一直以来，公司都是以项目制为基础在管理研发工作，以经典的瀑布模型作为标准的研发流程，公司通过CMMI3级认证的研发流程，也是以瀑布模型为基础。公司建立任职资格体系，也是以参与的各种规模项目的数量等作为评估的成果依据。
私底下一直感觉这种模型并不太适合于我们这种以增量开发为主的研发流程，CMMI运行的效果也不佳（实际上很少有项目完整执行CMMI流程）。这个问题困扰了我们很久，始终没有太好的思路来解决。一直到我看到了Scrum，学习了解并少量应用了Scrum形式之后，感觉这才是比目前瀑布模型更适合我们的开发模式。
作为一种敏捷开发模式，Scrum强调团队自管理，强调快速迭代，有清晰的组织形式，其自由开放的新理念也易为团队成员所接受。但是会对现有的研发管理框架造成大的挑战，特别是在满足公司市场战略，员工绩效评估等方面(我们已经习惯了项目由上面派下来，经理计划安排工作，团队成员执行的“常规”做法）。如果实施，这是一场从上到下的理念变革，如何保证公司、员工在这场变革中双赢甚至多赢呢？公司的市场目标、产品目标能否达成，员工是否能更有活力、更加投入，保证项目质量、进度，从而为公司、也为自己创造更大价值？
俗话说，一切重在“执行”，国外传来的这部“好经”，会不会被中国和尚念歪了（就像CMM ^_^)？我们怎样才能把Scrum学好、用好？窃以为可以从以下几个方面入手：
一，确定你的企业高层能否全力支持，这是企业中任何重大变革成功的关键。否则一个命令压下来，团队自管理就会成为泡影。
二，确定你的企业文化是自由、开放型的，能承受新理念的冲击。经理们能否放弃控制一切的欲望，员工们能否做好自我管理工作任务的准备？
三，确定你从哪儿开始Scrum，找一个合适的试点团队、试点项目。
四，培训宣讲，让团队成员们统一思想，使得大家都了解具体的方法、过程、和角色分工。他们大多数将会是贡献出一切的开餐馆的“猪”的角色，没有他们的理解支持，什么都将成空。
五，找好你的Scrum Master，找一个好的Scrum Master，确定你的Product owner。（好象没有项目经理，那他干什么？哦，我也不知道。）
六，开始吧
虽然有了这些构思，但还没有成为现实。Scrum，我们应该拥抱你么？