项目很紧急，所以过年这段时间也留在了北京加班。从有这个项目的计划到实际上线，时间只有二十来天，包括产品设计、ＵＩ设计、开发到上线。
项目组包括我在内，配了5个前端，其中两个是新同事。时间很紧迫，上线时间点在那儿，过一天少一天，而项目基本从零开始，从无到有。这是个机会也是个挑战，机会在于我们不用维护别人的代码，可以完全自己去设计，这对于日后的可维护性有着非常重要的意义，挑战在于时间短，开发团队要从规范到设计到互相适应的成本要压到最低。
我选择了scrum做为项目开发流程的框架，之前研究scrum了很长一段时间，而且在之前和秋云配合的项目中，我们已经应用过，虽然初次应用不尽如人意，但结果却是按预期计划按时上线了——scrum的威力可见一斑，即使经验的不丰富使其效果打了六折也依然让我们完成了任务。
有了之前的经验，在这次的项目里，我们的scrum做了一些改进：
1）scrum中提到了跨职能的团队，却没有提到串并行的问题，所以在估算团队生产力的时候，用“所有成员数＊时间＊打折系数 ＝ 生产力”的计算方式并不准确，这次我们将UI设计、页面构建这类必须先行的工作排除在了计算之外，他们并没有算到开发团队中，因为他们的工作和实际前端开发团队的工作其实是串行的。这样，计算出来的生产力才更精准。
2）因为实际工作中，由开发团队自行测试是不够的，所以我们会把QA加入进来，但QA并没有算到我们的开发团队中，他们的生产力也不会算到开发团队的生产力中。我们给开发过程定了“to do”、“开发中”、“自测”、“测试”和“完成”五个阶段，其中“自测”是我们开发团队自己测的，而“测试”是交给QA部门去测的。
3）燃尽图的更新，并非等到sprint backlog至到“完成”才更新燃尽图，我们把“自测”阶段的sprint backlog算了一半的完成，只要至到"自测"阶段，就可以减少故事点了，只是“自测”的故事点要＊0.5，算完成一半了。因为如果要等到“完成”才减少故事点，很可能让开发阶段长期处于高剩余的状态，而到后期，燃尽图下降的幅度会非常大，它并不能真实地反映开发进度，实去了让开发进度可视化的作用。虽然“自测”算完成一半这种算法也并不完美，但已经是个很大的改进了。
4）我们在拆分sprint backlog的时候，是整个团队一块儿拆分的，在这个过程中，我们对着ＵＩ设计图，将整个项目的功能拆分成几个层：“base层”、“表现层”、“control层”。base层做基础建设，基于jQuery，在此之上，我们定义了命名空间、Utils、Class等基础功能，和Base、Panel等抽象类，所有底层的工作全放到这一层，它对应的用户故事是"Base层"。表现层是功能最多的，也是我们工作的大头，为了让开发团队能对规范有更好的理解，代码风格更统一，我们在项目前期花了两天的时间统一代码格式、类的拆分。我们将工作中所有可能用到的类全部一起拆分，用ＵＭＬ图记录下它的类名、公有属性和公有方法名，这份UML图有两个作用：<１>搭起整个项目的架构，开发团队只需要实现定义好的接口就行，所有未被定义的都算是私有方法，开发团队在大的抽象层面上非常清楚项目中的各个环节。<２>代替开发文档，提供最简单有效的说明，以后只需要维护这份ＵＭL即可，不需要维护开发文档，即使项目交待或有新成员加入，学习成本也会非常低，从UML图就能知道代码是如何工作的。正常情况下，应该是在计划会议上拆分ｓｐｒｉｔ ｂａｃｋｌｏｇ的，而且时间应该不超过4个小时，但因为是项目的第一个轮次，开发团队不熟悉，代码架构也没搭起来，所以我们没有在计划会议上拆，而是另外花了整整两天的时间去拆的。估时也是开发团队一起估的，效果很好，因为对着UML图，开发团队对架构非常了解，基本上对估时不会有大的异议。
5）scrum master的角色是由我的扮演的，项目组的进度由我负责，而我又是唯一熟悉敏捷的人，理所当然我担任了scrum master。但和一般的情况不同，因为时间紧，所以我其实还要编写实际代码，所以我常常在两个层面工作，一方面主持会议，协调和其他部门的合作，另一方面，我需要沉到代码中进行编程。坏处是我的思路要不停切换，所以我只算了半个生产力（开发团队算４.５个），好处是我可以更近地贴近代码，更真实地了解到项目进展以及瓶颈所在。
项目实际进入开发阶段4天了，效果非常好，沟通成本低，开发进度出乎想象的快——当然，一方面因为scrum是个优秀的敏捷框架，另一方面我们的开发团队真的是很强，每个人的实力都不错，包括拆sprint backlog的时候和开发的时间，都非常地顺利，这非常难得。要知道，一个强大的工程师不难找，但一支由一群强大工程师组成的团队就很难很难得了，这一点上，我们无疑是幸运的。
最后，附上一幅我们任务墙的图片，
