4组-Beta冲刺-总结

组长博客链接

一、基本情况

1.1现场答辩总结

柯老师的建议：

1.美工可以考虑再增加人员。

答：美工后续会增加人员，来实现产品更加成熟和美感的体现。

2.评论的界面，书写框太大了，可以参考现实中一些比较成熟的产品，还有评论的界面不够美观。

答：下轮冲刺会着重修改美化。

3.先前进行过功能测试，之前页面逻辑的问题与bug是否解决完毕？

答：之前发现的问题已经解决完毕，关于答辩前我们测试过程中发现的问题，由于时间问题只进行了部分解决，在下一阶段将进行系统性的处理。

4.是否已经在准备上线？

答：由于具有论坛类的功能，所以上线需要相关材料，如营业执照，机构代码，域名备案等，准备上线，也会尽我们最大的努力交付成品。

5.关于论坛如何上线，试着曲线救国，即使是用残缺版也要尽量上线，这是下阶段的重点问题。

答：谢谢老师提出的宝贵意见，我们会尽我们最大的努力交出完善的成品。

1.2全组讨论的照片

1.3评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例

1.3.1本次作业的工作流程

答：（1）团队讨论确定整个团队的分工和整个beta冲刺的方向 （2）团队成员开始合作奋斗 （3）最后，内容整合，完成收尾工作

1.3.2组员分工、组员工作量比例

成员	工作内容	最终贡献比
林珏	优化“我的”页面、日记编辑页面，完成“设置”页面。	12.65%
王梓瑶	前端树洞系列、"我的"系列、举报系列 功能完善及页面美化，举报功能，删除功能，完善搜索功能，随机头像id显示，后台自动刷新功能	12.40%
邵明杰	前端日记功能部分与推送，用户登录功能，后台自动刷新功能	12.39%
孙巧	树洞搜索部分的后端代码，博客的一部分	12.31%
陈妍羽	后端部分接口bug修正与新增功能，PPT制作	12.65%
陈玉娜	设计完善数据库样式，整理举报逻辑，优化推送算法，部分PPT，答辩	12.98%
许雅萍	获取新的推送内容，完成过滤工作，更新推送数据库，完成博客的一部分	11.98%
邹莹	美工，ppt的一部分，演示视频	12.65%

二、总结思考

2.1.设想和目标

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

答：要解决的问题可以清晰且简单地来定义就是帮助用户转移焦点，释放情绪压力。

典型用户和典型场景部分的描述也很清楚的体现在需求分析当中，以下是其中一部分：

Emo情绪情况：

有消极情绪，但因各种原因无法倾述、抒发给周围朋友、家人。

典型场景描述：

①与舍友发生矛盾，但朋友较少或朋友重合度高，以致于无人可说。

②总以乐观开朗的态度对外，以致于有了负面情绪不敢与人交流倾述，害怕破坏良好形象。

③小林同学实习转正失败，想要打电话给父母，但父母工作已经很是疲惫，再加上不想让父母担心，最终还是选择不告诉父母；又想打电话给好友倾述，但朋友因毕业和对象分手，已经难过很久，不想再让朋友为自己难过。想来想去，竟然没有一个人可以倾述。

Emo日记提供的解决方案：

此类用户可以打开Emo日记的日记界面，把未能倾诉的心情，一字一字敲进自己的日记，在书写倾诉的过程中，缓解了难过情绪，还可以点击投喂小怪兽的按钮，小怪兽会把日记吃进肚子，同时会推送温暖的内容博得用户心头一暖（例如针对小林的情况推送“不怕从零开始，只怕从未启程”这样的话语）。

同时该类用户还可以通过树洞功能将消极情绪匿名上传，达到倾述给他人的效果同时又具有保密性和隐私性。很好地解决有极大倾述欲望却没有倾述对象的问题。

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

答：基本达到beta冲刺的页面优化和功能补充的目标。

原计划的功能是分为三大模块：前端页面美化，后端：搜索算法，个性化推荐算法，敏感词检测，数据库优化以及内容补充，这三个模块都按照原计划交付时间交付了。

由于软件还处于基本功能完成状态，测试才开始了一些，关于用户的问题暂时无法回答，我们团队8人，关于用户数量的问题还无法回答。

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

