最后一次团队作业-总结

这个作业属于哪个课程	https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1
这个作业要求在哪里	https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1/homework/3379
团队名称	都成
这个作业的目标	将这个学期的学习做一个总结

队员列表：

201731062234	薛磊
201731062230	李林
201731062231	燕泓达
201731062232	陈东
201731062229	沈瑞琦
201731062233	刘平
201731062117	蒋庆

正文：

薛磊（201731062234）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。　　

第一次博客作业链接：https://www.cnblogs.com/MlllXavier/p/10562307.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

问题一：

　　来源：2.2 效能分析工具——P31“先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方法进行详细分析”

　　问题：我认为用抽样的方法找效能瓶颈的所在有点困难。首先，使用抽样的方法是程序在特定的输入下调用的函数，这时候找出的调用次数较多的函数不具有普遍性。如果下一次输入不一样，另一些函数调用的更多，那么只优化特定情况下的代码块不是一个很优的方法。

　　答：通过深入的学习，我认为，应该利用效能分析工具先运行一下，找出运行次数很多的几段代码，然后在这几段代码上做优化，效率是最高的。

问题二：

　　来源：4.2.6 命名——P67“避免可要可不要的修饰词......可以问自己，如果在变量名中把这些字去掉，程序会更加难懂么？如果答案是否定的，那么可以把这些修饰词去掉。”

　　问题：我认为“问自己”不是很客观。一方面只是自己认为去掉后不会使程序更加难懂，而别人读的时候可不一定这么认为；另一方面只是现在的自己认为去掉后不会使程序更加难懂，而以后的自己不一定这么认为。我认为应该有一些特定的规则来命名，而不是模棱两可的，有时候自己也拿不定主意。

　　答：应该在开始编写代码前就将整个的命格规则与代码规范确定好，使每个命名都十分清晰。只要有一个行为规范，就不会碰到这些问题了。

问题三：

　　来源：5 团队和流程

　　问题：这章介绍了很多种团队模式和开发流程，那么，我们在具体操作中，该如何选择呢？而且我们知道了最优的模式和流程之后又会受到很多方面的羁绊而无法实现，该怎么办？

　　答：团队模式和开发流程，根据具体情况而定，一是要看团队中的成员组成，二是要看项目的需求。没有最优的模式，只有最适合的模式，找到最适合的模式后，就不会产生很多羁绊了。

问题四：

　　来源：8.3 获取用户需求——用户调研——P160“我们有这么多各式各样的工具，这是好事，但也会有副作用”

　　问题：既然说需求分析格外重要，又为什么不能做到极致，而说做过头了也会失败？那么该如何把握住那个度，不会过头呢？

　　答：需求分析固然重要，但是也不能一味的去做，那样会很浪费时间。我们软件工程就是要在经济，速度和质量上权衡，不能一味的偏重一方，做出足够好的软件就可以，不用也不可能做到完美。

问题五：

　　来源：9..3 PM做开发和测试之外的所有事情——P186“我们认为好的产品是在平等讨论（甚至争论）的基础上产生和完善的”

　　问题：PM做的是开发和测试之外的所有事情，包括对项目负责，对项目安全的考虑，和对程序员的任务分配等等。这其中难免会出现上级对下级的关系，而且一旦有人与PM的思维不同，PM就可以用其他手段来压制程序员，那么在这样的情况下如何做到平等？

　　答：这里就涉及到如何选择PM和PM应该怎么做了。虽然PM对项目的负责程度要大些，但并不代表PM与程序员是上下级的关系。在这种模式中，每个人都要为项目负责，而不单是PM一个人。

问题六：

　　来源：13 软件测试

　　问题：这一章提到了很多的测试方法，那么如何去选择恰当的方法？而且有些方法存在相交的情况，那么用这个方法测试无误后需不需要再用另一种方法进行测试？

