工程管理中的工程技术

本文是原计划在第一届“构建之法”软件工程实践教学论坛(福州大学承办)的发言,期待着能够借助讨论得以提高,由于不可抗力未能成行。

会议所有发言及参会者感言在这里[第一届“构建之法”软件工程实践教学论坛在福州召开 - 异步社区]。

以下是我计划的发言草稿,每张图是一页PPT,其下的文字是对应这一页PPT的发言。

 

幻灯片01

各位中午好,

我报告的题目是
《工程管理中的工程技术》,将主要介绍在软件工程课程中关于时间管理的体会。

我是杨贵福,来自东北师大。

 

 

幻灯片02

在教学和实际项目中,我们都会遇到这样一些问题。

比如,当你作为上级询问进度时,学生可能回答: 快了,就差一点了。

到底差多点儿呢?学生并不能回答。而软件工程,无论是实践还是段子,都告诉我们,当完成90%时,剩下的10%需要50的时间。越接近完美,花费的精力可能成倍增长,甚至可能不可预计,或者不可完成。初学者面临的问题不像莱特兄弟之后花了一百多年,机翼截面”效率”只提高了千分之一,而是他们并不知道需要达到何种程度,还需要多久,甚至已经花费了多久。

另一个现象。当问到为什么会有这样糟糕的结果时,学生经常诉诸基础。下一迭代要加强的,也是基础,至于什么时候能达到足够的基础,并不知道。或者诉诸态度,期待自己有超常的发挥,事实上他下一迭代中态度也就不过如此。工程方法正是要提供手段使常人也能完成任务。

幻灯片03

在工程实践中,也经常出现以内部进展代替外部效果,以态度代替方法,以愿望代替承诺。

这些会被评价为
缺乏职业素养、不靠谱、不成熟,或者年轻人还被有被体制化。这里的体制化是正面的意义,类似于电影《零下8度》中的中二狗终于成长为狗队的领袖。

这些现象表明,学生还缺乏对工程方法的基础认识,尤其重要的是工程中的因素应该是可估算、可度量,可以观测的。他们中基础较好的学生,通常对待技术参数具有足够的觉悟,能意识到代码和执行效果需要满足可以观测度量,能主动估算或预期现象,但是即使相当优秀的学生,在最初也很难意识工程管理中的因素也需要按技术一样看待,需要保证可估算可度量。

幻灯片04

软件工程教学中的一大块目标,是掌握管理技术。这需要三个方面,一是学生掌握管理中的手段,了解原理更佳,二是教师在教授的过程中,也主动运用,一方面作为表率,更一方面提高自己教学的可靠性。这是我们的信仰,当然也应实施。三是学生的学习过程也应遵循。所以,教学目标、教师、学生,都应遵循这样的原则,并且,产生的最终产品和中间工件,都应包括管理手段所依赖和产生的工件。

希望使学生意识到,管理中的手段不单纯是管理,同时也是技术。管理手段是为了完成行政决策的目标,对任务建模、参数量化,在实施过程中可以观测度量,可以估算的。所以具有技术手段的典型特征,因此可以视为技术手段。

幻灯片05

为什么强调工程管理手段是技术?

1.工程范围内的管理,与传统或者公众心中的管理不同,不具备艺术的特点,并没有多少发挥和人文主义的空间,而可以视为纯粹的技术手段。如上所述。

2.工程管理并不像初学生看上去那么简单。初学者往往会因为这些手段应用并复杂,数据采集简单,数据模型也简单,觉得不能发挥自己的聪明才智。需要使学生意识到,这是一种技术,而且其难度正在于他此刻还看不到的地方。

3. 具有技术手段的一般特性,可度量,可估算。

4. 应用技术手段的外部效果可以检验。现代工程管理确实促进了群体和个体的工作效率,使得受过训练的一般工程师具有更高的产出。

