标签：
最近两周一直在加班加点refactor代码，贡献了2014年最后一个周末和2015年元旦三天假期，终于赶在了sprint结束之前完成。
可见，这个sprint做的并不理想！
项目逻辑本身并不复杂，从数据库取数据，进行相关分析计算，然后在前端以图表的形式呈现结果。用的是Django框架，前端图形采用jqplot实现。
项目有三个平行的模块，各模块都要实现数据呈现，报表导出，图片下载功能，但各模块之间互不相关，额外的要求是三个模块都要有很强的可扩展性，以便以后增加新的查询选项，能快速实现。
三个人分别负责一个模块，而且在plan meeting的时候，确保了每个人都了解自己模块的功能需求。
大家都开始了自己模块的设计与实现，第一个星期：基础架构和核心代码实现，第二个星期：前端数据呈现和下载图表实现，第三个星期：互相测试和code review，第三个星期三开始：推倒，重构。。。
就是这么的无奈，在功能都实现了的前提下，又几乎重新编写了后端代码和重新修改前端template。
问题出在了unified思想上：
三个人分别在三个层次实现了unified：template数据呈现一致性，View层数据处理一致性，modle层参数化查询数据库一致性。
每一个模块都为了自己的unified实现做了相应的代码架构，别的模块想复用其代码很麻烦，甚至到了后期，因为命名不一致，连js代码都没法重用，只能眼睁睁的看着非常好的实现无法移植到自己模块中，从而，没法能够做到整个项目的unified。甚至，以后维护代码反而增加了复杂度，如果三个模块添加同样的查询条件，反而要分别进行三套不同的实现，而且因为不同的template元素id，同样的逻辑要写好几个功能相同的js方法。
为什么出现如此结果：
团队成员分布在不同的城市，没有及时沟通机制，交流不畅肯定是造成问题的一个原因。
在项目plan的时候对如何实现并不是很清楚，也没有人发表意见和建议，进行深入的讨论，导致摸着石头过河，每个人都按照自己的想法摸索，以完成功能为主，并未重复考虑，特别是整体考虑项目的架构和可扩展性。
三个人当中有一个比较熟悉项目逻辑，可是没有能够站出来主动负责承担公共代码实现，比如统一呈现数据的前端实现，相应的js验证代码，从而导致前端实现五花八门，甚至没有统一的命名规范。
总之，问题很多，没有及时有效的交流，没有做到充分的思考，没有搭好框架，没有公共处理模块的统一控制。。。
不是敏捷团队，但是按照敏捷的模式去推进，可是没有sm，没有daily stand up meeting等机制保障，只是靠着user story，靠着task去跟进项目，只会导致代码实现杂乱无章，大家只focus在自己的user story上，缺乏体眼光，只快速完成task，没有考虑集成。最终导致了代码的大量重构和返工，同时也增加了软件的熵。
标签：
原文地址：http://www.cnblogs.com/zhq1007/p/4202555.html
