提问回顾

问题博客链接

对曾经的问题进行解答

  1. 第五章中开始讲了团队和非团队的区别,之后讲的各种模型可以看出团队中分工的重要性(开发人员和测试人员以及各种其他人
    员相互协调才能做出好的软件)。软件开发过程中,开发人员和测试人员各司其职。但是,测试人员开始工作是在开发人员完成代码
    之后,这两者之间是不是应该在代码完成之前或者是在代码完成之后的测试工作中就应该有一些交流或者是合作?测试人员在开发人
    员写代码的时候是要干什么呢?开发人员在测试人员测试的时候是要做什么呢?

经过了团队项目,对测试人员的工作有了更加深入的了解。测试人员在写各种测试之前要搭建各种测试环境、找各种辅助工具进行测试。这些事情在开发人员进行开发的时候也是同步进行的。开发中,当一些功能实现了之后,测试人员就要进行场景测试、单元测试,这些也并不都是在整个项目都开发完成之后才进行的。开发人员和测试人员之间的交互肯定是有的。测试人员如果对代码中一些比较奇怪的地方提出质疑,开发人员要测试人员解释。

  1. 第八章 8.6 节讲到了如何对项目进行计划和估计,第九章中讲到了PM的各种职能,PM要带领整个团队进行开发,所以,理想情况下,
    项目经理应该是要对整个过程都有一个比较清楚的认识,比如说在什么时间点要完成什么样的效果(也就是估计),但是,在我们课堂
    上临时组建起来的队伍,好多同学第一次担任经理这样一个角色、开发人员的好多技能都要现学的情况下(按照书上所讲,这种情况下
    很难有一个较精准的估计),如何对一个团队的开发流程有一个比较详细的掌握呢?

在我们课上,每个任务都有时间节点,所以我们只要按照这个时间进度来走就行(真实的软件开发中相信也会有进度表)。在我们的项目中,因为采用的是敏捷开发方式,每天都要有一个“例会”,在这个会上,PM能够对每个人昨天的任务做一个了解,进而更新任务进度表。团队项目中,最开始遇到了一个问题,没有在规定时间完成PM发布的任务,PM就适当延长了这个任务的时间。

  1. 第八章中 8.2 节讲到 “很多人和很多机构都是软件的利益相关者,软件团队在分析软件需求是要考虑这些利益相关者”,并且提到我们
    团队中的好多人都是软件的利益相关者。在对用户进行需求调查时,如果团队中对一种功能的喜好上出现了近似等比例的分歧,书中虽
    然提到了要给机会让工程师提出需求和一件,但是如果时间、精力有限的情况下,从何角度出发做一个合适的选择?

在对用户的需求进行分析时,团队中的人员确实会产生分歧。团队项目的第一轮迭代,我们对实现哪些功能产生过分歧,因为当时还是设计阶段,还没有真实的用户,所以做决定的依据相对来说都是自己对这个软件的个人蓝图。最后,我们还是决定把这些功能的选择放到后边进行讨论决定,先着手实现我们认为没有分歧的,这个软件能够被用起来所必须的条件。后来,随着实践的进行,对这个软件也更加了解,基于对技术的看法等等因素,逐渐达成了一致。其实这也体现了敏捷开发的一个优点:每天都要进行交流,每天都要一起思考,自然也就容易汇集大家的思想。

  1. 第八章中 8.5 节讲软件功能的定位,可以看到,软件的功能分好多种,如果在实现了必要功能之后,团队中出现了对性能的优化或继
    续扩展一些辅助需求分歧的情况下,应该如何进行抉择?

在团队项目和结对项目中都出现了这样的情况。从这两次的经验来看,我更优先于实现功能性、安全性的扩展,因为一个稳定的版本在我看来是发布所必须的。但是这并不是说UI和用户交互、优化之类的不重要,可能这跟软件的种类是有关的。如果一个软件更注重用户体验,相应的,肯定优先考虑交互。

  1. 书中第七章中的第三节讲到MSF团队模型 在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成
    功的项目
    书中下面也提到了团队中每种角色都有自己特定的工作,就像是开发人员被认定的质量就是程序能够正常执行,功能正常
    实现.....书中也说每种角色之间的质量目标可能会有冲突,所以,每种角色的质量目标应该是如何形成的?

每种角色的质量目标确实是不相同的。对于开发人员来说,首要质量目标就是实现功能,然后才是这个功能的易用性;对于美工人员来说,质量目标就是软件的界面做的美观,符合这个软件的定位;对于测试人员来说,他们的质量目标就是希望通过他们的代码没有错误.......他们的质量目标都是和自己的所做的工作和工作目标息息相关的。

  1. 书中第二章 2.3节个人开发流程 中讲到了个人开发中有一些复审的流程(代码复查),根据 “百度百科”中 个人软件过程 对代码复审
    的流程来看,虽然是个人开发,但是自己复审自己的代码应该也是可行的,可如果是在有限的时间内,要完成一个相对完善的功能,
    个人软件开发中的某些耗时的过程是不是可以简化?

经过个人项目,个人认为,简化是可以,但是一定要确保质量。现在针对各种任务的可用工具很多,像是测试,可以写出测试脚本之后就让机器自动测试。

以上即是自己对之前问题的一些见解,通过一个学期的学习、实践,对之前的问题都有了一些认识并得到了答案。

新的问题

  1. 在项目开始之前,如果较好的选择出适合这个项目的技术?
  2. 如何将我们的软件更好的推广出去?
  3. 如果得到不同的用户反馈,如何进行抉择?

每个阶段学到的知识点

  1. 需求:学会了使用NABCD进行用户需求分析。
  2. 设计:进行实现之前要设计代码规范。
  3. 实现:最开始做的时候,不要想着把所有的都实现,先做出一个能用的版本出来。
  4. 测试:如何做场景测试、单元测试。
  5. 发布:发布之前要进行各种测试,一定要确保软件正常运行。
  6. 维护:发布之后要收集用户的反馈,并根据用户的反馈对软件做进一步的修改。

posted on 2018-01-13 22:39  AWwH  阅读(159)  评论(0编辑  收藏  举报

导航