最后一次团队作业

1.格式描述

姓名	学号
所属课程	https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign
作业要求	https://www.cnblogs.com/harry240/p/11524252.html
作业目标	总结回顾 整理资料文档
团队名称	七剑下天山
GitHub地址	https://github.com/BigTent0/HappyReading.git

2.团队成员

姓名	学号	博客地址
张鹏	201731062524（组长）	https://www.cnblogs.com/BigTent/
陈超	201731062510	http://home.cnblogs.com/u/kotofight/
王慧	201731062504	https://www.cnblogs.com/lazy-bear/
李邦国	201731062513	https://www.cnblogs.com/iron-man6/
沈梓琳	201731062501	https://www.cnblogs.com/LIn000
何鑫懿	201731062122	https://www.cnblogs.com/hxywxy521
侯思其	201731062124	https://www.cnblogs.com/siqihou

3.团队总结

张鹏

第一次博客链接：https://www.cnblogs.com/BigTent/p/11493888.html
个人总结：在这个项目过程中我的收货还是很大的。不仅对于软件过程有了深入理解，在在代码能力方面也有了很大的提升。在这个过程当中有一个道理让我记忆很深刻:一个团队，除了每个人要有过硬的技术水平，还需要加强沟通交流，尤其是在项目初期，对于需求和分工，一定要明确。这次我们做的是一个android应用，在这个项目开始之前我们小组只有少部分人接触过android，而且不是很精通。所以这个项目初期，大家都处于学习和探索阶段。因为之后我们有一门android课程，我想以这个项目顺便为后面课程做个铺垫。android涉及的东西很多，我们也学习了很多软件框架，这对我们软件知识是一个很大扩充，也是我们最大的收获。
在这个项目中，我做的是整体框架搭建和部分前端逻辑以及后端接口。前端访问网络用的是retrofit框架，后端用的springboot。在初期，光是学习和探索这些框架就用了很多时间。springboot以前学习过，还知道一些。但是对于retrofit完全不了解，刚开始根本不知道有这个框架。一开始我们直接才用android内置的httpurlconnection构造http报文来访问接口，但是这个代码量很大，不稳定，代码重用低，最后还是一位学长建议我使用的retrofit框架。通过这次项目，我对于软件前端后端的交互过程及原理有了更深的理解。
不足之处:作为这次项目的组长，对于前期分工已经组员之间的交流没有做到位，这对于一个项目组长是致命的。对于这一点我会认真反思自己，我觉得前期应该多花一些时间来做规划，磨刀不误砍柴工。这后面的矛盾可能会减少很多
对提出的问题进行回答：
问题1：在团队合作开发的时候，把任务分配好了之后，大家都各做各的，等到了整合的时候发现完全对接不上，很多人都不喜欢和团队交流，都按照自己的方式来。这种情况，有没有一种有效的方法让团队间的交流更加容易？
答：通过这次的项目开发，我认为避免这种问题组好的方式就是做好前期的准备工作，比如需求分析，需求分析一定要明确，然后软件项目框架搭建，统一了框架整合起来会更容易。还有设计，对于数据库要设计明确，功能模块最好精确到每一个接口方法。还有一点就是一定要统一开发工具的版本。

问题2：在敏捷式开发过程中，由于是便规划边做，在这过程中可能会存在很多变数，如果说改变过大，那肯定会给开发带来很大的困扰，这样的方式开发软件真的没问题吗？
答：在开发过程中，我对敏捷流程有了不一样的理解，敏捷开发模式不是说拿到项目就直接开始写，而是要经过需求分析，软件设计等步骤，在设计的时候要考虑到需求的变化，从而设计出灵活性高，能够适应各种变化的软件框架。只要框架设计得好，就算需求变化，我们也只需要重写相应的模块就行，而不需要对整个项目进行改动。总的来说，在设计的时候要注意降低模块之间的耦合性。

问题3：在以前的时候著名网络游戏英雄联盟有过一次大更新，直接修改了底层框架，导致后面一段时间游戏都很卡，给用户带来很大的负面体验。我想知道，学了这门课程，我们对程序框架会有了解吗，将来遇到这样的问题，我们能够解决吗？
答：当初提出这个问题是因为我对这个课程的教学目的不是很清楚。通过这段时间的学习，我发现这门课程主要是在讲软件开发过程，之余在开发过程中要用什么框架，或者什么技术并没有讲，也没法讲，因为太多了。如果现在让我来回答这个问题，我只想说，程序框架是在自己开发过程中，不断学习和总结过来的，所以在开发过程中，我们一定要注意学习那些优秀的软件框架。

