回答自己的提问

• 第一章（概论）

   （问）：在1.2.5节中，谈到了什么是好的软件？同时，我也很疑惑，因为Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性，那么是不是软件没有Bug就是好软件呢？

   （答）：我觉得不然，因为有实际用处的同时又是完美的软件，在这个世界上是不存在的。就算微软很自豪的window8系统也会有偶尔出现蓝屏的现象，但是这并不会直接影响到微软公司的能力，也不会直接影响到window8系统的可用性，因为你的RP是由你的程序质量决定的，所以我个人觉得软件不存在完美，总会有顾客的客观或主观因素而感到不满意，我们不能迎合所有的市场需求，最重要的还是考核市场的主流需求而不断完善自己跟团队研发的作品。

    还有，对于一个学生，我觉得自己努力做出来或者与团队一起努力做出来的项目或软件是就一个有价值的软件，不知道对其他人是否有价值，但我觉得对我个人来说很有价值。

•  第二章（个人技术和流程）

   （问）：在2.3节中，对比了大学四年级的学生和工作三年的软件工程师的个人项目耗时，表中可以明显的发现在需求分析和测试这两组数据上，工程师会比大四的学生用时多，而在具体编码上大四学生是比工程师花费的时间多。那这样是不是就一定说明大四的学生比软件工程师弱？

   （答）：我觉得不然，软件工程师是比大四学生多读了3年书，多工作了3年，两类人所处的环境跟所经历的东西不同，所以两个人任务完成的质量要求也就不一样，我觉得，按照目前来说，大四学生在对软件工程运用的熟悉程度上或许还及工程师，但只要经过刻苦的锻炼，丑小鸭也会变成漂亮的天鹅的！

    还有，虽然我们现在还是大学生，但我们每一个人都有机会去接触很多软件项目知识，我们每一学期都会有大大小小的专业相关的项目要做，如果我们学生懂得利用的话，这些就是我们增长社会工作经验的好途径。

• 第三章（软件工程师的成长）

   （问）：高级软件工程师，对于我们现在的水平来说，是不是就触不可及了呢？

   （答）：其实不然，我们现在还年轻，还有很多时间去学习、去实践，在通往高级软件工程师的路途上，我们可以考相关的证书来获取理论上的技能，然后去各相关的单位上实习来获取经验，最后通过自主研究或团队开发来进行实践，进而开发大脑和提升自己的动手能力。

    同时，我们要时刻对自己进行自我评估。绝大部分的软件工程师都不是技术天才，很多都是后天形成的，我们要多对自己的能力进行评估并作出及时的改进，然后通过不断的学习，把那些低层次的问题都解决了，变成不用经大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。

• 第四章（两人合作）

   （问）：在4.4节中，强调了代码复审的重要性。那我们应该以怎样的情况和环境下进行复审呢？

   （答）：代码复审有自我复审、同伴复审和团队复审，在软件工程中最基本的复审手段就是同伴复审。复审者是要通过发现问题来确保软件质量的，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着自己点头，所以，找到一个适合自己的同伴来一起工作是很重要的，让两个人在驾驶员和领航员的角色中互换，进而提高双方的能力水平。

    我很感谢与我结对子的队友-方俊杰小朋友，我觉得组队完成作业的话，每个人就应该要付出努力才行，如果在团队里做拖油瓶，那还有什么积极的意义？幸好我跟我的结对子队友都是认真负责完成自己工作和团队项目的人，我跟他从两个人的结对子合作到四个人的团队合作都结为队友，我们两个都在合作中慢慢磨合和适应自己和对方身上的优缺点，为的是对自己的项目成果有一个好的交待。

