昨天晚上参加了SCRUM中文网举办的“启动敏捷实施的5项准备”讲座，演讲人是国际知名敏捷顾问、Scrum导入专家Arne Ahlander。他的演讲时间不长，PPT只有10页左右，因为我对导入SCRUM多少也有所了解，所以倒没觉得演讲有什么新东西，但是演讲后的Q/A环节，从他的一些观点中我还是有所收获的。
1. 伤不起的“最佳实践（Best Practice）”
演讲后的Q/A环节，有位与会者问Arne有没有什么“最佳实践”可以帮助企业顺利导入敏捷或SCRUM。Arne马上澄清一点：“我不会使用Best Practice一词，而是使用Good Practice，因为Good Practice意味着可以变得更好。”
确实，时下“最佳实践”一词炙手可热，但是很多企业使用了所谓的“最佳实践”并没有获得预想的成功，原因可能就是受了“最佳”一词的误导。对于他最佳，不一定对你最佳。就好像找对象，最完美的不一定是最适合你的。所以导入别人最佳实践的时候，首先应该辨别，哪些适合自己，哪些不适合，不适合的不能采纳。
InfoQ上有篇文章《Better Best Practices》，从名字上看好像就是个悖论，已经Best了，怎么还能Better，其实文章要说的是：没有最好，只有更好！在导入“最佳实践”时，根据实践者的“上下文”，列出“利弊之处”，在权衡和妥协之中获得更适宜的实践。
前些日子看《黑客与画家》一书，作者Paul Graham说的更极端：“所谓‘业界最佳实践’，实际上不会让你变成最佳，只会让你变得很平常。”虽然他说的是编程语言，但在敏捷上道理一样。所以，别动不动就“最佳实践”，伤不起呀！
2. SCRUM中的构架
有位与会者问到在SCRUM中做构架的问题：在开发一个相当复杂的系统时，是不是需要几个Sprint来做构架？做多大规模的构架合适？以及如何在Sprint Review时演示构架？Arne先回答了最后一个问题。他建议，不要单纯地进行构架，在每个Sprint中要增加一些业务功能（Business Functionalities），这些功能是建立在所做构架基础之上的。这样，在Review的时候，演示这些业务功能，而不是演示构架，构架不太好演示，况且产品负责人、用户、Stackholders可能也不懂构架。
这实际上已经回答了第一个问题：可以在开始的几个Sprint中做构架，但不要单纯做构架，要加入业务功能。这样可以尽早得到反馈，并且持续地利用重构改进构架。那么做多大规模构架？Arne说，这需要对业务领域有所了解，由于他肯定不如提问者更了解他们的领域，所以这个问题应该由提问者自己找到答案。但是他又说：他的建议是要对反悔的风险进行评估。也就是说，如果由于你的构架规模大，时间长，反馈不及时，造成设计反悔的风险过大，就需要缩减构架的规模。因为SCRUM本质上，主张小步前进，持续重构地进行构架。之后，SCRUM中文网的Louis补充到，对于像电信系统的构架，可能需要一个前期的大规模的构架阶段，但是一般的企业应用系统，用SCRUM的构架方法应该可行。
现在业界存在的对SCRUM的争论之一，就是对于需要复杂构架的项目或产品，没有大规模前期设计阶段的SCRUM到底适用不适用。Arne的阐述，或许给我们提供了一条可行的解决之路。
3. SCRUM适合初级水平的团队成员么？
这是与会者的一个问题，恐怕这也是很多人的问题。很对人抱怨团队成员的素质低、水平差、没有主动性，没法实施SCRUM。我也曾经怀疑，SCRUM适不适合具有这样成员的团队。Arne给我们举了个例子。他提到刚刚登顶欧冠的巴萨：如果巴塞罗那队跟他儿子所在的校足球队比赛，他儿子的球队没有获胜的可能，但是他们跟实力相当的队伍比赛，就可能获胜。我想，Arne举这个例子，是想告诉我们：不要抱怨团队成员的水平差，他们仍然能够获得胜利，只要目标在他们经过努力后能达到的范围内，之所以我们不相信SCRUM能适合水平相对较差的团队，是因为我们把目标定得过高。我觉得这很有道理，不要因为我们的成员还不会TDD，就觉得我们无法实施SCRUM，我们可以从写Unit Test开始；虽然我们还做不到主动的、充分的交流，但至少我们可以从摘掉耳机，参加每日站会开始。不寄希望于SCRUM解决所有问题，我们只需要一个能让我们持续改进的平台和机会。