第02组 Alpha冲刺 总结

Alpha冲刺 总结

基本情况：

组长博客链接：here

答辩总结

本次alpha冲刺，我们小组完成度相对较高，组员也人尽其职。在答辩时老师提出的问题我们也相应给出了回答，老师提的意见我们也有考虑进未来程序设计的优化。本次答辩结果我们感觉上可以给自己打个八十分，虽然小程序还不很完善，但每个人都努力完成了自己负责的内容，希望下一次可以做到更好。

全组讨论的照片

工作流程

前端工作流程	后端工作流程	alpha冲刺轮次
搭建前端的开发框架，API的商定	搭建后端的开发框架，API的商定	alpha-1
首页窗口组件编写,mock框架引入	云服务器的部署，数据库的搭建，表的建立，实体层的设计	alpha-2
mock数据编写,授权页面编写,store设计和编写	做nginx的端口转发；域名的购买、解析与备案；各层逐步开始分析与设计	alpha-3
我的页面编写,网络函数设计,首页编写	完成各层接口的设计	alpha-4
窗口页面,菜品页面编写,网络状态提示组件编写	完成各层接口的实现	alpha-5
最爱的菜页面,收藏窗口页面,修改标签页面编写	逻辑上各种bug的修复	alpha-6

组员分工及成绩分配

姓名	本次完成任务	成绩占比
吴仕涛	部分文档，调配任务，宣讲ppt	3%
林逸丽	爬虫数据爬取	2%
邹薇	持久层部分接口实现和持久层部分测试	7%
高逸超	服务层部分接口实现	6%
林怡琳	编写假数据，对比更新api.ts，编写页面点击跳转	7%
傅兴佳	数据库建表、维护，持久层接口编写及部分实现	15%
王祺	后端框架的搭建，服务器的部署，实体层的设计，服务层的接口及部分实现，控制层的接口设计实现，与前端的对接、并处理json格式，服务层测试与bug修复	20%
沈帅	页面布局编写，假数据编写，体验-性能记录，编写网络接口	6%
李志炜	服务层部分接口实现	7%
苏炜杰	前端框架搭建,小程序注册部署,页面编写,和后端对接,和原型对接,协助后端测试接口,前端工具函数编写	20%
王佳欣	页面布局编写，假数据编写，新建页面编写	7%

总结思考

2.2.1. 设想和目标

• 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的小程序针对的是校内师生来到食堂会摇摆不定犹豫无法决定吃什么的痛点，希望做出一款小程序可以根据大家的口味帮忙决定吃什么。其中，用户只需要根据我们的算法推荐就可以得到结果，解决了普遍存在的“选择恐惧症”。小程序的定义还是比较清楚的，这来源于我们生活中自己也遇到的问题。在编写需求规格说明书时，我们对典型用户进行了清晰的定义，并且通过问卷调查明确了市场上是存在对于我们的小程序的需求的。

• 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

原计划的目标大部分都已经完成。在实际的开发过程中，我们将一两个功能放到了beta版本实现。核心功能有在alpha冲刺结束时按时交付。原计划团队内部测试，并没有用户使用。

• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量与预期一致（alpha阶段就我们内部使用），当最终产品出来的时候，我们团队成员对我们实现的结果还是很满意的，我们与我们既定的目标已无限接近，期待我们的beta版本吧！

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

经验教训：在项目的规划阶段对于一些具体细节的思考太少以及提前沟通不足。例如在实施前觉得都讨论的差不多了，但具体实践时具有难度不得不多占用一些时间去修改前面的错误。

改进：提高自己的编程能力、以及对于编程语言和框架的熟练度很有必要。

2.2.2. 计划

• 是否有充足的时间来做计划?

前端部分已经分配好任务，时间上是充裕的，大家都各司其职，贡献自己的力量。

• 团队在计划阶段是如何解决同事们对于计划的不同意见的？

我们小组任务分配合理，大家都认真完成自己的任务，小分歧大家会协商讨论，最终统一，love & peace

• 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

没有完全做完。没做完的原因：没有考虑到不同成员有可能在不同时期有考试，不少工作都是组长加班加点完成，但还是没有完全完成。

• 有没有发现你做了一些事后看来没必要或没多大价值的事?

没有，该踩的坑还得踩。

• 是否每一项任务都有清楚定义和衡量的交付件?

每一项任务都有清楚定义，前后端负责人根据成员能力合理衡量。

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

