前些天您给我们开会分析项目的时候,好像只画了两张图,相比几个月前讲课的时候少了很多。做项目时画什么图可以裁剪,我这样理解对吗?我们这样的项目,您特地画的这两张图是不是最重要的?您问出这个问题,说明您之前上课没有好好听,后来也没有好好复习和做题,“开会”似乎也开了个寂寞。不过,针对您问题中提到的几个点,倒是可以展开说一下。讲课时,大家的(《软件方法》)基础较差,当然是按照步骤讲解知识,布置练习,案例示范……。要是按照后来剖析项目那个节奏,原本14小时的课推导出来的模型,1-2个小时之内也可以得到的。此时,团队的几个骨干都有了一定的基础,和我这边的交流效率高了很多,改进模式一二三,涉众利益,泛化关联,一听就有共识是什么东西,过程就显得快了,这不就是我们课上和书上讲的好处吗:基本共识上的沟通,提高沟通的效率和深度。
工件评审是按时间收费的。如果我为了照顾像您这样的同事,又把知识点给过一遍,操作示范一遍,把3个小时能解决的问题拉长到14小时,领导也没意见,我倒是挺乐意的。对。不过,即使对,我猜测您也还没有理解里面的道理。
如果不需要和其他人交流,大脑又有足够的能力把握问题的复杂度,那建模在大脑里一闪而过可能就够了,不需要以其他形式表达。其实往往卡就卡在第二点“大脑有能力把握问题的复杂度”,就算爱因斯坦压根不想和别人交流,他在思考问题的过程中,估计也要在纸张和黑板上写大量的演算公式,哪怕演算完了就立即扔垃圾桶。如果需要表达出来,可以口头、文本、UML、其他……我在“开会”时的表现,就可以用以上知识点来解释。您阅读完以下文字后,(如果领导允许)可以回看当时的开会录像对照一下。首先,我建模的推导过程依然是完整的,需求从业务建模来,分析从需求来,设计从分析来,不会无凭无据。这个没有变化。业务建模和需求,我感觉几位骨干掌握得还好,所以,主要是看着贵方的“****说明书”(严格来说只能算是建模的素材),一页一页翻下去,主要通过口头交流,然后我说一些建模的意见以及特别要注意的地方。其实在探讨的过程中,也是有画图的,我也在屏幕上用笔画了一些简单的用例图、序列图,把要点画出来辅助探讨,只不过没有体现在我留下来的EA模型里面。一旦我觉得几位骨干已经基本理解我的意思,就往下走。但是,我在会上也要求了,几位骨干回去按照我说的要点,认真用EA建模,然后发给我看。我写这么一大通,最要紧的就是怕有的同学看到表面现象,说潘老师是这么干的,然后称赞我“敏捷”之类的。绝大多数“敏捷”的人,是“拍脑袋”,而不是厉害到了“在大脑里完成”。(3)我们这样的项目,您特地画的这两张图是不是最重要的?“开会”的时候我说了,逐点改进技能,贵司的这个项目目前来看,改进业务建模技能可能收益最大,那就先聚焦于改进业务建模技能,其他工作流像以前一样搞就可以。您说的那两张图,一张是系统的分析类图,一张是某个类的状态机图。上面说过,如果我简单点一下要点,下面的同事就能心领神会去完成建模任务(主要是业务序列图),那就点出要点就行。之所以我要画这两张图,是因为这个类图和状态机图需要更多的抽象能力,我估计我点了要点,下面的同事也搞不定的,所以我就自己上了。刚才也说了,先聚焦于改进业务建模技能,而我画的分析类图、分析状态机图属于分析工作流,暂时置之不理即可。如果分析设计按照以前的搞法,这两张图有参考价值,参考一下无妨。如果纯粹是为了学习类图和状态机图的知识,拿来当学习资料也无妨。但千万不要误解说,潘老师画这个就是让我们要学会用类图、状态机图来解决项目中的问题!然后把大量精力投进去——您的项目问题很多,但最大的问题不在这里。
[讲解再更新]31套UML/SysML+EA/StarUML的建模示范视频-全程字幕(20221201更新)
[周末上课]1月7-8日分析设计高阶-网络公开课(原“剔除伪创新的领域驱动设计”)
《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信:umlchina2