答：软件还处于基本功能完成状态，所以在软件推出之前用户暂时为我们开发人员，重要功能和我们预先的设想一致，并且通过本轮的beta冲刺关于页面优化，以及功能的完善修改，相信用户的体验度会更好。同时我们团队的目标是让用户使用重要功能的感受尽可能地好，所以我们将朝着这个目标继续奋斗！

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

答：经验教训：团队沟通十分重要，还有页面逻辑还是存在一定问题，对用户体验感的了解与反馈很重要。会尽可能把用户感受这方面，以及页面逻辑优化考虑到后续工作中。如果历史重来一遍，我们会更加尽可能考虑到更加细致。

2.2 计划

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

答：之前完成的选题报告、需求分析报告里的各项内容已经非常清晰地描绘出了我们团队想做什么、要做什么、以及怎么做的大概框架，并且在alpha冲刺阶段已完成基本功能的实现。同时在beta冲刺初期我们团队开会确定了主要完善功能和页面美化以及工作流程安排。所以对于用于计划的时间，我们团队是充足的，到最后一轮beta冲刺的时候，已经完成了本轮冲刺相应的任务。

2.2.2团队在计划阶段是如何解决组员对于计划的不同意见的？

答：在冲刺初期我们团队的内部关于一些细节问题不同的意见还是比较多的，最主要的解决方法是持有不同意见的队员阐述观点，之后整个团队协商得出结果。

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

答：计划里需要在beta冲刺阶段完成的工作都已基本完成,如个性化推送功能，搜索匹配，以及数据库更新，页面美化。

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

答：回顾看来都表示在初期学习技术中做了一些没必要或者浪费时间的事情，学习的知识没用上或者学习的方法不对反而浪费了时间，以及不同任务的成员之间工作的沟通不够充分导致对相同功能的实现逻辑不同，做了本来不必要的返工，浪费了一部分时间和精力。

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

答：是的。在Beta冲刺前，我们就针对emo日记本次冲刺的基本任务做了尽可能的详细规划。更重要的是，在冲刺前我们团队针对完善功能以及页面美化两大任务开了一次会议，进行了关于实现细节方面的讨论和协商。由此，我们团队对于每一项任务都有较为清楚定义和衡量的交付件。

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

答：很幸运，我们团队在项目的整个过程都按照计划进行，没有出任何无法挽回的意外。项目没有出现什么意外，因为在吸取了第一轮alpha冲刺的经验教训，本轮冲刺组员们的默契增加，更加团结高效。关于整个小程序项目的上线问题，因为有匿名树洞交流此类社交/论坛类，所以关于小程序的上线有着一定的困难，当时是有预估到这个问题的，只是目前被提上了日程，感觉有一些困难，但是也是可以克服解决的问题。

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

答：有留下缓冲区，作用在于应对突然发现的错误能够及时进行修正，以及对一些突发状况可以有时间去处理。

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

答：由于alpha冲刺和beta冲刺中关于页面逻辑以及用户体验等方面考虑不够细致全面，所以将来的计划会根据内部用户测试进行实时调整。对于缓冲区的预留，尽量争取更多时间。对于加班来说，如果可以不加班就不加班，饱满的精神状态才能有最佳的生产力，提高“生产效率”才是关键。

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

答：学到的：缓冲区的重要性、以及对于风险预估的重要性、还有团队和谐以及高效合作的重要性。如果历史重来一遍，会对分工做更合理的规划，会增加根据项目进度调整计划安排的机制，以及对项目的进度做进行更仔细的控制，还有关于一些细节问题，应该在初始就讨论协商清楚，避免之后可能会产生的分歧与冲突。

2.3资源

2.3.1我们有足够的资源来完成各项任务么?

答：有。但是应用已有资源的能力还不够强。

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

答：估计方法是考虑这部分的逻辑复杂程度、这部分负责人知识的掌握程度。精度是实际与估计相差不大。

2.3.3测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

答：测试的时间和资源还是比较缺少的，但是本次冲刺还是预留了一段时间给团队内部人员进行测试，修改了一些bug。因为第一轮被柯老师指出页面的不成熟，所以对于美工等的工作没有低估其难度，均安排了相应的成员去负责此类任务。

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