5. 从教学的效果的角度上看,让学生充分意识到管理是技术,对于提高学生的动机有帮助。学生普遍对技术较为推崇,尤其技术基础较好的同学对管理充满蔑视。他们的观点来源之一,是技术水平确实与产品质量相当程度上正相关,软件工程课的作业也体现出这一点。所以,他们把失败归结为技术。他们意识不到,技术基础差,正是自我管理水平低的结果。如果不提高管理水平,不是技术水平不能解决问题,而是技术水平不会提高。

幻灯片06

强调工程管理,尤其适用于学生的技术基础较差的情况。

无论学生水平如何,教师抱怨学生水平是普遍现象,就像学生抱怨自己基础不好所有才有今天一样。在这种情况下,由于时间的关系,补足基础是不可行的。比如在作业设计中我请教过邹欣老师,console程序看起来不酷,不能更好地吸引学生的兴趣,但是他们又不会GUI怎么办。邹老师说,只好用console,原因非常简单,因为他们不会GUI。我们需要接受现有情况,在现有的条件下设计解决方案。仅仅承认现状,把失败归因于不可改变的因素,也于事无补。

在工程教育中,有些训练是与软件无关的,让学生意识到这一点,有利于提高他们的自信,因为不需要基础,尤其是数学或程序设计能力这种短时间难以有效果的,他们更容易相信自己可以胜任或有收获。

我们相信,软件工程首先是工程的,其次才是软件的。工程的一般共性远大于软件的特性。科目的训练重点,也应该是工程类学科共同的部分优于计算机。

邹欣老师设计的一个作业实例,策划班级到邻近城市2日游。我的理解,就体现了这样的教学动机。这里包括任务分解,如果评判各个方案的优劣,那么方案评价的标准是什么样的,有哪些指标,这些指标如何赋值,以及对指标体系合理性的讨论。像会议承办,也都具有明显的工程管理的特色。而这些,无论学生以后是否程序员,是否在IT 领域,这些能力都是需要的。具体的每一门课程,比如软件工程,应体现工程教育的总的目的,而不仅留在通识课或共同课或基础课中。

所以,作业和考试分数度量的,应该是工程管理的训练效果,而不是工程实施需要要的编程基础。具体的说,工程管理所产生的工件,像WBS表格、PSP表格、燃尽图,才是度量的重点,至于程序好不好,代码好不好,产品好不好是次要的。只要燃尽图是真实的,了解应该如何度量时间和功能点,那么即使产品不好,而过程是合理的,那么应该高分。

比喻。如果考核测量身高,那么只要能测出来自己的身高,就得分,精度高分数高,而不是身高越高分数越高。

幻灯片07

在这里,我选择讨论时间的度量和估算,原因是时间是在项目中最宝贵的资源,稀缺并且不可替代。生命是由时间构成的,消耗时间做什么事就是花费生命本身。希望能在时间管理中使学生也意识到这一点。另一个原因,时间是可度量的可估算的,具有技术手段可实施的特性。此外,在度量中,希望是迭代周期较短。戴明环体现了反馈的思想,在每个迭代周期观测和重新估算。如果度量的颗粒度较大,比如超过一周,初学者很难掌握。此外,学生往往在以前的教育中更多的是被动接受计划,而很少主动计划和实施检讨,所以缺乏自我管理的训练。因此,短迭代有利于了解时间的度量,也有利于使效果在可控范围内。教学排课的周期决定,一周是个合适的时间段。SCRUM要求在每个周期中还有1天为周期的更短迭代,如果教师或助教能够跟进,会效果更好。 幻灯片08

这是时间度量和估算技术手段中的一个实例,WBS和PSP2.1结合。WBS部分体现了任务或功能分解,对每一部分估算时间,在实施中测量时间消耗。要求学生在度量时客观,而不是掺杂主观情绪,比如自责。在尸体检讨时,也检讨对工程方法的使用,而不是检讨态度。

