充分理解之后的再反对，总不能说我站着说话不腰疼了吧。
一年以来我感觉自己对SCRUM的态度有些变化，因为实在与现在的工作无关，也就缺少必要的关注了。还有一些原因是自己身在‘池塘’，就算想着干爽也是不可能的。近来又在推行测试驱动开发（下文TDD）我就想把自己的理解写一写，记录一下，以免忘记了。
目标：流水线方式是为了让不同程度的人更好的契合在一起，能够迸发出高水平的实力。
SCRUM本身就是一种流水线，TDD当然也是。简单的说，不管是SCRUM还是TDD目标都是提高团队交付高质量代码的能力。他们都允许失败，但是必须坚持不懈。说起来就这一点让人感觉很不爽，因为一开始的低质量和缓慢的进度都是这些流水线的副作用，也就没什么可以吐槽的地方了。但是真正的流水线却不会因为刚刚开始而效率低下，所以应该是流水线本身的问题（某些规定还是不详细）。所以如果进度比较慢，那也许我们的约定约束的方式太人性了。
SCRUM流水线是以Sprint为周期的，期间大概有计划会议、每日站会、开发工作、评审会、回顾会。TDD流水线是以测试开始的，流程大概有单元测试用例、开发工作、重构工作。当然集成测试、回归测试这些阶段性的环节，应该可以先在流水线里剔除，毕竟刚刚开始。这样看，TDD细化了SCRUM的开发工作。可以说两者是相辅相成，因为SCRUM重点突出快节奏，高质量，而开发时往往因为计划会的上手程度要大于开发工作，直接导致只是快节奏，而忽略了质量。而TDD则是慢节奏（相对来说，其实TDD也需要有一种紧迫感），高质量的。因为编码工作增加了一倍，工作时间当然也就延长了，这一点应该体现在SCRUM计划会的时候会估算更长的开发时间。但是一旦测试用例确定，代码质量理论上说是不会下降的，这就是相辅相成的重点吧。建议开发者测试用例写完或者开发过程中，有相应的审查机制，这样可以保证单元测试的质量。因为模具造车，模具有问题车自然会有问题。
形式上：两种规则的叠加
目前的流水线应该是：计划会、每日站会、开发工作（单元测试、开发、重构）、评审会、回顾会。工作量其实还是按照SCRUM上的定义，由开发者进行的。我想难点应该在计划会结束后，把分得的任务改成测试用例这一环节吧，当然重构应该是最难的，但是符合测试用例才是第一要求，结合的质量应该也在这个环节。工作量不好制定的一个原因是，TDD要求开发者不断测试最少实现代码，这就意味着TDD有可能是个死循环。当然流水线是死的，人是活的。但是仍然不建议人工干预太多，流水线的质量问题只能通过修改流水线来解决。刚开始，我猜想大概还是会先开发功能再开发测试用例。如果实在这样开发，建议不要把测试放到所有或者大部分功能完成之后再去完成，还是要一边开发功能一边测试。
还有一个问题是单纯为了迎合TDD而出现的性能问题，一开始肯定会有估算时间太少的人。最后为了完成不影响绩效，或者是正常开发的时候，会有一种测试成功就好的错觉。最大的体现可能就是编码的性能问题，当然每个方法在运行测试的时候都可以编写单元测试规定运行完方法的时间来规避这个问题，但是这个时间是多少还是需要经验的。所以建议在TDD开发过程中就不断进行代码质量检查，让质量检查和测试用例一起规范开发人员的代码。
实际上：并不适合所有的项目
我也想过这个问题，SCRUM适合需求不断变化持续交付的项目，TDD则适合长期做产品（沉淀下来的测试用例，对产品的重构与业务沉淀具有巨大的意义）。但是这两种需求并不是所有的项目需求，所以显而易见结合后的规则并不适合所有的项目。我就面临这样尴尬的位置，硬件接口这边的数据转接服务，短则三天交付，长则十几天交付，这个时候代码行数甚至都不超过千行，一个人完全能够认领。如果还是按照SCRUM或者TDD的方式就有点本末倒置了，最终的目的不是为了盈利么？这种情况下我觉得就不需要这些所谓的规则了，因为千行的源代码是完全可读的。开发者能在短期内完全理解自己写过的东西，这个就完全够用了。
总结：实事求是，开拓创新
两者结合，只要实事求是我想一定能够让项目步入正轨，提高当然就需要开拓创新啦~
PS. 我对敏捷的敌意当然还是不变的。