• 第五章（团队和流程）

   （问）：是不是说只要能组合在一起的就是组成了一个团队了呢？

   （答）：其实不然，软件团队有各种形式，适用于不同的人员和需求。适合自己的团队才能共赢！

    一个好的团队流程能把冲突的积极方面（各自尽力把自己的工作做好，说服别人）释放出来，而避免消极方面（因为冲突而产生的消极、抵触情绪等）。我们不能因为说有了团队的队友就放松对自己的要求，因为每一个人的工作质量会直接影响到最终软件的质量，当所有的个人高质量工作加起来才可以达到一个优秀的团队高质量工作项目。

• 第六章（敏捷流程）

   （问）：在6.1.1 中有谈到敏捷的开发原则，其中有一条说“经常发布可用的软件，发布间隔可以从几周到几个月，能短则短”，那么，是不是可以把问题对应到我们平时电脑或手机上的软件更新？

   （答）：相信大家都会遇到这样的一个困惑，我们的电脑和手机时不时就会弹出一个框来提示我们要更新系统软件的版本，可是，版本更新得如此频繁，那些软件需要我们更新的软件，如果我们更新完了，这个软件就真的是焕然一新了吗？就会有更好的体验效果了吗？答案是不一的，因为作为使用者的我们，从实战可以得出，有时候一些软件的更新只是很微小，更新完后几乎发现不了有什么大改动，此时就会让有些用户觉得该公司是在“骗流量或者骗点击量”。这些都因人而异，因为有时有的软件更新真的可以使得用户使用更加方便或有更大的视觉冲击震撼。

    但是，其实有很多软件的更新都是在原基础上添加很多新功能的，或者补充原来不够完美的功能，所以，一般在有WIFI的情况下，用户还是会选择去更新软件的。

• 第七章（MSF）

   （问）：什么是MSF？MSF规划得如此合理，那么是不是就可以随意而安了？

   （答）：MSF它其实就是微软推荐的做软件的方法——微软解决框架方案（Microsoft Solution Framework，MSF）。答案不言而喻，MSF在世界范围内由微软顾问咨询部及微软认证的培训中心提供培训，它在不断发展，它是一个框架结构，它不是一成不变的。相反，MSF会随我们从微软的客户和合作伙伴那里的学习而不断的发展和完善，新的思想和准则会不断地被引进MSF。这些发展将适应技术的更新、商业需求的变化，并支持构建更好的软件解决方案。

    MSF注重团队模型，它展示了如何组织项目队伍，在时间控制和连续不断发展计划的要求下，有效的交付系统的解决方案。它描述了六种基本的角色（产品管理、项目管理、开发、发布管理、测试、用户体验）。在MSF团队模型中，任何技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。任何一个角色都无法实现其目标，都将危机整个项目。因此，每个角色都被认为是同等的重要，重要的决定都要共同做出。

• 第八章（需求分析）

   （问）：构建一个软件系统最困难的工作是什么呢？

   （答）：答案无疑是要—确定要构建什么。其他任何工作都不会像这部分工作那样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。因为需求涉及很多方面：功能、性能、运行环境、界面等等。

• 第九章（项目经理）

   （问）：如果项目出现风险了，是不是就是项目经理的责任了呢？

   （答）：那当然不是，一个项目是属于一个团队的，风险主要从不确定中产生，成功的项目经理是关注风险作为主要的关心的事。所有影响項目的问题总是以这种方式或那种方式从风险上产生。一个好的项目经理可以显著地减少风险，通常通过坚持开放的沟通的政策，以保证每一个重要的参与者都有机会表达自己的意见和关心的事。所以，项目经理一定要有号召力、交流能力、应变能力，还有，项目经理还必须自信、热情，充满激情、充满活力。

• 第十章（典型用户和场景）

   （问）：如何判断一个场景的典型性及优先级？

   （答）：这需要团队在前期达成一个统一的意见和标准，所以制订评价纬度是整个研究中最重要的一个环节。评价纬度不是固定的，每个产品，每个时期会有不同的标准。根据制订好的评价纬度，相应的挑选场景的总原则也就产生了。

