采用敏捷开发感觉时间总是过的很快，三个星期一转眼又过去了，日历从2012转到了2013，我们的项目在新的一轮迭代之后，也变的更加丰富多彩。
之所以用“丰富多彩”这个词完全是为了体现在这个sprint中我们出来了IOS版本：背后的各种磕磕绊绊。IOS上依赖的一些lib文件是另一个城市的site维护的，很不幸拥抱变化的scrum模式遇上了跨site的交流不畅，具体过程实在是不想回顾了，总之这个sprint结束那天，我从电话里分明听出了另一个site的女程序员略带火气的建议：“有什么改变要让我们及时知道”。可问题是我们这边变了又变，到了demo展示前一天晚上才定下来workflow，再及时告知也晚了。我认为这种现象勉强算是敏捷开发的弊端吧，交流成本过高的体现。不可能避免跨site的交流，也就是很难做到大家随时的交流，这种情况下，没有严谨的完善的设计的缺陷就体现出来了，大家都喊着事先定好接口，划分清楚责任，可是真正实施起来，做着做着以前定好的东西就变了，而且大多改变是在两三个人的临时讨论之下完成的，讨论达成一致，回去改改代码完事，没有记录，没有总结，看起来简洁灵活，可是许多这样定下来的东西，过不两天，又会提出修改，甚至几天以后都不知道为什么要这么设计了，改了它更无所谓，相当令人郁闷的现象。或许每次讨论需要强制做些会议记录，可这并不是解决问题的根本办法，我从来不认为设计是可以轻率的定下来的，传统的开发模式的优势就是做好充分的设计，这一点在敏捷开发模式下略显薄弱，我想相对近期的设计还是要做的，比如一个完整sprint的设计要先做掉，而且要详细做，做完要出正式的不可轻易变更的文档。
当然了，并不是只有问题，也有不少的收获。出来了具体的架构，至少现在看是没有问题的，结合第一个component也证实了这种模式的适用性；各种平台下的编译也进入了正常轨道；unit test 也带来了积极的作用，大家更热情的进行ut；跨平台的第三方动用库也通过修改适用了起来。总之，这个feature算是把整个项目的底子打正了吧，其中也存遗留了一些问题需要解决，不过应该不会造成太大的block了。
明天又是新的一个sprint , 坚持最后三个周，迎接春节假期~