团队第六次作业——事后诸葛亮
一、作业描述
| 这个作业属于哪个课程 | 2019秋福大软件工程实践Z班 |
|---|---|
| 这个作业要求在哪里 | 团队第六次作业——事后诸葛亮 |
| 团队名称 | 碎阅创造营 |
| 这个作业的目标 | 项目事后诸葛亮 |
| 作业正文 | 碎阅创造营——事后诸葛亮 |
| 参考资料 | 项目管理之事后诸葛亮会议 |
二、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 软件项目要解决的问题：收集分类整理各种碎片化信息，定时督促用户浏览
- 定义清晰
- 对典型用户和典型场景有相对清晰的描述
2. 我们达到目标了么？
- 原计划的功能基本实现
- 按照原计划的交付时间交付了
- 原计划中没有列出用户数量要求
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 团队软件工程的质量有明显的提高
- 团队会议效率、团队成员配合完成度、任务计划和分配合理情况等方面都有所提高
- 标准衡量：各功能完善情况及对应的花费工作量
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 原计划中没有列出用户数量要求，且目前只在开发测试阶段，因此还没推广，没有用户量
- 我们已经实现了大部分基础功能，距离目标已经更近一步了
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 应该提早进行开发，前期写文档和学技术花费的时间较多，导致冲刺的时候时间紧张
三、计划
1. 是否有充足的时间来做计划?
- 有，在需求分析、系统设计和数据库设计期间已经定制了初步计划，在项目冲刺开始前完善具体了任务计划和分配情况
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 开会期间一起讨论，团队成员们积极提出各自的意见，若有分歧，大家一起分析商量出最优方案
3. 原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 基本完成原计划的工作
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 基本没有，每份付出都会在将来以不同的形式体现其价值，有的是教训，或是经验积累
5. 是否每一项任务都有清楚定义和衡量的交付件?
- 是，每一项任务都有基本的明确目标，冲刺阶段会做每日汇报和演示，且各自测试验收后，最后统一验收测试
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- API版本不兼容，配置花费了大量时间
- 没有Android开发经验，且属AS导入项目的常见问题
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 冲刺时间紧张，没有留下缓冲区
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 将来会根据任务的难度和团队成员可安排的时间适当调整每天的工作量情况，并预留1-2天的缓冲区
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 细化分工，在任务安排和分配时综合考虑，在一个合理的情况下达到最优的目标，按照计划时间及时测试和验收。
四、资源
1. 我们有足够的资源来完成各项任务么?
- 技术资源较为短缺，基本花费大多的时间来学习，边学习边开发
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 有一个初步计划，任务进行中根据实际情况进行调整
- 精度开始时较为粗略，实现过程中逐步讨论完善
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试方面，各模块及时自行测试，没问题后，会再进行统一测试，硬件方面基本满足
- 美工设计/文案方面低估了难度
4. 你有没有感到你做的事情可以让别人来做更有效率?
- 没有，基本根据团队成员想要学习的方面进行分工
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 团队资源安排上需充分考虑到任务难度及实现情况，团队内及时交流进行情况，尽量避免成员任务分配不均、实现难度相差甚大
五、变更管理
1. 每个相关的员工都及时知道了变更的消息?
- 是的，有每日会议，也会在团队群内进行交流讨论
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 根据功能重要性及任务实现难度和实际进度，团队交流讨论统一意见
3. 项目的出口条件（什么叫“做好了”）有清晰的定义么?
- 在需求报告里的界面需求、功能验收等模块中有比较清晰的定义
4. 对于可能的变更是否能制定应急计划?
- 能，队员响应速度快，团队能及时提出突发情况，并及时进行相应的调整
5. 员工是否能够有效地处理意料之外的工作请求？
- 基本没有意料之外的工作请求，大多在计划中进行
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 经常沟通交流，群内及线下及时通知变更消息，尽快讨论制定出应急计划
六、设计/实现
1. 设计工作在什么时候，由谁来完成的？
- 在项目需求分析的时候完成的，由团队成员一起完成的
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 没有，基本都是成员统一意见的结果，都能在工作开展前做好决定
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 有运用单元测试、UML等工具来帮助设计和实现
- 都有显著的效果。单元测试有效地保证了每个部分的正确性，使用uml更好地理清类、对象等之间的关系。
- UML图有更新补充，需要更新UNL文档。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 剪贴板检测功能由于开发难度较大Bug较多
- 发布后部分界面没有返回键，影响页面间交互
- 原型设计存在缺陷，后期开发没进行统一整理
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 代码复审比较仓促，由专人负责检阅
- 有提前统一代码规范，整合时再进行检查，但部分命名不规范未修改
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计工作时需要尽可能的接近团队实际情况，尽量合理的安排任务。要统一代码规范，并且严格执行
七、测试/发布
1. 团队是否有一个测试计划？
- 有,文档工作以及冲刺阶段皆有定制详细计划
2. 是否进行了正式的验收测试？
- 已进行正式的验收测试
3. 团队是否有测试工具来帮助测试？
- 无
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 人工手动测试，模拟器调试
- 有用，可以在开发过程中查找不足
5. 在发布的过程中发现了哪些意外问题？
- 版本不兼容，Android版本低的部分手机无法运行
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 需要制定完整有效的测试计划，运用适当的测试工具提高测试效率
八、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
- 基本时根据团队成员想要学习的方面或者擅长的部分确定的
- 基本上是人尽其用
2. 团队成员之间有互相帮助么？
- 有，无论是线上线下都乐于帮助队友解决难题
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 团队成员及时讨论交流、汇报实际进度和完成情况，基本没有出现问题
感谢环节
-
苏杰隆：我感谢林震对我的帮助，因为他在队长最困难的时候担起了团队的领导任务
-
陈毅东：我感谢苏杰隆对我的帮助，因为他帮我找到了实用的教程和范例
-
林涛：我真心感谢陈毅东对我的帮助，因为他在Android studio的使用上给予了我帮助，让我更快的入门
-
刘新耀：我感谢陈毅东对我的帮助，因为他在代码调试上帮助了我很多
-
卢昱妃：我感谢全体成员对我的帮助，一个项目的完成与团队中每个成员的努力都不可分割。从互不认识的八个人，到一起合作完成项目，感谢每个成员对我的耐心和帮助。
-
蓝飞鹏：我感谢苏杰隆对我的帮助， 因为他在我不知怎么做项目时为我指明了方向
-
林震：我感谢苏杰隆对我的帮助，因为他借我手机进行调试，并且对我的代码提出了一些有益的建议
-
黄淑云：我感谢全组队员对我的帮助，组内学习交流氛围很好，互相学习，互相分享，为求更好地实现项目。这八个人是一个整体，缺了谁都是不完整的，缺了谁都很难会达到目前的完成情况，再次感谢全组同学。
九、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- CMMI二级，管理级。对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范阶段
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 大家的配合更加默契
4.你觉得目前最需要改进的一个方面是什么?
- Github 版本控制
十、事后诸葛亮会议照片
十一、各组员对于最终项目成果的贡献度
| 组员 | 工作量比例 |
|---|---|
| 苏杰隆 | 12% |
| 陈毅东 | 12% |
| 林涛 | 10% |
| 刘新耀 | 10% |
| 卢昱妃 | 10% |
| 蓝飞鹏 | 10% |
| 林震 | 18% |
| 黄淑云 | 18% |