沈梓琳

第一次博客：https://www.cnblogs.com/LIn000/p/11483108.html
github地址：https://github.com/Lin-000
个人总结：这学期的学习让我对软件工程领域有了新的认识，从基本概念到开发流程，从职业规划到水平评估，从代码规范到结对编程，从两人合作到团队开发。以及《构建之法》所介绍的NACBD模型、分而治之方法、敏捷开发小组会议和燃尽图、结对编程这些方面的知识点和技巧，我们都较好地应用到了自己的项目开发的整个过程中去。迭代会议、单元测试和代码复审这些部分都是我之前不了解的，学习完之后，让我对软件工程领域有了更进一步的认识，同时也认识到了编码能力以及团队协作与沟通能力的重要性，让我在今后的学习过程中，更加注重自己这方面能力的培养。

• 问题一：第二章单元测试部分(25页~28页)，书中出了好的单元测试的标准，分别列出了四个应该和两个必须，给出了单元测试的要求，那么测试人员在做单元测试工作时，具体的策略都有哪些呢？面对较多需要测试的问题时，测试人员怎样做才能快速高效的完成测试工作？？
  =》具体的策略：当设计一个单元测试的策略时，可以采用三种基本的组织方法，分别是自上而下法、自下而上法和分离法。依数据的分类列出输入，执行被测试程序，然后，判断输出是否符合预期。高效的完成测试工作：测试人员在测试前期要充分的了解和把握需求，要多和项目经理，开发甚至是客户经理沟通，每次测试结束之后都要总结和反思，适当的引入自动化测试，减少繁琐重复的测试工作，保证测试的质量和进度，提高测试效率。（答案参考书籍26到30页）

• 问题二：第六章敏捷开发部分(109页开始)，这几页书似乎一直都在谈论敏捷开发的优点，以及能够给开发者带来多大的便利，那么敏捷开发的缺点都有哪些呢？有没有因为错误使用敏捷而造成损失的经典先例？？
  =》敏捷开发的缺点：敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。敏捷失败案例：某知名大型互联网公司，被采访者是一个叫David的工程师。他是这样总结失败的原因：“有些高层错误理解了Scrum和Agile，导致歪曲了某些东西，使得Agile变得形式化”，他们在项目中尝试使用了SCRUM中的一个实践：每日SCRUM会议。下面是David描述不了解SCRUM的项目经理，如何使用这个实践的：“项目经理发现这个东西挺好，就单独把Daily Scrum拿来进行推广；结果，这个经理并不理解什么是Scrum，他把Daily Scrum变成了Daily Report：每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。而其他Scrum的精华部分都没有推广。”有的网友分析，得出结论说失败是因为“这家大型互联网公司的制度和文化的问题”。当然，失败肯定是跟这有关系，但我觉得还没有直接上升到整个公司的制度和文化。了解SCRUM的人，都会很清楚。他们对SCRUM的应用很初级，也只用了一个SCRUM中提到的晨会（其实，在其它很多的软件开发方法中都有这个实 践）。我们可以看出，他们的问题就是：项目经理根本不知道什么是SCRUM。也许连自己在开发中遇到了主要问题是什么都还不清楚？就四处寻药，甚至就给自 己下了一个处方。（答案参考百度）

• 问题三：第五章团队和流程部分：文章中提到了很多关于IT企业、以及相对比较专业的团队如何创新的相关知识，作为学生要如何处理这些知识？理解后又如何将它运用出来？
  =》学生应该多多培养自己的创新思维，大胆尝试。可通过三种方式培养创新思维和运用创新。 一、广泛阅读。既然创新不是真的创造未知而是对既有认知的有机组合，那起码得有素材可供组合。知识最直接、最范围的获取途径，应该就是阅读了。不断地阅读去大量的获取新知识，才有灵感乍现的可能性，没有充分的知识素材，也就不可能有什么灵感。二、充分讨论。有或没有灵感乍现，讨论都是非常必要的过程。讨论有两个用途，一个是获取新的知识，你认为非常不可思议的，对另一个人来说可能司空见惯，这个世界有很多的未知等着你去发现。二个是论证你的模型，自己非常激动的想好了，并没有什么卵用。把这个模型输出出来，让别人论证一下高下立判。三、独立思考。有自我判断力是非常重要的，真正的创新只会诞生在一个人的脑子里，只是可能最终由大家丰富后落地，但从没听说能讨论出一个创新。（参考知乎）