• 许雅萍：有，关于推送内容的挑选，如果是不同的人，获取到的内容会不相同，没准会使推送的功能推送起来更加有趣，吸引人。

• 邹莹：没有，找素材这些事情挺需要运气的，效率高低和是谁在做差别不大。

• 陈玉娜：暂时没有。

• 邵明杰：可能有，也可能没有，不太了解大家所擅长的，如果擅长就肯定让她们来做更好，大家水平都差不多谁做都一样.

• 王梓瑶：大概没有。

• 林珏：不太清楚。可能如果对布局样式更加熟练的话，会修改的速度更快。

• 陈妍羽：不清楚，但大家都在前一个冲刺阶段学习了不同的知识，如果交换的话应该会使效率变慢。

• 孙巧：没有。

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

答：经验教训：关于页面逻辑的设计，如果重来一次，应该会实现的更加贴合真实用户感受，模拟真实用户场景，营造出更好的用户体验，这将会是我们后续任务的重心。

2.4变更管理

2.4.1每个相关的员工都及时知道了变更的消息?

答：每个相关的员工都及时知道变更的消息。在群里发布变更消息后，会要求相关人员都进行回复。在拥有一个总群的基础上，前后端还各自成立了内部的QQ群，一定程度上提高了变更管理效率。

2.4.2我们采用了什么办法决定“推迟”和“必须实现”的功能?

答：采用统一标准进行判别：优化现有功能优先，扩展功能推迟。目的是beta冲刺结束，我们的项目能够在alpha冲刺已完成功能的基础上提高其可用性和用户体验感，在时间还有剩余后再去考虑扩展其他功能。

2.4.3项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

答：目前对于“做好了”的定义主要是：能够为用户提供一个功能可用、好用的情绪宣泄类小程序，且程序界面令人舒适、体验感好。但是我们团队对于继续完善、“做好”小程序的追求是无止境的。

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

答：能，我们团队会谨慎对待各种可能的变更，在任务开始前会开会进行全面讨论，在突发情况出现时，也会采用线上线下结合的方式，群策群力制定应急计划，保证所有人的进展顺利。

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

答：能够。在项目完成以及组内体验小程序的过程中，如果有认为前端或者后端逻辑处理或者推送数据库数据不匹配的情况，组员们会积极在群里提出来，相关人员讨论后及时进行修改完善。所有的组员都以一种积极的态度对待团队里的事情，并且出色地完成。

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

答：在开发过程中，经常会遇见一些不可预见的问题，这是不能避免的，需要团队成员共同克服；在程序开发之前，需要确保组内成员都明确自己的任务即团队目标，在开发过程中也要随时保持有效沟通，避免组内各方出现理解偏差导致一些无用功耽误时间。如果历史重来一遍，会在任务初始的会议中做更加细致的安排，确保组内各人完全朝同一个方向前进。

2.5 设计/实现

2.5.1设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

答：设计工作是在alpha之前的需求报告部分完成的。基本由全组共同完成负责。是合适的时间、合适的人。

2.5.2设计工作有没有碰到模棱两可的情况，团队是如何解决的？

答：有出现模棱两可的情况。解决方法是私下讨论，再提出问题全团队讨论。

2.5.3团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

答：有用到UML图和原型设计工具帮助设计。这些工具很大程度上帮助了我们完成设计和实现。

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

答：现在的状态和最初的UML文档区别不大。产生的原因是对于软件的要求提高，希望软件更加完善，针对之前没有考虑周全的用户需求增加了一小部分功能。目前暂不需要更新UML文档。

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

答：树洞相关功能bug最多，不论是在前端逻辑处理还是后端接口上；因为树洞功能相对较多，前端处理逻辑的工作量相对较大，且在编写接口过程中，后端也存在一些没有考虑周全的地方。还未到发布这一步。由于是第一次团队一起完成一个项目，较为生疏，没有考虑到具体实现起来的实际可用性，因此在设计/开发的时候没有想到这些情况。

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

答：后端接口部分是由后端工作人员在初步完成接口代码后，使用测试工具对接口逐个进行测试的同时检查代码是否有逻辑不通的地方，同时前端工作人员在进行接口连接的时候，意外发现一些小bug及时通知后端人员进行修改；前端的代码复审是由前端人员进行检查，同时在发放给组内成员体验小程序时，由组内人员对页面、组件逻辑等进行检查。所有组员严格执行代码规范。

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