大部分过程都按照计划进行了，项目的意外就是在最后要发布的时候发现了很多bug，修了一整天。风险预估到了，所以修bug还是预料中。

• 在计划中有没有留下缓冲区，缓冲区有作用么?

有留下一点缓冲区，缓冲区很有用，下次beta会继续留缓冲区。

• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

感觉目前整个团队的态势发展良好，只要维持住目前的节奏就好了。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

《人月神话》，第二章写着“系统编程的进度安排背后第一个错误的假设是：一切都将运作良好，每一项任务仅花费它‘应该’花费的时间”。所以该走的弯路不会少的。

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，但是确实经验比较不足出现问题越发现越多。

• 每个成员明确公开地表示对成员帮助的感谢：

我感谢阿桶（苏炜杰）对我的帮助

（1）技术方面

在前后端交互的时候，涉及到了json的格式转化，我们的格式是这样的

{
    "code": "number",
    "data": {
        
    }
}

我写了好几遍bug，愣是搞不定，各种拆东墙补西墙，苏少教了我一招

public class JsonObject<T>{
    private Integer code;
    private T data;
}

这就搞定了！！！佩服！！！
害！惭愧惭愧，Java基础没学好，泛型没学到家啊！

（2）工作方面

像极了监工，是不是来督促我，嗯，老push了

（3）debug方面

我在debug的时候，他会在我旁边跟我一起debug，老手经验高超，加快了debug的速度

（4）团队方面

拉高了整组平均颜值，很棒😎

我还感谢傅兴佳对我的帮助

由于我的实体类和接口设计不当，因为我的失误，他经常要改数据库表结构，或者要新增接口，跟他交流时候他就马上“好”，一段时间后就搞定了，i了i了，还是比较省心的（虽然写过bug，但是绝对功不可没）

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学会了要加强沟通，很多前期的沟通和深入设想会帮助后面避免很多bug和冲突。学会了更好更有效的任务分配以及会议记录，及时调配任务。

2.2.8. 总结

• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

我们的团队还不够成熟，在本次的alpha冲刺中对程序的开发，我们属于CMMI的CMMI一级，执行级。在执行级水平上，软件组织对项目的目标与要做的努力很清晰，项目的目标勉强可以实现。但是由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。

• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

我们的团队目前传出去尽量往规范化发展的一个阶段，我们队员能力参差不齐，团队内部沟通也是尽量让每个人能有事情去做，每个任务能够努力完成

• 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

我们相对于之前立下的目标来说，每个人都有一点进步，在本次alpha冲刺阶段都有一定的成长，当然写了很多bug，也遇到了很多困难，我们的团队都付出努力去完成。有一颗进取的心是我们团队最大的收获。

• 你觉得目前最需要改进的一个方面是什么?

最需要改进的是我们的沟通问题，很多时候有一些可以避免的bug，一些可以减少的代码量都是可以提前沟通去解决的。在后面的beta冲刺中，我们会加强我们内部沟通，有更快的效率去完成我们的程序开发。

• 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

参照《构建之法》P114页的敏捷开发原则，回顾我们的Alpha冲刺过程，我们做得比较好的有：

第四条：“业务人员和开发人员在项目开发过程中应该每天共同工作”。团队现场编程是常有的事。

第五条：“以有进取心的人为项目核心，充分支持信任他们”。前端组和后端组各有一名组长，分组管理，在他们的带领下每一个组都把各自的工作完成的不错。

第六条：“面对面的交流始终是最有效的沟通方式”。例如Alpha站立会议、团队编程、开会讨论等等。

第九条：“不断关注技术和设计，才能越来越敏捷”。例如：前后端之间采用了showdoc进行API商定，形成文档；后端组使用了swagger框架，在配置后可形成可测试的API文档，前端访问相应路径，便可以直接查看后端的整个控制层（即路由API），并且可以在上面直接进行API测试，而不需要POSTMAN，这样一来方便了不少，后端自己内部则采用JUnit进行单元测试。

回答测试组问题

1. 标签可以自定义吗

标签不能自定义，但是可以给后台提意见新增标签，我们本身设定的标签量非常大，所以尽量避免找不到标签的问题。

1. 首页店铺的三个菜品展示的权重如何决定，是评价最多的菜品吗

我们后端有专门的Recommended Algorithms算法确定菜品推荐，推荐菜品评价数只是一方面，评分也有相应权重等等。