第04组 Beta冲刺 总结
2.1 基本情况
组长博客链接：
答辩总结
- Beta冲刺完成了大部分功能，接下来就是完善各个部分功能还有项目上线了
全组讨论的照片
评估贡献比例
- 工作流程
- 确立待完成功能
- 完善功能
- 功能测试
- 完善界面
- 组员分工
| 姓名 | 分工 | 预计贡献比例 |
|---|---|---|
| 林锦龙 | 管理项目进度，完成延迟购买功能 | 9% |
| 王昱 | 爬虫数据处理 | 11% |
| 沈明镇 | 爬虫数据处理 | 8% |
| 曾杰楷 | 爬虫数据处理 | 7% |
| 陈子杰 | 完善传参 | 12% |
| 林昊炜 | 设计标签 | 6% |
| 陈嘉辰 | 设计标签 | 7% |
| 刘京一 | 完善折线图 | 13% |
| 鲁任 | 美化界面 | 12% |
| 陈嘉龙 | 收藏功能 | 8% |
| 刘佳润 | 首页推荐，答辩演讲 | 7% |
2.2 参考模板进行总结思考
2.2.1. 设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件是辅助大学生购物，帮助大学生进行购物决策，推荐大学生生活里可能需要的各种优惠好物的小程序。
- 定义的十分清楚，就是针对大学生的购物痛点。
- 典型用户与场景：
- 想要购物但是存在选择困难的大学生可以通过首页推荐来选取好物
- 想要购买商品但想要等待价格降低的用户可以通过延迟购买功能来实现降价提醒
- 想要了解商品信息可以通过商品界面的数据图了解信息
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 还未达到目标
- 除去首页推荐和折线图，其他都完成了
- 对于用户数量因为功能还没完善，所以还没达到
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 对于用户数量因为功能还没完善，所以还没达到
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 经验教训：分工时应该分的更细致一点，而且最好应该先了解好开发流程再进行分工
- 改进：我们会进行更加合理的分工，并且一开始就限定好商品的范围，减少不必要的时间浪费
2.2.2. 计划
- 是否有充足的时间来做计划?
- 有，开发初期我们特意开了数次会议进行计划
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 开会解决，通过开会讨论，消除分歧
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 大部分完成了，对于最后一个界面，数据还没有完善
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 暂时没有，目前来看开发到现在都是挺有意义的
- 是否每一项任务都有清楚定义和衡量的交付件?
- 有，对于对应任务都有要求做到什么程度
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 是，都在按照计划进行，没有什么意外，风险的话，可能就是爬虫难度比较大吧，因为淘宝反爬难度比较大
- 在计划中有没有留下缓冲区，缓冲区有作用么?
- 有，缓冲区用来大家交流心得
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 暂不做修改，继续保持原有节奏开发
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了小程序的开发流程，前端和后端对应的知识
- 改进：我们会进行更加合理的分工，并且一开始就限定好商品的范围，减少不必要的时间浪费
2.2.3. 资源
- 我们有足够的资源来完成各项任务么?
- 有，人手足够，时间还行
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 通过开会并且查阅相关资料，估计得出
- 精度:理论上还算准确
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 对于人力和软件/硬件资源，目前来看是足够的
- 对于那些不需要编程的资源 (美工设计/文案)，低估了一些难度
- 你有没有感到你做的事情可以让别人来做（更有效率）?
- 没有，团队分工还是挺合理的，每个人都有自己擅长的事
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 经验教训：分工时应该分的更细致一点，对于人手的分配要做好
- 改进：我们会进行更加合理的分工，并且对于美工要更加注重
2.2.4. 变更管理
- 每个相关的员工都及时知道了变更的消息?
- 是的，我们采用了微信开发者平台，共同使用一个仓库
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 我们通过开会讨论得出
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 有，有制定对应的接受标准
- 对于可能的变更是否能制定应急计划?
- 有，比如爬虫，我们就有加派人手或者付费接口的计划
- 员工是否能够有效地处理意料之外的工作请求？
- 是
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 对于变更，其实一开始应该说好不能随便上传，否则会有点乱
- 改进：应该加强上传管理
2.2.5. 设计/实现（4分）
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 在开发初期就由大家开会统一完成，由项目经历领队，大家统一讨论，有不同意见也能马上处理
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有，对于某一功能的设计存在争议，通常是直接讨论消除争议
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 有利用UML来设计类图，这些工具提高了我们设计的效率
- 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 完善一些功能的描述，进行实地开发时遇到了困难，对其进行了修改，已经更新了UML文档
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 爬虫部分遇到的BUG最多，因为数据的格式不好统一，项目还没发布，后续BUG还没发现
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 通常由对应功能负责人来复查，严格执行代码规范
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 对于BUG的处理，代码规范的设定
- 改进：设立更合理的代码规范，并严格执行
2.2.6. 测试/发布
- 团队是否有一个测试计划？为什么没有？
- 团队有对应的测试方案，包括推荐功能，延迟购买等
- 是否进行了正式的验收测试？
- 功能还没开发完全，还没正式验收
- 团队是否有测试工具来帮助测试？
- 功能还没开发完全，还没正式测试
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 目前还没开发完成，也就没有对应测试
- 在发布的过程中发现了哪些意外问题？
- 未发布
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 测试计划的设立
- 改进:应提前做好对应的测试计划，保证发布的可行性
2.2.7. 团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
- 通过讨论分配，完成了人尽其才
- 团队成员之间有互相帮助么？
- 有，大家聚在一起开发时互帮互助，线上开发时也在群里讨论
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 开会统一解决
- 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
- 我感谢王昱对我的帮助，帮我做了很多事情，很有条理，让我能清楚的完成自己的任务。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 对于团队的分配和管理要合理
- 改进：增加团队成员的互动，提高队伍磨合度
2.2.8. 总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 团队目前已经达到了CMM/CMMI的第二级，可重复级。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合阶段
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 团队和磨合程度大幅度提升
- 你觉得目前最需要改进的一个方面是什么?
- 团队的时间安排吧，接下来学习任务也很紧
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈，团队多次进行会议讨论协商
- 团队要定期反省如何能够做到更有效，并相应调整团队的行为，我们每隔几天会进行进度讨论，及时调整团队方向
