只允许用户修改自己的svn日志的钩子脚本：

for /f "usebackq" %%k in (`svnlook author %1 -r%2`) do @set var=%%k

if "%3" == "%var%" goto test
if "%3" == "li"    goto test
exit 1

:test
if "%4" == "svn:log" exit 0
echo Property '%4' cannot be changed >&2
exit 1

经过本周一，周二的扫尾，周三上午日会时就对系统进行了演示。
本系统关键点没有搞定，也就是说本次sprint目标没有实现。本次演示时，发现仍有若干功能的遗漏。

整体投入度比估计值还低。功能遗漏是我监管不力，其实是故意不去管的，就是测试我的故事列表是否写得够清晰，能让大家都看明白。实事证明这里是需要改进的。故事要细化，要有自己的主题。不能因为相似而合并不相关的故事。

故事的分解这次也做得不好，本身团队习惯按层级编码，但一个故事分三层做的话，又太小，合在一起又太乱。下次还是明确细分一下，以免遗漏。

本次测试驱动没有很好执行，下次改进，先写测试代码。

好的方面是已经搞定cc.net，能自动完成代码获取，编译，单元测试。web的自动测试还没有实现。

进入sprint时，人员的投入度要尽量提高，减少其它项目或任务的干扰。外部的因素要尽量减少它的依赖性，以保证项目的正常进度。

总之，这是我们第一次scrum的经历。

公司动荡，时常开会。投入度低。
E，F 加入进来，第一天基本是熟悉一下项目。
今天分配下去的任务也很少。关键点还是卡着。

周四：C完成接口编码，总算完成了。其它一般。E,F刚开始了解。
途中跑，比较平稳。燃进图上，曲线在上方，催促着我们。

周五：关键点上仍然没有测通。开始另一个关键点（上周二的设计）的编码。
随着任务的减少，空闲人员开始自发地结对。

到这次日会，燃尽图上走到11点的位置。还剩余5点。下周还有2天，5人，周三演示。

A继续Dal相关的编码;B归位，进行UI及与Dal的对接;C进入新方案的接口编码。
世事难料，先是公司重组，将有人事变动。后是C有要事，得请假。整体投入度又要降低。
好在还有兵马好动，E,F已经完成其它项目，计划再加2人进入这次sprint。

不足的地方：如果对照目标的话，由于核心功能出现技术困难，本次sprint的目标没有太多进度。现在忙的都是些外围的辅助功能。

奥运圣火照耀着我们。中国13金了。

突然想把奥运会比做项目，4年计划，运作，决战于16天。然后又是一个全新的4年。这比赛的16天好比sprint的演示，这是个交答卷的日子。

周四日会，A完成数据库设计，C难题未解
A计1d,B的任务完成度不好估计，等他回来再计算。燃尽图上向下走1d。
A开始新的任务，dal层的编码与测试，C的任务是个难题，只好自己D出马试试水。

这两次会议都在15分钟内完成，毕竟才问询三个人的任务。感觉都没做多少交流。时间就到了。

周五日会，A在写测试代码时，比较手生，进度落后，C难题无解，D试水也无解。
难题无解只能另寻解决方案。C着手另一种方案的设计，A继续写dal与测试。燃尽图上没有向下走。

周二日会，A忙其它，没有完成任务，B完成了UI的框架编码，C回来了

昨天用的记事贴，贴在玻璃上，好多掉下来了。最后还是在玻璃上先贴上白纸， 记事贴再贴到白纸上。明天看效果。

布置任务板占用了一些时间。由于实际情况，任务板贴在会议室里，有条件的话，应该贴在工作区内，大家都能实时看到的地方。

目前对backlog没有做详细的任务分解。做一点分解一点。A继续做初步的数据库设计，BC进入功能点的开发。B的功能比较复杂，需要进行UML的分析。

燃尽图上向下走了一个点。

在看了N遍之后，N>10。越觉得Scrum的可行性很好，就准备先拿一个小项目来试试。

首先这个DMM项目只有功能需求，无操作界面需求，提供的文字没超过两行。

之前的做法：做系统设计，数据库设计，UI设计。

Scrum的做法：编写产品backlog,做Sprint计划会。

