zoukankan      html  css  js  c++  java
  • 个人阅读作业3

    读《移山之道》所提出的问题:http://www.cnblogs.com/peilei/p/4027864.html

    阅读软件开发书籍的一些体会:http://www.cnblogs.com/peilei/p/4093899.html

    一、问题的解答

      第一个:书中衡量员工工作质量中(DEV)中其主要衡量两个指标,一是check in 的质量,也就是签入破坏构建的次数,二是功能是否按期完成,如果延期,是否提前交流,我想知道是不是还会有其他灵活的衡量指标?

      在软件开发人员的绩效考核指标设计过程中,如果过于强调结果,往往会使研发人员沪市公司的组织纪律和秩序;如果过于强调行为,则使研发类人员关注能力,会引导员工只注重做事的方式,而忽视研发的结果。就像日常工作中,可能会有一些研发类人员不遵守公司制度,比较有性格,但却往往能向公司研发部提出比较好的idea,工作业绩也比较突出,而另一些行为上遵规蹈矩的软件开发人员却不能为公司提供新的发明,对公司没有实际的贡献价值,从这两种软件开发人员的行为中我们能够总结出来,员工工作质量的衡量标准应该以结果考核为主,行为考核为辅,题目中的两种指标,一个check in的质量,一个功能是否按时完成,这些都是从结果上进行考核的;所以我认为应该再加入一些从过程中进行考核的标准,给予一些工作努力但是结果不是很突出的职员一些鼓励,因为只从结果上说的话,有可能打击一些工作能力弱一些的但是一直在努力学习的职员,而且因为工作的难度可能会不一样,所以最后绩效考核应该不能只以结果考核来论断。

      第二个:在现在社会,人员流动是很普遍的问题,怎样解决人员流动带来的团队协作之间的一系列问题?

      在之前的第一阶段结束之后,老师要求每个团队选出一个成员进行转会,当初选择的时候,确实蛮纠结,因为每个团队都不会想让自己团队的编程主力转会到其他团队,这样对自己团队的任务进行会是很大的损伤,同样在社会中,如果一个团队的的灵魂人物跳槽,同样会给这个团队带来重创,而有时候人员流动是不可抗的,这时候为了避免人员流动给团队带来的损害过大,必须要求团队成员之间的沟通非常紧密,开发的各个环节之间最好有相应的文档材料备份,这样即使是一个成员离开了,新来的成员也能够根据留下的文档材料尽快的了解团队的工作,而且如果团队之间的交流足够紧密,团队的其他成员会对离开的成员的工作有足够的了解,能够根据自己的经验指导新来的成员。每个成员都要有明确的工作定位,负责的工作也要根据工作定位尽量分开,这样团队任务的交接能够更加顺利。

      第三个:如何在一个软件开发团队互相还不是特别熟悉的时候快速开展开发工作,如何分配团队成员之间的工作,如何处理成员对自己的分工的不满?

      我们团队刚开始的时候也是从来没有从来没有过Android开发的经验,不过相对好的是我们团队的成员都是自己班级的同学,所以说彼此之间很熟悉,对彼此的编程能力的了解也相对多,所以我们在开发开始的阶段分配任务是由编程能力强的同学担任主力,然后带一个稍差一点的同学,两个人一起负责一个模块,任务划分开之后,就由这些小的分组自己商量选择任务的分配,我认为,如果是一个彼此之间不熟悉的团队开始开发任务时,首先要对每个成员的强项实力进行一个大致的评估,明确每个人最擅长的部分是哪里,发挥其所长,将任务分配开之后尽量按照每个人擅长的不同部分进行选择,这样能够最大程度地避免分工选择之间的冲突,而且在开发过程中也能够防止成员因为自己任务的分配产生抱怨情绪。

      第四个:在软件开发的后期如果出现了很多bug,怎样追究团队成员的责任,又如何修改?

      首先,一个程序中必然存在bug,不过是多少以及严重程度的差别,所以,尽力测试软件,发现其中的bug是软件开发过程中非常重要的一部分,在我们做北航MOOC客户端的过程中,首先是在DEV进行编程的过程中就出现了许多的bug,这时候DEV就要对自己之前写过的代码进行测试debug,修改其中存在的问题;其次,在软件的前后端进行合并的时候,合并之后也是bug的多发期,这个时候就要前后台一起合作,把中间代码的接口搞清楚,debug是其中很重要的环节,找出bug出现在哪里,并且根据bug的位置进行追溯,追溯到个人,这样可以使队员编程的严谨性提高并且提高他们的代码质量;最后测试人员进行测试的时候也会发现各种隐蔽的问题,就比如说我们软件中一个网络异常的问题就是在测试的过程中发现的,还有有的时候界面跳转界面的内容回出现混乱,而这些情况是在特定的情况下才出现的,所以这个时候就要测试人员擦亮眼睛,找出bug之后交给开发人员进行debug修改,这样循环往复,一款软件就会逐渐的变的完善。

      第五个:在软件测试到时候应从哪些方面考虑?如何选择测试方法与工具,怎样才算测试完成?

      我认为软件的测试要始终贯穿于软件开发的过程中,并不是说等到开发人员把软件完成之后测试人员才开始进行测试,应该是在开发人员每写完一个模块就可以交给测试人员进行测试这个模块的功能,保证模块中不会出现隐藏的问题,这样对代码质量是一个很大的保证;接下来在软件初步完成之后,测试人员先把各个模块的功能测试完毕,再从整体的角度进行测试,这个时候出现的问题一般都是模块之间的接口传递数据出现的bug,我们团队选择的测试工具是Testin平台以及百度的云测试平台,这两个平台都能够提供对软件全方位进行机器测试,并且记录也比较完善,每个出现问题的机型都会有相应的截图反馈,如果通过的机型大于90%,可以认定程序不存在特别严重的bug,深度遍历测试可以把软件中的每个项目都测试一遍,这项测试的结果还是有一定的参考性的,但是同样不能盲目相信,毕竟机器并不是人手工的测试,所以我们的软件测试人员这时候就要模拟各种各样的场景比如手机电量不足,信号差等情况下对程序进行手工的测试,只有在手工的测试都通过的情况下才能算是测试完成。

    二、新产生的问题

      1、在M1阶段的开发过程中,可能是由于大家对Android开发都不熟悉,并且团队中没有一个对全局把握比较好的同学,所以当时任务的分配不合理,造成一部分同学积极性差,做的工作比较少,另一部分同学一直在干活,但是由于难度比较大,进度也很缓慢,所以说软件开发团队中对于任务的分配是一个很重要的问题,必须要有一个切实可行的方案来执行,保证每个成员都付出自己的贡献。

      2、团队之间的交流必须畅通,及时汇报自己工作的进度,这样PM能够对整体项目进度有一个宏观的把握,如果交流不通畅,可能有队员因为一个难题受阻,不能够解决,别的队员也不知道,这样就会拖慢整项工程的进度,而如果交流通畅的话,大家可以就这个问题提出自己的意见,问题被解决的可能就会大大提高。

      3、敏捷开发过程中每天的scrum meeting必须作为一个硬性的指标来执行,时间不必长,主要是为了起到一个监督的作用,还有就是让PM对进度的把握更好,及时的调整任务。

    三、学到的知识点以及新的体会

      首先经过这一个学期,我们的的确确走了一遍软件开发的过程,对整体的过程变得清晰了许多,对其中的许多要求也明白了很多,这都是这个学期的收获,学习的过程就是一个遇见问题解决问题的过程,在这个过程中走一遍的我们确实会有很多自己的理解和体会。

      1、需求分析

      当时我么团队的需求分析即北航学堂NABC是我写的,当时确实查找了很多关于北航MOOC的资料,从不知MOOC为何物到熟记很多网络公开课的站点,毋庸置疑,MOOC课程确实是网络发展的一个方向,网络拉近了人与人之间的距离,也使得学习变得更加简单,并不仅仅局限于到学校找老师,自己在网络上寻找资源进行自学也是一个很重要的途径,北航的MOOC课程就是在这个环境下诞生的,说老实话,北航的MOOC课程和其他的站点像coursera,清华这些的差距很大,用户量也确实没办法比,不过既然学校要做这个平台我们自然是尽可能把它做好。如果上面的资源比较多的情况下,确实可以作为复习的一个好门路。就软件开发来讲,这个阶段让我认识到做需求分析的时候一定要综合各方面的因素,比如说我们当时就不知道北航MOOC的课程只有仅仅13门,先不说用户量,资源的总量就是一个硬伤。

      2、设计阶段

      软件的设计阶段是为软件开发过程打基础的重要阶段,在这个阶段要做的主要就是工作进度的计划以及任务的分配,可以这么认为,一个好的计划是成功的一半,有好的计划之后实施起来的难度就更小,拿我们当初的例子说一下,我们就是因为开始的时候的计划不行,根据学长讲的把程序大致分成了三个部分,网络连接、数据处理以及UI设计,然后三部分分给了三个二人小组,后来就发现网络连接没有做完的时候根本没办法进行数据处理,而网络连接又因为学长那里的服务器接口一直没给我们,所以进度一拖再拖,导致我们M1阶段的失败,所以,设计阶段一定要把后期可能遇到的问题提前想清楚,把任务分配的细化一下,不能把程序像一块馒头一样简单拆分开,你啃一块我啃一块,特别是在队员的开发经验比较欠缺的情况下。

      3、实现阶段

      实现阶段就是根据计划进行项目的开发,这个过程执行得好不好,直接决定了项目最终的成败,我认为这个阶段最重要的就是这个团队的执行力,执行力足够好的话,团队的成员能够按时完成PM分配的任务,即使不能完成也能够付出足够的时间去学习体会,这样这个团队的实现阶段是不会落后的,而如果一个团队的成员比较拖沓,PM也没有及时进行敦促,这样大家一起向后拖,这样的结局肯定不会好,所以作为一个监督手段的scrum meeting就显得尤为重要,按时开当天的scrum meeting,成员报告自己当天的进度,这无疑是一个很好的进行督促的手段,所以说敏捷开发的手段中还是很有科学依据在里面的,PM的作用在这个阶段也凸显在很重要的位置,并不是作为一个记录者,而是应该作为一个指挥者,这对PM的个人能力是很大的考验。

      4、测试阶段

      测试阶段是保证软件质量不可或缺的一环,好的测试能够发现软件中存在的各种各样的的问题,能够使用户获得更好的用户体验,不至于使程序出现各种问题。我们的软件测试使用了Testin以及百度的云测试平台,这是一个很好的测试工具,能够帮助开发人员试验在各种机型上面自己的程序是否能够很好的运行。同时测试人员也要在自己的Android设备上对程序进行深层的遍历测试,毕竟网站上的机器测试可能不能够百分百真实的反馈测试信息,测试的时候要模拟各种情况,将发现的问题反馈给DEV进行修改,测试人员和开发人员之间的密切配合也相当重要。

      5、发布阶段

      发布阶段即软件已经修改掉目前所能修改的全部bug或者是有些不重要的不好解决的bug留待以后解决,我们在这个阶段也注册了很多开发者平台,比如豌豆荚,91,小米开发者平台等等,这些平台能够给开发者展现自己才华很好的环境,不过感觉上面的审核进度真是够慢的。

      6、维护阶段

      我们目前就是处于这个状态,因为还是会从程序中发现一些问题,就进行不断地小修改,修改之后等到积累一定时间之后就在网站上发布新的版本。

      

  • 相关阅读:
    iOS中Zbar二维码扫描的使用
    SOJ 1135. 飞跃原野
    SOJ 1048.Inverso
    SOJ 1219. 新红黑树
    SOJ 1171. The Game of Efil
    SOJ 1180. Pasting Strings
    1215. 脱离地牢
    1317. Sudoku
    SOJ 1119. Factstone Benchmark
    soj 1099. Packing Passengers
  • 原文地址:https://www.cnblogs.com/peilei/p/4215810.html
Copyright © 2011-2022 走看看