Beta冲刺 总结
基本情况：
组长博客链接：here
答辩总结
本次beta冲刺，我们小组完成度相对较高，组员也人尽其职。在答辩时老师提出的问题我们也相应给出了回答，老师提的意见我们也有考虑进未来程序设计的优化。本次答辩结果我们感觉上可以给自己打个八十分，虽然小程序还不很完善，但每个人都努力完成了自己负责的内容，希望后续可以做到更好。
全组讨论的照片
工作流程
| 前端工作流程 | 后端工作流程 | beta冲刺轮次 |
|---|---|---|
| 编写筛选页面 | 新增管理员类、表；引入商家图片；域名审核通过 | beta-1 |
| 页面美化,上拉刷新 | 完成管理员相关的控制层和前端大部分的查表页面（查找） | beta-2 |
| 授权页面修改添加新用户跳转值标签修改页面添加菜品页面添加 tag 功能菜品和窗口页面分享申请小程序发布,获取体验版小程序 | 新增管理员标签管理相关；做nginx的https转发 | beta-3 |
| 修复小程序在 andriod 上显示不好的 bug首页添加食堂拥挤功能修复页面跳转bug小程序通过审核 | 添加食堂拥挤程度接口；添加查找菜品对应窗口的功能；添加查找对应食堂所有窗口功能；添加管理员前端页面删除逻辑 | beta-4 |
| 修复小程序在 andriod 上显示不好的 bug修复页面跳转bug | 添加根据标签筛选菜品对应窗口功能；添加管理员前端页面返回逻辑；添加地图图片；修复热门比较器的bug | beta-5 |
组员分工及成绩分配
| 姓名 | 本次完成任务 | 成绩占比 |
|---|---|---|
| 吴仕涛 | 细节商定，地图绘制，产品测试，文档 | 12 |
| 林逸丽 | 打标签、评分、测试bug | 4 |
| 邹薇 | 图像压缩处理，编写dish的模糊查询并编写相应的测试代码 | 6 |
| 高逸超 | 产品测试 添加标签 | 4 |
| 林怡琳 | 产品测试、添加标签 | 6 |
| 傅兴佳 | 完善持久层接口 | 6 |
| 王祺 | 管理员的实体类、控制层及前端页面；搜索/筛选接口的实现；食堂拥挤程度接口的实现；部署图片；做oos触发器；修复热门排序比较bug | 25 |
| 沈帅 | 测试接口、添加标签 | 4 |
| 李志炜 | 添加标签、产品测试、评分 | 4 |
| 苏炜杰 | 前端页面新功能编写,修复前端bug,页面美化,协助后端配置ssl,https,上架小程序 | 25 |
| 王佳欣 | 产品测试 | 4 |
总结思考
2.2.1. 设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的小程序针对的是校内师生来到食堂会摇摆不定犹豫无法决定吃什么的痛点，希望做出一款小程序可以根据大家的口味帮忙决定吃什么。其中，用户只需要根据我们的算法推荐就可以得到结果，解决了普遍存在的“选择恐惧症”。小程序的定义还是比较清楚的，这来源于我们生活中自己也遇到的问题。在编写需求规格说明书时，我们对典型用户进行了清晰的定义，并且通过问卷调查明确了市场上是存在对于我们的小程序的需求的。
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
原计划的目标大部分都已经完成。按照原计划交付时间交付了，原计划用户量已达到。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量与预期一致（已有400用户），当最终产品出来的时候，我们团队成员对我们实现的结果还是很满意的，我们与我们既定的目标已无限接近，期待我们的最终版本吧！
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：在项目的规划阶段对于一些具体细节的思考太少以及提前沟通不足。例如在实施前觉得都讨论的差不多了，但具体实践时具有难度不得不多占用一些时间去修改前面的错误。
改进：提高自己的编程能力、以及对于编程语言和框架的熟练度很有必要。
2.2.2. 计划
-
是否有充足的时间来做计划?
前端部分已经分配好任务，时间上是充裕的，大家都各司其职，贡献自己的力量。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们小组任务分配合理，大家都认真完成自己的任务，小分歧大家会协商讨论，最终统一，love & peace
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有完全做完。没做完的原因：没有考虑到不同成员有可能在不同时期有考试，不少工作都是组长加班加点完成，但还是没有完全完成。
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，该踩的坑还得踩。
-
是否每一项任务都有清楚定义和衡量的交付件?
每一项任务都有清楚定义，前后端负责人根据成员能力合理衡量。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
大部分过程都按照计划进行了，项目的意外就是在最后要发布的时候发现了很多bug，修了一整天。风险预估到了，所以修bug还是预料中。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
有留下一点缓冲区，缓冲区很有用，会继续留缓冲区。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
感觉目前整个团队的态势发展良好，只要维持住目前的节奏就好了。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
《人月神话》，第二章写着“系统编程的进度安排背后第一个错误的假设是：一切都将运作良好，每一项任务仅花费它‘应该’花费的时间”。所以该走的弯路不会少的。
2.2.3. 资源
-
我们有足够的资源来完成各项任务么?
没有，组内大部分成员都没有开发项目的经验，大家都是在边学边做中完成的，但通过学习网络上的资源，不断提升自身能力。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需时间和其他资源由具备开发经验的成员决定，精度较高。
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间、人力较为充足，测试需要的软件/硬件资源不足。对不需要编程的资源有点低估难度了。
-
你有没有感到你做的事情可以让别人来做（更有效率）？
没有，每个人都能发挥自己的特长，把自己做的方面做到极致（至少是我们组的最高水平），所以说每个人都是不可替代的。
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果任务布置能更精确就好了，这样子有利于项目进度的把控。
2.2.4. 变更管理
-
每个相关的员工都及时知道了变更的消息?
是的，每个人都能及时知道消息。团队总的有一个交流群，前后端小组分别有一个交流群，沟通很方便。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据实际情况决定功能的必要性。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
界面舒服美观且计划实现的功能能够顺利执行，不出现严重bug。
-
对于可能的变更是否能制定应急计划?
能，团队成员互相帮助。
-
员工是否能够有效地处理意料之外的工作请求？
能，团队成员人数充足，能够较好地解决。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
体会到了团队协作的重要性，我们学到了如何更好地在一个团队中发挥出应有的作用。改进：做好应急计划，避免出现不可预料的状况。
2.2.5. 设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作由吴仕涛和苏炜杰完成，很合适。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有模棱两可的情况，苏炜杰有很高话语权。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
前端在后端没有正式部署的时候使用mock数据来测试网络请求和页面状态,使用微信小程序开发工具的 Audits 工具来测试页面的性能,用 typescript 给 js 加上类型来规避开发阶段的类型 bug,前端的几个工具函数都有使用 jest 来单元测试.
-
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没区别
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
后端与前端对接时产生最多bug，因为没有讨论好细节。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
前端有一个主仓库,每个组员都 fork 了一份到自己的 github 上,提交到主仓库必须使用 pull request,这样可以做到每个提交都做到 前端负责任的 code review
前端使用 eslint 和 prettier 来规范代码,开发时每次代码更改都会检查规范
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了debug能力，改进就是提高沟通效率。
2.2.6. 测试/发布
-
团队是否有一个测试计划？为什么没有？
没有测试计划，但是在最后测试的时候发现了原来没有考虑到的问题。
-
是否进行了正式的验收测试？
有部分完整测试。
-
团队是否有测试工具来帮助测试？
后端使用postman对每个情况都进行了测试。
前端使用微信小程序开发工具的 Audits 进行页面性能测试, jest 进行单元测试 , mock 进行接口测试
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
暂未进行完整的测试计划，未来会有标准的测试方法。
-
在发布的过程中发现了哪些意外问题？
发布没有发生太多意外，在演示时出现了部分显示错误的情况。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
假如能重来，后端需要更加积极的交流，前端组内也写上技术文档，提高前端界面质量。
2.2.7. 团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
团队的成员角色是根据能力匹配，一个萝卜一个坑，每个人都有自己的定位，在任务分配已经尽最大可能实现人尽其才。
-
团队成员之间有互相帮助么？
团队成员互相帮助是在我们小组非常常见的事情，前端组长和后端组长尽职尽责，帮助组员成长，平时工作时有问题都能里及时解决，互帮互助。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
出现问题我们及时沟通，及时去修复bug，但是确实经验比较不足出现问题越发现越多。
-
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢王祺对我的帮助， 因为他很帅。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学会了要加强沟通，很多前期的沟通和深入设想会帮助后面避免很多bug和冲突。学会了更好更有效的任务分配以及会议记录，及时调配任务。
2.2.8. 总结
-
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们的团队还不够成熟，在本次的beta冲刺中对程序的开发，我们属于CMMI的CMMI一级，执行级。在执行级水平上，软件组织对项目的目标与要做的努力很清晰，项目的目标勉强可以实现。但是由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。
-
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们的团队目前传出去尽量往规范化发展的一个阶段，我们队员能力参差不齐，团队内部沟通也是尽量让每个人能有事情去做，每个任务能够努力完成
-
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
我们相对于之前立下的目标来说，每个人都有一点进步，在本次beta冲刺阶段都有一定的成长，当然写了很多bug，也遇到了很多困难，我们的团队都付出努力去完成。有一颗进取的心是我们团队最大的收获。
-
你觉得目前最需要改进的一个方面是什么?
最需要改进的是我们的沟通问题，很多时候有一些可以避免的bug，一些可以减少的代码量都是可以提前沟通去解决的。在后面的每周冲刺中，我们会加强我们内部沟通，有更快的效率去完成我们的程序开发。
-
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
参照《构建之法》P114页的敏捷开发原则，回顾我们的Alpha冲刺过程，我们做得比较好的有：
第四条：“业务人员和开发人员在项目开发过程中应该每天共同工作”。团队现场编程是常有的事。
第五条：“以有进取心的人为项目核心，充分支持信任他们”。前端组和后端组各有一名组长，分组管理，在他们的带领下每一个组都把各自的工作完成的不错。
第六条：“面对面的交流始终是最有效的沟通方式”。例如Alpha站立会议、团队编程、开会讨论等等。
第九条：“不断关注技术和设计，才能越来越敏捷”。例如：前后端之间采用了showdoc进行API商定，形成文档；后端组使用了swagger框架，在配置后可形成可测试的API文档，前端访问相应路径，便可以直接查看后端的整个控制层（即路由API），并且可以在上面直接进行API测试，而不需要POSTMAN，这样一来方便了不少，后端自己内部则采用JUnit进行单元测试。
回答测试组问题
你们没问