夏天里的敏捷：10月底总结会议笔记【问题笔记】

    今天开总结会议了，笑的我都累了，最后记得sp最后说了句，我们大家之间的默契越来越好了，开会时候，

老大老是重复一句话“我认为你们都是成年人了，我举反例子，你们可别放在心上呀......”，然后大家挨着说了

很多问题，我暂时记录下：

1.乱

     SP直接说了一个字，就是“乱”，原因很简单。过节回来，老大感觉生产力下降了，直接开启下个迭代，

上次那个迭代根本没上线，并且这个需求变数很大，然后经过一个星期之后，一起上线问题困扰了我们，

虽然最后争取到一起上线，但是很多细节，我们都忘的差不多了。所以感觉很吃力。

总结：已经开发出来的东西要尽可能早的交付。

     第二个教训就是我们没拆版本，如果真的上次拆分产品线不上线的话，我们就面临着“抽版本”的问题，

那就感觉自己在抽自己耳光，其实之前我们一直在不同分支上开发，但是经常性合版本，造成很大浪费，

所以后来直接在主分支上开发，但是现在是10月份，需求变数很大，很多需求做了不是直接上线，而是领

导们审批是否上线，所以决定版本控制的从新考虑进去。

总结：最后决定把做这个需求对系统来说变动比较大的可以抽出来，还有是急得可以抽出来，慢的也可

以抽出来，可以单独一个版本开发

2.PD维护。

我们的PD一直有大家一起共同维护，但是有的需求涉及到同一个表，比如上线记录里面一个表被修改2次，

张三跟李四同时修改了一个表，这个时候很可能出现问题。为了解决这个问题我们直接找了个人来整理PD,

有人需要添加数据库字段，必须先找这个维护PD的人进行维护。

总结：PD要一个人去维护

3.“燃尽图一直在基线上面，没下来过”

新加到迭代里的人每天都消耗0工作量。这个迭代里面新加进去2个成员，大家都知道，添加新的成员意味着

这个团队的生产力只能降低，但是郁闷的是那家伙4天的工作量都是0，你说气人不气人呀。“你4天都是0，

你还怪人家说你呀”。其实我认为这个人可以加上来，但是他的日工作量就按1-2算会比较好。问题是我提出

来的，但是没办法，总的有人说吧，对事不对人。

总结：其实我认为这个人可以加上来，但是他的日工作量就按1-2算会比较好。

4.需求估的不准

这个主要是一个特别复杂的需求，光了解原来的功能就废很多时间。

总结：最后给的预留时间可以消耗掉

5.细节没去想

一个字段页面输入长度应该跟数据库保持一致

数据库视图里面绝对不允许用“select *”，因为你加字段的时候，这个表结构在动态的变化，这个*，随时都可

能成为你系统的地雷

ConverTo是坚决不让用的

查询语句select *是坚决反对的

取数据的时候要根据名称，而不是直接根据索引 同样道理数据库表结构别想变化，一变化就等于给自己装炸弹

总结：这些问题，交叉测试时间增加一倍，来解决这些问题。

6.zl被打断的次数越来越多

        我隔壁的帅哥zl，经常性的被打断，这次迭代的时候老是加班，当老大说这些时候的我就在

想：他不被打断才怪呢。新加进迭代的这个小窦跟他结对开发，这本身就拖延了他所做的那块的

速度；再加上新加进来的一个员工，对我们的ECP来说几乎是张白纸，就做在他旁边，几乎是随

时就可以打断他，在加上我，还有sp，还有偶尔打过来的电话，还有老大随时都打断，我一直在

想，他要能安生，那恐怕只有告病在家吧。一想到zl忙东忙西的现象我就想笑，压力这么大，还

老是接那么多的活，看来他压力真是不小呀！！但是如何才可能拒绝打断呢？对于他，我虽然天

天坐在他旁边，但是仍然没想到怎样才可以拒绝打断。老大最后说尽可能的减少他的工作，大家

打断他之前必须先问先自己过脑子，比如看代码，尽可能自己去找，找不到在去问zl。

7.交叉测试的if

看到IF我就烦，后来发现这样比较有经验的程序员看到IF就会兴奋，然后会问你为什么这么写？你

那样判断不可以吗？这样写有可能出现什么问题？比如一个string字段是否为空的验证，他会问你

数据库是NULL还是空，if（st!=""&&st!=null）

总结：努力提高自己的代码质量，代码重构还是的翻的，挣取下次看到if的时候也兴奋一把

7.换位思考

     让我等公交的时候都在笑的是我们公司那个女孩，她负责处理销售提过来的一些BUG，但是销售的

态度很不给力，她很不喜欢，甚至抱怨，她学着说XX的话（让我感觉很好玩），说系统不好用，老大

极力说让她忍，而她就感觉自己很受委屈。其实这个问题我曾经也遇到过，幸好那女孩脾气比较好，

要不早就骂起来来了。这个问题任何一个企业都不应该去回避的，其实我认为越回避问题也就越严重。

你越是说让自己手下忍，结果只能有一个现象，只是崩溃。甚至在开会的时候我也听到别的组在提倡

“禁止抱怨”其实我还是不喜欢禁止这2个字，这也许就是很多人离开这里的原因吧。也许这样事情作为

管理也只有这么办了。这些问题任何团队里是经常出现的问题，其实只要我们用户交互做好了,BUG少了，

人家自然就不会抱怨了。

    “这个世界上最大的噪音我想应该是抱怨的声音吧，所以我时刻提醒自己不要给浮躁的世界再添一份

浮躁，也不要给迷乱的观念更加一份迷乱，做一个逆风的飞翔的风筝，我要飞得更高！”

    一个团队里面最主要的是包容吧，就像我们在谈论的时候ZWZ说“你的OPEN”，一个团队如果这些都做

不来，趁早还是散伙吧！！！！

总结：站在用户的角度去想问题，学会去包容别人

    关于换位思考，还有一点是：我们现在的很多地方很不人性话，程序员几乎是按照程序员思考方式进行

写的，所以我们应该尽可能的站在客户角度去想系统。

总结：在交叉测试的时候，这个问题的暴露出来，尽可能的让终端用户参与进来

 ------------------------后记---------------------------------------------------------

      以前开站立会议的时候大家都是绷着脸，今天我小窦在SP讲话中莫名的笑了下，等到他同步自己

问题的时候，说自己刚好遇到刚才SP的问题，幸好SP提醒。我准备离开办公室的时候，小窦还在跟我

开玩笑，还有zwz,我自己感觉自己很开心，以前下班之后，大家都闷闷的走了，连招呼都不打，我其

实更希望这样的办公环境。好了就写这些吧，明天还的有计划会议呢，估计的开一天会，现在赶紧补

觉去了。