　　答：测试方法有很多种分类方法，每种分类方法又会分出很多的类。虽然有这么多的测试方法，但是他们的适用情况不一样，应该在合适的情况下使用合适的方法。测试方法在设计的时候选定，一般不会出现相交的情况。

三、是否产生了新的问题？请提出。

无

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

在这一个学期的学习中，我学会了很多的新技能，首先，接触了博客园，建立了自己的博客，并在上面写一些自己在编程之路上的一些知识点和心得体会。再者就是学会使用GitHub，用GitHub管理源代码，用GitHub克隆大神的代码。还有就是学会了用Visio画一些简单的图，用来方便的描述项目的某些东西。学会了使用QucikTest来此时一个软件，等等。

五、有什么深刻的体会，对自己一学期学习过程的总结。

这一个学期中的学习路程可以说是很艰辛的，首先是接触了一些以前从未接触过的东西，像博客园，GitHub，QuickTest，Visio。然后是站在了一个新的角度去看待这个专业。本来认为这个专业就只是学习如何编代码，如何解决一些技术上的难题，而现在才明白这个专业并不只是编代码，还要以工程学的方式来学会如何开发一个质量，速度和成本相互平衡的项目。再者，就是我在这一学期的项目实践中，做了项目组长的职位，压力比较大。但也在这较大的压力中成长更多。了解到平衡一个团队的重要性，学会了如何推进一个团队做项目。总之，这门课程，使我受益匪浅。

 

李林（201731062230）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。　　

第一次博客作业链接：https://www.cnblogs.com/239234l/p/10558154.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

（1）第二章

　　效能分析，表2-1，消逝时间，对于后面的解释，当用户看到程序没有反应时，不知道程序在干嘛时，用户应该怎么做？
　　答： 感觉当初提问题时这么傻，程序没反应，当然是继续等或者直接关闭程序啊，最不好的结果是卸载程序。

（2）同一位置

　　本函数时间，计算时间时，如果不算被调用函数时间，那么这个函数时间怎么算？本函数运行时是要运行被调用的函数得啊。
　　答：在调用函数之前获取当前时间，在调用之后再次获取当前时间，然后计算时间差。如果函数执行时间较短，会得到时间差为零的情况，此时修改程序为调用该函数1000次，然后将时间差除以1000；

（3）第三章

　　如何才能成为一个真正的软件工程师？
　　答:积累软件开发的相关知识，提升技术技能；积累问题领域的知识和经验；对通用的软件设计思想和软件工程思想的理解；提升职业技能；实际成果。

（4）第五章

　　这么多的团队模式，开发流程，我们应该做何选择？
　　答：选择真正适合团队的，适合项目的，能够让客户满意的模式和开发流程。

（5）第六章

　　敏捷流程和第五章的团队模式，开发流程有什么联系？区别？
　　答：敏捷流程是开发流程中的一种。敏捷流程是能够尽早地交付有价值的软件以满足客户需要。

三、是否产生了新的问题？请提出。

冲刺时间是不是有点短了？

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

学会了Visio，Github的用法，以及功能测试软件的使用。

五、有什么深刻的体会，对自己一学期学习过程的总结。

 大家作为一个团队进行开发，都做自己分配到的任务，都能够相互协作，相互帮助地完成任务。相互帮助的力度还不够，交流还不是很完美。

 

燕泓达（201731062231）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。　　

第一次博客作业链接：https://www.cnblogs.com/wanyouyinli/p/10552243.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

问题1： 8.3 获取用户需求——用户调研  以我学生的视野来说，现在的各种计算机产品似乎是已经饱和了，更高端的产品我们学生还做不出来，以后的工作也许就只有搬砖，这样一想，学习计算机的热情似乎就被浇灭了，这时我们怎样思考这个问题呢？
 我的解答：世界永远在进步，这一刻我们觉得先进的产品也许在下一刻就会被淘汰，当然身为学生的我们现在还不需要考虑这些问题，只需要做好自己的本职工作，为将来的工作打好扎实的基础就行。
 
