目标

没有目标就是在浪费生命。
大志者得中，中志者得小，小志者不得。
对于软件开发，有钱就可以找人做一个勉强可用的软件，这算是起码的目标。如果再高一点，要做出品质良好的软件；那么除了钱，还要有能力（或者说钱要到位，钱到位了能力也就有了）。但优秀的软件，绝对不仅是钱的问题，也不仅是能力的问题，而是态度的问题。所以，我觉得：好的目标既能像愿景一样触动人的激情，同时又不像愿景那么空，要清晰，确定。对于这次重构任务，目标的清晰确定基本达到了，但没能激发大家的内驱力和主动性。

计划

有人说计划无用，因为计划永远赶不上变化。
而事实上，计划就是用来改变/调整的。不断地减少目标与现实的差距就是计划的意义。所以，计划要有步骤，要有细节，有时间点。没有持续（调整）的计划，完成目标纯粹是幻想。
作为目标按时间点的切片，计划一方面不应该容易达成，太容易则会导致懈怠；另一方面也不应该太难完成，太难则会影响士气。另外，要控制风险。墨菲定律说了，问题总比我们想象的复杂。重构过程中很多细节都没有考虑到，后续肯定还有更多预料不到的复杂问题。

反馈

行百里者半九十。
有了计划并不能确保能一步步逼近目标，走向成功。我们还需要及时的、持续的反馈。
首先，每一步计划是否完成，需要明确的验证。我们觉得完成了和真正完成了，是有很大差距的。重构中各模块接口之间打通，我调了一周还多的时间，本来预计最多一天即可完成。
然后，人是需要正向反馈的。确定且正确的验证结果，给我们带来的愉悦以及持续下去的动力，是金钱等无法达到的。
最后，负面的反馈更是对我们的提醒和监督；促使我们及时调整工作方法，调整计划不会偏离目标的方向。目前重构的验证不够及时，是最需要改进的地方。

团队

计划的执行者首先是团队这么一个整体，其次才是每一个人。
启动会这个充满仪式感的重要环节，也是团队真正组建完成的时刻。参与启动会，表明愿意进入团队。启动会上目标的确认，也是又一次明确任务，达成共识。然后，团队一起制定计划，并一起执行计划。
理想情况：我们把Requirement拆分成多个Feature，作为一个特性团队，应该所有人力投入到当前优先级最高的一个Feature；每个人认领一个可独立测试的自上而下纵切的用户故事。
实际情况：按功能模块划分了人力，虽然有交叉和结对，但个人进度无法与团队进度一致。而且，对于纵切用户故事，一个人或两人结对来完成的做法，并不是所有人都认同。目前用户故事还是按功能模块来横切，集成联调任务需要更有主动性的人来承担。

环境

无论是内部还是外部环境对团队的影响都不可忽视，需要理性对待。
每一个团队都有自己特有的氛围，我觉得重构小组是一个学习型的团队。
首先，每个人都能得到尊重；然后，彼此之间乐于分享。
在完成任务的同时，每个人都得到成长，是我们最乐意看到的。对于外部环境，或对团队有助力，或对团队有阻力；助力可遇不可求，阻力要看风险应对。对于风险计划外的事件，我们不能完全丧失主动性，在厘清现状的基础上，眼光向前看，尽我们的努力向目标前进。