zoukankan      html  css  js  c++  java
  • 回答自己的提问

    回答自己的提问

    第一章

    问题具备和精通大量的专业知识并不是一个合格的软件工程师,那么一个合格的软件工程师应该还要具备什么呢?

    我的回答:一、良好的编程能力。编程能力直接决定了项目开发的效率。这要求软件工程师至少精通一门编程语言,熟悉它的基本语法、技术特点和 API( 应用程序接口 ) 。  二、自觉的规范意识和团队精神。随着软件项目规模越来越大,仅仅依靠个人力量已经无法完成工作,因此,现代软件企业越来越重视团队精神。一般来讲,软件 企业中的程序员可以分为两种,一种是 " 游击队员 " ,他们可能对编程工具很熟,能力很强,编写的程序简洁高效,却缺乏规范和合作的观念;另一种程序员个人能 力不一定很强,但程序较为规范,合作意识良好。第二种人更适合现代软件企业发展的潮流。对于基础软件工程师来说,他们在企业中的角色决定了他们必须具有良 好的规范意识和团队精神。  三、认识和运用数据库的能力。信息以数据为中心,因此与数据库的交互是必不可少的,了解数据库的操作和编程是软件工程师需要具备的基本素质之一。

     

    第二章

    问题:在以往老师布置的作业中,所有同学都是完成后直接提交给老师的,并没有按照PSP的表格来统计自己在这次实验所用的时间,那么我们是否从现在起养成做PSP表格的习惯呢?这个习惯对我们最大的好处是什么?

    我的回答:按照PSP规程,改进软件过程的步骤首先需要明确质量目标,也就是软件将要在功能和性能上满足的要求和用户潜在的需求。接着就是度量产品质量,有了目标还不行,目标只是一个原则性的东西,还不便于实际操作和判断,因此,必须对目标进行分解和度量,使软件质量能够"测量"。然后就是理解当前过程,查找问题,并对过程进行调整。最后应用调整后的过程,度量实践结果,将结果与目标做比较,找出差距,分析原因,对软件过程进行持续改进。

     

    第三章

    问题:我们掌握自己职业各方面的理论,但是没有实践过,那么我们该通过什么方式来实践呢?哪种实践方式最好呢?

    我的回答:我们可以多参加一些学校举办的关于软件方面的活动来实践自己学到的知识。这也是最好的方法。

     

    第四章

    问题:结对编程这个模式在之前我们就开始实践了,但是感觉两个人一起完成的程序所花的时间比一个人花的时间快得并不多,那么我们该如何提高编程的效率呢?

    我的回答:1、编写单元测试,提高效率;2、训练自己的编程能力;3、多阅读代码和技术资料。

     

    第五章

    问题:本章主要讲团队合作的各种模式和团队的开发流程,选择合适的团队模式当然要从实际来考虑和分析,但一个好的团队取决于什么?

    我的回答:好的团队嘛,首先一定要有一个好的领导者,有魄力和毅力,有远见,带领整个团队不断进步。然后还要有各个领域的几个精英人物,不要太多,但一定要“精”,这样的人能顶10个普通人。还有,就是团队里可以有普通人,但绝不能有心术不正的人,这样的人一定会让整个团队退蒙羞。最后,再不断加强他们之间的默契,看清每一个人的优点与缺点,以后还要更好的合作。

     

    第六章

    问题:我们现在实践的是2人结对编程,并不算什么团队,书里说团队很弱不能强行把敏捷套上去,为了避免这个问题的出现,我们以后要如何创建一个强的团队呢?是不是有很强的技术员聚在一起就可以建立一个强大的团队了呢? 

    我的回答:最关键的一点,就是自身,包括自己的心胸,为人处事的态度。处理问题的方式方法。自己具有能力才能够联合他人共同创业

    。 其次,要仔细选择团队成员。在选择德和才时以德为先。创业是艰苦的。如果团队成员在创业中无法面对困难,出现逃避,推诿。或者互相之间猜疑,敌视的话,肯定完蛋。所以,选择成员时,要分清关系,最核心的成员,一定是互相之间关系比较和睦的。人品比较好的。 再次,在创建时,就要把团队的权责分清,谁该干什么,不该干什么都要说清楚。必须要有一个最终决定的人。如果你自己来领导团队更要注意这一点。一个没有权责分明的团队很难想象能够成功。 最后,在吸收团队时,最好适当考虑一下个人的背景,相同或相似背景的人合作起来会更加顺畅。

     

    第七章

    问题:本章主要讲MSF(Microsoft solution framework)微软解决方案框架的方法。在7.5节陈述了MSF敏捷开发模式的极大优越性,做出来的软件质量很高,但后面7.6节说到MSF CMMI开发模式是比MSF开发模式更好,是不是MSF CMMI更适用于现在的开发呢?

    我的回答:不是的。这是要考虑到自己团队的结果和能力等综合因素来选择开发的模式的。

     

    第8章

    问题:8.7中分而治之,我们都知道每个人的能力不同,对同一个工程的态度也不同,或者说团队中都没有愿意站出来扛,那该怎么办?

    我的回答:这时要发挥自己的带领能力了,如果自己有能力的话,自己站出来罗,群龙无首的团队是成不了大事的。

     

    第9章

    问题:一个团队中PM的人数可以有多个吗?

    我的回答:可以的。

     

    第10章

    问题:对我们了解了用户的需求后,但是我们想法和做出来的软件会和用户的需求有偏差,比如风格、界面的修饰等等,那么我们程序员怎样才能让自己的想法更加靠近用户的想法呢?是设身处境么?

     

    我的回答:设身处境是个很好的方法。我们还可以多花时间和用户去沟通,这样我们的想法才会和用户的越来越接近。

     

    第11章

    问题:我们现在这个阶段是在做四则运算APP,如果按照这章的步骤走下去,每天都要进行进度更新,和每日会议还有每日构建的,会不会不太符合我们现在的处境?毕竟我们的所有时间不能只为一门课程服务,还要大量的时间花在其他的课程上呢。

    我的回答:很明显,看问题的我的看法是不用这样的,而且没有这样的时间去折磨,到我们真的涌入到公司才会这样做。

     

    第12章

    问题:在实际的项目中,我们并不知道哪个阶段才开始设计用户体验,那么我们如何确定呢?

    我的回答:这个我也是很清楚,需要老师的帮助来解答。我认为是在自己团队觉得做得差不多的时候可以开始设计用户体验吧!

     

    第13章

    问题:本章主要讲软件的测试,介绍了各类测试的作用和功能。而对软件测试是为了让我们做出来的软件更加完美和更具竞争力。我们如何快速发现我们所做的软件存在的bug呢?

    我的回答:凡是不符合用户需求的,或者在使用过程中给用户造成不便的,都认为它是Bug。话虽然说的有点极端,但是现实就是如此。那么对于刚入行的软件测试新手迅速找出软件中的Bug思路如下: 1、尽快熟悉公司的产品业务 比如你们公司做ERP软件的,你肯定要迅速熟悉EPR的业务流程;比如你们公司是做法院软件的,那么你一定要熟悉法院审判案件的流程,只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷,你发现的软件缺陷才是有价值的。否则即使你能找到一些软件缺陷,那也是纯软件的缺陷,价值不大。

     

    第14章:

    问题:本章主要介绍了QA的主要内容,还有QA和Testing的区别。在Cost Control中,告诉我们要控制好自己的软件开发的成本,时间和金钱等。假如我们是个新的团队,第一次做软件开发,并不知道时间和成本控制在哪种限度,对于这一问题,我们要如何解决呢?

    我的回答:我觉得应该多看看别的团队做相似的项目所花的时间和开发成本,再结合自己团队的综合情况来决定的。

    第15章

    问题:本章讲了软件项目的会诊和项目的总结、回顾以及软件按时发布的各种招数,在Design Change Request中,对于砍掉功能这一招数,是因为有个模块不能实现,而我们现在是在做一款APP(四则运算),我们的特色功能是用户答对全部题后可以进入玩游戏的模式,但是进入游戏这款功能我们不能够实现,演示快到了,我们是否也是采用这种砍的招数呢,或者换成其他功能?

    我的回答:砍掉应该不好吧。我们可以试图换成其他功能来代替这个功能吧。如果砍掉了就会降低我们做的app在市场上的竞争力。

     

    第16章

    问题:本章主要讲了在IT行业中的创新,而处于当今时代,对于我们这类普通人来说想出一个创新的点子,是一件几乎不可能的事。书上说,创新的关键是技术还有要成为领域的专家,才能创新,只有这样才能创新是不是要求太高了?

    我的回答:我认为这是因人而异的,有些想法是自己不经意想到了呢?

     

    第17章

    问题:在职业道德这方面,假如我们团队有一个编程技术一流,是团队的核心,但是他职业道德不良,我们该如何处理呢?

    我的回答:先和他坦白一下,叫他改一下,实在不行我们还有两种方法,一种是继续忍,另一种选择离开这个团队,找新的方向发展。

  • 相关阅读:
    python 中的[::-1]
    python 闭包
    elastic
    文件上传进度条修改
    python decorator的理解
    同方爬虫--面试题
    js typeof
    浅谈软件项目实施
    数独·唯一性技巧(Uniqueness)-1
    数独二
  • 原文地址:https://www.cnblogs.com/ouqifeng/p/4602878.html
Copyright © 2011-2022 走看看