iColin 

经过项目组近一个月的奋斗，英国站于4月28日正式发布上线，感谢项目组每一个辛勤付出的同学, ^-^ 照旧对项目做个小结：

值得发扬的：
每个人只是做了每个人该做的事情，这是Basic，而且还有很多不够的。

做得不够的：

1. 设计评审，TC评审不充分。很多问题表象是沟通不充分，实际上则是评审时评估得不够充分，导致后续需求变更频繁。先想好再做，可能是前期策划的时间比例投入得太少了点。

2. UC文档，这个东西是开发和测试的依据，也是项目质量的基本保证（UC文档的质量得不到保证，项目发布后才发现UC上的文案是错误的）另外项目期间所有需求变更必须体现在UC上

3. 沟通，沟通的主动性和技巧，需求方需要主动和开发方沟通，并能准确传达期望值，最好是定期review以保证质量；沟通技巧，每个人都有自己的做事风格，选择合适的沟通方式

4. 统一需求接口，对于多需求方的项目，务必使得需求用同一个声音说出

5. 发布前期，需求方和设计师协同测试，有问题早发现早解决

值得注意的问题：

copy不简单是一个copywriter，特别是我们在做国际化站点的时候，更应该让他们早期参与到项目之中来，这样才能设计出符合他们阅读习惯和审美的页面

这次项目尝试使用敏捷开发模式，整个流程耗费大约3周时间

从项目过程来看，貌似省去了很多的细节来达到了”敏捷”，细细回想，敏捷开发模式目前并不一定适合开发人员

回顾下采用敏捷开发在项目中暴露的问题：

1. 很多必要的沟通以及详细合理的文档需求被省略了，导致团队成员之间的信息不对称

2. 由于前期的沟通不充分或者考虑欠周全，频繁变更需求（代码质量和项目进度都会受到影响）

3. 需求分析不够，导致资源不到位

敏捷开发，让产品快速迭代，是个不错的想法，要采用敏捷开发，团队的综合实力都要提升一个台阶才行，PD要有足够的经验，保证在前期精准把握核心需求，要有足够的影响力和执行力，关键时刻能拉的住资源为项目服务；开发人员也要有更强的实力来敏捷评估和开发；敏捷开发就是全闭关，不要老是被项目之外的事情所骚扰