编写产品backlog是我看这本书的一大亮点，一直以来就为这个如何演示所困扰。因为不清楚这回事，有需求来了就开工，完全不知道如何结束。做到满意为止，当然是个美好的愿望。但做为一个开发人员来说，一个功能反反复复得修改，工作得不到认同，会有失落感。backlog的如何演示解决了这个问题。一个业务需求，配上如何演示，就有了衡量开发是否完成的标准。

操练第一步：编写产品backlog

backlog看书上说得这么轻巧，就列了一下字段。真要写个如何演示出来，还是有难度，它有点象测试用例。不过在编写的时候，有个感觉很好，如何演示就象已经在做好的系统上操作一样，想象着去测试各个功能。自己在写的过程中，还是不自觉得开始罗列一些对象，属性。不知道有没有停留在业务层次上。然后我就列了12个backlog。照书上的方法打印成卡片。

操练第二步：Sprint计划会

虽说书看了N遍，一召集人马开会，就全忘光了。我把卡片往桌上一摊，先让大家看。然后讨论功能，对优先级做了些调整。之后就开始做估计值了。因为之前团队里玩过几次计划纸牌游戏，对这个熟啊。在估计过程中，对几个功能相近，用时偏小的backlog进行了合并。最后得出7个backlog，估计值16。

在做完这些之后，我居然宣布散会了。回来一整理，才发现什么sprint周期，目标，演示日期等提都没提。晕啊。好在我说了下周一来了做任务分解。

整理后，按3个开发人员计算，70%的投入度，得出8天的开发周期。考滤这个项目次要，大家手上还有其它重要的项目在做，这个投入度还得再降一降。下周日会再汇总一下意见，订个目标，演示日期出来。

支付宝首席架构师程立的分享很精彩。讲述了支付宝几年走过的架构历程。《程立谈架构、敏捷和SOA实践》

截止到2008年5月6日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。 对于这样一个系统，支付宝也是从简单三层的应用开始的。面对不断变化的业务，海量的数据，系统内产生了上千个类的情况，给开发维护都造成极大的困难。之后开始应用SOA,对系统进行封装，将功能做成服务，每个服务都可以应用集群进行支撑。

分布的业务，分布的数据，海量的访问。

对事务的处理，提到了两个概念：ACID(原子，一致，隔离，持久)和BASE(基本业务可用，柔性状态，最终一致)。

支付宝对BASE的实现有一个TCC模型（try-试执行,cancel-取消,confirm确认）。

在之后的讨论中，有幸程立和我们在一个小组。对分布式系统中的事务处理，及在SOA中的应用引起了大家的关注。ACID被称为刚性事务，BASE被称为柔性事务，这个叫法很快被认同，也很好理解。讨论很快集中到最终一致上。因为大系统应对大并发时，必然会采用柔性事务，以保证基本业务可用。之前自己做的一个系统里也遇到过这种问题，刚开始的时候采用刚性事务，在小数据量的时候好象没什么问题，当数据量大了之后，一次刚性事务就会占用系统极大的资源，对用户的响应和并发都造成影响。之后改用柔性事务的处理，把请求放到一个队列里执行，这样就避开了并发，只是用户操作的结果不是即时有效，有系统处理的延时，也就是最终一致。不过当时开发的时候不知道ACID,BASE的概念。

支付宝是7*24小时运行的系统，其中各种服务上百个。这样的系统开发，维护都是一个大问题。先说开发，编码之后的测试，光环境就需要上百台机器，这可不是每个开发人员都能得到了。然后是维护，系统需要更新，但服务不能停，怎么办。例如有50台机器需要更新组件，就先停25台进行更新，然后开启，再更新另25台。这就要求组件的向下兼容性要好，更新的过程要严谨。

随便提一下支付宝的开发模式，以产品线为组织形式，各产品线每周提交一个更新包进行系统改进。新加的项目周期控制在3个月以内。没有严格的模式定义，比较倾向于敏捷。目前开发人员在200左右。

整体来说，现在的支付宝架构良好，开发有序，前程一片光明啊。

反观自己，架构还在初级阶段，开发混沌，路漫漫兮其修远 吾将上下而求索。