随笔写下的开发流程

刚才突发奇想，对于开发的流程有了一点新的想法。就发出来，供你们拍砖。不知道你们对这个流程有什么不满呢，尽管说，但愿尽快完善它，尽快应用它。好了，说正文吧。

1 了解需求

就是了解客户，或者是市场的需求。可能要结合调研，深刻体察，问卷调查之类的形式。尽量了解市场的动向，方便把握咱们的方向。

2 业务建模

了解的需求，定义的产品方向以后，就须要进行业务建模了。又能够分为三个阶段：

业务分析：分析市场的需求，划分业务的方向，找到业务的主体以及业务的大概内容和范围。

整理业务粗粒度的用例：分析完业务以后，将分析的结果整理为粗粒度的业务用例。能够用工具来辅助这个阶段的工做。把握业务的脉络和方向。

细分业务用例：有了粗粒度的业务用例以后，须要进一步的细分，整理业务的细枝末节，考虑每种业务的可能性，业务的流程，业务数据的流向。

 

这个阶段参数的人员不包括开发人员，主要是业务分析人员，需求分析人员，和系统的架构师，若是须要的话，能够引入高级软件工程师。

3 业务知识的传播

这个传播主要是说，须要将成型的业务知识传播给开发人员。一个系统，通过了分析，最终是要实现的，要用代码的堆积的，因此再开发以前，须要开发者了解业务的脉络，不然实现的东西会偏离方向，并且有可能实现的过于简单或者过于复杂。

4 整理技术用例

这个阶段有两种作法：

1）开发人员在高级软件工程师的辅助下，将细粒度的业务用例整理为技术用例，也就是想办法实现每一个业务用例。固然了，有可能细粒度的业务用例和技术用例是一对一的关系，也有可能不是，而是其余关系。反正，要转化为技术用例。技术用例的内容包括：须要什么技术手段，什么算法，如何实现，循环仍是如何，修改哪些表，是否须要数据库事务，使用sql事务仍是代码写事务，等等技术细节。最好达到伪代码，也就是谁拿到了，均可以实现的地步。

2）高级工程师在架构师的辅助下，完成第一种作法的内容，不让开发人员参与。

这两种作法的区别就是有无开发人员的参与，各有各的好处。开发人员参与，能够锻炼他们的分析能力，可是他们介入业务也不是一件好事。由于咱们都知道，开发人员的思惟方式和业务人员的思惟方式是反过来的，不是一种方式，容易没有结论。并且，开发人员专一于技术，对他们也是好事，尽可能不要分散他们的精力，让他们尽力实现软件，尽力用更好的方式实现软件。

5 Job Item

技术用例也出来了，这样就能够划分工做了。每一个人划分几个技术用例，估算出实现须要的时间，列一个表格，或者是用什么管理工具管理一下，反正方便控制进度就行了，须要知道的是每一个人都在作什么，什么作完了，什么尚未完成。

每一个Job Item有四个阶段：未分配，已分配（未开始），进行中，结束。根据这些阶段，对于功能的实现进度一目了然。这可能须要开发人员天天更新本身的工做内容，或者是主管天天跟踪进度以后，修改进度表。

6 跟踪

不要觉得任务分配好了，就一切万事大吉了。跟踪是必要的，必定要跟踪进度，并且要按期的检查，不然后果不堪设想。每一层的主管负责跟踪本身范围内的完成进度。

技术组长：组员技术用例的完成状况，技术的实现有什么困难，手段是否合理。跟踪的过程当中顺便给予指导。

项目经理：跟踪的目标就是业务用例，细粒度的，粗粒度的，根据职责范围跟踪。仍是就是总体的进度，是否须要加人，是否须要加班，人员的情绪是否正常，等等。

 

好的，说完了，但愿你们赶忙拍砖。多提宝贵意见。