• 问题四：第十三章用户体验部分，如果某个产品发布上线之后，从用户那得到的反馈很不好，有很多吐槽，这时产品是考虑下架还是耐心更新修改呢？？如果一个软件或服务前期投入了不少的金钱或时间，但随着时间的流逝，软件有些后继无力，那还有维护的必要吗？是选择直接抛弃还是更新后继续运营？
  =》现在觉得，如果软件产品上线之后，得到的反馈不好，如果该产品的前景不好，可以考虑下线，不在继续维护了，可以从新的出发点来做符合大众需求的新产品。如果软件产品只是部分有缺陷，优化后的前景还是可观的，可以继续更新完善。

• 问题五：在第十六章中，谈到了创新，也说了关于创新的时机和招数。列举了一些产品的创新，印象比较深的是：对于一个魔方的销售，针对不同的用户使用了一些不一样的商业模式。初读之后，还是不太了解在软件工程领域中创新到底是什么样子的？ 新的设计模式属于软件工程领域的创新么？创新有规律可循吗？
  =》可以把关注点集中在以下几个方面：第一：基于云计算平台进行创业。第二：基于大数据平台进行创业。第三：基于人工智能平台进行创业。新的设计模式属于软件工程领域的创新。创新是没有规律可循的，墨守成规的创意是没有价值的，应该根据时代发展的需要，人们生活的需要，来做有意义有价值的产品。（基于我对创新的认识做的简答）

没有产生新的问题

掌握的新技能：
通过半个学期的自学，基本知道了Android应用程序开发的一般流程，对常用控件用法，以及事件的监听方法基本掌握，在界面的学习中，我发现Android为我们提供了很好的类似反射机制，通过Layout文件夹下的配置文件，可以快速的形成界面，在配置文件可以设置属性或者样式都很快捷方便。也可以直接使用拖动控件的方式，来完成页面的布局，对比较特殊的界面也可以通过处理嵌入到指定的界面，也可以通过Java代码直接创建View进行添加，但比较复杂，对一些点击、选中、按键等处理的事件，界面之间的跳转Intent管理，通过Bundle对数据在界面之间进行传输。在手机交互式通信服务中，学习了Android手机之间进行短信发送、广播、对广播的监听、服务等，在Service类中没有context，可以通过Handler来每秒反复运行，自动送出系统广播信息。此次项目更加加深了我Android产品开发的认识。

王慧

1、第一次博客作业链接：https://www.cnblogs.com/lazy-bear/p/11495047.html

• 2、问题解答。经过差不多一学期的学习，在学习到很多新知识的同时，也将自己以前的问题与困惑解开了。
  • 问题（1）：现在回头来再看这个问题，感觉蠢蠢的。通过这学期的学习，让我明白所谓“理论”与“实践”是相辅相成、联系密切的，没有什么轻重缓急之分的。没有坚实的理论基础知识作为支撑，我们又怎能完成复杂的实践工作呢。就像我们小组的这次项目一样，因为我之前没有接触过Android相关知识，所以在完成任务的时候就花了很多时间还走了很多弯路。特别是在刚开始的时候，一边摸索一边前进，花费了很多的时间与精力；后面随着知识的不断累积，所以在实际运用过程中就相对容易些了，整个的效率也得到部分提升。所以，对于“理论”与“实践”，我们应当重点关注如何将自己所学的理论知识运用到实践中去，而不是纠结孰重孰轻。
  • 问题（2）：对于这个问题，目前我还没有切身的体会。但是通过同学们每次的展示，我都能明确地感受到大家强劲的技术能力，做的项目都非常好，所以我觉得厉害的人始终都是厉害的，不论他有没有什么官方资格认证。当然，有了资格认证书相当于锦上添花，何乐而不为呢？
  • 问题（3）：关于敏捷的团队，书上提到这样一个改变——多功能型，意味着现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。那么，每个人都有责任完成相应的后期任务，这样的话大的任务就被细分了，完成起来也就相对容易一点了。在我们小组完成项目的过程中也是如此，每个人都有测试任务和其他非编码工作要去完成，当大家都把自己对应的任务完成时，整个后期任务也就完成了。
  • 问题（5）：敏捷流程团队成员都是足够强的，每个人的能力都是比较强大的，而且在认领自己的任务时大都是根据个人能力以及爱好去选择的，也即自己应该是有相应能力完成该任务的，同时个人也应该对此任务负责。如果真的遇到了非常是棘手的问题，也要尽全力解决，若实在无法解决就应该向其他高手请教，解决问题，不拖整个项目的进度。
