封闭笔记——第二天，开始优化流程

2010-03-02 晴 微凉

今天我们进入了正式的开发阶段，各个项目组也都开始按照自己的步骤进行下去了。

今天非常显著的几点进步如下：

• 产品、测试拆分场景
• 研发拆分用例为 TestCase
• Git 初步使用

今天我一直在整理新的开发流程，相对于以往，新的流程非常强调场景的概念。从产品的需求到最终上线，都是围绕场景的。（具体我会稍后详细解说）
对于场景，第一步也是关系着流程能否跑起来的关键的一部就是产品的用户“场景”。今天我们伟大的产品人员抽象了每一个用户场景，让我们测试和研发的童鞋非常容易入手。
对应着“场景” ，我们的产品、测试、研发都进入了角色，都开始了围绕着场景的战斗。

花开两朵各表一枝，我们先说产品和测试的用户场景。早上，产品和测试的童鞋采取了半结对的方式拆分用户场景，把每一个场景都拆分成为逻辑上可以测试的用例，并记录为Wiki。这样以后对产品的需求覆盖有据可循，也对研发的开发边界有了一个良好的指导。

我们再看另一路的研发。携昨晚测试童鞋拆分用例之威，今天研发的童鞋就已经开始撰写 TestCase，并且已经跑起来了。来，为他们呱唧呱唧。
TestCase 就没什么可说的，今天说说在使用过程中，尤其是初次使用的时候可能遇到的一些问题和疑问。最常见的是：

1. TestCase 和功能性代码貌似只能迭代进行，无法先写完整的TestCase
2. TestCase 中的那些只有名称没有实现的代码，看上去怪怪的。

先说第一个问题，如果是个人开发，当然是迭代进行最为爽快，用例完成，代码也完成。但是对于团队开发，而且是从业人员有梯度的情况，情况可能不同。因为有时候要以一个设计者的身份，有时候要以一个管理者的身份。这时候，我们可能需要更多的统管的一些责任，那么完成大多的TestCase是一种比较可行的办法。

对于第二个问题，其实使我们在开发中身份转换的一个情况。大多的场合，我们是开发的身份是开发人员，我们是细节，这时候我们的视角是从下向上看的。而在我们撰写TestCase时候，是一个使用者和设计者，这时候我们是需要从上往下看的。我们是API的第一批使用者，如果这些API我们自己用着都不爽，那么别人一定会来砍我们的。

另外，我们这次还有很重要的一个环节，就是每天晚上的Review。这里既包含对代码的Review，也包含对TestCase的Review。这里不再废过多的笔墨，我会找时间专项讲解的。

第二天的工作是充实的，我们感受到了团队在成长，感受到每个人在成长。真不错。