既是结束，也是开始
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign/ |
|---|---|
| 这个作业要求在哪里 | https://www.cnblogs.com/harry240/p/11524252.html |
| 团队名称 | 巧克力王子与六个小矮人 |
| 这个作业的目标 | 对本课程及项目作出总结 |
| GitHub地址 | https://github.com/Chocolate-Prince-and-Six-Dwarfs |
队员列表：
| 姓名 | 学号 |
|---|---|
| 陶一（组长） | 201731062213 |
| 孟祥一 | 201731062207 |
| 易林 | 201731062134 |
| 王艺霖 | 201731062127 |
| 陈劲松 | 201731062132 |
| 沈墨 | 201731062115 |
| 干冰雪 | 201731062502 |
团队队员个人总结：
陶一 201731062213：
问题博客： https://www.cnblogs.com/pastrain/p/11505989.html
对问题的解答：
-
原问题： 我看到4.2的代码风格规范里面，说缩进“是用Tab键好，还是2、4、8个空格？”后面的结论是“4个空格”更好。而我本人的缩进习惯却就是Tab，而且用了很久了。难道说缩进的方式不应该是按照每个人的不同习惯来的吗？再者说，4个空格相对1个Tab键来说要浪费更多的时间，没必要一定要用4个空格来缩进吧？
解答：
根据这几个月的学习和了解，发现在不同的编程语言甚至不同的操作系统中，分别有自己比较合适的缩进方式。学习一门语言就要学习这门语言自己独特的地方，所以我觉得应该在适应语言的基础上再根据自己的习惯来写代码。另外，在团队开发时，要在开始就制定好缩进的规范，不然难免出现个别小问题。 -
原问题： 在7.2.6“保持敏捷，预期和适应变化”中，说“干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。”那么就是说，在客户的需求并不是很明确的时候，就将项目接下来么？这样会不会不太谨慎？不应该确定好了客户的需求之后再开始开发的工作吗？
解答：
对于这个问题，现在的我的理解是，有时候客户在最初给出的需求往往并不是那么的明确，可能会在后期作出更改。而我们作为项目的开发人员，对于这样的情况，我们要做的应该是及时的对当前的项目进行调整，对于客户提出的新需求及时进行应对。就是要求我们要有随机应变的能力。当然，对于那些胡搅蛮缠，乱提乱加需求的客户，自然还应该有我们自己的原则。 -
原问题： 在9.4“领导力——高效的团队讨论”这一篇中，“目的”这里，“目的并不明确”，“每周一次，每天一次”，“对细节的争执”，这些问题我都不是很理解。开会的目的是为了解决问题，那么开会的频率应该是确定的吗？而且开会的内容是应该由leader来确定还是由开发的程序员来提出？至于细节方面，难道是应该粗略说明，然后再下去解决吗，如果沟通出现问题怎么办？
解答：
在这个课程中，我们就进行了一次团队开发的实战，而我也有幸成为了我所在的团队的leader。所以对于开会这个问题，我也是深有感触。开会的内容有很多，但我们更多的是关于项目的理解和工作的对接方面的。比如说，对于某一个功能的实现，每个人想的可能都不一样，如果都根据自己的想法来做，那么在后面的对接上肯定会出现问题。所以我们需要经常开会来进行足够多的交流来解决这样的问题。对于开会的频率，我现在觉得应该是固定的，特别是大的团队。因为团队人数太多，如果不是固定的，那么很难保证每次开会的时候所有人都能来到，就难以进行很好的交流，也就起不到开会的作用。至于开会的内容，主要是由leader来组织，开发人员当然也要在开会前就提出自己的问题，准备开会时解决。细节方面，我觉得是在时间合理的前提下，自然是越细越好，也是为了不出现理解差异问题。 -
原问题： 我看到在11.6中有这么一个问题：“你的团队的源代码控制用的是什么系统？”怎样根据自己的团队的情况来确定源代码管理工具？参考的点有哪几个？
解答：
这个问题其实现在感觉特别简单...自然是看工具的优劣和开发人员的习惯。因为一个优秀的工具肯定会让更多的人喜欢，反过来，大部分人喜欢的工具，自然也不会太差。就比如我们本次选择的GitHub这个工具，有无数的软件开发者习惯将自己的开发代码存放到它的仓库里，它也证明了它的价值和使用价值。确实是非常好用的工具。 -
原问题： 第15章的15.1.8“招数：逐步冻结”，说“要让程序的各个方面有次序地‘冻结’，这样才能把稳定的软件交付给用户”。那么万一冻结了一部分程序后，后面的小部分在调试的时候发现出现问题，要对前面的冻结程序进行修改时该怎么办？冻结真的是有必要的吗？
解答：
是有必要的。我现在可以肯定地说，是非常有必要的。因为在我看来，没有人能够在开发了很多代码和程序块之后，还能在之后要修改时将涉及到的每个地方都修改到。如果修改不到，就可能会产生Bug。并且，之前已经测试完好的代码，进行修改后无法确保没有新的Bug，又要进行重新测试。无论是人力还是物力方面都是资源的浪费。除非是整个项目组要准备进行重构或者是新版本的更迭时，否则我觉得冻结代码、禁止修改，是非常有必要的。
新问题：
暂时没有什么新的问题。因为做一个新的项目接触到的新的东西太多了，特别是技术方面。所以很多的时间都是出于学习的状态，出现技术上的问题，通过百度、CSDN、overflow基本都能解决。如果真要说的话，大概就是如何很好的让开发团队中的人安心做好自己的工作，不埋怨吧hh
掌握的新技能及方式：
- 首先要说的，那肯定就是写文案、写文档的能力。上这一门课，写了大概有十篇博客，还有开发所需的项目选题、概念设计、需求分析等一系列文档。经过这么长时间的文字编辑，自己的写作能力感觉有了很大的进步。。。
- 然后是源代码管理工具的使用。选择使用的GitHub，家喻户晓。软件开发者的必备工具。经过这次的团队开发，也算是能够熟练使用GitHub来上传保存项目代码，跟团队成员的分工协作也是更加方便和得心应手。
- 最后自然是专业能力方面，学到了很多新的知识，比如一直想学但没有机会的计网方面、前后端交互所用接口设计方面、新的框架的接触和使用方面。通过这次的团队项目的开发，推动着我从网上，从团队成员那里学到了这些东西。
深刻体会、总结：
团队项目的开发任务结束了，这门课也接近了尾声。怎么说呢，不断学习，不断进步吧。不得不说，跟他人合作开发一个大型的项目确实是不简单，好多问题、方方面面都要考虑到，而且如何很好的进行交流也是很重要。作为leader，要能够合适的安排好开发工作，并且要能够及时的进行调整。这些都通过这次的团队项目让我学到了许多。
孟祥一 201731062207：
问题回顾：
- 问题博客：<https://www.cnblogs.com/dreamone11/p/11480226.html>
- 对课程的想象：
经过一个学期的学习实践，其实这门课程和我当初设想的样子很像，但是又有一些差别。可以说这一门在实践中学习的课程，我个人很喜欢把软件工程和建筑学相比较，因为我觉得这两门学科真的很相似，并且软件工程的很多实践方式都是从建筑学上总结而来。这两个专业都不是单纯的技术知识可以囊括的，算法技术、一门语言只是程序员需要掌握的一部分内容。如果你想变得更加专业就必须掌握软件工程的相关知识，数学、管理学都是对软件工程来说非常重要的知识！可以说软件工程是一个综合性非常高的专业。学生可以在大学阶段就接触软件工程行业的工作开发，
再说说实践方面吧，我们在课上学习软件需求分析方法、不同的软件开发流程适用于什么情况、两人结对编程方式、团队合作方法。我个人认为这门课程最有价值的地方就是这门课极力给学生创造真实的软件工程行业的工作流程。这对于我们来说是一次宝贵的学习体验机会。
-
对问题的再次理解：
-
问题一：如何将单元测试自动化？（单元测试如何集成到自动化中的？）
再次理解：在经过第二次个人作业后，我便对单元测试有了更深的理解，我又去查了一下自动化测试的概念：自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 其实自动化测试就是利用自动化测试工具，设计出自动化测试用例，从而搭建自动化测试的框架。设计与编写自动化脚本 ，从而达到自动化测试的效果
-
问题二：在工程中如何，软件工程师解决问题方式的选择问题
再次理解：实践得出。对于不满足于“解决目前直接的问题”，而是想“解决问题背后问题”的情况其实在软件工程行业是频繁发生的。在我们的项目开发过程中也遇到了类似的情况。很多时候“实现”了一个功能，并不是真正实现，而是先把样子的做了出来，并不能根本性的解决问题。那么我们其实需要权衡的是时间效率和质量。我认为在开发一些已经有类似产品的软件产品时，可以选择“解决目前直接的问题”，这样可以提高开发效率。合理运用开源代码是我们每个人都会经历的。当我们开发一些创新性软件项目时，我们往往需要“解决问题背后问题”，计算机科研领域往往会注重从根本问题出发，解决根本性问题。
-
问题三：对产品开发过程的需求可不可以理解为制作团队对开发的规定？
再次理解：实践得出。经历了一个学期的学习，我在很多情况下都有一个感悟：有需求就有市场！ 这么看来其实对产品开发的需求，根本上还是从用户那边得到的需求。其实说用户不太准确，因为客户不一定是用户。终端用户使用软件，但提出需求的人不一定是终端用户，我们把提出需求的人称为客户。软件团队在经过需求分析过后，指定的一系列文档都是为了软件开发的良好进行。这些约束有时并不是软件团队指定给自己的，而是客户限制的。所以我们不能把产品开发过程的需求理解为制作团队对开发的规定。
-
问题四：接受风险也算是一种应对风险的手段么？
再次理解：实践得出。经历了团队开发之后，我明白不是什么事情都是顺心如意的。往往大部分时候，开发的情况不能如你所愿。那么不能避免的风险肯定也比比皆是，外界因素对软件开发的影响是很大的。就像资金短缺、人员变动、不可抗因素。我们的学生团队都会因为各种各样的问题而耽误开发，在软件工程中就更有可能发生这种无法避免的风险了。这也就是风险评估的重要性，当然风险评估的成本也是很高的，所以我们最好把风险控制在可以接受的范围内，这样接受风险也不失为一种合理的应对风险的手段。
-
问题五：关于“探索式”的测试的理解问题
再次理解：实践得出。在这学期的课程中，我们其实有很多机会接触“探索式”测试的机会，在自己的团队项目测试中和针对其他团队的项目的测试作业中我其实都有用到这种“探索式”测试。对于其他团队项目，你并不知道他们的代码，也不知道具体的框架结构。所以只能使用黑盒测试，“探索式”测试可以模拟大量用户的位置操作所检测出的不合理bug。
-
-
新问题： 学生团队存在的意义，或者说如何合理地进行学生团队的管理？
从上大学之后，也参加了有三次左右的学生团队项目的制作了。可以说这次团队合作是为期最长的一次，在合作上和分工上也都比原来要更加规范更加合理。但是依旧不能完全按照当初设想的进度安排进行开发，这或多或少会引起团队内的消极情绪。所以合理的管理制度就很重要，但是对于学生来说没有薪资，绩效的制约，所以对学生团队的管理我认为真的是很不容易。不是所有人会把百分之百的心思放在一门学科上，也不是所有人会投入百分之百的热情。那么在这样的情况下怎么维持一个学生团队的开发呢？我认为简单的不做事扣分，做事不扣分，多做事加分的政策是无法根本上解决这个问题的。我认为这是一个值得思考的问题。
-
新收获： 这门课程带给我的收获可以从两方面说，首先是软件工程相关的知识（不涉及技术）：软件开发流程、如何进行软件需求分析、软件开发模式。这些知识都是老师在课堂上传授的，并且在课后布置的作业中都会要求我们对这些知识进行实践。包括团队项目的立项、项目需求文档的编写、使用敏捷开发的方式进行项目冲刺。然后说下技术方面的提升：1.数据库的设计和实践 2.Jquery的学习和运用 3.Git的使用（团队合作、结对编程）4.对原型设计工具的使用和原型模式的理解。技术方面可以说是在做中学，个人作业、团队项目开发中需要到的技术都需要你去接触去学习，所以说在做中学可以说是非常重要的能力，也非常考验一个人的能力。
-
总结：
充满收获和思考的一段“旅程”，一段难忘的团队合作经历。我想能带给我这些的机会不多，很有幸在这门课上体验到了。说实话，这门课程的学习过程确实很辛苦，也很累。但是经历过来了，一切就都是很美好的会议。当初自己脑子中蹦出的团队项目点子最终在大家的努力下实现了。可以说看着自己的想法一点一点的实现出来是一种很奇妙的感觉。这其中有大家每个人的努力，我们交流、分享想法，一步步的完善我们的项目。可以说是目前为止我经历过最棒的一次团队合作。
再说说我自己，这学期为团队答辩了四次，可以说这也是很棒的经历。带着团队里所有人的努力成果站上讲台，给他人讲述我们的成果和项目也是很兴奋的事情。我也知道了交流的重要性，在软件工程这个行业交流是非常重要的，你需要知道别人想要什么，甚至还需要引导他人表达出他的想法。还有团队交流也是非常重要的，团队的每个人应该充分的沟通才能保证团队的正常工作。
希望自己可以在之后的学习生活乃至以后的工作中都能回想起现在所学的东西，做到真正的学有所用。
易林 201731062134：
问题博客： https://www.cnblogs.com/charmingdid/p/11506468.html
对问题的解答：
- 如果自己在一个软件开发团队中，怎样正确的判断自己所处的团队的类型，如果都不属于书中列举的类型，怎么判断团队是否适合自己？（第五章第一节）
答：
先通过对照团队是否属于书中某一类型。如果都不是，通过自己在团队中工作的是否高效，和其他成员相处的关系以及团队对自己是否有帮助来判断。 - 如果自己有了一个创新想法并开始动手做，但在还没有做完却发现有人与你有同样的想法并且比你先一步做出成果，是该继续做下去还是放弃？（16章第一节）
答：
应该继续做下去，可以当做锻炼自己的机会。 - 在创新和利益冲突时怎么选择，就是创新会减少或者损害利益的获取？（16章第一节）
答：优先考虑创新，创新才是发展前进的动力，并且就算创新可能会损害当前的利益，也可能会为以后有更得帮助。 - 针对一个现有的优秀的产品，想在这个产品的基础上加入自己的东西来达到创新的目的，怎样能有效的进行创新并具有较好的效果？（16章第四节）
答：
先对产品进行一定的调查，尝试找出不合理的地方或者可以优化的地方并针对性的进行创新。 - 在同用户交流获取用户体验的过程中，用户的体验要素和自己的理念产生冲突是说服用户？说服自己？还是可以两者兼得？
答：
如果认为自己的理念是为了用户好，用户最终会赞同我的理念也说服用户。如果只是因为自己的的习惯等应该说服自己。
新问题：
没得新问题
掌握的新技能及方式：
掌握了使用原型设计工具对产品进行原型设计
掌握了对github的使用
掌握了前端开发设计页面
深刻体会、总结：
这次的团队项目是我大学以来做过的最久的团队项目，自己感触很大，深刻体会到了团队的力量，但同时也体会到了在团队合作开发中沟通交流的重要性。
王艺霖 201731062127：
问题博客： https://www.cnblogs.com/Kowaine/p/11508141.html
【回答自己的问题】
-
在结对编程的过程中，协商交流非常重要。但也存在着非常固执的人、这种情况之下如果项目停滞，该如何尽可能减少损失(时间上和金钱上)的情况下让项目继续？（4.6）
答： 建议开除。 -
PM如果“只手遮天”，在系统性地开发中带来的好处大还是坏处大？（9.3）
答： 依据PM的能力和经验而不同，若PM经验丰富，则好处大，否则后患无穷。 -
若将来打算做自由的软件开发者、不参与到团队项目中，学习团队项目的流程是否对个人开发有益？如果有，具体体现在开发流程中的哪一步呢？（2.3，5.3）
答： 有益，便于个人开发时也系统性地做好对软件项目的管理。 -
如何在用户体验和合理性上做权衡？打个比方，用户要喝水，我设计从自来水管接水烧开，用户却偏偏要我挖一口井，再把井水捞上来烧开。众所周知，这样就伴随着饮用井水的安全性问题（即使烧开了也无法保证井水对人完全无害），但是用户偏偏要觉得井水更健康。更简单的来说，就是能给用户带来更高体验的同时也伴随着隐藏的风险。这种情况下，该如何权衡用户自身体验和合理性？（12.1）
答： 这需要依据经验和理论两方面协调。不合理的需求要尽早否决，合理的需求要尽早分级。 -
通读整本书，依我拙见，这本书在章节顺序上是很让人迷惑的，请问有没有一个合理的阅读顺序呢？
答： 不清楚，基本没用这本书。
【产生的新问题】
为什么总有脑残想着搞事情？是袁隆平爷爷的锅吗？
【掌握的新技能】
- linux用得更熟了。
- 即时通讯技术
【总结】
我们都是世界的齿轮，有个性的确很重要，但这是建立在不会影响其他齿轮运转的基础上的。如果一个人的想法大于了实际能力、好奇心大于了责任心，这个人是不适合在社会生存的。
陈劲松 201731062132：
问题博客： https://www.cnblogs.com/fantapi/p/11512436.html
【对自己问题的回答】
-
对于个人开发流程，我觉得在文档与项目设计上应该花功夫，特别是项目设计，如果一开始项目设计没
做好，那么在后面的开发过程中会遇到很多问题，甚至有可能将前面的设计打翻，并重新来过。并且个人
开发流程应当严格遵守流程，而不要自己想当然的去做，这是我在实践过程所得出来的结论。 -
在这门课中，我亲身体会了一次结对编程，并且受益匪浅，认识到在结对编程上，两个人都应尽心尽力，
而不是将所有工程都交予一个人来完成，这样就失去了编程过程中学习他人编程技巧的作用，同时也可能
导致项目的失败。 -
针对这类需求，我会与团队中做需求分析的组员进行交流，而不是选择回避甚至不去理会。
-
应该通过亲身的项目实践来进行软件测试，而不是只看书而不进行实践。
-
这种情况下，就需要扩大采访用户人群，并加以整合，再对得来的数据进行详细的分析。
-
在初期的分配工作中，就应该详细的划分工作量，如在过程中有所改变，就应当及时告知编码人员，进行
相应的改动。
【通过这门课程学习到了】
- 对于前后端交互更加熟练
- 即时通讯的了解
- 熟悉了敏捷流程
【总结】
通过这门课程的学习，对于敏捷方法有了较为清楚的认识，并且通过亲身的项目实践，对于项目的开发
流程有了很好的掌握，同时明白了团队合作中交流的重要性。
沈墨 201731062115：
第一次个人作业： https://www.cnblogs.com/sm644245985/p/11477831.html
问题解答：
1.性格在结对编程过程中遇到的问题
第四章末尾提出了性格对合作的影响，我认为在结对编程的过程中，应该把两人的性格合适放在首位。工作是建立在合作的基础上，两个人合的来才是展开工作的前提。至于编程水平和擅长领域，这些是可以慢慢提升，在合作的过程中提升自己，让自己达到合作需要的要求，只是会花费一些时间，差别越大需要的时间也就越多。所以优先选择性格合适，然后才是选择能力接近。这对开发的影响最小。
2.“让人惊喜的功能，会极大提高用户的满意度”
让人惊喜的功能，往往很难设计出来。更多的情况是，用户根本不觉得这个功能有用。所以在之前我提出把有趣的功能“藏着”，未来在竞争中逐步放出展示自己的独特。我认为这种做法确实不切实际，功能在用户体验上，还是应该广撒网，把自己的想法全部实现出来，“让人惊喜的功能”往往就藏着其中。
3.软件服务是否要考虑满足少数人的要求
未来软件服务的领域会越来越广，而且现在也已经足够广了。而今天的少数人，也可能成为未来的多数人。满足少数人的需求，可以帮助软件有更好的拓展性。例如我们团队项目中的移动端，我们考虑到可能会出现没有网络，但需要使用我们软件进行记录的情况。于是添加了离线登录的功能，而这一功能在未来却可以拓展为在我想要上传我的记录时，我才使用在线登录。这也许会变成一个让人惊喜的功能。因此考虑少数人和少数情况是非常必要的，这能够提升软件的灵活度。
4.牺牲质量来提升用户体验度是否合适
用户体验非常重要，用户基数，决定了软件发展的上限。如同AB站、微博、知乎等社交媒体和原创平台，这些社交软件的工作方式是让用户与用户互动，例如知乎上是由用户提问又由用户解答，B站是是由用户UP主发布视频，又由用户观看视频产生流量。B站凭借弹幕这一提升视频播放器体验的方法，成为了全国数一数二的视频网站。但其网站质量却有很多缺陷。这些缺陷可以在后来慢慢修复，现在也已经修复了很多。所以在软件初期，牺牲少量的质量来提升用户体验度是有必要的。但是牺牲的质量，不能影响了体验度，例如为了美化界面导致打开网页的速度太慢。
5.关于专和精的关系，一点自己的看法。
我作为一名在校学生，精通一项技能是闯荡社会所需要的。但也需要广撒网，丰富自己才能走的更远。全栈工程师更适合小型的公司，但我们毕业时更应该去大公司开拓视野，积累更多的经验。所以练好自己的“敲门砖”是很必要的。
新产生的问题
课程中学习很多项目管理的内容，但在小组工作中，自己的体会不是很深刻。在选择管理者的时候，是应该按照技术丰富还是协调能力来选择？技术丰富的管理者，虽然更能掌控项目的开发，但团队中技术较弱的人比较多时，进度总会让他不满足。而技术不足的协调能力强的人，更能让团队中每个人都在做事，但对于开发的过程不能很好的掌控。
学会的技能
在小组开发的过程中为了进行移动端的开发，学会了android的许多技术以及GIT源码管理工具的使用。
以及原型制作，Axure和墨刀的使用。以及在赶项目的时候对网页前端框架进行了学习。
课堂上讲述的项目管理内容，也丰富了我对软件开发过程的理解。
最后是博客的编写，过往个人作业的博客得分还算挺高，养成编写博客的习惯确实有助于记住学过的知识。
对课程的体会
这一门课程的作业相比其他的多了太多，但也让我们学到了很多东西。学习的内容也涵盖了我们以后要使用的各项技能，是非常有意义的。在变强的过程中总是很苦，很累的，坚持过来了，就可以收获非常多的东西。
干冰雪 201731062502：
问题博客： https://www.cnblogs.com/gbx123/p/11482527.html
问题一：
书中提到了敏捷开发的流程，其中我对第3点“经常发布可用的软件，发布间隔可以从几周到几个月，能短则短”这一观点保持疑问，如果开发产品已经上线，更新太快，用户能接受这个速度吗？就像我作为用户，我的电脑window系统，老是隔不了多久就会有更新，我很郁闷，每次更新都会让我的电脑很卡，我就直接关闭了更新。另一层面，作为开发人员，他们是不是会有更多的负担，不断地发布新东西，他们需要不断地改进，在不断地接受新产品，这样的项目，对开发人员要求是不是很高？
回答： 敏捷开发满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。敏捷开发的核心正是迭代式开发，增量交付，产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。开发团队和用户反馈推动产品开发，新的功能或需求变化总是尽可能频繁地被整合到产品中。
学完这门课，我认识到敏捷开发带来的好处：
- 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。
- 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
- 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。
- 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。
- 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
问题二：
一个软件由一个人完成的很困难，并且也极少有一个人完成。所以大家会选择共同合作中一个项目，在第五章已经例举了一些团队模式，虽然目前在学校没有完成过一个大的项目，但通过分组进行一些小的程序设计，在团队中每人要负责一个模块，当组长分配任务时，有些模块大家都觉得难，而不愿意去做，有些模块比较简单而大家都愿意做，这样很难分工，这时该如何分工，才能算是一个团队的和谐合作？从而提高效率。
回答： 学完这门课，在团队实践开发过后，我意识到，学业过程中不是要让会的同学去完成他之前就会的任务，我们小组采取的是，一带一的开发模式，不同的成员会不同的技术，当两个人组合在一起时，他们是互补的。这样的可以拓展成员的学习广度，也更快促进了项目进度。如果让前端人员去做后端搭建，那他得从零开始，如果让后端人员只负责后端开发，不来接前端模式与进度，这也同样会让开发减慢，在相互了解，相互学习中更能促进整个项目的完成。
问题三：
用户界面的设计特别重要，这对前端工作者来说尤为重要。就日常人们所说的“第一印象很重要”。从而用户体验也是非常重要的，因为软件的目的是满足用户的需求，要从用户的角度考虑问题，课本中所指的“同理心”P（251），由于我们跟别人的想法不同，对事情的看法、解决方法也是不同，面对大量的用户，又该如何理解别人的心理、动机能力？
回答： 通过团队合实践吗，我们小组在完成alpha版本的时候，前端界面是极其不统一的，而且在同学们测试的时候，也对我们项目提出了很多关于界面的建议。我们为了达到用户的标准，在beta版本的时候，对前端页面进行了很大的重造。产品是为用户提供的，满足用户需求是我们开发人员一直所追求的，在提供给用户的测试中，我们可以收到很多用户反馈的建议，这些东西便是我们增进产品友好程度的重要标准。一切需求来自用户，我们不能以自己的标准去衡量自己开发的产品是否能满足大众。让产品去面对大众，这样才能从大众那里收到反馈，我们才能更好地改进。
问题四：
软件测试如果没有专门的测试人员，会造成什么样的后果？一般来说，程序员检查自己的代码时很难发现bug，因为他在测试时会按照自己的代码流程测试，所以很难发现问题所在，如果有条件我认为一定要有专门的测试人员，但是市场上有一些团队就缺少测试人员，一人身兼多职，这样会给项目造成什么样的后果？他们遇到哪些问题可以放到后期再去处理？
回答： 我们小组在阶段性开发结束后，是组内设计人员进行了一些列相关测试。我认为设计人员可以担任测试一职，他们比开发人员更能懂得产品需求，他们更能以用户的角度去检验我们产品的水准。在开发团队中一般设计人员负责项目前期设计工作，而在设计结束以后，这些成员的任务仿佛就没有了，而开发人员这时却是要完成很大强度的工作量，如果在开发人员开发到一定阶段，需要对前期开发程序进行测试的时候，这时设计人员就可以担任这份工作，以减轻开发人员的工作量，也使得资源充分利用，减少团队资源消耗。
掌握到的技能：
经过这学期的学习，我通过小组合作，团队开发，线上学习，编程训练，更加深刻地了解了前端框架的使用，学习了前端一些常遇到的浏览器兼容问题，学到了前后端交互的开发过程。更加学习到了敏捷开发模式的流程，体会到了团队开发过程中交流的重要性。
总结：
这学期经过这么课程的学习，我意识到了项目管理并不是那么简单的一件事，以前觉得做开发是最难的，觉得学习技术是最难的。但是，现在看来，再看开发过程中，技术不会，可以反复练习，熟能生巧。而项目管理是需要整个团队齐心协力的合作。在以后的工作中，完成任务的同时，我也会更加注重整个团队的合作。
