一月份反思内容：BUG&Communicate

在公司写的1月份反思内容：

---

反思主题

指标系统未让客户满意

反思时间

2010-1-27  9:30:00

反思地点

办公室

---

现象/案例

1.BUG超出预期的范围：发布客户版本前，我们自己都感觉软件已经没有什么BUG了。但是一旦小红把软件交互给客户时，就会从小红那里获得许多的BUG反馈。而这些BUG，在当时正在和客户发版本的情况下，时间仓促，改起来感觉有点手忙脚乱，怎么忙也没办法忙完。
2.沟通并不十分有效：当小红到了广东开始实施软件时，我和她沟通时老是不断的重复一些已经讨论过的问题。显得不是十分有效。

---

反思内容

1.1.首先想到的，就是测试力度不够。未能保证在给客户发布版本之前把所有的问题都测试出来。不过这个问题也是跟现阶段部门的实际情况相关，毕竟暂时只有华明一个测试，而且是只有一半时间能够测试。
1.2.其次，为什么会出现那么多BUG呢？这个对于我们开发人员来说，就是一个十分值得反思的问题了。我想原因肯定有很多，如：开发代码的随意性；四个月过去了，我还是没有学透OEA框架；框架目前的易用性较低；没有进行Code Review？……等等。
1.3.软件过程是否需要加一些其它的内容呢，Code Review？Test Driven Development？

2.1.目前的沟通存在障碍，主要因为进行沟通的双方不能准确的定位对方所说的概念，以及双方使用不统一的词汇。所以，我觉得，要达到尽快减少沟通障碍的方法，应该是建立一个螺旋、增量式的“词汇规范”。
2.2.讨论重复的问题，是因为这个问题在讨论结束后，并没有被记录下来。很可能是因为双方都觉得没有必要对这个问题进行记录，例如：在我们出现的问题中：小红有可能在想，这个问题是技术的范围，所以我只要在遇到问题的时候询问技术人员就行了；而我在想，这个问题很简单嘛，说了一次，她应该就明白了。

---

改进方案

1.1.在没办法添加测试人员的情况下，我们应该在客户版本发布前，尽早地停止新功能的添加，预留时间测试及修改BUG。如：20号交版本，应该保证16-18号一定要出比较稳定的版本，然后可以在剩下的时间再继续测试、修正，以达到更稳定的版本。
1.2.在二月份内，我会搜集网上著名的编码规范，整合成我们所使用的。可能分为两套：一套《框架开发编码规范》、一套《应用开发编码规范》。
1.3.组内非正式的讨论如何提升代码质量。

2.1.我会把沟通中遇到的出现有歧义的概念一一记录下来。
2.2.我会把所有遇到的有可能会再次遇到的问题，都简要的记录下来。以备再次出现时，只需要Ctrl+C Ctrl+V就可以了。

---

检视时间

2月份

检视结果

……