• 3、新掌握的技能
  • 通过这个学期的学习，我学习到了Android的一些知识,掌握了基本布局方式，例如线性布局、相对布局，同时学会了主要控件的使用，比如listview、recyclerview。还有，学会了需求分析以及认识到了其重要性，不管是课堂上的知识还是项目实践都有所帮助。同时也掌握了一些基本测试技能，这在我们的个人的作业和小组项目中都有所体现。
• 4、总结
  • 在整个学习的过程中，我不仅学习到了新的知识，掌握了新的技能，增强了自己的知识水平能力，还体会到学习的重要性以及团队交流在整个团队中的重要性。这一次我们小组做的是APP，需要用到新的知识，我不希望因为自己知识的贫乏而拖其他成员的后腿，所以我尽力学习新的知识并为自己所用，这让我体会到“做中学”的意义，以自己所需推动自己去学习，效果似乎更佳。不仅如此，看到其他人都非常优秀时，意识到自己与别人的差距越来越大，所以更得要多多学习了。以前没有什么小组合作经验，这次让我非常明显地感受到交流沟通的重要性，每天相互汇报完成的任务，相互讨论问题，商讨进度问题，都极大地促进了整个小组前进的步伐。

侯思其

第一次博客地址：https://www.cnblogs.com/siqihou/p/12039005.html
问题1.在第三章《软件工程的成长》中

3.3中关于专和精的讨论。有人说一个人就可以快速成长一名全栈工程师，这让我想起街头卖艺的单人乐队，他们什么都会一些，可以很快的演奏一些曲子。与之对立的，是只研习某一乐器的乐手，你愿意花钱听哪种演奏呢？
我对这个讨论也感到疑惑：因为我认为在懂更多技术的人会有两方面优势，一是在团队开发中如果能了解更多方面的技能，那将减少技术人员的沟通成本。其二，了解更多技能也会在未来也有更多的选择机会。但如果专攻一门技术，意味着会将更多时间放在一个方向上，但与人沟通成本较高，知识面狭窄，所以怎样调节专与广的平衡依然比较迷惑。

答：不管在电视里，生活中，还是书籍中，我们总会看到各种各样的成功人的案例，他们都是各方面的精英，刚开始认为他们只专注与自己的领域，但后面却发现他
们“身兼数职”，就一个简单的人民教师来说，国家对其要求，不仅要不断的去提高自己的专业知识，给学生去传授，还要去学习心理学，教育学等知识去了解，发现学生。
所以，结合构建之法加我的个人观点，我觉得，作为一名工程师，我们首先要定位自己的领域，然后去专攻，去精学，其次，再去了解相关，以便对于一个小的
项目来说，自己可以知道项目的前后，独立开发，但对于一个大的项目来说，我们只需要完成自己的领域就可以了。

问题2.在第四章《两人合作》中

在4.7的讨论中有提到，“人和人不一样，......MBTI类型，讨论不同性格类型对合作有多大的影响，在合作的各个阶段应如何应对？”也就是说团队成员的性格可能会影响团队合作项目的质量，我也认为性格不同的人在做事风格和对待问题的态度都有较大的区别，那么是否应在成立团队前做MBTI测试从而更好的组合成一个团队

答：通过课堂学习和百度，我任务在人际关系中，和不同MBTI类型的人打交道若对其性格有一定了解，那么在工作上会减少许多冲突，团队合作的效率也能大大提高，因此在成立团队时可以对成员进行MBTI测试是有利于团队成员之间的了解和合作的。

问题3.在第五章《团队和流程》中

