互联网开发的特点是什么，用一句很有名的话来说，就是always beta，什么是always beta，直白的翻译，永远的测试版，为什么会这样，因为用户的需求总是在不断的变化，唯一不变的就是变化本身。这种特点的开发特别适合敏捷开发，而强调自组织特点的Scrum又是其中一个值得尝试的开发模式。点评在最近一段时间内做了一些这方面的尝试，在实践的过程中得到了一些粗浅的认识。
1.为什么要选择Scrum
让我们来看这样一个方程，决定一个项目成败的元素有哪些？工作量，期限，质量还有功能需求，由于需求是不断变化的，所以期限也无法确定，一个四元方程中有两元是无法确定的，那质量当然也无法确定。而Scrum就是先把期限定下来（冲刺周期），然后再把功能需求定下来（冻结需求），而工作量是已知的，这样质量就可以得到很好的控制。
2.如何划分冲刺周期
按照Scrum的定义，一个冲刺周期一般为30天，而对于互联网开发来说，这个周期显然太长，对于一家运营模式比较清晰的垂直网站来说，开发项目的复杂度一般不会达到几个月的程度，所以把冲刺周期划分为1-2周会更加合适，而这个周期也应该去适应网站的发布周期，个人认为2周是一个比较合适的冲刺周期，当然，目前在点评这个周期一般为1周。
3.每日站立会议
Scrum里面有一个很有价值的概念就是每日站立会议，很多开始实行Scrum的公司都会先纳入这个概念，而实际的效果如何呢？根据我们的实践，包括一些网上的资料，发现每日站立会议往往会变成一个每日报告会议，项目成员将每天的工作进度报告给项目经理，项目成员之间根本没有交流，这个根本不符合Scrum的自组织特性。Ken Schwaber在《Scrum敏捷项目管理》一书中针对这种情况提出应该鼓励成员在每日站立会议中多做眼神的交流，我觉得这个措施值得尝试，让每个人都去关心Story中的每一个任务的情况，让其更有参与的意识，提出自己的意见和建议。
4.Scrum头号杀手
好像很恐怖的样子，什么是Scrum的头号杀手，那就是在冲刺周期内作出需求的改变，Scrum严格要求冲刺周期内冻结需求，但是在执行上，相信很难做到这点，应该讲，做不到这点就不能算真正在实行Scrum模式，这个时候就需要Scrum的执行者能够有坚韧的决心，敏锐的判断力以及出色的说服力。所谓坚韧的决心，是因为需求的变更可能来自上级甚至高层，不能被这些因素影响你的判断力。所谓敏锐的判断力，一方面是指在制定冲刺的时候要能够判断出隐性需求，往往之后需求的变更是由这些因素引起的。另外一方面，是指需求方在提出需求变更的时候，需要判断出其需求的本质是什么，到底什么才是他想要的结果，这些并不一定通过其文档或者讲述能够看到的。所谓出色的说服力，是指在作出正确的判断后，如何用清晰简单准确的语言去说服对方放弃在当前的冲刺周期内作出需求的变更，当然，并不是要把对方的路给堵死，而是给他开辟另外一条路。
Scrum并不是万能药，照搬照抄的结果必然是失败，希望能够有更多的从事互联网开发的朋友来一起学习一起交流。