Archive For 九月, 2010
发现客户有时候会自己骗自己。 最开始，客户主管会计说她需要需要一个财务轧帐功能，需要按月查看应收应付、实收实付、预收预付情况。我们就按照各需求给客户做了轧帐功能。 做完之后给客户现场演示，他们也认同了这个功能，觉得是他们想要的功能。演示完后的第二天这客户的主管会计电话过来沟通。说需要按照不同的业务类型来做轧帐。当时我正在做一些其他功能的设计，只是简单的记录下她的要求。 今天她再次电话联系我，说给我发了个邮件有一个她期望的界面。我当时心想真是个好客户，都直接把UI 给我设计好了。后来一看还真是有那么几分样子，Excel里列举出了他们所有要求。 后来一细看原来他们的要求是前后矛盾的，就预收预付这一块，一开始客户是要求按照她什么时候录入系统来做完实际业务预收预付的时间。可当她自己开始解释自己设计的Excel表的时候发现原来她们还需要一个转凭证的功能，并且按照凭证时间来做轧帐。 这个过程本身很有意思，也让我开始慢慢开始尝到Scrum的甜头。我很庆幸我没有马上去动手设计某些具体的UI或者DB，没有一开始的就埋头很细节的东西，而是等到另外的时间来做一个讨论，而且这个讨论时客户发起的。 觉得这个事儿跟某些大家常说的“生气时不做决定、高兴时不做承诺”很像，不在兴头上胡乱做决策。因为这时候往往会不自觉地屏蔽掉很多的其他信息朝一个死胡同去走。
最近几周一直在试图提高开发效率，让团队能敏捷起来。 首先是试着将一些很大的Story切割，切割成相对较少的、有商业价值的故事。为了这个Boss还采购了很多书，业界比较响亮的《用户故事与敏捷方法》也被买回来了，可惜我自认为没到那个境界，翻译版的读起来特别别扭，看不下去了。找了些其他的资料，参考着小范围内的重写了一些story。 然后根据上几个Sprint的观察，发现沟通是很很多不畅，大家的理解不一致，又开始加强在沟通环节的投入。但实际上效果都不好。 而今天的一次重构，好像让我发现了问题的根源–我们开发本身不够敏捷。现下已经完成的代码里，任何一个修改，都会带来不可预知的灾难。因为我们根本没法在每次交付的时候保证自己完成的东西是否已经满足既定的需求，更别提按照敏捷的思路来进行迭代了。 敏捷本身是要去快速交付，快速完成可以工作的软件。起码交付出来的东西必须可以工作才对。无论如何去剔除故事，捡业务里面相对简单重要的故事来做，需要满足客户的需求这个终极需求不会改变。如果每个故事或者开发的task本身交付出来就无法保证正确性，又何来在其上的调整完善呢。 或许敏捷在task级别或者编码级别对开发者的要求要比瀑布的高，还是我们的team压根就还没上路？