答：经验教训：设计的时候应该要尽可能地完善，要充分考虑到各种可能出现的问题，以免在项目后期再进行调整比较耽误时间。如果历史重来，我们会更加详细周全地进行项目开发前的设计，进一步明确组内共同目标。

2.6 测试/发布

2.6.1团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？

答：有测试计划；目前正在进行正式的验收测试。

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

答：后端使用postman测试接口。

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

答：目前是由组内人员体验项目成果，通过程序的可用性来测量并跟踪软件的效能的。从软件实际运行的结果、一些bug的消除以及用户体验感的提高来看，测试工作很有用。改进的点在于测试数据应尽可能符合项目投入使用后的真实运行环境。

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

答：由于我们的小程序涉及树洞这样偏论坛类的功能，无法用个人号进行上线，需要营业执照等等证件，目前还没有找到解决办法。

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

答：学到了测试工作的重要性。如果历史能够重来，那么将尽可能完善测试计划，充分地考虑后期发展的各种潜在问题，如小程序上线所需条件等等。

2.7 团队的角色，管理，合作

2.7.1团队的每个角色是如何确定的，是不是人尽其才？

答：团队每个角色的确定主要根据每个队员自己的偏好和兴趣，其次根据队员各方面能力。基本上完成了是人尽其才。在beta冲刺中针对老师的建议做了人员微调整，增加了美工。

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

答：有互相帮助。每个队员遇到困难都能很好地说明困难之处，积极地寻求其他队员的帮助。

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

答：出现项目管理和合作方面的问题，前后端队员Q群内部先进行解决，无法解决的问题会放到整个团队的Q群中来讨论和商量解决办法，直至问题解决。

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

• 许雅萍：我感谢 全体成员 对我的帮助， 因为某个具体的事情:感谢小组成员对组长工作的配合，以及每个人对团队工作的认真负责以及不懈努力，感谢大家的日夜奋战，不放弃，不气馁。

• 邹莹：我感谢 许雅萍对我的帮助， 因为某个具体的事情帮助我一起选视频的配乐。。

• 邵明杰：我感谢 大家，所有人，各司其职，配合的很好。对我的帮助， 因为某个具体的事情都差不多，有问题就共同讨论，共同敲定每一个细节。。

• 王梓瑶：我感谢 明杰对我的帮助， 因为某个具体的事情明杰很认真思路也很清晰，每次我改不出来都会帮我一起顺逻辑找bug，太有安全感了。（而且每次看到她在努力都能断了我想摆的念头。

• 林珏：我感谢 全体成员对我的帮助， 因为某个具体的事情大家都很努力。

• 孙巧：我感谢 陈妍羽对我的帮助， 因为某个具体的事情在接口上出现问题的时候都是她陪着我调试的。

• 陈妍羽：我感谢 孙巧对我的帮助， 因为某个具体的事情接口有问题无法解决的时候是问她才解决的。

• 陈玉娜：我感谢 陈妍羽，邹莹对我的帮助， 因为某个具体的事情在最后答辩讲稿上，她们帮了我很多，给我提意见，帮我完善讲稿(｡･ω･｡)ﾉ♡。

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

答：团队内的每一个人都能尽可能地发挥自己的作用、做自己感兴趣的模块是很重要的；由于是团队间的成员有些之前相互没有接触过，所以需要成员间进行磨合，培养团队默契，否则容易在合作过程中出现一些理解偏差。如果历史重来一遍，在最初的项目计划中会进行更详细的分工，组员间相互提醒进度。由于有了alpha冲刺做铺垫，beta冲刺中有意地避开了之前的坑，遇到的沟通问题相对较少。

2.8 总结

• 许雅萍（组长）

  • 总结：虽然本次冲刺时间比较短，对自己负责模块的了解，以及完成任务的能力仍旧提升了一些。对整个团队项目初见雏形，迎来1.0功能基本完善的版本感到无比喜悦，对之后真实用户体验的测试与反馈收集有了一定的计划任务安排，整个团队也在两轮冲刺的三周时间内，变得更加和谐默契有序，希望在组员们的强力合作之下，我们的emo日记会呈现出更好的模样。