一个建议是,任务分解细一些,以每个工作日能够完成多个任务为宜。一方面提高自信心,另一方面初学者控制超过一天的任务非常困难。事实上,初学者控制超过1小时的任务都会感到困难,觉得前途渺茫。如果分解得到的任务数量过多,说明选择的任务边界太大,应该降低任务难度和范围。

幻灯片09

第二个例子是燃尽图和SCRUM站立会议。重点是保持记录,以后再次建议拆分需求,降低颗粒度,每天多个任务,而不要多年燃烧一个任务。要小心瀑布法的倾向,在初期定下宏愿,后面发现根本不能完成。在学生创新创业项目中这种情况也经常出现。初学者的愿望是MBP( maximum
beautiful product),但是愿望的可行性往往未深入考虑。我的体会是限期MVP(最小可用产品)有帮助,另外降低初始的迭代周期有帮助,避免伟大的计划,类似于RUP以架构为核心,必须快速实现可以跑起来的框架。

幻灯片10

第三个实例是PSP例行报告,要求每周作业中都包括。建议手写记录,比各种计算机和手机工具都来得便捷,除非一直坐在同一台计算机前面工作。希望向学生强调客观记录,不要检讨态度。原始数据比总结重要,学生倾向于总结为泛泛的空话。学生在总结时说过,今天我学了C#,我的回答是你怎么不说你学了计算机呢。应该先有记录,后有总结。

PSP曾经用于向学生证明他们的作业量并不大。当学生抱怨作业量的时候,我要求他们看PSP上记录的时间消耗。无论时间很少,还是记录的任务太泛泛,都说明没有实际投入。

此外,有学生纠结PSP的分类如何进行。这种可以事后总结的内容,重要程度低于事实记录。并且,在PSP的过程中,分类可以调整。所以,最初怎么喜欢怎么来也无所谓。

幻灯片11

估计时间不够,[技术原型,应对技术基础较差]一页不讲。如果时间多余,单独展开。

技术原型,是为了技术基础不够好,对需要使用的技术不熟悉的同学,为他们掌握某种特定技术设计的路线。

对于技术基础好的同学或学校,是显然的,并无价值。邹欣老师指出,技术好的同学可以在结对编程和团队项目中,练习”技术领导人”角色。领导力这一工程能力是技术基础不能替代的。

幻灯片12

教师在教学过程中,也应记录和估算时间,既然时间是如此重要的资产。

我在工作中,使用PSP,并据此预估完成还需要多少时间。

我应用西红柿时间管理法,保持在批作业时集中精力,不做其余的事情。在我的实践中,碎片时间不可靠,一是没有碎片时间,都用来分配做别的了,像开会这一类的时间也不太可能用来批作业,二是建立工作环境需要较长的时间,三是如果延续时间长,容易出现标准不一致。最后这个问题,可以通过把作业的判分降到以小题为单位,降低主观性。最有效的办法,就是集中时间处理,按邹欣老师说的,”除了你说的那些,我基本不做别的”。并且邹欣老师提到的一段话对我非常有启发,与各位分享。他在出了书以后,有前辈叮嘱他,现在面临的诱惑会很多。这是前半句。我以前一直以为诱惑指的是金钱美女之类的,这位前辈的后半句说,会有很多人找你做各种事,(大意)都是有责任有荣誉的。这些不可能全都做好,只有舍充其余的,才能把核心功能完成。

幻灯片13

这一页的内容是按邹欣老师要求增补的。

我原本的报告内容集中在围绕时间这一因素的工程管理手段,这里讨论其他的工程手段,也非常重要。

比如节省时间的手段。

要节省时间,与在效能分析中相同,应该首先profile,严格地或不严格的,得到哪些工作最消耗时间,对这一工作自动化。

自动化的目标是提高效率,方法是软件工程中的常用手段,比如自动化脚本。我实现了git批量pull操作脚本,用于周期更新全部学生的代码。避免每个学生单独拉。邹老师希望构建自动测试框架,我还没有做,注意到福州大学Z班做了相关工作。

