软工第一次博客作业-阅读和提问

第一次博客作业-阅读与调研

项目 内容
这个作业属于哪个课程 2023年北航敏捷软件工程
这个作业的要求在哪里 作业要求
我在这个课程的目标是 学习软件工程知识,提升团队合作能力,积累网页开发经验。
这个作业在哪个具体方面帮助我实现目标 本次作业使我了解软件工程的流程与模式,并锻炼信息提取与提问的能力。

问题一:站在员工的角度,敏捷开发是否具有可持续性?

一些软件界的专家开始倡导“敏捷”的价值观和流程,他们肯定了流行做法的价值,但是强调敏捷的做法更能带来价值。(摘录自P114)

听说过一句话“ddl是第一生产力”,临近ddl时效率会变高。这和敏捷开发颇有异曲同工之妙,我认为敏捷开发的一个原理是通过连续不断的ddl提高团队的工作效率,在保证一定质量的情况下产生更多价值。 ​

但根据我的大作业/比赛经历,每肝一次ddl身体就受到一次“摧残”,所幸大学四年不是每天都要肝ddl。但软件开发不同,用户的需求一直在变更,员工每周也都要上班,如果考虑长期高强度的敏捷开发环境下,员工效率、心理等因素,这种敏捷开发模式是否具有可持续性?

问题二:在大学第一次软件工程课程中安排敏捷开发是否合适?

如果你的团队很弱,那么强行把敏捷(或者其它高级方法)套在上面也没用,也许还会适得其反,往往需要经历许多次失败/总结/改进的过程才能让Scrum走上正轨。(摘录自P123)

对于绝大多数北航计算机学院的同学,前后端工程的开发经历只有大三上学期的数据库大作业。

不可否认这些同学中不乏强者,但我认为大部分人(包括我)从开发经验上来说总体较弱,既然书中提到强行将敏捷方法套在弱的团队上没有用处,并且“也许还会使得其反,经历多次失败”,那在很多同学在第二次工程就采用敏捷开发这一高级方法是否合适? ​

我认为可能在有过一段基础开发经历后再过渡到敏捷开发较为合理?这个时候成员对开发的流程较为清晰,对开发中的可能遇到的问题也有较为准确的估计,在高强度的冲刺更可能避免混乱发生。可能对于北航软件学院经历过3次软件工程的同学,敏捷开发更能发挥作用。

问题三:在软件工程课程中,如何较为准确估计任务的时间?

软件工程师在长期的实践中,摸索出一套经验公式:实际时间花费主要取决于两个因素—对某件事的估计时间X,以及他做过类似开发工作的次数N。

Y=X\pm X\div N

注:Y是实际时间花费。中间的±表示加上或减去。(摘录自P181)

书中提到这套经验的估计方法对入职一两年的开发/测试人员也许有用,但是对于绝大多数大学生,这个N要么是0,要么是1,似乎估计的误差有些过于大。考虑到大学生还有其他课程任务,这种估计的需求的确存在,但书中提供的策略只能提供估计精确度一个大致的概念。 ​

此外我认为估计的误差还和任务距离当前的时间有关联,任务距离当前时间越久,越难进行估计。那么课程是否需要一种适应性的估计方法,根据项目的进行动态变化预估任务的时间?对于初次上手的同学,将这种估计工作交给更有经验的软件工程人员是否会更合适?或者有别的什么好办法?

问题四:软件服务是否应该记住用户的选择?这种权力是否应该由用户决定?

12.3.1 软件服务始终都要记住用户的选择(摘录自P264)

书中这一节通过Windows Live Writer的例子,强调软件没有记住用户最近使用字体带来的麻烦。 ​

但是记录用户选择会涉及隐私的问题,有不少用户不希望自己的使用记录被保存下来;此外,不少新闻软件根据用户的浏览记录进行推送,导致用户只注意自己选择的东西和使自己愉悦的通讯领域,出现信息茧房的现象。

针对这种需求,流行的做法是给用户提供选择是否记录选择的权利,例如不少浏览器设置了无痕浏览模式。但有时候用户无法预见自身以后是否会使用到当前的记录,如果此时软件开发者预见到了,那是否还需要把选择的权力交给用户?

问题五:如何激励创新者的提出新想法?社会又需要多少创新者?

可以看出,在算法和数据库领域,创新的想法一开始往往不被接受,而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。而这些决定还是很有经验的期刊审稿人做出来的。(摘录自P348)

既然在算法和数据库领域,创新的想法往往不被接受,但在前人基础上的扩展往往可以成功。而且创新还会经历很多失败,投入不少成本,为什么要去创新呢,follow别人的成果这不香吗? ​

我认为目前缺少对创新者的激励,因此我的第一反应是如何去激励大家去创新?但进一步想,这种激励有必要吗?

听说过一种观点,中国的理论数学交给最聪明的几十个人去研究就足够了,那么创新是否交给学校/企业中最聪明的一部分也足够了呢? ​ 进一步地,在无人创新和人人创新两种极端之间,创新的比例应该在多少为宜?

你可能感兴趣的:(软件工程)