问题2： 9.2：PM，PM可以是产品经理也可以是项目经理，毫无疑问他们在一个团队中都是极其重要的角色，书中也讲了他们对于一个团队的作用，但是并没有提及我们该如何锻炼成为PM的能力？
 我的解答： （1）学习和应用强势知识 （2）提高沟通能力 （3）对专业知识业务能力与理解力（4）提高人格魅力（5）掌握扎实的项目管理能力和知识体系。
 
问题3 ：11.4.2 书中给出了开发人员的标准工作流程，即有功能需求，复审，详细设计，实现设计等等当然还有解决设计中遇到bug，那么我们我们开发的时候需要一丝不苟的根据标准工作流程来开发吗？
 我的解答： 开发的时候的确需要一丝不苟的根据标准工作流程进行，凡是工作，必有计划；凡是计划，必有结果；凡是结果，必有责任；凡是责任，必有检查；凡是检查，必有奖罚。制度、规章、流程、标准、环节、衔接、细节，一定要严严实实，横向到边，纵向到底，结合部到位。只有这样才能保证开发健康有序的进行。
 
问题4：12.1.5 不让用户犯简单的错误，书中给出了一个飞机遥控器的例子，这和我们开发软件时遇到的问题类似，增加更多功能操作的复杂性会影响用户体验，而如果不增加的话，又不能够实现一些功能，那么我们应该如何抉择呢？
 我的解答：队友书上这个案例，可以对取出遥控器设置一个按钮，然后在各个按钮上面添加上语言文字。
 
问题5：16.1.7书中说成功的公司有价值观——追逐利润，一种成熟的产品，利润是50%，另一个是新产品，要开拓新市场，而且利润率是10%，那么我门应该如何选择呢？
我们学生是更应该注重实践还是理论呢？
我的解答：这两种方案并不矛盾，可以同时进行，用成熟产品的利润去开发新产品的市场，只有不断的开拓新市场，才不会在后面被淘汰。同样，作为学生，实践和理论也并不冲突，在学习理论的同时进行实践也是对理论的更好巩固。

三、是否产生了新的问题？请提出。

对于有些编码功力不太好的同学来说，花了大量的时间做前期的工作，编码的时间并没有太多，这样对他们是不是不太友好？

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

学会了利用visio绘制状态图，类图，以及活动图，还有学会利用码云以及Github等学习。同时还对“爬虫”有了一定的了解。

五、有什么深刻的体会，对自己一学期学习过程的总结。

任务繁重时一定不要先急着要是行动，需要将自己的思绪先理清，这样才方便后面工作的进行，一个优秀的项目仅凭一个人“单打独斗”是无法取得成功的，项目的开发不仅仅是编写代码，前期的用户调研，需求分析有时候甚至会比代码更加重要。

 

陈东（201731062232）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。　　

第一次博客作业链接：https://www.cnblogs.com/cddchen/p/10557774.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

问题1：

我看了2.1.2章节的这一段文字“ 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）”，不考虑模块的具体功能提出时间限制

解答：通过看书复习发现为什么单元测试要快，因为单元测试都是项目中的模块，因为单个模块小而精，需要处理的东西并不复杂，所以在该模块单元测试的时候就应该尽可能快

 

问题2：

我看了3.4章节的这一段文字“一个IT专业的大学生来面试，简历上写“技能：精通Visual Stdio C#编程”。于是面试官叫他用Visual Stdio IDE写一段程序。一个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程”，发现我们应该如何自己在某个能力上的水平，“精通”只是相对概念，每个人的定义都不相同，只是不同公司需要达到某个层次的人。

解答：通过实践观察学长面试过程，发现精通只是一个相对概念，每个公司每个面试官都有自己的标准，有的是通过问问题来了解，有的是通过进行一个测试来了解

 

问题3：

我看了4.5.2章节的这一段文字“在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。”，发现在自己了解的情况下，除了和队友出去比赛的时候是三人共用电脑，其他时候没有还有一个这种情况。

