0
Posted on Saturday, June 29, 2013 by 醉·醉·鱼 and labeled under
一个缺少需求分析师的团队,只靠只言片语的accept criteria。这样的团队,在和客户的交流上,就存在了障碍。需求分析师,在这里,将是失败的开始。

经历过一次开发,是个痛苦的经历。当初在plan会议上面,大家打算把一个功能移掉,又打算在其他地方把这个功能加上去。一切没有比较靠谱的文档,连客户的要求都没有一丁点信息,就开始做了。好吧,做了,到现在我都不知道客户是否满意这样的东西。
0
Posted on Saturday, June 29, 2013 by 醉·醉·鱼 and labeled under
偏执的我,觉得两个都好,但是现在的我,还是偏向于后者。

我很难理解这里所谓的破窗户,对于我来说,现在的系统是bug太多,我完全不知道哪个会是所谓的破窗户。也可能,现在的软件就是在腐烂。在时间和上面的压力下,我还是觉得,权衡出所谓的"足够好的软件"是可行的。交付给客户可以用的软件,也是好的。就算苹果手机,自己也是有bug的,只是,不会影响到它无法正常使用。

不知道乔布斯会不会劈死我,那个要等我下次读完乔布斯的书再说了。
0
Posted on Saturday, June 29, 2013 by 醉·醉·鱼 and labeled under
自己修bug引起的其他bug,最后没有被QA发现而成功逃离到了Production,最后由于bug的严重性,而需要的一个hotfix。

最后,问题还是出来了。正如当初自己提交的时候的那种忐忑不安,也像高中数学考试里面那种盲目自信到最后还是不能够拿到满分的感觉。自己在处理其他问题的时候,发现了一个bug。在和BA确认之后,我改了,提交了,测试了,上了Production。上去后的一周,客户报回来了问题,结果发现是自己的问题。再次提交fix,并且写邮件给各位老大说明这一问题,定夺是否需要hotfix。最后,还是hotfix了。自己自嘲道:"我也有今天啊!"

周末闲在家里看《程序员修炼之道》,第一节就提到,需要对自己和自己的行为负责。突然,心里微微触动,打算写点东西给自己:
  1. 不要给自己找借口。我试图找过结果,比如,跑去QA那边晃悠晃悠,打算劈当时测这个的QA,为毛你漏掉这个bug了。结果还好自己没有那么狠心劈下去,因为,那实际上是自己的错。
  2. 而是提供选择。还好的是,自己还是有那么一点直觉"既然问题这样了,我能够做什么?" 提交了fix,自己再测试一把,保证那些数据都修好了。然后发邮件给老大们,让他们定夺这个fix要怎么弄,需不需要hotfix。
  3. 不要相信QA。正如QA的至理名言:"永远不要开发!" 现在这样的环境下,自己也不能够相信QA了。存储过程的改动比较方便测试,拿到Production上面一测就好了。心里悠悠道:"没有时间是硬伤!"

PS: 最近要招人了,希望招到一个老老实实做事的人,人品没有问题的人。