得益于从二月末开始独立带项目，决心引入自己修炼了很久的神功“敏捷开发”。好在团队成员配合，领导不反对，执行的还算顺利，转眼间三个迭代已经过去，着这里总结一下。
第一个迭代周期
第一个周期的主要任务是把原来的代码向c++移植，并且完成重构。在第一周中我没能直接参与到任务开发当中，采用了每天早上跟大家讨论布置任务，让大家完成的方式进行，任务进行的出奇的顺利，大家都有条不紊的完成了任务。
这时候还没有跟大家讲敏捷开发，基本还是采用了布置任务的形式，我在这是强调了一些知识扩散的基础，让大家尽量尝试结对编程，限于工位比较窄小，结对编程并没有被全面落实，不过大家每段代码都给大家讨论了一下，虽然效并行率，但积极性却提高了。
第二个迭代周期
第二个周期一开始，我跟大家讲了一下敏捷开发的基本思想，我并没有全盘脱出所有的实践。我强调了一下几条。
1. 固定时间的迭代周期（一周）。
2. 任务的时长是2-16个小时。
3. 用任务看板来展示迭代任务。
4. 每个人写代码给至少两个人review。
5. 每天早上九点召开站立会议。
6. 每周一、二、三、四下午五点又一个人给大家分享一些课程。
马马虎虎的第二个迭代就这样有模有样的开始了，大家积极性较高，有些到了下班时间没完成的都会用晚上的时间看一看，争取改出来。这一周大家很有成果，我也直接参与到了开发当中，不过我意识到了一些问题，我这个段对基础有些差。我要面对一个几乎零基础的团队训练，我们团队六个人当中，四个人不具备独立开发的水平。此时我考虑一些问题：
1. 如何训练这些基础薄弱的同学？ 让他们既感到有成就感，又能快速吸收知识。
2. 我遇到一些需求难以被划分的任务，比如说，我需要重构一部分相当恶心的代码，我不确定自己要花多久去做这件事情，如何做也要等我充分理解代码以后才知道。而且重构这种事情一般都是随手做的。
3. 有些技术方案不确定的用户故事，我不知道这个需要多大的成本（时间）。难以估计，一开始的两个迭代式因为我自己心里有数，才清楚的。
第三个迭代周期
经过了前面遇到的问题，我请教了一些敏捷“高人”，他们告诉我，我漏掉了一个“0迭代”，我应该在第一次迭代中准备一些故事，调研好实现方案，在接下来的几次迭代中使用，等推进了几个迭代后面的实现都可以在这几次迭代中慢慢估算出来。
于是我决定，在第三个迭代中去做一些调研工作，关于如何实现这些问题进行一下调研，我决定使用一次“小迭代”，只有三天，大家对任务完成的还是很不错的。
下面是一些经验，不知道对错：
1. 应该有第一个“0迭代”。
2. 需要再每次迭代中调研一下下次迭代会实现的用户故事的一些技术方案。
3. 针对基础薄弱的同学我采取了，施压加鼓励的措施，一方面让他们看到差距，另一方面让他们感受到自己的进步。具体方法就是同过讲清楚实现方案，让他们去实现编码。他们完成速度不会很理想，但进步效果还不错。
三次迭代转眼就过去了，我们的进度还算理想，似乎敏捷完全没有那么容易，测试驱动开发我还没能引入，结对编程似乎还差一些，当本着一个敏捷团队的思想，只要每次迭代我好一点点，那就够了，最终我们会成为一个强大的团队！！！