从需求入手开发流程

       最近开发了两条流程，一条是对客户已经在使用的流程进行平台转移，一条是在已交付的应用中增添一条固定流程。这两条可以说都需要从头开发，而由于其状态不同在项目开发中也很值得介绍下开发过程。

       需要转移平台的流程是问题处理流程。之所以要转移平台是因为之前运行的应用客户准备放弃使用，再者客户需要将信息化进行整合，将不同应用下具有业务连贯性的流程整合到正在开发应用中来，其中问题处理流程便是这种有着业务连贯性的流程。

       待开发的固定流程，之所以称之为固定流程，是因为它是已有流程的一个特例，其中流程结点参与人是事先固定的（虽然可以修改，但变动频率相对较低）。之所以要重新开发这条固定流程而不是在已存在的流程进行代码级的参与人指定，原因是那条通用流程经过客户一段时间的使用也在做二期的升级处理，它已不完全适用固定流程。

       问题处理流程所在项目由于是自己一直经手的项目，其架构和开发模式较为熟悉，需要改变的是将原先架构中仅考虑到一条流程的处理（如待办任务、任务历史等等）改为考虑多条流程的处理。而真正需要耗费些时间的是需求的梳理上。

       虽然问题流程客户已经在使用了，但查看其留下的文档仅有一个功能的简单描述和工作量的简短评估，至于每个结点每种数据关系及其来源和去向都没有任何描述。面对此种情况首先要做的是能入手。

       接手一个任务不能入手则没办法进展下去，在此指导下前两天没有做代码级的动作，而是不断的运行之前那版的应用，然后对比流程设计，逐步熟悉每个结点的具体要求，从数据来源和去向直至细微到每个字段的样式和可读写性等等。在此期间逐渐形成一个可以指导开发的文档，其中应该包含每个结点的界面情况、每个结点流转后在下一个结点的展现（即前一步动作对后一步所产生的影响）

      一个很好的经验是将上文所说需要整理的内容用excel进行梳理，每个sheet中记录一个结点的情况包括截图和说明，多个sheet间形成流程的一个分支，在此情况下共形成五条流程分支，如下图所示：

       固定流程是在另一个项目中，其本身已经有文档，流程的业务说明、流程流转说明、结点大部分情况也已做了说明。而其流程设计则在和流程设计人员协作在理解需求的基础上进行了三次修改将其设计完成的。在详细阅读了需求后，应该将这种需求结合项目架构和项目开发方式思考如何将其转化成项目实现。这首先要求理解利用该项目做开发，而我自身对该项目的大体架构有所了解，但其后续演变了不少，而该项目又是远程团队开发的，故而沟通起来很不方便，不过流程开发有些规律可循，那就是流程之间要处理的内容基本上是相同的（大体包括元数据、附件、处理过程等），又考虑其为原已有流程的特例，故而这个开发照葫芦画瓢再花上一些时间理解和修改不同的地方就可以实现。

        整体来讲这条流程的开发较为顺利，但是在后续测试时也难免出现bug。由于此流程是固定流程，其逻辑相对简单，故而此处的bug多数是需要完善性的，而这些在需求中没有提到。这个问题在团队中往往也是存在的，其原因很可能是在众多需求中，提到过这类需求，而对于不同流程来讲这些也许都是适用的。产生开发时出现这种状况说白了是开发人员没有完全了解到项目，像这种半路夫妻很容易出现这种状况，再有就是开发人员和需求人员没有站在彼此角度去讨论需求，大家讨论下是完全可以避免的。

       这两条流程开发完后，测试没有出现功能性bug，这得益于架构做的较好，对项目开发方式有一定的了解，为需求到实现的转化打了基础，更得益于在需求的理解上有个相对较好的协作：项目组支配资源梳理问题流程需求，与需求人员沟通需求的方方面面等等。虽然很多事情不完备，但已经为开发顺利进行贡献了不少。总之顺利开发的要素有两个一个是需求、一个是架构和开发方式，而前者是入手的关键环节。