从接触scrum到现在已经快一年了。
在这一年里，组内一直使用scrum的流程进行开发管理，虽说有些山寨，但看上去还是像那么回事的：blog分解、计划分解、立会、发布、回顾，该有的都有了，自己对于敏捷也从开始的新鲜到了现在的。。怎么说呢，不那么新鲜了。。。。
这次的产品是一个升级版，功能比较单一，但由于原来的代码主要来自于项目，1.代码质量不是很好 2.各个项目的功能也不太一致
这次升级的两个目的：
1.提高代码质量、优化架构
2.把已经在用的几个项目的需求抽炼出来，固化到产品中。
由于发版日期提前，我所在的小组全部都过去支援，我们去的时候，开发已经进行了3周。正好第一次迭代结束。
到昨天，第二次迭代也结束了。
在这中间发现了一些问题，权且记录在此，以后可以有个参考。
1.由于时间紧，任务多，并且大部分功能在项目上已经用了很长时间，所以我们去的时候看到的情况是：大部分的业务代码都是直接从项目拷贝的，改动很少；这样代码质量基本没有提升。
2.拿这次发布来说，昨天加班不说，加班的时候一个白天基本就在搭环境上了，而且自测到了晚上9点才完成，而环境更是到了11点才正式搭好---而且还不完全好使。
3.立会时间太长，原因主要是人多 --13人，而划分小组也比较困难，另外一个原因就是有时会纠缠到细节上面，浪费了时间。
4.对代码质量的意识不高，由于团队成员普遍比较年轻，设计、编码经验尚有欠缺，再有就是不重视重构。
对于以上的问题，自己目前想到的解决方案（有待进一步验证）：
1.加强人员能力培养，其实每天花不了多少时间就重构的很好
2.加强自测意识、使用自动部署工具，简化部署，每天早上立会说完成某个功能的时候，必须在部署后的环境而是不本地开发环境测试完成；加强交付标准的制定--培养意识。
3.这个目前还没想到办法，我的想法是根据业务类型分为两组，并且要求每个人在表达问题的时候，清楚、简介。
4.能力培养；关于重构的问题，是个普遍现象了，原因主要有两点：一是不重视或者懒 二是害怕改出问题。对于一，只能加强大家的意识了，让大家重视起来；对于二，还得靠自动化测试来保证改动后的正确性。
写完这些后，发现目前遇到的问题主要是两个：
1.人员能力/意识问题
2.自动化工具（部署/测试/代码检查等等）
我在想，这两个是不是阻碍我们敏捷起来的原因呢？我们的山寨敏捷是否就山寨在这了呢？
对策也比较容易了：
1.人员能力培养，这个话题可太大了，目前是采用项目+导师的机制。。。
2.找工具，不行就写一些辅助工具，不能全自动还不能半自动么。。。
我不知道自己想的这些时候跑偏了，只能摸索着前进了。。。
就拿这两点当做一个突破点吧。