刚才突发奇想,对于开发的流程有了一点新的想法。就发出来,供大家拍砖。不知道大家对这个流程有什么不满呢,尽管说,希望尽快完善它,尽快应用它。好了,说正文吧。
1 了解需求
就是了解客户,或者是市场的需求。可能要结合调研,深入体察,问卷调查之类的形式。尽可能了解市场的动向,方便把握我们的方向。
2 业务建模
了解的需求,定义的产品方向之后,就需要进行业务建模了。又可以分为三个阶段:
业务分析:分析市场的需求,划分业务的方向,找到业务的主体以及业务的大概内容和范围。
整理业务粗粒度的用例:分析完业务之后,将分析的结果整理为粗粒度的业务用例。可以用工具来辅助这个阶段的工作。把握业务的脉络和方向。
细分业务用例:有了粗粒度的业务用例之后,需要进一步的细分,整理业务的细枝末节,考虑每种业务的可能性,业务的流程,业务数据的流向。
 
这个阶段参数的人员不包括开发人员,主要是业务分析人员,需求分析人员,和系统的架构师,如果需要的话,可以引入高级软件工程师。
3 业务知识的传播
这个传播主要是说,需要将成型的业务知识传播给开发人员。一个系统,经过了分析,最终是要实现的,要用代码的堆积的,所以再开发之前,需要开发者了解业务的脉络,否则实现的东西会偏离方向,而且有可能实现的过于简单或者过于复杂。
4 整理技术用例
这个阶段有两种做法:
1)开发人员在高级软件工程师的辅助下,将细粒度的业务用例整理为技术用例,也就是想办法实现每个业务用例。当然了,有可能细粒度的业务用例和技术用例是一对一的关系,也有可能不是,而是其他关系。反正,要转化为技术用例。技术用例的内容包括:需要什么技术手段,什么算法,如何实现,循环还是如何,修改哪些表,是否需要数据库事务,使用sql事务还是代码写事务,等等技术细节。最好达到伪代码,也就是谁拿到了,都可以实现的地步。
2)高级工程师在架构师的辅助下,完成第一种做法的内容,不让开发人员参与。
这两种做法的区别就是有无开发人员的参与,各有各的好处。开发人员参与,可以锻炼他们的分析能力,但是他们介入业务也不是一件好事。因为我们都知道,开发人员的思维方式和业务人员的思维方式是反过来的,不是一种方式,容易没有结论。而且,开发人员专注于技术,对他们也是好事,尽量不要分散他们的精力,让他们尽力实现软件,尽力用更好的方式实现软件。
5 Job Item
技术用例也出来了,这样就可以划分工作了。每个人划分几个技术用例,估算出实现需要的时间,列一个表格,或者是用什么管理工具管理一下,反正方便控制进度就好了,需要知道的是每个人都在做什么,什么做完了,什么还没有完成。
每个Job Item有四个阶段:未分配,已分配(未开始),进行中,结束。根据这些阶段,对于功能的实现进度一目了然。这可能需要开发人员每天更新自己的工作内容,或者是主管每天跟踪进度之后,修改进度表。
6 跟踪
不要以为任务分配好了,就一切万事大吉了。跟踪是必要的,一定要跟踪进度,而且要定期的检查,否则后果不堪设想。每一层的主管负责跟踪自己范围内的完成进度。
技术组长:组员技术用例的完成情况,技术的实现有什么困难,手段是否合理。跟踪的过程中顺便给予指导。
项目经理:跟踪的目标就是业务用例,细粒度的,粗粒度的,根据职责范围跟踪。还是就是整体的进度,是否需要加人,是否需要加班,人员的情绪是否正常,等等。
 
好的,说完了,希望大家赶紧拍砖。多提宝贵意见。