| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10863 |
| 团队名称 | soy-sauce-team |
| 这个作业的目标 | 团队项目的事后总结 |
| 作业正文 | https://www.cnblogs.com/lwbdui/p/13256286.html |
| 其他参考文献 | http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html |
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
提供一个可让让学生快速、准确找到自己所需要查找的网课课程app。定义的还算清楚。对典型用户和典型场景有清晰的描述
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
1.没有完全达到目标。我们系统注册功能未能实现，注册时数据不能保存至数据库，只能通过在数据库中手动添加用户登录信息，查询功能跳转时会出现页面崩溃的情况。系统还存在一些大大小小的问题需要改进完善。
2.按时间交付，但质量还是有比较大的问题
3.用户数量之前没有考虑
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一阶段相比，团队软件工程的质量还是有所提高，比如，最基本的在代码编写规范和测试方面，衡量的标准依据任务完成的效率和出现bug的频率。而且界面设计的也更美观了
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
不一致，和预先设想的有出入，但是功能大部分都实现了，也离目标更进了一步
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
会多了解一些有关框架的知识，把代码做规范，让每个团队成员都积极投入到项目中来
计划
1. 是否有充足的时间来做计划?
有充足的时间来做计划，因为都是第一次做团队项目，计划难免有些欠缺
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会聚在一起开会讨论，有时也会线上讨论，通过讨论得出一致的决定
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有，还有少许没做完。因为我们的技术还是有点欠缺，日后我们会强加学习的
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有吧，有时候我们讨论就会说想要实现哪哪的功能，结果到最后就完成不了。所以我觉得讨论问题还是要从实际出发，归根到底还是我们的技术不足
5. 是否每一项任务都有清楚定义和衡量的交付件?
有些有，有些没有
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
还是与原计划偏离了一点，有几个功能未实现，对自己团队技术水平估值不准确，有一段时间因为考试原因，github代码也忘了迁入
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有
8. 将来的计划会做什么修改？
从实际出发，考虑团队的技术因素，让计划更实际一点
资源
1. 我们有足够的资源来完成各项任务么?
有，但是我们利用的不是很完美，准备的也不足
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
借鉴了网上优秀的作品，大概估计了一下，精度的话没有做过多要求
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
足够。像美工的话确实低估了难度，还好这学期学了UI，帮助了不少
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有些确实可以，对工作分配的不到位
变更管理
1. 每个相关的员工都及时知道了变更的消息?
知道，我们有一个相关群，里面会及时发通知
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
在系统中起重要作用的功能和一些能设计完成的功能列为必须实现，其他无关紧要的和因技术因素导致无法实现的会相应的推迟
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
大概吧，一般某个功能或者部分完成了就称呼为“做好了”
4. 对于可能的变更是否能制定应急计划?
会召开线下讨论
5. 员工是否能够有效地处理意料之外的工作请求？
还好，一般有额外的工作需求就会在团队群里说明一下，大家都会积极讨论解决
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在对项目需求分析阶段，团队人员一起讨论完成的，合适的时间合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有这种情况，负责该工作的队员互相进行协商，解决不了通过组长帮助解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
1.没有用到单元测试和测试驱动开发。
2.使用到了UML和其他工具来帮助设计与实现。
3.有对UML文档进行更新。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
1.查询功能和添加人员信息功能，注册功能，与数据库的连接有问题。
2.发布之后还是上述的这些情况需要后续抓紧解决。
3.经验不足，考虑不周到。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审没有进行，只是利用工具对功能进行了检测，没有严格执行代码规范。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计方面应该多加考虑和符合现实能力的设计方案，让后面的工作能够顺利的开展，不
要好高骛远天马行空。实现方面 应该加大功能监测的力度和代码的审查。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，依据需求分析安排的的测试计划。
2. 是否进行了正式的验收测试？
已完成验收测试
3. 团队是否有测试工具来帮助测试？
有测试工具来帮助测试
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
1.没有进行测量和跟踪软件效能
2.测试工组还是对项目的开发有很大帮助的改进主要是多学习测试方法和测试工具的功能，在进一步的去改进测试工作
5. 在发布的过程中发现了哪些意外问题？
意外问题暂时没有
6. 我们学到了什么? 如果重来一遍, 我们会做什么改进?
多学习测试方法和测试工具的使用，多实践，提高测试效率，提高产品质量
团队的角色、管理、合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
我们组员之间一起讨论任务分工，工作任务根据个人能力和技术
2. 团队成员之间有互相帮助么？
有
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
小问题一般是私下沟通解决，大的问题组织一起开会解决。还可以通过调整工作任务安排处理问题
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了如何合理分配工作，我们会从组员工作量方面进行改进，有利于提高工作效率
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
应该都不属于，项目有些功能方面还存在大大小小的问题
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
应该还是处于萌芽阶段，这是第一次进行团队项目的开发工作，方方面面的还是没有经验。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
我觉得应该是从个人能力方面以及团队合作意识方面有了不少的提升
4. 你觉得目前最需要改进的一个方面是什么?
每个人的专业技术水平吧
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例
1.能做到有效的面对面交谈。
2.对不懂的问题，踏实的去学习和了解。
会议截图