在阅读5.2时，认识到很多经典的“软件过程模型”，比如“瀑布模型”、“统一流程 ”、老师上课也讲了增量模型等，但这些开发流程中都使用到了开发文档，也就是都是用文档驱动，很考验文档的表达能力，我认为这在软件开发的过程中显的比较繁琐，是否有一些更优的解决办法，或其他的没那么侧重文档的软件工程模型呢？

答：通过课堂的学习和项目实践中，我了解到开发文档在一个项目的开发过程中的作用暂时是无可替代的，无论是需求分析还是软件设计都需要一个直观且易看懂的载体供开发人员或客户进行交流沟通或是制定规约，而文档则是一个非常合适的载体，因此在几种软件开发模型中，软件开发文档依然存在且不可或缺，即便是敏捷开发，也只是削弱了文档的部分功能，但依然无法替代。

问题4.在第十章《典型用户和场景》中

在10.3.3中提到工程师的设计师如何体现下列原则的：程序模块对应运行环境、相关模块、输入输出参数有什么假设？这些假设验证过么？这在上次暑假的做项目的时候我就在考虑这个问题，当对输入输出参数的假设与真实数据有误差的时候该怎么调整？加入调整代码或许就要动很多的代码。如何有效避免假设数据与正式运行的数据不相容问题。

答：通过老师的讲解并结合项目实践，我认为程序的运行环境和输入输出参数等应当是在需求文档或设计文档中就规范好的，对参数的假设需要一定的经验，因此一般是经验丰富的专业人员参与项目的需求分析和设计过程，以保障输入输入参数的准确性，同时在测试阶段也应依据文档设计测试用例，测试不通过的代码的返工量取决于软件模块之间的耦合度。

问题5.在第十三章《软件测试》中

在13.3.2讨论测试用例这里，书上说道一个软件有很多可能的输入和环境参数，我们没有能力穷举所有的可能，也没有必要。这里只介绍了等价类划分，边界值分析，决策表、因果表和功能图方法等方法，只提到了部分方法并没有说明怎样才算是符合有效测试用例这个标准。

答：结合老师所讲和项目时间，我认为好的测试用例，必须具备一下三个特征：
1.整体完备性：“好的”测试用例一定是一个完备的整体，是有效用例组合的集合，能够完成全覆盖测试需求。
2.等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3.等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。
能做到以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。

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

在课堂上，我了解了什么是软件工程及软件开发的工程流程。了解了瀑布模型、原型模型、增量模型等几大主要的软件过程模型，同时老师也是侧重于讲解了敏捷开发模型，之后结合项目实践，在软件的开发流程中结合老师上课讲授的知识点，从需求分析到软件实际再到代码实施和软件测试横向的体会的开发流程。同时小组采用了敏捷开发模型，确定出项目经理，产品经理对项目进行管理，合理安排软件开发计划严格把控项目进度，让项目质量得到保障。在实践中我掌握了使用git控制软件版本，使用easyapi对后端接口进行设计分工，使用墨刀进行原型设计，在github上寻找开源技术等。

（三）体会和总结

通过该课程的学习，我们对一个软件项目的开发流程有了更清晰的了解，再结合项目实践受益良多。在开发工具上，接触了开发文档、版本管理工具、原型开发工具，接口管理工具等一系列开发工具。在编写完需求文档，设计文档等开发文档后，结合项目推进，深知在前期文档编写不明确会导致功能点不明确项目无法推进在等问题。在版本管理上我们使用git对项目进行管理，这也是首次使用工具管理软件版本为我们的软件开发节省了大量的时间。在项目开发过程中我们也遇到许多问题，在项目初期，我们的分工还算合理，前后端分离，功能划分多比较理想，因此项目的整体推进的进度还算比较满意，但中期的时候在功能点没有集中，团队成员间的沟通减少，导致项目推动很慢，很长时间都没有新的模块更新，项目越到后期，越觉得前期的准备不足，在设计方面做得不是很好，这些都是前期在设计和分工的时候花费时间过少导致的遗留问题。在实际进行团队项目的时候发现人数越多，在设计和沟通上的难度就变得很大，特别是我们的水平并不是很高的情况下，每个人都有自己的想法导致集合模块的时候出现很多问题。值得高兴的是，随着时间推移，成员之间的默契度在不断提高，很多问题都可以沟通解决。总的来说虽然过程中稍有瑕疵，但我对项目开发流程以及涉及的常用开发工具有了一定的了解，为未来在软件开发行业的工作奠下基础。

