工作流管理
前几天在 DevSuite 中设计项目工作流时，突然想研究一下工作流这个概念了，所以考虑一段时间也Google了一把，现在来开始写写想后感，呵呵。
先Show一下我设计一个工作流程图，比较简单，适合业务流程不复杂的公司，特别是做项目的软件公司。
工作流，顾名思义，工作的流程，或者说是业务的流程，干一个活，做一件事情，总是有个开始点和结束点的，复杂点的中间可能还有审核点等过程，这些开始、结束、审核等过程都可以称之为一个状态，也就是描述这个事情进行到了什么地步了，而把这些状态按照发展的先后顺序连在一起，就称之为一个流程了，事情处理的流程，也就是所谓的工作流了。
工作流的概念应该提出有一段时间了，比如上个世纪丰田发明的“流水线”，把汽车的组装分成几十个步骤，每一步都由专人来完成，汽车只要在流水线工作台上一直移动下去，每到一个步骤那里停一下，完成以后移动到下一个步骤那里，这样子，只要移动到最后面，这个车子就组装完毕了，而对于员工来说，本来可能每个员工都全能的，要什么都干，而现在只要干一个固定的步骤就行了，这样子就分工明确，大大提供工作效率。
而进入信息时代以后，越来越多的工作、业务都是跟信息有关，也就是跟网络有关，跟电脑有关。脱离了传统的模式，工作流是否还需要？答案当然是需要的，而且是更加需要了！因为对于一个工作来说，本质都是没有变的，都是需要去开始，去结束，去审核；但是方式却变得很多，本来都是手工的一个活做一下就结束了，能看到感知到的，而现在呢，你干的活不一定是一个实体的活，而是一个虚拟的活，比如说传统的去银行取钱，原来都是在现场一个一个排队，从这个柜台去填表啊，签名等，拿到现金就好了；但是现在呢，都可能是通过网络来办了，你不用去辛辛苦苦排队了。但是实际的流程还是没变的，总是先申请，然后看看你帐户里有没有钱，然后你还是确认这样子，最后钱取到你的帐户里或者其他工具里。
工作流程看起来还是差不多，但是其中的内涵有了很大改变，我们要考虑很多传统工作无法想象的地方，比如网络安全性、网络承载量、审核自动性、审核准确性、覆盖全面性、流程可定制性、权限可控制性等等，因为这些都不是由人来控制的，而是需要系统来控制的。
针对这些现代化的工作流特性，现在已经行业都做得很好，今天主要来谈谈我所熟悉的软件行业，当然其实其他行业的工作流系统说到底也是一个软件系统，只不过这个系统是用来处理它们行业的流程。所以我这里说的软件行业，是说软件行业里本身业务的工作流，比如开发一个产品的流程管理。
软件开发，目前看来，主要分成了传统开发模式和敏捷开发模式，传统的主要是瀑布为代表，敏捷的话，以Scrum为代表，所以今天介绍也是基本以这两个为主。
对于瀑布模型而言，一个产品的开发，一开始就设计好要做些什么，要多少时间，什么时间完成什么，然后接下来就按部就班，一步一步完成了，就像建楼房一样，先设计好，再慢慢建，中间只能按照计划来，不能说要再加一层楼或者顶上弄个铁塔，这样子不符合设计的，可能最后会倒塌的。
而工作流对于这种模型而言，很简单又很复杂，为什么说简单呢？这种模型因为已经在初期设计好了，以后不会有改动了，所以对于工作流而言，只要一开始设计好，以后就不需要去管了；为什么又说复杂呢？对于产品而言，因为一开始把所有都设计好了，相当于要考虑了以后发生的任何情况，预估未来可能性就太多了，所以对于工作流的步骤而言，需要考虑很多可能性，因而这个工作流需要设计得极其复杂才能覆盖所有可能性。
而对于Scrum而言，因为太想敏捷了，太想简化了，工作流对于它来说甚至可能是一种束缚了，但是工作流真的不需要吗，也未必。其实我们所说的敏捷，只不过是一个方法论，并不是一个规范性的东西，它的确建议简化，但是简化不一定简化工作流程，而且简化也并不是敏捷的本质，敏捷最重要的是欢迎变化，拥抱变化。而对于欢迎变化而言，流程不见得是一个必须简化的东西，比如Scrum的确流程简单，但是RUP流程很复杂，所以流程只要合适就行，最后能达到欢迎变化，快速响应变化的目的就行了。
所以，综合而言，我觉得工作流对于软件开发而言，还是需要的，但是可以根据模式的不同而决定不同的工作流，简单的、复杂的。