作业要求如果写得够好,下次可以复用,可以根据学生针对spec的困惑每次增量修改,也能节省教师的时间。

学生互评作业,在团队作业阶段,一方面降低教师工作量,这很必要; 一方面也能帮助学生学习客观、量化地评价工业产品,这也是软件工程课程的教学目的之一。互评也是工程管理的绩效考核中的重要手段。

幻灯片14

这一页也是按邹欣老师要求增补的。

迭代增量开发目前我们还没有成功的案例。在第一轮课,我要求每个团队的作品上继续开发至少一个功能。希望因为是同一学期,开发者容易接触到,能降低增量开发的难度。但是工作量还是很大,能够把其他团队的作品运行起来,就已经不错。优秀的团队可以增加功能,但是工作量非常保守。

试着讨论一下原因。在学期间,学生对于迭代增量和工作量的估算,是初学,增量开发对于前期基础要求也不低,所以不容易成功。即使是自己的代码,alpha阶段以后,也倾向于不增加功能,只填旧坑,或者只许愿不兑现。

学期间的增量难度更高一些。课程结束学生不再对教师有责任,如果没有更新代码的意愿,而是因为课程被迫,不更新才是正常选择。我自己的项目,除非上级有要求,还没有主动维护更新的。第二,即使是自己的代码,如果继续迭代,可能也难以为继。第三,年轻学生有创新的欲望,他们并不关注能力,而是关注表现。继续实现别人的想法,不符合他们的期待。最后,增量开发对开发者和遗留的代码都有相当高的要求,开源社区能换人开发的项目,也并不多见。

在软件工程课程中,如果想教学迭代增量,也许可以从降低项目难度和文档要求入手。

文档要求来自一个经验。东北师大本科生曾经与丹麦哥本哈根北商学院合作5个学期教学,双方学生远程合开发一个简单项目。能够取得一定结果的原因,是丹麦学生非常注意从每一个阶段的文档。

幻灯片15

个人经验,有些学习不宜预设效果目标。

除非你经历过,是专家,否则你不可能可能回答,背陌生5000单词需要多久,长胸肌或任何一块肌肉到什么围度卧推多少公牛需要练习多久。

对于这些学习,不宜预调效果和截止期。一方面如前所述,我们没有这种能力,那只是愿望,对于完成目标没有技术手段上的价值。另外,能降低心理压力。Douban阿卡纳著有《各种普通的食物最好吃的时刻》,她有抑郁症,她说为了长跑,她欺骗自己”今天就是最好一跑,跑完以后再也不跑了”,也很有效。宏伟的目标并不总有帮助,只看脚下有时更容易一些。所以只记录今天的指标,这些指标对于完成总的任务有何帮助,我们不去关注。

也可以记录投入时间,用来度量成就。也可以观测实际效果,但是不是期望的指标,只是顺其自然得到的结果。

正如邹欣老师所说: 只问耕耘, 不问收获, 因为收获的周期很长,
而且有各种不可控的因素。但是应该不断耕耘。

我想,一直努力,要么为了自然的结果,要么为了过程本身的意义。至于短期的效果,不作为评价方法是否有效的指标。那么,指标可以就是时间。

图示,是我在keep上锻炼,还有用扇贝和百词斩背单词的记录。9182分钟,575天和597天。也向学生证明,教师所推崇的,自己也在努力做。

幻灯片16

以下是本次报告参考的资料,感谢作者。 幻灯片17

这一本是沿着《构建之法》的参考书列表看下去得到的。 幻灯片18 幻灯片19 幻灯片20 幻灯片21

感谢各位,期待讨论。

=========================

博客会手工同步到以下地址:

[杨贵福]

[杨贵福 - 重剑无锋,大巧不工]

[杨贵福 的专栏 - CSDN博客]

[giftdotyoung.blogspot.com]