08组团队项目-中期总结

[徐祥坤102101438]

一、团队名片

(2.1) 团队名片（5分）：

队长博客链接：https://bbs.csdn.net/topics/617601577

团队Logo

团队ID号与团队名称

• 团队ID号：08
• 团队名称：瞎蒙都对

团队现场答辩总结
这次的中期答辩为我们的alpha冲刺画上一个较完美的句号，同时为我们的beta冲刺指出一个较明确的方向。的确，二手交易平台要想能够更加多吸引当代大学生，"有趣好玩"是一个非常重要的点。后续的宣传我们将会往这方面靠拢，同时一些已开发的功能也会往更好玩的方向去修正，我们的"寻宝堂"，将不只是一个普通的闲置物品处理平台，哪怕你只是在路上遇到一片好看的树叶，捡到一块好看的石头，也可以放在我们的交易平台上进行交换;或者是拍到一张或精美或搞怪的照片，也可以放到我们的"寻宝堂"上出售，会有人"慧眼识珠"而喜爱它的。后续的beta工作正如PPT上所讲述的，也会继续推进"社区""我的""订单追踪""聊天室"功能，大家敬请期待。

团队讨论的真实照片

以表格形式展示团队中每个人在本次作业中的具体分工和各自得分比例。（得分比例之和为*总人数100%*，例如3人团队得分比例可以为95%、100%、105%）

人员	分工	得分
戴雨晴	前端	103
文莎莎	前端	101
陈奇权	前端	100
张翔玑	后端	102
胡佳鑫	后端	97
陈芙蓉	后勤	100
徐翔坤	后勤	101
曾祥宝	后勤	95

二、总结思考

(2.2) 参考教材《构建之法》中第15章 现代软件工程 项目回顾（Postmortem）模板 进行总结思考（45分）
附录：现代软件工程项目回顾（Postmortem）模板
2.2.1 设想和目标（5分）
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

一定程度上解决校园内存在的学生物品不能物尽其用，甚至个别严重浪费的情况

典型用户：有闲置物品的大学生

典型场景：比如毕业季会出现的毕业学长会出售二手物品，这时候一个线上物品交易平台就有很必要了

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

没完全达到，原计划功能，完成了交换、出售、租赁功能，好物待选还差一点，社区完成了一部分

原计划用户数量还没有达到，不过我们还是对它持乐观的态度，相信随着产品的优化，时间的推移会有更多的用户加入的

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

还是有偏差的，毕竟还有一部分功能没有实现，比预想的要更低，目标就在那，只要不停的向目标走，当然会越来越近啊

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

经验教训：
从小事做起,然后再扩展,不能一下想把哪一个部分做得特别好,还是要先完成基本的功能,然后在此基础上迭代优化
还有就是bug总是不可避免，要提升自己debug的能力

2.2.2 计划（6分）
是否有充足的时间来做计划？

没有充足的时间，但是我们还是花了不少了时间做计划，因为计划对于任务的完成非常重要

团队在计划阶段是如何解决组员对于计划的不同意见的？
原计划的工作是否最后都做完了? 如果有没做完的，为什么？

组内积极组织会议进行计划，使大家的意见达成了一致
还没有，一方面计划的不够周全，另一方面计划赶不上变化，计划的作用肯定是有的，但是要完全赶上计划是也没那么简单

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

好像没有什么。大家时间花的都挺值的

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

每一项不敢说，但是大部分还是说的很清楚的，前端要做一个什么用户界面，后端接口要有什么功能说的都挺清楚的

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

大致上是的，物流功能不太好做，当时以为物流功能很多市面产品都有就以为不会很难，后来发现物流的话不只是软件层面能解决的，还要有其他人力物力的支持

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

有，有作用啊，有时候遇到计划的时间赶不上，全靠它赶ddl

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

计划缓存区的时间看还不能加长一点，因为经常时间不够赶ddl，得把平常的任务时间安排得紧一点

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

学到了团队合作的重要性，如果重来一次，我感觉一开始就按照现在团队合作的情况来说的话，前期的进度会比之前快得多

2.2.3 资源（6分）
我们有足够的资源来完成各项任务么？

目前还是有的，就是时间资源可能会有点紧，其他都还好

