软工网络15个人作业4——alpha阶段个人总结
一、个人总结
（一）
（二）
感谢我们任劳任怨不辞辛劳以至上火的PM和10分钟路能走30分钟的后端同学。
二、回答问题
问题1：
结对编程中有两个角色：
1.驾驶员（Driver）：控制键盘输入。
2.领航员（Navigator）：起到领航、提醒的作用。
这两个角色还是可以互换的。
我的疑惑是，结对编程两个人的能力不一定在同一水平线上，每个人都有自己比较擅长的地方，那么，如果两个角色可以互换，是否说明双方都要读懂对方的代码。假设，一方负责前端设计，一方负责后端开发，虽然两种技术之间有部分相关，但是这意味着两方都要了解对方的代码么？
回答：
目前看来，假设两者分工为前端后端，前端不一定要了解后端的代码，但是后端需要了解前端的代码。前端在调试时需要应对后端的显示问题，也就是需要了解后端代码的“结果”。后端需要针对自己的需求对前端提出需求和改进要求。
问题2：
我看了书本P109这一段文字：
软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者同意并支持正确的项目方向。既然不能驱动团队成员，那只能靠外力来驱动了。
但是我还是不太懂，我的困惑是，这段文字应该是用来阐明‘老板驱动模式’的有理性，但是这段文字中的‘利益相关者’和‘外力’我认为意味不明。在我看来，软件团队的最大利益相关者是当前团队的领导，和软件的需求方。那么当这个团队不能说服利益相关者支持软件向较好的方向开发，只能靠外力来驱动，那么这里面的“外力”是指什么呢？
回答：
这个问题当时没有理解清楚，“外力”应该指的是这个团队的上层领导，一个尚未成熟的团队没有自己的独断能力，那只能借助比团队等级更高的外力来确定整个团队的前进方向和最终目的。
问题3
我看了书P99这一段文字：
软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
我的疑惑是，正如文中所说，“特工团队的成员”是在某一领域达到“专家”、“高手”的地位，那么是不是意味着这种人群与整个IT群体相比，所占比例较小。那么当一个公司在遇到棘手和紧迫性的问题时，能够找到足够多擅长这个领域的人来组建一个团队么？例如后文中举例的‘Y2K’问题，我查了相关资料，其中提到，
直到2000年将要到来的时候，人们才感觉到两千年问题的紧迫性。于是社会和政府都投入了大量的人力和物力来避免发生大规模的计算机灾难。
当时的相关从业人员并没有预先意识到事情的紧急性，或者忽视了可能到来的系统混乱。在我看来无论是医疗，金融，政府或者是国际组织在这件事件中所面临的急迫性是相等的，而事件之前并未组织相关团队。那么在危机当前各个行业都需要聚集一个对这个问题有深入了解的团队，是不是比较困难？
回答：
当初提这个问题的时候，是基于2000年的情况设想的。但是这几年科技发展迅速，与2000年的技术水平已经有很大进步，近几年出现的病毒风暴都能够比较迅速地解决。解决速度完全取决于工程师对原理的了解程度。互联网的发展使得技术人员在专业方面的交流更为方便，解决问题也可以多渠道，现在的技术水平已经能够解决和避免多年以前的历史遗留问题。所以我认为既然2000年已经过去了，就不要执著于过去的事情了。
三、再提问题
问题1：
关于这本书的排版，刚开始其实没什么感觉，用久了就有问题了。目录只写明了这一章的起始页码，个人认为用户体验不是很好。比如我需要找一个小目录，还要先从大标题进去再一页页翻。
问题2：
我读了书P163页关于用户调查问卷的文字，结合这次alpha阶段的问卷调查，发现了一些问题。根据以往做过的问卷调查，有的选项会设置“其他”选项，当用户选择这个选项时，发起者并不知道用户所指的“其他”是什么。虽然问卷有“其他”必填功能，即是选择“其他”就需要填写信息，然而出现了两极分化。细心的用户会根据自己的实际情况丰富这个备注，然而，这类用户大多是与发起者有密切关联的人群。当问卷扩散开，传播到与发起者并无联系的群，这个备注中的信息就会出现无用信息，就类似于“啊”这类的填个汉字就提交的。在我们做问卷的过程中，也有收到“为什么要必填好烦啊”这样的评论。作为问卷发起人，我们的初衷是想要获取更多的信息，因为我们在设计问卷的时候难免有想不到的地方，然而对于目标群众可能会造成困扰。
所以，问卷中的“其他”这类选项应该怎样设置？
问题3：
我读了书P12.4页关于“贯穿多种设备的用户体验”，有这个问题：现在手机有很多型号，手机屏幕尺寸也不一样，在设计的过程中，发现同一种排版方式在苹果产品上出现问题的频率更大些。华为产品的屏幕尺寸长宽比一般不会有太大波动，但是苹果的产品波动比较大。iPhoneX给人直观的印象就是屏幕较长。相同的布局对其他产品可能适用，但是在这种型号上界面美观就出了问题。我想问的问题是：前端不可能对世界上所有手机型号都设计对应的版本，那应该如何处理这种兼容性？
问题4：
这是一个不怎么正经的问题。也许是感慨在以前的项目中遇到了一个问题，就是PM（姑且算是吧）给了我一个设计草纸（真的很草），不需要实现和后端的链接，只需要把这些条条框框设计成具体的网页。但是那个原型（姑且算是），怎么看怎么哪里不对，就是肉眼就能预感到很丑的类型，无论是排版还是功能安排。并且是，给了菜单内容，但是没有说明具体菜单做什么的草图。因为情况非常特殊（不能描述），所以我能够对接的对象只有PM。具体要进行的设计虽然是完工了，但是因为没有和后端联系，要用到的框架类型我只能随意安排。不要问PM去哪了，PM布置完任务就消失了一个星期，下一次出现是要我交成果的时候。我问一个问题TA可能一天后回吧。遇到种问题句很迷惑。不期望得到回答，只想发泄一下。这种情况，只能保持微笑。再次赞扬一下我们尽职尽责的PM
问题5:
我大概能知道老师的初衷，通过团队项目感受软件开发的过程。然而实际上，我们水平有限。最后展示出来的成品也有一定限制，并不能达到完美，这是很正常的。本来只是想看一下同学的代码看看不同的实现方法，结果某些团队，提交记录或者源码都展示了一个事实，就是并不是自己写的代码，来源过于明显。
网络上完整的源码有很多，虽然不得不承认，把源码拷贝再运行的过程中可能会有很多问题，解决问题也是一个学习的过程。然而这个举动解决的问题时如何能让代码运行而不是如何去实现自己的设想。
并没有经历什么开发过程，反而是在应付作业。代码借鉴是正常的行为，然而也要有个度量，正常的过程是在借鉴中学习，但是这种源码照搬的行为感觉已经偏离了软件工程的意义。参与了全程，即使最终结果有bug有逻辑错误界面不够优美什么的，如果是自己写的代码出了问题自己承担问心无愧。和队友谈论过也决定不是很服气。只是想问，这门课对于代码借鉴到底有怎样的要求？这是一个开发的过程，对于从开始到结束都绞尽脑汁写代码改方案的同学真的公平吗？