学期总结
|
这个作业属于哪个课程 |
|
|
这个作业要求在哪里 |
|
|
团队名称 |
都城 |
|
这个作业的目标 |
学期总结 |
一、个人信息
姓名：蒋庆
学号：201731062117 第一次阅读作业
二、问题追溯
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. 提高软件的信息查询和处理能力；
三、产生的新问题
问题一：我们在团队合作中，经常效率很低，那么团队合作中应该如何高效的沟通？
问题二：在团队合作中，团队成员的代码应该如何合并？
四、经过这学期的学习，掌握到的新技能
五、心得体会及收获
经过了一学期的学习，使我对这门课最开始的看法也发生了改变，一开始我以为这门课全是概念的东西，其实不是，更重要的是从团队中学习，团队的学习让我收获了很多，也让我发现了很多自己的不足。①让我学会了团队合作，虽然一个人的效率是最高的，但是一个人的能力更是有限的，因此团队合作也很重要；②自学能力的提升，团队项目的开发过程中有很多的知识盲区，只能自己去自学；③学会了在网络上寻找各种资源（学习资料、视频等）以及寻求帮助（知乎、CSDN等）；④各种软件开发工具的使用，如开发工具VS2017，源代码管理工具github等；⑤学会了坚持，软件开发过程中难免熬夜什么的，必须赶时间做完，即使类，也不能说放弃；⑥软件开发过程虽然很累，但是软件开发出来使用软件时的成就感是无与伦比的。