各项任务所需的时间和其他资源是如何估计的，精度如何？

主要按照做任务的人的意见和大家的经验综合做出一个总的意见，当然会有偏差，所以后面还要视情况再做一下修改，总的来说把控的还是不错的

测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
照目前进度来说还是有的，对于美工设计之类的还好吧，组内的队员还是很有创意的，动手能力也比较强，当然要精益求精的话难度还是有的

你有没有感到你做的事情可以让别人来做（更有效率）？

有的，开始大家对于介绍自己的特长的时候都有点谦虚，所以就是大家都不会什么，所以到了分配任务的时候会有不合理的时候，所以感觉有的东西给其他组员做会更轻松一些，但是做自己不擅长的事还是可以学到些其他知识的

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

分工上会改一下，还有就是软件的功能设计会改一下，比如物流板块，社区聊天部分可以加发送图片，这样商品的交易的时候买家会更有安全感（不容易被坑）不过现在再进行改进也是来得及的

2.2.4 变更管理（6分）
每个相关的员工都及时知道了变更的消息？

是的，我们一直都有积极交流的作风

我们采用了什么办法决定“推迟”和“必须实现”的功能？
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

对于一些基本功能如：租贷，出售，交换，捐赠是没办法推迟的，是必须实现的，其他没有那么刚需的功能比如公益排行是可以适当推迟的，我们是按照用户的实际需求来考虑的

对于可能的变更是否能制定应急计划？

可以的,有良好的沟通都是没有问题的，怕的就是小组缺乏沟通，遇到问题手忙脚乱，但是我们小组目前还没出现这种情况

组员是否能够有效地处理意料之外的工作请求？

可以的，由额外的需求或者是原来的产品已经满足不了需求都是有的，小组的成员对于这种情况都已经适应了，大家一起商讨对策，分担任务大家都习惯了

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

改需求是常态，撸起袖子加油干就是了

改进：对于需求要开始就尽可能考虑好，这样可以节省花费的时间和精力

2.2.5 设计/实现（6分）
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
对于设计工作，是组内成员讨论完成的，是在选题确定以后组内线下会议完成的，选题确定以后才好根据选题设计，这时候设计是再合适不过了，而大家一起设计可以有效集结大家的智慧，比个人想要好得多

设计工作有没有碰到模棱两可的情况，团队是如何解决的？
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

有的，通过uml工具理清思路，uml非常有用，uml对于分析面向对象的设计有很大的优势，要什么类，之间有什么联系，有哪些流程，哪些步骤都显示的很清楚

比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

uml内容更多了，开始是一个框架，随着任务的开展，越来越多的细节加了进去，文档更加详细了，以后还是要更新的，因为确实是很有必要

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

复审组内大家自己看看，觉得有什么可以改进的地方就提出来，是的，执行了代码规范

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

学到代码的复审是一件很有必要的事，良好的代码可以提升产品的性能，提高代码质量和可维护性。在软件开发的整个生命周期中，代码审查贯穿始终，有着非常重要的作用。

2.2.6 测试/发布（5分）
团队是否有一个测试计划？为什么没有？

有，我们会在beta5阶段进行，具体的实现还没有讨论详细

是否进行了正式的验收测试？

还没有

团队是否有测试工具来帮助测试？

目前还没有决定要使用哪款工具

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

人工手动测试，还是有用的，改进可以尝试找专门的测试工具测试

在发布的过程中发现了哪些意外问题？

对于部署的不太熟悉。

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

学到了软件测试帮助开发者找到产品存在的问题，找到改进的方向，对于提升产品的性能有重大的意义
改进：使用自动化测试工具提升效率

2.2.7 团队的角色，管理，合作（5分）
团队的每个角色是如何确定的，是不是人尽其才？

个人根据自己特此提出意见，最终大家协商确定的，没有，存在选择角色和自己特长偏差的地方

团队成员之间有互相帮助么？

有的，遇到不会的都会相互讨论，相互解答，任务太多一个人搞不过来，其他成员也会帮忙解决一部分，比如这次前端忙不过来的时候后勤也会过去帮忙

当出现项目管理、合作方面的问题时，团队成员如何解决问题？

协商提出意见，大家集思广益，相互理解，帮助问题就不难解决了

