Archive For The “软件开发” Category
带了小一年的项目，期间设计、团队、文化眉毛胡子一把抓各方面都有些感触。古人有云：学而时习之，不亦乐乎。先来个设计部分的总结吧。以下的一些观点也是源自此次项目，积累较少也只能一叶障目了。 1 业务架构设计 由于这个项目于公司和我个人都是全新的，而且公司的骨子里含着咨询的基因，所以在项目过程中免不了要给客户调整、优化工作流程。也就有了我想要说的业务架构的设计。 这里要说的业务架构不是一个大而化之的业务，而是指的需要在系统中实现的业务部分以及系统将如何配合其他非系统中实现的环节来为客户提供价值。 1.1合理切分业务模块 说到这个系统内外环节的衔接，就不得不提业务模块的切分。业务模块的切分对于一个具有一定规模的企业而言，往往是一个无法言语的病痛。 如果各个部门之间如果完全没有业务上前后关系还好说，但我想哪个企业都很难切的那么清晰吧。举个例子谁家都有个财务部吧，财务不直面业务数据，但是老总往往又比较关注银子，保不齐会要求财务的来点统计报表吧。企业打算上系统，当然的希望系统把这部分工作完成了，就出来了传说中的中国式的报表。这本来还不算什么，可是财务在不是那么了解业务的前提下，会把这个报表的数据源头压到业务部门去，这么一来二去，离杯具也就不远了。 这个时候需要的是对业务的整合，梳理客户的业务，划分业务模块，将原来穿插在各个职能部门的业务按照实际的业务流向（汇报线往往是一个不错的选择）从新组织，也就是常说的柔性组织，理出来这个组织之后才能开始就各个业务模块来做细的流程梳理。
发现客户有时候会自己骗自己。 最开始，客户主管会计说她需要需要一个财务轧帐功能，需要按月查看应收应付、实收实付、预收预付情况。我们就按照各需求给客户做了轧帐功能。 做完之后给客户现场演示，他们也认同了这个功能，觉得是他们想要的功能。演示完后的第二天这客户的主管会计电话过来沟通。说需要按照不同的业务类型来做轧帐。当时我正在做一些其他功能的设计，只是简单的记录下她的要求。 今天她再次电话联系我，说给我发了个邮件有一个她期望的界面。我当时心想真是个好客户，都直接把UI 给我设计好了。后来一看还真是有那么几分样子，Excel里列举出了他们所有要求。 后来一细看原来他们的要求是前后矛盾的，就预收预付这一块，一开始客户是要求按照她什么时候录入系统来做完实际业务预收预付的时间。可当她自己开始解释自己设计的Excel表的时候发现原来她们还需要一个转凭证的功能，并且按照凭证时间来做轧帐。 这个过程本身很有意思，也让我开始慢慢开始尝到Scrum的甜头。我很庆幸我没有马上去动手设计某些具体的UI或者DB，没有一开始的就埋头很细节的东西，而是等到另外的时间来做一个讨论，而且这个讨论时客户发起的。 觉得这个事儿跟某些大家常说的“生气时不做决定、高兴时不做承诺”很像，不在兴头上胡乱做决策。因为这时候往往会不自觉地屏蔽掉很多的其他信息朝一个死胡同去走。
最近几周一直在试图提高开发效率，让团队能敏捷起来。 首先是试着将一些很大的Story切割，切割成相对较少的、有商业价值的故事。为了这个Boss还采购了很多书，业界比较响亮的《用户故事与敏捷方法》也被买回来了，可惜我自认为没到那个境界，翻译版的读起来特别别扭，看不下去了。找了些其他的资料，参考着小范围内的重写了一些story。 然后根据上几个Sprint的观察，发现沟通是很很多不畅，大家的理解不一致，又开始加强在沟通环节的投入。但实际上效果都不好。 而今天的一次重构，好像让我发现了问题的根源–我们开发本身不够敏捷。现下已经完成的代码里，任何一个修改，都会带来不可预知的灾难。因为我们根本没法在每次交付的时候保证自己完成的东西是否已经满足既定的需求，更别提按照敏捷的思路来进行迭代了。 敏捷本身是要去快速交付，快速完成可以工作的软件。起码交付出来的东西必须可以工作才对。无论如何去剔除故事，捡业务里面相对简单重要的故事来做，需要满足客户的需求这个终极需求不会改变。如果每个故事或者开发的task本身交付出来就无法保证正确性，又何来在其上的调整完善呢。 或许敏捷在task级别或者编码级别对开发者的要求要比瀑布的高，还是我们的team压根就还没上路？
以下内容整理自一封我发出来的内部交流邮件，略去一些内部信息 最近对项目进展缓慢我个人觉得有两个原因。 1、 开发组的技术能力 可能还真的没达到可以实施敏捷的水平，或者是没能达到很好的发挥敏捷益处的水平。 2、 咱们目前三个组的配合上和衔接上也有一些不协调的地方。 目前对于第一点，我觉得暂时没啥好的解决方案，只能不断的提高大家的技能水平。 但是对于第二点我倒是有些想法。就是对原来我们做的那个领完任务然后开始给设计讲解对需求或者设计的理解来扩充一下。 我觉得要强迫大家多思考，然后再开始做，思考的过程中需要包括对风险的评估、对自己业务范围内编码设计的评估，那怎么来强迫呢，最简单的就是将给别人听，给别人讲明白了。本来我们就需要大家都来理解业务，来挑战设计，以便以后能将设计降到每个小team里。 因为每个sprint都需要来分组，我就想在原来讲个我听的过程稍微扩充一下，讲的过程中带上一些实现的思路，让另外一个组也听听。这样至少两个组都能了解业务，对他自己遇到同样或者类似的场景，可能借鉴或者参考对方组的思考方式。但是昨天跟@P讨论时候又有一些新的想法。就是在两个组互讲的基础上，再往外扩张下。将测试和框架拉进来。