李邦国

博客园地址:https://www.cnblogs.com/iron-man6/
githup地址:https://github.com/iron-man45/WordCount
解决第一次作业的问题:
1、如何提高软件工程师的核心竞争力？核心竞争力是什么？（第三章软件工程师的成长，p60）
答:提高自身编码能力，养成良好的编程习惯。核心竞争力是包括编程技术及解决问题的能录。
2、为什么要把项目放在TFS上？（这样会存在签入签出的问题）如何解决签入签出的问题？（第11章）
答:是为了软件版本控制问题，而且通过一些管理手段可以解决签入签出问题。
3、开发软件过程中是要把质量还是速度哪个放在第一位？（P235十一章）
质量与速度一样重要，要根据用户需求及开发经验来确定。
4、如何保证软件测试结果是长期影响而不是短期刺激？（p256第十二章）
答:测试用例的数量一定要足够多
5、每日构建是什么？它有什么意义？（p235第十一章）
答:每日构建意味着自动地，每天，完整地构建整个代码树。意义:保证测试工作正常进行。

6、如何避免“不分主次，想解决所有依赖问题”这一思维误区？（p48第三章）
答:对解决问题的各种方案的耗时进行预估，筛选掉可能出现这一问题的方案。
总结
下面我将从三个方面进行总结，第一是从编程技术上，在做项目之前的两个月，也就是上个暑假，我就开始学习android开发，但大都是按照教材上的知识点来学习理解，没有去做项目。真正开始写代码，就会遇到书上没有的bug，需要自己想办法解决。项目结束，我也想了自己收获了什么，应该学习更多的是前端的设计以及app应该如何兼容大多数的手机(虽然没有完全做到，但我会在今后的学习中着重对待这个问题)。第二我想说项目遇到的困难，按照时间顺序来说，第一个就是电脑ip地址会随开机不断更改，导致app无法访问服务端数据。第二个问题是，服务端的springboot框架的使用不太清楚，耽误了不少时间，第三个问题是，服务端maven项目要通过maven方法打包，才可以在服务器上运行。第四个是，请求网络数据时，使用异步请求，没有得到结果就开始进行下一步程序，这个问题也是花了很多时间。第五个想内部类传参数时，会受到很多限制，当时我是通过list才解决的。下一个方面是，团队合作方面，这也是这门课的重点。沟通永远是第一位的，防止了任务被重复完成。其实对于团队项目来说，软件的版本控制问题才是最难的，使用git工具也不够稳妥，应该有一个专门的人负责管理。

何鑫懿

第一次博客链接：https://www.cnblogs.com/hxywxy521/p/11515643.html
问题一：
在第四章《两人合作》中，每个程序员都多多少少有一些个人的怪癖，那么在交流中，一旦两个人的观点发生了极大的冲突，两人各不相让，那么便会极大的影响程序的进度，这样做别说更好的完成程序，可能连程序的完成都是一个问题。人人不同，我们不能保证每一个人都能够做到倾听他人意见，及时认识到错误？
解决策略：
在不违背原则的情况下，相互理解，多站在别人的方位上去看待问题，遇到矛盾尽可能的更多的交流和沟通，还有就是在合作之前，分配好两人小组，尽可能地让两个人的脾气和性格和相符合，可以很好的合作，做好分组之前的管理工作。
问题二：
在团队的组建时，就一定要确定工程模式吗？
解决策略：
在团队组建的时间不同，便要去确定是否要确定工程模式。如果在项目的需求都已经写好了，在组建团队就要确定好工程模式。而如果项目还没有确定，那么在团队组建时，不要确定工程模式，要根据项目的具体情况，来决定工程模式，不同的情况，要随机应变。
问题三：
在了解用户的需求过程中，总会遇到许多的用户需求不稳定的情况，此时应该如何？
解决策略：
此时应该深入了解用户的情况，还是应该根据他模糊的需求描述，先通过敏捷开发开发出一个简易模板，让用户看看效果，在进行迭代，达到用户的需求。
问题四：
实战中实现源代码的管理，一定要一个人管理与维护到最后吗？因为一旦有新人来进行管理与维护，他不了解源代码的需求和具体的代码实现功能，就可能会出现不可挽回的损失。
解决策略：
在写源代码时，管理人员就一定要相关人员写下源代码管理文档，好可以不让一个人管理和维护到最后，一旦原来的人员不在了，就可以让新人阅读管理文档，在管理源代码，这样就可以最大避免损失。
问题五：所谓的软件测试就一定是bug越少越好吗？
解决策略：
对于不同的用户和情况，对于bug的理解不同，需要去解决的bug也不同，去解决当时用户不同的问题。
没有产生新的问题。
学习的新技能：
Android 应用的简易开发和项目完成的流程。自己通过书本和网络资源去学习简易的开发，通过项目过程，去理解和了解项目的完整流程。
个人总结：
首先，经过这个学期的学习，不论是生活还是学习上，我的收获都很大。学习上，学习到了许多新的编程技能，像android开发，还是第一次接触，连编译器的安装都花费了大量的时间，去学习安装，一步一步的尝试，才运行成功。还有就是编程中的bug问题，对于bug我们并不能只是纸上谈兵，要自己去慢慢地尝试去面对和解决问题，而且bug并不定都要去解决，对于不同的用户，要解决的bug问题不一样。新的疑惑就是不知道自己到底要去学习什么，到底怎样去学习，学习什么内容，怎么学习有用？还有就是团队活动，对于在门课，团队的沟通、交流和合作是特别重要的，一个人闯天下的时代已经过去了，一个人的能力在强也不堪大用。古人云：“一个人在强，也只有一只老虎，一群人强，那就是群狼。老虎也怕群狼。”所以团队必不可少，但是一定要做好沟通、交流和良好的合作，才能完成不可能的编程项目。