每个成员明确公开地表示对别人帮助的感谢 （写在各自的博客里）：

我感谢戴雨晴对我的帮助，因为她作为组长，总能给我的工作提出改善意见。
我感谢陈芙蓉对我的帮助，因为同为后勤，她总是积极与我交流讨论工作事宜，给予我许多帮助。
我感谢曾祥宝对我的帮助，因为同为后勤，他帮我分担了部分任务，与我商量如何应对问题。

2.2.8 总结（6分）
列出组内所有人Alpha冲刺阶段后的心得。

曾祥宝：
这次alpha冲刺对于我们而言是比较有挑战的，但是也在其中学习到了很多的新知识，提升了自己的编程能力，也见一窥了软件开发的‘全貌’，不只是写代码，还包括需求分析，测试，运营等等，对于软件有了心得看法，同时也深刻认识到了团队合作的重要性。

戴雨晴
这次的冲刺真的是胆战心惊加上十分的累，因为两天一博客，所以感觉时时都有督促的感觉，一直在不停的写前端，我们是主页、社区、我的的功能每个功能一位前端负责，然后我们这两周主要的就是要做主页，所以我的这次冲刺的任务也比较大，再加上很多课程也有ddl，在这些加持下，我成功的病倒了，然后我的任务也顺利完成了一部分。

胡嘉鑫
物品状态的追踪是一个难题。一个想法好不好要看它能否落地，能否真正用技术实现，这也间接体现产品经理要具有深厚的技术功底。

陈芙蓉
因为是非开发人员，所以我并没有很多开发方面的心得体会，主要讲讲在PPT制作,UI设计和答辩方面。
UI设计方面：这次团队编程让我对UI设计方面有了更深的认识，对XD PS等工具运用得更加熟练，对UI设计规范方面也比之前更加注意。
PPT制作：首先就是素材查找方面那是蹭蹭up了哈哈哈哈哈哈哈哈哈，然后制作PPT的速度也比之前更快了。
答辩方面：此次中期答辩算是我人生第一次上台答辩经历，也算给我们组的这次的alpha冲刺画上一个完整的一个句号，没给我们组丢人哈哈哈哈哈哈哈。

徐祥坤
项目完成了一个大阶段的攻坚，这期间我也感触良多。
我深知团队协作的重要性，充分发挥每个人的专长，我负责的部分难度不大，但我会积极提升自己。
不仅如此，平时我也和组员间沟通频繁，明确工作目标，时常汇报工作进度。
我做工作时也会缺少灵感，但我保持冷静和耐心，不断学习新的知识和技能，扩展自己的知识面。
与此同时，我有在工作中保持高质量要求的意识，会和他人讨论改善成果。
总之，alpha冲刺中我得到了许多的经验和教训，它们必然会对我的未来产生积极的影响。

文莎莎
在Alpha冲刺项目的开始阶段，我们首先明确了项目的目标和预期成果。接下来，我们将任务分工，并根据每个人的特长和兴趣进行了合理的分配，提高了我们完成任务的效率，确保每个人都能在自己擅长的领域发挥最大的价值。此次alpha冲刺帮助我更好地规划时间，是一次宝贵的学习经验。

陈奇权
第一次进行团队合作，在Alpha冲刺阶段中通过学习和实践，更加熟悉了前段的设计。在合作方面，沟通很重要，有不懂的就及时和队友沟通，相信自己的队友。哪部分工作紧张，在自己能力之内互帮互助，有助于及时跟上总体进程。团队之间的交流尤为重要，当然自身需要不断学习，掌握更多的知识和技术。

张祥玑
在Alpha冲刺阶段，时间紧任务重，这无疑给予了我很大的压力。然而，正是这种高压环境促使我不得不更多地投入时间去学习新知识，并将所学迅速运用到实际项目中。在这个过程中，我深刻体会到了“边学边用”的重要性。尽管学习的过程是枯燥无味的，需要付出大量的时间和精力去阅读资料、编写代码、调试程序等，但当真正掌握了一项新技能，并将其运用到自己的项目中时，那种成就感和满足感是无法用言语表达的。总的来说，Alpha冲刺阶段是痛并快乐的。虽然充满了挑战和压力，但它也带给我很多收获。