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

Posted 2020-09-18

一、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的时候才做完，这篇博客就是如此。一个真正优秀的工程师是有着超强的积极性的，是勇于承担勇于解决问题的，我离这个目标很有很远的距离，说来惭愧啊，但我是个要强的人，我会正视自己的问题，勇于解决问题，提高自己。