• 第十一章（软件设计与实现）

   （问）：一个项目是一个整体的，每一个人所负责的每一个模块都必须关联起来才能成为一个整体，例如我的主页完成了50%后，为了查看整体效果，发给队友与他的模块连接起来，如果对方在我的程序上修改了部分，然后同时我也继续编写我剩下的内容，双方都在我那个原本完成了50%的进度模块上做了修改，那接下来的工作，到底用谁的？

   （答）：实际上两边的修改都要用上，然而我不可能等对方修改后再继续做下一步工作，而对方也不可能等我完全100%做完我负责的模块后才查看修改或连接，因为这样会导致工作效率大大的下降。这个我觉得这个仿佛有点像我们学习操作系统时的那个售票系统，几个窗口同时都要给顾客售票，总得有一个机制管理剩余的票数，因为不可能能同时几个窗口成功售出同一张票。

    我们这次的项目，针对这个问题，我们所使用的方法是：大家约在一个自习室一起合作做，当我完成一个部分后，立马把这部分的代码拷贝给队友，让队友去继续完成后续阶段的内容。

• 第十二章（用户体验）

   （问）：在众多竞争产品中，用户为什么会选择你的产品？用户是如何与你的产品发生交互的？他们怎么用？在使用过程中有出现什么问题吗？

   （答）：用户在使用软件时，其实第一印象是很重要的，这很大机会会影响到用户是否会把该软件进行二次使用，但这也并不意味我们设计软件只设计一个外表光鲜的东西，毕竟一个外表漂亮而没什么实际用处的空壳是没有多大的用处的。我们要多从用户的角度出发，用户体验设计时要尽量降低用户的认知阻力，同时我们也要多了解自己写的软件，而我们的心里、技术能力和一般用户有很大差别。

• 第十三章（软件测试）

   （问）：当测试时发现好多Bug该高兴还是该忧愁？

   （答）：并不是说测试出Bug后该软件就是不好的软件，因为测试就是为了证明程序有错，而不是证明程序无错误。一个成功的测试是发现了至今未发现的错误的测试。当我们发现程序有Bug时应该感到欣慰的，因为毕竟是自己发现的，自己还有时间、机会去完善，一旦是被用户发现先，那就要被投诉咯~

• 第十四章（质量保障）

   （问）：很多人都问我们的项目进展得怎么样了？能不能演示？我们该不该拿着半成品去给朋友去体验？

   （答）：一开始，我们是拒绝的，因为我们队真的想把最好的作品展示在大家面前才会没有那么快就把半成品拿出来。但是后来意识到，成功是要在发现问题的基础上去实现的，所谓当局者迷旁观者清，让部分用户去事先体验一下半成品或速成品的话，其实是可以加快项目的进展的。像微软公司即将推出的Windows10系统，听说功能很强大、很吸引人。虽说Windows10未正式发布就受如此多的人去追捧，但微软公司还是实现推出事先体验Windows10的体验者名额，让用户先去体验，再让他们体验者去感受和发现可能存在的漏洞或错误。

• 第十五章（稳定和发布阶段）

   （问）：用户的真实反馈会不会很刁钻？

   （答）：一开始我们很怕用户的真实反馈会很刁钻。但后来发现：经不起讨论、批评的项目还有什么进步空间可言！

• 第十六章（IT行业的创新）

   （问）：大家都喜欢创新，而好的想法就会赢。那怎么才会有好的想法来源？是平常多积累？多看新闻？先发者可以赚得新眼球，后发者可以储备更多的纠错过程。那我们究竟是当后发者还是先发者好？

   （答）：好的想法其实可以从生活中的方方面面来获取，只要我们足够细心、用心。先发者和后发者各有各的优势，根据不同的现象情况可以做出对应的选择。

• 第十七章（人、绩效和职业道德）

   （问）：我们又还没有真正的踏出社会，我们靠什么储蓄社会经验？

   （答）：只要细想一下，踏出社会要靠做工程或项目来积累经验，而我们现在在读生正在做的项目不也就是可以积累当作积累经验了吗？