陈超

第一次博客地址:https://www.cnblogs.com/kotofight/p/11516549.html
个人总结:
在这次项目中，我主要负责前端界面、部分测试以及配合博客书写。这次项目并不是我第一次接触小组项目，但是是第一次接触安卓。最开始的时候连按钮都不知道咋拖，后来看了菜鸟教程和网上大佬们的博客才好起来，可能一开始还会抱怨为什么自己没学安卓要选安卓的项目，后来就不会了，因为以后可能还会有这种边学边做的项目经历。这次也让我看到了在前端方面自己和别人的差距，他们的页面好看太多了，自己还需要努力。通过这次项目也让我看到了一个完整的软件开发过程，让我对未来的职业有了一定的了解。
不足之处:作为这次项目的一员，并没有和每个成员都保持频繁的交流讨论，可能有时候保持在完成组长分配的任务的状态下，没有更积极主动一点，希望在之后的项目中吸取这些教训，努力改进。
回答第一次博客提出的问题:
1.结对编程在现实中确实存在，虽然很难实现完美的结对编程，但是大致上是差不多的。对于水平差距较大，在起争议的时候，在不同的方面，会听从不同人的正确意见，并不会出现始终一个人主导大权的情况。
2.通过学习，我知道了PM的重要性，不仅需要稳固的知识学习，更需要经验。
3.文档有文档的要求，规范的文档是基础，再规范的前提下，更方便理解就很重要了
4.不同的模式有不同的选择，做出大部分功能然后迭代，或者小强地狱，都是根据实际情况来看的，并不能说谁好谁坏。
5.这个问题当初问的范围有点大了，学习知识，勇于实践，拥有强大的求知欲和动手能力，象限一定能提高。

文档整理

开发文档

下载地址：https://pan.baidu.com/s/1i2JamZr4XuqpU2Vpp915Zg
项目源文件

下载地址：后端：https://github.com/namehousiqi/ReadingWebserver.git
前端：https://github.com/namehousiqi/ReadingApp.git
使用说明和安装包：https://pan.baidu.com/s/1B1YDhTXppRCMTteMI-tIKQ
下载安装包即可安装，使用说明见文档

感想总结

经过差不多两个月的奋战，项目终于迎来的尾声，对于我们的这个项目，完成度还是很符合我们的预期的，虽然有很多细节部分还没有去实现，但是作为一个小说悦读软件，已经可以正常使用了。能够顺利完成这次项目，非常感谢队员们的努力和配合，你们的付出我都看在眼里，记在心里。我们的小组从卓越班组队那天，就一直没散过，后来又新增了两名新队员，大家经过这么多次项目，彼此都有了一定的默契。感谢有你们的陪伴。
最后感谢助教，感谢老师的严格要求和辛苦付出。