解答：通过实际操作，发现结对编程其实很常见，虽然我们学生时期都是单打独斗，但是在工作中结对编程出现的也很频繁。因为结对编程有很多优势，可以解决单人编程时经常出现的问题

 

问题4：

我看了5.2章节的对众多软件团队的模式，包括主治医师模式和明星模式等，书中给出的大量概率，我们应该如何理解对模式的选择

解答：通过看书学习，发现我们如何选择团队模式，是要通过分析自己团队的配置的，根据项目、技术能力、团队规模等灵活的选择

 

问题5：

我看了8.1章节的这一段文字“软件团队需要找到软件的利益相关者，了解与挖掘他们对软件的需求，引导他们表达出真实的需求”，发现我们对用户需求分析时，连用户自己都不能清楚的明白自己的需求，为什么需要我们软件公司花费大量时间帮助用户挖掘自己的需求。

解答：通过实际发现，帮用户解决需求问题也是我们团队任务的一环，需求分析正确了才能正确的引导后面环节的进行，否则就是竹篮打水一场空

三、是否产生了新的问题？请提出。

在团队合作中，如何让每个人都有相同的贡献，通过这次实践发现成员的贡献有大有小，其中经常是少数人为团队作出了大部分的贡献？

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

通过这学期的学习，在软件开发方面，编程技术得到了提高，对面向对象思想有了更清楚的认识；更掌握了github等团队源代码协助平台的使用，加快了开发速度；掌握了编写模块要进行正确的单元测试，才能证明你的模块是对的，不能敲出来代码认为是对的而不进行测试。

五、有什么深刻的体会，对自己一学期学习过程的总结。

虽然这个课程时间很长，任务繁重，但是在繁重的任务压力下才会有提高，因此通过这个课程对我自己而言是更掌握了编程技术，使用软件进行团队协助的能力和团队间互相协助，沟通的能力也得到增长，这对之后参与项目工作是极其重要的。

 

沈瑞琦（201731062229）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。

第一次博客作业链接：https://www.cnblogs.com/SimbaSRQ/p/10546543.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

