freebox
2008-08-31 21:18
我服务的行业是养不起一整套过程的所有开发人员的,他们找不到物理学家,无法去找电工,不能找一个CPU开发团队,不能找一个操作系统开发团队,也找不到一个应用服务器开发团,但是这些东西他们买得起,软件他们也买得起,只要他们觉得买到的软件足够应付他们的需求,他们也不必找我们,但是事实是他们的需求一直在变化,他们找不到一个现成的解决方案解决所有问题,在工具不发达的今天,他们自己暂时还不能通过定义业务来生成计算机代码,所以就有我们了。

工序的执行和工序的设计可是不同的,不能混淆这两个意义。不是说有了这些框架,拿着OO的Java工人就变成OO派了,真正的OO是要和业务员,和领域专家一起讨论才会知道的,当设计一个良好模型满足他们的需求变更时,工人就变成了设计师,他设计了这个工序,改良了工序的执行(能迅速响应各种需求变更)。没有应用场景也就没有模式什么的了,闭门造车做出来的系统是不能满足应用的,因为单靠自己是无法确认这个领域究竟是什么样的,只会造出来一个看着挺好,但实际用不上的软件。

可能一个Intel工厂里的设计者正在聚精会神地研究24核CPU是什么样的,因为他学的就是计算机电气电工,而另一些人正在讨论为什么这个销售模型即将崩溃了,因为他们学的就是开发业务软件。觉得自己在哪个位置是只有自己才知道的事情。

banq
2008-09-01 12:28
>正如完成产品流水线上的每个工序一样,我们也只是软件设计中的一道工序上的工人,处于什么工序只做什么事>情,而不是做该是别人做的事情。真正能改良产品的绝对不会是工序上的工人,工人最多是出个宝贵改良的意

工序: 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 3. 编码实现 4.测试调试 5.部署运行。

工人就是从第3个阶段介入。前面需要架构师和建模业务专家,也可以聘请专业咨询公司介入咨询。

整个工序前面3个阶段价值最高,也是70%贡献,但是现实中,这部分重视不够,这样,第4阶段就依赖测试工程师来补救,所以,为什么市场上测试工程师很热,这是由于错误的软件工程思路导致。

bookview
2008-09-02 10:21
做事情一般分成目标,方法,行动三个方面。大家都知道这三个环节往往不会全都明朗,而且随着事情的发展变化,原本确定的方案也会变得不合时宜;特别是社会进入分工合作时代,加让大家对事物的认识原本就存在差异化,因此怎么么去管理,怎么去响应变化就成了各个行业优胜劣汰的重中之重。

<工序: 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 4. 编码实现 5.测试调试 6.部署运行。>

用目标(做什么),方法(怎么做),行动来做如下分析行吗?

(分析建模,模型细化)是强调分析目标吗?要管理什么数据,要有什么功能,是了解做什么。

(架构,编码实现,测试调试)是强调分析方法吗?怎么管理数据,怎么管理功能,是去想怎么去做的问题。

(部署运行)是怎么去执行。

如果是这样子分析可行的话,我觉得不是对前3不够重视,而是这没方面的杰出的人才,无法做出响应变化的需求分析。前面的工作没做好,再加上分工不明确,所以后面才要去补救,增加4,5的工作量,过度的要求第3,4步的能力还要去分析什么是变化的。

banq
2008-09-02 19:56
>怎么么去管理,怎么去响应变化就成了各个行业优胜劣汰的重中之重。

现在基本都是敏捷工程方法。

bookview
2008-09-02 20:43
我个人认为敏捷工程一种用行动后的结果来分析真实需求的方法,在目标无法确定的时候依赖行行动后所得的经验。

猜你喜欢