• 邹莹

  • 总结：这次冲刺一直想要到代码层次，能够真正的打代码，参与到最前线。但事与愿违，只好待在美工的位置上。最后，在美工的位置上也学会了很多东西，找到了一些有趣的网站。一直害怕寻找的素材会被diss太丑，还好，中规中矩。认真做好每一件工作吧，总会有收获的。

• 邵明杰

  • 总结：前端不是简单的功能实现，不是简单的样式布局实现，要是想真正做到极致的用户体验，一定要提前做好设计分析，整体架构分析，由于没有了解对微信小程序开发过，一路走来都是摸石头过河，最后整体的开发架构就显得岌岌可危，我们只是搭建起来了，但什么时候报错，会有什么报错都是未知的，让人心慌慌，并且刷新页面这里动不动就整个页面就刷新，改为局部的会更好吧，而且总觉得是可以利用本地缓存来达到更好的加载效果吧，感觉就是一堆废品，想要修改却牵一发而动全身。整体下来对前端更深入了解了，也更了解一个完整小程序开发的过程，审美有待提高。

• 王梓瑶

  • 总结：Beta冲刺跟Alpha冲刺于我而言是两种不同的状态，Alpha更多时间花在了学习上，摸着石头过河天天摔跤，掌握了大致技能，有了基础，Beta就是无情的打字机不停地完成一项接一项的任务，一天一轮，感觉都顾不上别的学科，每天都在写软工。一个成熟的应用真的要花很多很多时间精力啊，每次以为好像没事啦，立马又能有新的bug新的需求又啪嗒啪嗒写很久。虽然知道不可能一蹴而就一劳永逸，但每次又发现bug时还是很挫败，学艺不精。还好我的队友也特别努力认真，哪怕大家都疯狂迭代改到真的不想改了，也还是会一边说着算了过会儿群里又多个新的版本。不过我也知道，我所有的痛苦崩溃都来源于自己的无能，能做的也只有认真一点，好好努力、好好进步。

• 林珏

  • 总结：在这次beta冲刺中，我的任务主要是修改页面的样式。刚开始对样式布局还不是很熟悉，对于布局的嵌套有时会迷糊，套着套着就不知道是哪一层了，样式也不知道要调整哪一个类才能呈现出想要的效果。后面慢慢摸索，逐渐熟悉起来，对布局和样式的掌握也更加的熟练。这次才发现，微信开发者工具中调试器中wxml可以点击进去查看布局和样式、默认样式，取消一些样式可以预览到效果。这个功能很实用，居然到这次才发现。除了修改样式，还要修正页面逻辑存在的bug，没有想到bug实在是不少啊，这次发现的bug基本修正。感觉应该还是会有未知的bug存在，想来debug之后也不会少。

• 孙巧

  • 总结：在beta冲刺中，依旧遇到了一些问题，在完善新功能的同时还需要对一些bug进行修复，这让我感受到了在完成项目过程中，要考虑到很多方面的因素；同时在这个过程中，我写的代码比alpha冲刺少很多，但是还是花了很多时间，主要是因为对知识的不全面掌握吧。除此之外，我也意识到了在项目之初的设计工作是很重要的，一个尽可能详尽的设计可以有效减少实际编写代码过程中的很多无用功。

• 陈妍羽

  • 总结：经过这一轮的冲刺，感受到要完善已经做好的项目是不容易的，首先要系统地学习相关的知识，然后再将理论运用于实践，如果只是零碎地学习，会经常碰到错误，要重新查找资料进行学习，浪费不必要的时间，同时也会遇到很多困难。同时也体会到事先规划好细节的重要性，提前把可能出现的情况都考虑到能够避免很多本不必要的问题。除此之外还意识到了团队合作的重要性，要把需要交接的任务细节提前沟通好，否则在交接的时候会出现双方意见不同，无法及时进行交接合并的情况。

• 陈玉娜

  • 总结：感觉团结和沟通真的真的很重要！！！大家有什么想法及时提出，描述清楚，降低沟通成本，也便于大家解决问题。大家一起解决找到的bug，提出了很多想法，从中找到最合适的解决方法，真的跟nice