2018-09-02 总结

8.30演示那一天，还在做新功能开发，演示前几分钟，还在发版本，这种经历不想再体验了。

工作内容

• 8.30演示冲刺
• 演示场景验证
• 下周工作计划安排

反思

关于演示

之所以我们里程碑演示那么狼狈，是因为我们延期了，但又想再赶一赶，在最后一刻让演示看起来达到预期。

所以，演示那一天，还不能保证测试环境的稳定性，还在代码里添加新功能，甚至在演示前几分钟还要发布一个版本。

再去看代码，里面零散地写着TODO，写着”临时解决方案”，写着“为了8.30演示”; 而演示结束后，部分小伙伴松了一口气，下班的时候把电源也带了回去，想着明天好好休息一天——他们误以为8.30是星期五，“明天不用上班了”。

如此疲于奔命，如此焦头烂额，似乎一切都只是为了演示。感觉很忙，但其实做得却很少。演示完后，似乎精神都空虚了。

这不是训练有素的团队应有的样子。

关于延期

其实我认为，延期就延期了，承认就是了。接收现实，承担责任，仅此而已。导致项目延期的因素有很多，好好反思，下次做得更好，没问题的。

演示的时候，周老板也在。其实功能范围这么广，细节这么多，他一下子也看不过来，我看他在演示前半段一直是在打哈欠的; 演示内容这么多，再加上有他在场，客户们也并不会在界面上吹毛求疵。再者，BOSS真正关心的，是数据的完整性，用户购车流程的便捷性，还有就是使用MOBY商城后，如何与现有系统打通并维护，业务又如何开展，这些才是真实世界里需要考虑的事情。所以其实只要进度不是落后太多，在BOSS这个层面并不会太过追究的

再进一步，就算是明显落后了，反映到BOSS那里去，他也不会为难。因为真正难缠的是小鬼，BOSS要的是解决方案。毕竟他这个层面，当然明白，事情并不会是一帆风顺的，遇到问题，是很正常的事，想办法解决就是了。打个比喻，说好的五点的飞机，延误两个小时，你能怎么办？还不是乖乖地等。所以这就回到了开头：项目延期了，我接受这个事实，承担后果，总结反思，下次做得更好，不再犯同样的错误。毕竟软件交付，交付的并不止是软件，还有用户体验。而软件每一次迭代都比上一次要好，也是属于用户体验的一种。

所以，我认为我们应该稳扎稳打，而并不是看起来很拼命的样子，只是为了演示，导致整个团队都身心乏惫。我们是在跑马拉松，而不是短跑冲刺，长此以往，对我们是有害的。

我不想我们沦落为普通的外包团队。

延期原因

那么来分析一下导致项目延期的原因。除了外界不可控因素以外，导致我们延期的因素有以下几点：

1. 迭代周期过短。一周两个版本，根本不符合开发节奏
2. 计划做得空泛。为了应付外界因素，一次就做一个里程碑的计划，自己做得费劲，实际又不按照计划来，因为这期间肯定是有变化的，而因为计划里内容太多，调整起来也费劲，于是便懒得调整，一切放心中，导致计划丢失了原本的意义。
3. 团队成员并不清楚短期目标。这跟第2点是密切相关的。因为计划空泛，只是应付外界，自己根本没用起来，所以需要根据情况，每天每人分配1~2/人天的任务，而各个任务之间可能并没有太多的相关性，导致成员也是盲人摸象，如果做好了当前任务，并不知道下一步要做啥
4. 没有验证场景。我们是要演示的时候，才根据功能来规划演示场景，这完全是本末倒置的。应该是先想好演示场景，再去划分功能模块，开发出一个闭环功能。

关于改变

下一个里程碑，我们要稳扎稳打。正如多米哥所说，“慢就是快”，千万不要贪功冒进，我们要稳步前进。我们会做出以下改变：

1. 改变迭代周期：一周一次。
2. 改变排计划方式：先想好验证场景，划分好闭环功能，再与成员协商，分配短期任务。一次只排一个迭代的计划。
3. 先进的理论指导实践：敏捷开发。

首先，我们要找回属于我们的开发节奏。所以第一步，是把迭代周期变为一周一次。范围，时间，成本，质量，四个维度，唯有质量是不可妥协的。一定要有这种意识，与外界据理力争。拿出“如果这个谈不拢，那就得另请高明”的魄力。

再者，根据验证场景来划分功能，这样做出来的功能是闭环的，大家也清晰自己在做什么，更容易理清任务之间的逻辑关系，也方便自己去验证。

一次排一周的计划，一方面每个人能知道今天做完了，明天要做啥，就不需要我每天盯着进度，生怕有人阻塞，需要我来调度：他们可自行调度。另一方面，一周的工作量排起来没那么费劲，又能灵活调整，可以从容应对后面的变化。

脱离落后，解放生产力，需要先进的指导理论。现在我感觉是摸着石头过河，亟需一个引路人，一盏指明灯。我相信敏捷开发将是有力的理论武器。

“敏捷到底是什么，敏捷实践起来很难”，虽然多米哥这样说，但我明白，这只是外国理论本土化的时候，遇到一些困难挫折罢了。不改变，永远停滞不前; 还不如去实践尝试一波，毕竟还有突破的可能，也许就能走个通天大道。