工程管理中的工程技术

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

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

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

各位中午好，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如节省时间的手段。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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