首页 > 代码库 > 个人作业3---个人总结

个人作业3---个人总结

一、alpha 过程总结

       1.作为我们小组的组长,第一阶段的冲刺让我收获良多。虽然我们并没有把我们原先计划的卡片做完,但在这七天的实际冲刺过程中,我们又发现了许多我们在冲刺之前所没有预想到的功能。因此,从实际上来说,其实我们是超额完成任务的,而且是超了不少;

       2.在我看来,我们小组在alpha阶段冲刺过程中最正确的选择就是坚持每天收集用户的最新反馈。因为我们在每天完善功能之后,都会继续把完善好的四则运算软件发给一些朋友使用,让他们继续帮我们测试、提建议,所以我们的APP实际上每天都在进步,每天都在往更加符合用户需求的路上前进。而且,在这个反馈的过程中我们还发现了许多新的功能点,这些是我们最开始没有想到的然后在做的过程中又慢慢摸索到的,这也使得我们的软件越来越完善,越来越能够满足用户的需求;

       3.但反过来说,我们本次冲刺的一大弊端就是早期的用户需求调查不到位,先前的需求分析有点过于想当然,没有落地去考察真正需要的对象,造成我们一开始对这个软件的功能定位存在偏差,导致之后在不断完善的过程中产生了大量本可以避免的工作。好在老师们及时指出我们需求分析的漏洞,让我们下定决心去切实落实需求分析,我们才能找到小学数学老师以及个别家长对我们提建议,才有了我们每天完善的四则运算APP;

      4.就我个人而言,本次冲刺我还是十分满意的。本次冲刺我们已经基本上完成了最开始时设想的功能,出题、复习、计时功能都已经实现,同时还把原来限定的1~10以内的题目扩展到任意数量的题目。错题复习方面,即使还不能做到生成任意数目,但已经可以实现在200道题目以下的任意数目,这个对于实际使用中其实已经是够用的,但我们还是会继续完善。我们在用户调研的过程中还新增了弹窗提醒的功能,这可以帮助用户对自己的水平有更准确地定位。总而言之,我对我们团队第一次冲刺的成果非常满意,我们会继续努力的。

二、对软件工程的五个问题

1.关于“结对编程”

      《构建之法》书中4.5章节中对结对编程形式有以下的形容:

    “在结对编程模式下,一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前,面对同一个显示器,使用同
一个键盘、同一个鼠标一起工作。”

      然而我现在仍然不是太理解“结对编程”这个编程模式,我承认这种模式有它的优势,但不可否认的是,这种编程模式有一种浪费资源的嫌疑。大部分同学都跟我一样,在刚刚开始接触结对编程的时候都以为是两个同学为一组,分别完成实现不同功能的代码,然后汇总在一起,完成整个程序。后来在老师再三强调之后才发现,原来是两个人同时做同样的事情,一个做一个审。但是我真的觉得这个编程模式很浪费资源,明明两个人可以各做一半,为什么非要两个人一起做一样的东西呢,这不是浪费时间吗?而且像我们以前的课程设计或者说IT企业里的小团队,大家更多的都是使用明确分工的工作模式,一人负责一个模块的内容,很少听说哪个团队的每个人都在一起完成某个单项功能,这非常有可能使效率变得非常非常低下。

2.关于“PSP”

      《构建之法》书中2.3章节中对PSP有以下的形容:

  “PSP的目的是记录工程师如何实现需求的效率,而不是记录顾客对产品的满意程度。”

      就我个人而言,之前的几次个人作业中都做过PSP表,但我并不知道PSP的作用在哪里,或者说我做了三四次的PSP表我却并没有得到一点点收获。在我做完PSP表的时候,也并没有感觉到效率的提高,而是做到哪算哪,跟这个表没有丝毫的关系。

3.关于“换人机制”

      为什么要换?换人的意义在班级当中还存在吗?我个人认为在班级里的换人毫无意义,本次的换人根本就是为了换人而换人,对项目的进行一点帮助都没有,甚至还有负面的影响,简直是百害而无一利。首先,各个团队的换人形式可笑,有抢红包、掷骰子等等,选出的人根本就是随机的;其次,各个团队都保留了自己的核心成员,因此无论加进来的是谁,也只是来写写博客的,划划水的,根本达不到锻炼的目的;最后换人机制搞得同学之间有点尴尬,换掉谁都不合适,因此大部分团队都选择互换。

4.关于“代码复审”

      《构建之法》书中4.4章节中对代码复审有以下的形容:

代码复审的正确定义:看代码是否在“代码规范”的框架内正确地解决了问题。
代码复审的形式有:自我复审、同伴复审、团队复审。
软件工程中最基本的复审手段,就是同伴复审。

      我想请问一下,同伴复审跟团队复审有什么区别吗?我个人认为团队复审跟同伴复审有很多相似的地方,为什么不考虑把它们合在一块呢?只分成自我复审和他人复审不是更简单直接吗?

5.关于“其实还是人的问题”

      《构建之法》书中17.2章节中对“其实还是人的问题”有以下的形容:

    “P={做事的,不做事的,不让别人做事的,P4=做假的事的,P5=假装做事的}”

      在一个团队中,肯定难以避免有个别完全打酱油的人,对于这种人应该作为PM来说应该怎么办呢?

三、自我评价

 

        以下是我根据邹欣老师的“自我评价表:http://www.cnblogs.com/xinz/p/3852177.html ”得出的自我评价:

1-8

E

D

D

B

B

D

D

D

9-16

C

C

D

D

C

C

D

C

17-24

A

C

D

B

B

C

D

D

25-32

B

C

B

C

D

D

B

C

33-40

C

D

B

C

C

 

 

 

 

自我反思:在做完这个自我评价表之后,我更加清楚得=地认识到自己就是一个“假工程师”,不爱打代码,不爱优化算法,就喜欢拖延,把任务堆到deadline的时候才做完,这篇博客就是如此。一个真正优秀的工程师是有着超强的积极性的,是勇于承担勇于解决问题的,我离这个目标很有很远的距离,说来惭愧啊,但我是个要强的人,我会正视自己的问题,勇于解决问题,提高自己。

 

个人作业3---个人总结