团队作业第六次—事后诸葛亮
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/2019FZUSEZ/homework/10151 |
| 团队名称 | 8rookies |
| 作业正文 | https://www.cnblogs.com/yantu/p/12044570.html |
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决问题：为广大考研学子提供考研相关信息，包括考研资讯，真题，参考资料，同时提供平台供交流咨询
- 定义：相对清楚
- 描述：相对清晰
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 基本达到目标
- 原计划功能基本实现
- 按原计划时间交付
- 自身原因限制，关于用户方面没有相关数据
3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 团队软件工程质量有一定程度的提高
- 团队协作得到提升，配合更为默契
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户方面没有达到
- 逐渐接近目标
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 团队协作应更加充分，进行更多交流
- 提升团队工作效率，注重用户方面
计划
1.是否有充足的时间来做计划?
- 时间相对紧张
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 由于之前没有接触过软件开发，制定计划没有太大的冲突，总体上是有想法提出时没有得到反对，有异议的情况会集体讨论斟酌
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 大部分完成
- 时间不够充裕，自身技术水平限制
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
- 有但总体不多，主要由于初期前后端及数据库负责人区分较为明显，缺乏沟通
5.是否每一项任务都有清楚定义和衡量的交付件?
- 基本清楚
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 基本按计划进行，意外更多是因为技术问题限制
- （你们看着补啊，没有记得删）
7.在计划中有没有留下缓冲区，缓冲区有作用么?
- 有缓冲区
- 作用：在陷入开发瓶颈时还有时间完成开发计划
8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 明确计划的详细步骤，留下缓冲区
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 进行开发前对自身技术水平进行详细的认知
- 制定详细的开发计划
- 明确所有人的开发部分，限定时间促进工作效率
资源
1.我们有足够的资源来完成各项任务么?
- 资源相对不足
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
- 没有注重精度问题
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 时间，人员不足（由于掌握的人员过少）
- 没有低估无需编程资源难度
4.你有没有感到你做的事情可以让别人来做（更有效率）?
- （记得补充）
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 在有限资源的情况下合理安排各项资源的分配
- 尽可能争取相对充足资源，首要提升自身
变更管理
1.每个相关的员工都及时知道了变更的消息?
- 相对及时
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 线上讨论，互相通知
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 相对清晰
4.对于可能的变更是否能制定应急计划?
- 能，但效果不大
5.员工是否能够有效地处理意料之外的工作请求？
- 能
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 加强团队成员间的沟通方便工作的变更
- 开发工作前组织好团队成员的集合，提前制定应急计划
- 最需要改进的还是团队成员的技术问题，大部分人并没有开发经验，也没有较好的教程来学习。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作是在做项目需求分析的时候完成的，主要由做原型设计的同学设计，大家也会讨论决定。
- 是
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有，小组讨论解决，技术人员拥有主要话语权
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 没有
- UML文档比之前设计的少了一些功能，删除了一些认为对用户帮助不大的功能
- 是
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 前后端交互功能产生的bug最多。因为这一块的代码逻辑比较复杂，需要考虑的方面也比较多，而且不熟练，BUG很多。
- 测试版中出现了后台服务未能保活的bug
- 对项目的难度估计错误
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 代码复审由审查者评审代码的格式、风格、命名是否符合规范。
- 否
- 应严格执行代码规范
- 严格执行代码规范，对代码结构进行必要的优化
测试/发布
1.团队是否有一个测试计划？为什么没有？
- 有
2.是否进行了正式的验收测试？
- 否
3.团队是否有测试工具来帮助测试？
- 否
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 并没有测量和跟踪软件的效能
5.在发布的过程中发现了哪些意外问题？
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 并未能发布，仍有较严重的问题未能解决
团队的角色，管理，合作
1.团队的每个角色是如何确定的，是不是人尽其才？
- 根据每人自身的技术水平决定自身角色
- 基本做到人尽其才
2.团队成员之间有互相帮助么？
- 互相帮助的情况经常出现
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 还没出现这方面的问题，大家都互相帮忙，合作得挺愉快的。
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- CMMI一级，成员依赖基础所制定的计划完成，缺乏经验
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合阶段
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 各方面得到小幅度提升
4.你觉得目前最需要改进的一个方面是什么?
- 自身技术水平
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?
请列出具体的事例。
- 都做得不是很好
| 成员 | 贡献比 |
|---|---|
| 李承泽 | 13% |
| 林斌祥 | 13% |
| 柯禧帆 | 13% |
| 叶琦熠 | 12% |
| 周丽榕 | 11% |
| 吴雅虹 | 11% |
| 张昊 | 12% |
| 刘英杰 | 15% |