1.第一章：P7举的飞机安全功能的例子，我联想到我们以后如果要自己设计与开发一个软件与应用，我们到底是从用户需求出发去设计，还是像这个安全功能一样，考虑一些不怎么用到但是不可或缺的东西？也就是这个钻研方向我不清楚(虽然这是个很简单的例子）；

　　答：通过对书上“需求分析”这一章节的学习与理解，我明白了，任何一个软件都需要跟用户进行需求上的了解，并围绕用户的需求来进行后续软件过程的安排设计，以及对用户进行及时的反馈。

 

2.第四章：两人合作中，代码规范的重要性是什么？不规范又能如何？

　　答：代码规范可以减轻结对编程的负担，以及提高结对编程的效率；两人统一代码的规范与模板，可以方便项目上的交流；通过对教材以及PPT上的关于合作、结对编程的内容的学习，解决了此问题。

 

3.第六章：所谓的敏捷流程的缺陷指的什么？如何去避免呢？

　　答：敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。通过上网查阅资料获悉敏捷流程的缺陷。

 

4.第十章：既然有时候，就算我们弄懂了客户的描述，但由于客户自己的一些问题导致设计出来的软件不合心意，那如何能做到一次性满足客户的需求并可以使这个软件扩大更多客户？

　　答：一次性满足客户的所有需求几乎是不可能的，做一个项目，其过程中，用户的需求一般是在不断变化、不断增加的；而且，在进行需求分析时，双方的交流方式与效率也会影响到初步的需求分析结果，并进而影响到后续软件开发的进程；因此，一般都是阶段性的向客户进行反馈，比如，增量模型与螺旋模型就是不断的做出一个阶段的软件，提供给用户，并收到用户的反馈，以这样类似的形式来最终满足用户的所有需求；通过查阅教材以及PPT上本课程内容获悉答案。

 

5.第十三章：关于软件测试，开发人员是否要加入测试人员的队伍，或者是否测试人员要全程开发人员的开发过程，不然测试过程中，写入的代码不能达到共识怎么办？

　　答：软件测试外包的人员要与软件开发商的技术人员紧密联系，加强和开发人员的沟通，从项目启动到项目结束，要了解开发的工作进行到哪一步，其中是否存在什么影响项目计划的风险，如果有及时想办法一起解决；通过查阅教材与网络解决了此问题。

三、是否产生了新的问题？请提出。

1、一个软件团队中，每个人的能力肯定参差不齐，如何做好每个人任务的分配，既不影响软件的开发进程，也不会让某些人员觉得不公平？

2、假设某个团队成功做出一个软件，并上市得到了很多用户的反馈，当他们获得劳动成果时，如何分配功劳，如何知道每个人所做的事情到底价值几斤几两？到底孰轻孰重？

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

1、在某些未涉及过的代码领域或者技术型领域，我的学习能力与吸收能力提高了，面对陌生、困难的知识也不会觉得麻烦而不想去做了，最开始学习新知识很苦，因为什么都不知道，什么都看不懂，当很快进入学习状态后，便吸收得很快，也从中体会到了学习的乐趣与成就感。

2、GitHub是个好东西，可以从上面获取很多别人分享的代码或专业知识；自己的代码也可以传上去分享，方便交流方便学习，也学会了如何将自己的代码打包上传。

3、我们组的软件用途主要是获取网络上关于电影、音乐、小说和应用的链接，并向用户提供下载。做之前想都不敢想，总觉得很困难，而真正当做出来时，才觉得也不过如此，其实只要不怕学习的麻烦，敢于挑战未知的东西，在学习过程中便会发现自己的加速度越来越快，胆子越来越大，能力也越来越高。

4、最后，学这门课前，本以为会打很复杂的代码，会做出很精美的图片或动画，就很牛逼；学了课程后才发现，在做一个项目的过程中，如何与队友进行交流；如何与客户进行交流；甚至作为一个项目带头人，如何有效管理软件过程以及项目人员，才是最核心的干货。只会做不会想，就只有当程序员的命；多做多想多变通，才是当软件带头人的料，才有混得更好的机会。

五、有什么深刻的体会，对自己一学期学习过程的总结。

一开始，我对这门课充满了排斥，因为我讨厌长篇大论的概念，我喜欢学习操作性强的东西，能实打实做出东西来的学科、知识；后来才发现，我的想法很无知，也太急功近利，看起来这些概念短期内不能带给我什么，但其实如我上面所说，如果只是会操作，那只能在一个软件项目中扮演其中一个小角色；而如果我能够理清整个软件项目过程的脉络、框架，我能有条不紊的利用所学知识在以后的项目实践中运用起来，使项目能够最大效率的进行开发和反馈，那才是真正有用的东西。说得再物质一点，项目带头人和项目参与人员就是钱多钱少的区别。

复习书本以及PPT的时候，我没有为了考试去死记硬背概念，而是静下心来看，真正去理解那些概念与逻辑，不仅没有我想象中那么繁琐，反而越看越清晰明了。总的来说，这门课虽说任务重了点，但学到的东西的确不少，让我的思维方式以及对于软件工程领域中我看重的区块有了很大的改变。

痛并进步着吧~

 

刘平（201731062233）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。　　

第一次博客作业链接：https://www.cnblogs.com/pingecy/p/10555685.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

2.1.2 好的单元测试的标准
我看了这句“这对于那些爱写复杂代码的人是一个很好的惩罚”，不懂他们为什么要写复杂代码，大一的时候，有人说我写的代码很幼稚，垃圾，既然复杂了会这麽麻烦，那为什么还要写成这样，简单不好，复杂也不好，我觉得很矛盾。

答：现在编码觉得只要够简单就行，因为别人可能会读你的代码，那些复杂的，可能是为了进行算法运算，这些是通过团队项目编码时实践操作中得出的感悟。

2.4 实践——设计有实际意义的软件工程作业
我看了这句“软件工程的作业题不好出·····题目非常简陋”，这里我觉得有些跟我的想法不一样，老师也说会布置个软件项目，不知道这算不算不简陋，题目如果难了，除了那种经常做编程的同学，其他人会怎么做，或者直接放弃了，因为都是一个从未接触过的东西，毫无头绪，老师说回组队，可是如果一个队伍的队员敲的代码量都非常少，这个队伍又怎么做，不要说去问其他人，有的同学根本不会给你讲，这或许是他们自己的错，可是老师布置的这个任务，他们并没有学到什么，因为在毫无帮助的情况下，不知道多容易放弃，或者老师安排助教老师和同学一队，队员少点，多指导下，但这样老师又不够，因此到底该怎样解决作业这块问题。

答：解决这个问题的关键是，必须寻找到有实力的团队，和愿意带你的大佬，同时，放弃这块也可以通过加入团队来解决，一个人容易放弃，融入集体后，就不会这么轻易，这是我自己的实况，前面一个人做时，和通过团队一起完成任务。

3.3 软件工程师的职业发展
我看了这句“他们都是以什么样的心态对待这一职业的了？”邹老师分了一个类，从中可以看出第一点“临时寄托或工作”算比较差的，我想提问，职业不就算一种工作吗，正因为工作是必须的，才会有动力，因为我也是专业调剂，因此我觉得老师说低动力不赞同，有的人也是“随波逐流的思想”走到哪，就努力，但会坚持下去，不知道以后会做什么，因此才会把现在的工作努力来完成，不一定会这么极端。

答：这点我没办法解决，没有谁和我讨论过，不过我始终相信，有时候随波逐流不一定代表别人不努力，当他自己懂得困境，有点将来的生活的的梦想，就不会堕落。

16.1.7 迷思之七：成功的团队更能创新
我看了这句“如果公司不断满足已有用户需求········不免会被新的颠覆性创新淘汰”，一个公司目前有产品吸引许多粉丝，按照上面说话，产品不断更新，最终会被淘汰，那我们又该怎样做，不断更新会被淘汰，不更新了会直接失掉利益，如果在这个产品上花的精力少，去钻研其它新技术，那这不是直接对这个产品的讽刺吗，既然不会做大，做好，那当初创造出来还有意义吗？

答：这点没解决，具体我也没经历过，只有自己参与后，才能有体会

16.5 创新和作坊
我看了这句“创新的出路到底在哪里？····不妨走进各自小作坊”，按照我的理解，这个小作坊是指人自己的小圈子，但创新不是应该在一个更广阔的空间吗，创新出来的东西应该服务与大众，假如你在农村里，有了新想法，创造出来一个东西，可是你会在农村卖吗，而农民用的人多吗，这个可能会是一个亏本生意。

答：创新的却需要宽阔的空间，但有时需要自己的天地来寻找灵感，虽然可能发明的东西不能被看好，但坚持总有成功，从其他书和各种自媒体上的文章看到。

三、是否产生了新的问题？请提出。

无

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

了解了github,这个是我们以后工作必备的技能，掌握倒不至于，又没有专门去弄，何况那么短时间也不可能轻松掌握这么庞大的功能

五、有什么深刻的体会，对自己一学期学习过程的总结。

对创造一个软件有了更加具体的体会，编码没有文档重要，文档可以持续记录你开发的任何一部分，少了这部分，你可能没有具体的计划、概念等，很难按时开发，和维护软件。

 

蒋庆（201731062117）：

一、请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。

第一次博客作业链接：https://www.cnblogs.com/JQloveJX/p/10560277.html

二、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的

1、第五章5.3.2 瀑布模型（P97-P199）

　　问：这里（P98）说到瀑布模型文档和复审的重要性，那么在复审过程中发现前一阶段的错误，就应该维护文档，但是每个阶段的文档又是独立的，这样就造成了文档维护的困难，那么怎么才能降低文档维护的困难呢？或者说有没有一种更好的方式写文档，使得维护时更简单？

　　答：1. 每个阶段尽量正确，错误少；

　　　　2. 利用VSS(Visual Source Safe)等电子文档管理工具；

　　　　3. 规划并制定出一套适合于自身项目的文档管理规则；

 

2、第五章 团队和流程（P90-P107）

　　问：这一章介绍了很多的团队模式和各种软件开发流程，那么一个团队怎么选择适合自己的模式，软件开发时如何选择适合的高效的开发流程，同时团队成员之间难免有不一致意见，如何统一意见？

　　答：（1）

　　软件团队模式分为很多种，如主治医师模式、社区模式、爵士乐模式，官僚模式等等，它们各有优缺，应用于不同环境，不同类型的团队成员，比如主治医师模型适用于首席程序员极其优秀的 情况，而对于我们学生而言，比较好的还是交响乐团模式以及功能团队模式或者两者相结合。交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；而功能团队模式是指具备不同能力的同事们平等协作，共同完成一个功能，在这个功能完成以后，这些人又重新组织，和别的角色一起去完成下一个功能。

　　　　

　　　　（2）  1. 首先，团队中应该有一个比较好的领导者，大家都比较公认的人当这个领导者。

　　　　　　　2. 其次，在大家达成一致意见之前，必须每个人都能够充分发表自己的看法和意见。

　　　　　　　3. 第三，在团队内部，应该尽量避免针锋相对的矛盾，而是应该和风细雨比较好。

　　　　　　　4. 第四，一个团队遇到一些重要的事，需要达成意见的时候，应该彼此商量，不能某个人决定。

　　　　　　　5. 第五，我们在一个团队中，如果达成意见以后，还应该通过实践来检验这个意见的正确性。

 

3、第六章 6.3 敏捷的团队 （P116）

　　问：这里写到：“如果你的团队很弱，那么强行把敏捷套在上面也没有用……如果你的团队已经有这么厉害的一帮人，那么不用也能写出好的软件”，弱的和厉害的团队似乎都不太适用敏捷，那么怎样的团队才适合呢？

　　答：1. 小团队

　　从生活经验上来看，小动物一般用敏捷来形容，比如兔子、猫（当然，大动物也有，如：这头猪真胖，但它竟然还这么敏捷）。小团队不会出现大团队那种尾大不掉的情况，「敏捷开发」进度可能每天都会变化，小团队有着更低的管理成本，产品经理可以很好的把控整个团队节奏。当然，小团队也是要五脏俱全的。

2. 需求聚焦

　　用「敏捷开发」肯定是有目的的。不管什么目的，肯定是为了快速响应、快速上线。这时，产品需求一定要聚焦、再聚焦。有太多团队都是开发到后期突然要改一些不影响大局的东西，比如界面不好看、Icon不精致、交互不酷炫、需求Cover面窄。这些东西放在普通开发节奏的团队中是没有大问题的，但是在「敏捷开发」团队中，只会拖慢整个团队进度，本末倒置。

　　　　3. 工作内容无边界

　　及时补位的思想是要深入到每个团队成员心里的。「敏捷开发」的团队或是初创团队一般都是一个人当好几个人用，每个人都是多面手（这也是好多朋友觉得小公司好的一点，即负责的内容多、成长快），原因就是他们的工作没有边界。比如底层开发生病了，中间层大哥一定要顶上；比如QA人手不够了，产品经理写测试用例并参与测试也是常见的事。

4. 团队无明显短板

　　越小的团队越容易暴露问题，木桶理论在小团队中更容易体现。「敏捷开发」过程很容易被团队中的短板所影响，这事虽然其他成员也有及时补位的精神，但每个人精力毕竟有限，我们还是希望能够每个人各尽其职。补的应该是未知的突发情况，而不是可预见的短板，这两个本身就不是一回事。

5. 互相信任

　　团队目标必须高度一致，并且相互信任，尽量少的辜负其他人。产品绝对信任开发评估结果，开发绝对信任产品发起的需求等等。少质疑多沟通，才能快速实现目标。好多大团队都会有各种需求评审、用例评审，每天文山会海，而「敏捷开发」会尽可能简化这个流程。但是我们要说的评审只是手段，目的还是要锤炼产品需求。因此纠结于是否该简化评审流程的朋友们，请尝试理解“不要把手段当目的”这句话。弱化评审的前提一定是产品经理自己已经将需求想明白，即满足团队预期、满足产品预期，再进行交付。

6.拥抱变化

　　之所以采用「敏捷开发」，真正的目的是快速响应、解决问题。当外界环境发生变化的时候，一定要及时接受并拥抱变化。所谓的变化来自两方面。一方面是外部变化，比如产品方向和预期不符、市场反馈不好等；一方面是内部变化，比如效果图或者交互真的需要改动才能上线等。面对这种未知的问题，团队里的相关人员需要及时调整心态，一起拥抱变化。

 

4、第八章 8.3 获取用户的需求-用户调研（P154-P160）

　　问：用户调研的方式有很多，如何选择一个合适的方式呢？还是集中方式结合使用呢？怎样结合使用？

　　答：1. 焦点小组——要求会议的组织者有很强的组织能力，能让不同角色都充分表达意见，并如实总结这些意见。

　　　　2. 深入面谈——着重探究用户在使用软件时有哪些困难，并如何改进软件，让软件更好用。

　　　　3. 卡片分类——适合团队收集的信息杂乱无章。

　　　　4. 用户调查问卷——一般结合其他方式使用。

　　　　5. 用户日志研究——要求用户记录自己日常工作或生活中与软件相关的行为。

 

5、第十二章 用户体验 （P249-P271）

　　问：这一章写到了用户体验，那么怎样才能提高用户体验，提升用户体验应从哪几个方面着手？还有在用户界面设计是遇到有用户说好，又有用户说不好使应该怎么处理？

　　答：1. 营造良好的软件运行环境；

　　　　2. 注重软件的界面设计，给用户留下良好的印象；

　　　　3. 努力提高和优化软件运行效率；

　　　　4. 软件的功能设计满足用户的人性化需要；

　　　　5. 提高软件的信息查询和处理能力；

三、是否产生了新的问题？请提出。

问题一：我们在团队合作中，经常效率很低，那么团队合作中应该如何高效的沟通？
问题二：在团队合作中，团队成员的代码应该如何合并？

四、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

团队软件开发过程中不仅学会了使用如Github、Visio等软件开发需要用到的工具，并且还通过看书、网上查相关资料和实际操作等方式学会了结对编程、代码复审、单元测试、功能测试等。

五、有什么深刻的体会，对自己一学期学习过程的总结。

经过了一学期的学习，使我对这门课最开始的看法也发生了改变，一开始我以为这门课全是概念的东西，其实不是，更重要的是从团队中学习，团队的学习让我收获了很多，也让我发现了很多自己的不足。①让我学会了团队合作，虽然一个人的效率是最高的，但是一个人的能力更是有限的，因此团队合作也很重要；②自学能力的提升，团队项目的开发过程中有很多的知识盲区，只能自己去自学；③学会了在网络上寻找各种资源（学习资料、视频等）以及寻求帮助（知乎、CSDN等）；④各种软件开发工具的使用，如开发工具VS2017，源代码管理工具github等；⑤学会了坚持，软件开发过程中难免熬夜什么的，必须赶时间做完，即使类，也不能说放弃；⑥软件开发过程虽然很累，但是软件开发出来使用软件时的成就感是无与伦比的。

 

团队项目GitHub地址：https://github.com/MlllXavier/WorkerBee

转载于:https://www.cnblogs.com/MlllXavier/p/11072015.html