4组-Alpha冲刺-总结

组长博客链接

一、基本情况

1.1现场答辩总结

1.1.1柯老师的建议与问题：

• 界面不够美观，要求达到看不出来是学生作品的水平。

  • 答：好的，我们会进一步改进。

• alpha完成程度？

  • 答：完成到60%以上。

• beta能否完成？

  • 答：计划完成基本功能的优化和拓展功能，如果时间来不及的话，就优先完成基本功能的优化。

1.1.2林同学的建议与问题：

• 不友好的评论怎么解决？
  • 答：我们提供举报功能，用户可以将自己觉得不友好的评论进行举报，后台工作人员会进行处理。

1.1.3唐同学的建议与问题：

• 遇到聊得好的网友可以提供私聊、加好友功能吗？
  • 答：我们提供的是全匿名树洞，不支持以上功能；如果真是如遇知音，我们建议可以在评论区留下联系方式。

1.1.4刘同学的建议与问题：

• 举报全部都是人工审核吗？举报之后是怎么处理解决的？
  • 答：是的，目前计划是人工审核。举报之后，后台工作人员人工审核，属实的话，在前几次会对用户行为进行记录并删除该用户评论或者树洞帖子；超过一定次数，冻结该账户。

1.2全组讨论的照片

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

1.3.1本次作业的工作流程

答：冲刺前期是所有组员边学知识边尝试进行开发；前后端同时进行贯穿整个冲刺阶段，服务器的搭建、爬虫工作和推送数据的上传在编码基本完成之前完成为项目部署和前后端衔接测试提供条件；冲刺后期前后端衔接。

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

成员	工作内容	贡献比
林珏	完成“我的”页面的布局。我的收藏，我的点赞，我的评论，我的树洞接口连接，与详情页的连接和数据传递。完成树洞编辑和日记编辑页面。获取全部树洞的显示，树洞详情页的接口连接、显示。评论功能的实现。	11.70%
王梓瑶	完成“树洞主界面”“树洞详情”“搜索结果”“我的点赞”“我的评论”“我的收藏”“我的树洞”的页面布局、组件添加、样式设置和调整、事件函数及绑定、逻辑跳转，传递接口信息并更新。调用接口实现不同页面的点赞收藏功能，搜索功能。设置不同页面的导航栏信息和部分页面样式调整。前端整合。	12.30%
邵明杰	学习算法，完成“登录授权”，“日记主界面”，“日记详情”，“小怪兽动画”，“推送”，“更多推送(没有用到)”页面样式布局，完成日记部分逻辑自洽，完成显示全部日记、写日记、删除日记、推送、登录认证接口数据请求，完成小怪兽动画功能，完成域名解析。	13.20%
孙巧	接口编写，调试接口	12.10%
陈妍羽	部分接口编写，调试接口，美化ppt	12.90%
陈玉娜	设计树洞模块、日记模块数据库样式，协助整理筛选推送内容，协助完成PPT制作，答辩	12.80%
许雅萍	爬虫获取推送内容，建立推送数据库，制作答辩ppt	12.60%
邹莹	学习爬虫相关知识；服务器搭建；协助项目部署服务器；过滤推送数据；alpha冲刺博客	12.40%

二、总结思考

2.1.设想和目标

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

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

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

Emo情绪情况：

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

典型场景描述：

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

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

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

Emo日记提供的解决方案：

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

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

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

答：基本达到目标。

原计划的功能是分为三个模块，这三个模块都按照原计划交付时间交付了。

由于软件还处于基本功能完成状态，用户暂未我们团队8人，关于用户数量的问题还无法回答。

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

答：软件还处于基本功能完成状态，所以在软件推出之前用户暂时为我们开发人员，重要功能和我们预先的设想一致。同时我们团队的目标是让用户使用重要功能的感受尽可能地好，所以我们将朝着这个目标继续奋斗！

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

答：经验教训：应该尽可能把用户这方面考虑到alpha冲刺中。如果历史重来一遍，我们会更加尽可能考虑到方方面面。

2.2 计划

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

答：在alpha冲刺之前完成的选题报告、需求分析报告里的各项内容已经非常清晰地描绘出了我们团队想做什么、要做什么、以及怎么做的大概框架。同时在alpha冲刺初期我们团队开会确定了主要实现功能和工作流程安排。所以对于用于计划的时间，我们团队是充足的。

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

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

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

答：计划里需要在alpha冲刺阶段完成的工作都已基本完成。

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

答：回顾看来都表示在初期学习技术中做了一些没必要或者浪费时间的事情，学习的知识没用上或者学习的方法不对反而浪费了时间。

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

答：是的。在alpha冲刺前，我们就针对emo日记做了尽可能详细规划，对于所有功能的实现通过类图做了清晰的设计，同时原型的设计也早早完成。更重要的是，在冲刺前我们团队针对各种功能的实现开了一次会议，进行了全面的讨论和协商。由此，我们团队对于每一项任务都有较为清楚定义和衡量的交付件。

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

答：很幸运，我们团队在项目的整个过程都按照计划进行，没有出任何无法挽回的意外。如果要说，应该是项目部署到服务器的过程比较艰辛，队员对于云服务器的部署等等都不太熟悉，所以经常出现接口方面的错误，耽误了前后端较多的时间。这个风险也是当初没有估计到的，没有估计到的原因是对这方面的了解并不充分，所以导致低估这方面的难度，造成了这个风险。

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

答：有留下缓冲区，作用在于应对突然发现的错误能够进行修正。

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

答：由于alpha冲刺中计划和项目实际进度有不匹配的地方，所以将来的计划会根据实际项目进度进行实时调整。对于缓冲区的预留，尽量争取更多时间。对于加班来说，能不加班就不加班，饱满的精神状态才能有最佳的生产力。

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

答：学到的：缓冲区的重要性、以及对于风险预估的重要性。如果历史重来一遍，会对分工做更合理的规划，会增加根据项目进度调整计划安排的机制。

2.3资源

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

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

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

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

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

答：测试的时间和资源还是比较缺少的。对于美工等的确有低估难度的现象。

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

• 许雅萍：有，可能爬虫更会爬的同学来做，所花费的时间可能更少，效率更好。

• 邹莹：有，我负责部署服务器，我感觉交给负责后端的队友来做会减少很多不必要的服务器方面的交接。

• 陈玉娜：因为初期分工不是很明确，所以做的比较多的是辅助工作，在效率这方面没有过多想法。

• 邵明杰：可能有，可能没有，大家如果都不太擅长的话，效率应该都差不多，我只是个那里不够到哪里的工具人。

• 王梓瑶：没有。

• 林珏：没有。

• 陈妍羽：不清楚，因为并没有不知道其他人是否会更加了解、能够更快地掌握。

• 孙巧：暂时没有。

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

答：经验教训：对美工的低估难度。历史重来应该会将美工这个身份单独列出成为一个重要任务部署。

2.4变更管理

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

答：每个相关的员工都能及时知道变更的消息。在群里发布变更消息后，会要求相关人员都进行回复。

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

答：采用统一标准进行判别：基础功能优先，复杂功能推迟。目的是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）是如何进行的，是否严格执行了代码规范？

答：还未进行到代码复审这一步。如果到达这一步的话，要求所有组员严格执行代码规范。

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

答：经验教训：设计的时候应该要尽可能地完善，在后期进行调整比较耽误时间。如果历史重来会更加仔细地进行设计。

2.6 测试/发布

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

答：有测试计划，未进展到正式的验收测试阶段。

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

答：使用postman测试接口。

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

答：暂未考虑到软件的效能方面。从前后端交接来看，测试工作很有用。改进的点在于尽可能测试符合真实运行环境。

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

答：暂未进展到发布阶段。

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

答：学到了测试工作的重要性。如果历史能够重来，那么将完善测试工作的计划。

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

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

答：团队每个角色的确定主要根据每个队员自己的偏好和兴趣，其次根据队员各方面能力。基本上完成了是人尽其才。

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

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

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

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

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

• 许雅萍：我感谢 过滤组和全体成员 对我的帮助， 因为某个具体的事情:爬虫过滤机制不够完善，需要人工过滤，过滤小组被拉过来当苦力，感谢小组成员对组长工作的配合，以及每个人对团队工作的认真负责以及不懈努力。

• 邹莹：我感谢 邵明杰对我的帮助， 因为某个具体的事情引导我开始部署服务器。

• 陈玉娜：我感谢 许雅萍，陈妍羽对我的帮助， 因为某个具体的事情在PPT制作上以及讲稿的完善上，她们根据我的想法不断调整PPT内容、展现形式，帮助我完善讲稿。

• 邵明杰：我感谢 所有组员，孙巧，林珏，王梓瑶对我的帮助， 因为某个具体的事情在有工作交接的地方大家协作的都挺好的，在接口那里如果有问题会经常问孙巧小姐姐，前后端交接的时候经常突然袭击，感觉她很认真负责，接口报错后问她都能很好的解决。后面两位就是一起完成前端的小伙伴了，一路走来至少5000行代码都是我们辛辛苦苦写下来的(原来前端工作量这么大)，这也算是革命友谊了。

• 王梓瑶：我感谢 明杰和小珏对我的帮助， 因为某个具体的事情没有具体的事件，如果非要概括，大概是她们让我感受到了团队真正的意义，不仅仅是因为个人精力有限完不成才需要团队，而是在共同完成项目的过程中，互相鼓励互相学习，苦中作乐一起进步。还很感谢明杰的认真和耐心，人也太太太好了！任务完成得比我们快，学得也比我多比我深入，帮我们debug，还耐心告诉我们为什么。功能相似的部分，有的直接复制她的代码过来改。也是她的敬业让我没有放弃。小珏也很认真，而且节奏很稳，时间安排也很合理，让我发现其实拖到需要熬夜才是效率最低的。她们身上都有很多很多值得学习的地方。是益友，也是良师，跟她们一起努力真的太太太快乐了。

• 林珏：我感谢 邵明杰对我的帮助， 因为某个具体的事情在出现bug的时候，总会提供帮助，顺利解决问题。

• 陈妍羽：我感谢 孙巧对我的帮助， 因为某个具体的事情很多接口和对数据库的处理出现错误的时候是和她一起调试找原因的。

• 孙巧：我感谢 陈妍羽对我的帮助， 因为某个具体的事情调试接口的时候，两个人一起检查bug效率高很多。

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

答：团队里每一个人都能发挥自己的最大作用是最重要的。同时合作方面是最容易出现问题的。如果历史重来一遍，对于合作的小团体会进行更详细的分工，更密集地询问进度。团队的沟通也非常重要。经常的沟通能避免非常多的不必要的麻烦。

2.8 总结

• 许雅萍（组长）

  • 总结：应该是因为速成学习，基础不牢，知识体系不够好的缘故，学习时间真的很长，后来搞通了之后，才发现走了一些没有必要的弯路，信息获取越多，才能提高学习效率，团队的分工还要更详细具体一些，因为自已也在忙碌学习分配到任务的所涉及的知识，对整个团队的进展的把握不足，在下次beta冲刺应该对某一阶段完成什么样的成果进行约定和按时验收，不能采取佛性放养政策，要提高团队效率，避免进度安排不够合理导致后期进度紧张，陷入任务可能无法及时完成的困境。

• 邹莹

  • 总结：在这次alpha冲刺里，我主要负责服务器部署方面的任务，学习和掌握了很多新的知识，对于云服务器和linux有了更深层次的理解。同时也负责了推送内容的整理，用的是比较笨的方法，感觉到了自己的不足，希望在后续的任务中能够在这方面有所进展！

• 陈玉娜

  • 总结：这次Alpha冲刺最大的感受应该是分工一定要明确详细。因为前期粗略的分工导致后期分工出现重叠或不明，给冲刺带来一定问题。

• 邵明杰

  • 总结：一周速成微信小程序开发，从最初的简单样式，到最后的逻辑自洽每一行代码都是辛辛苦苦敲出来的，事实证明，磨刀不误砍柴工，，在正式开发前一定要有一定的知识基础，前后端要事前就多交流，做好交接的准备。不然到最后来回修改代码逻辑，来回返工，真的会写代码写到吐血，前端工作量真的很大，写的很心酸，也写的很累，只希望最后的付出能有回报，且成正比，也是成长了很多，学会了完整的小程序开发流程，小程序父子组件的传参与接口数据的请求也算明白了。

• 王梓瑶

  • 总结： 回顾这两周，其实冲刺前，就学了一点点东西，没有任何项目经验，先前剪剪视频搞搞美工画饼还行，上手就愣住了。到只剩下三两天的时候，感觉还遥遥无期。布局写得一团乱，页面逻辑太多太杂，文件也不少，找bug都得翻半天列表。又没有系统学习过，总是要完成什么步骤就去搜什么，网上的代码复制来复制去，可能是心态也不好，坐在电脑前没有任何进展，停滞不前，又很怕自己会拖后腿，焦虑崩溃，很是痛苦。和小珏两个人在宿舍喊了一晚上的“不行就摆了吧”“躺平这才对啊“…！甚至已经在找代写的边缘疯狂试探…不过问了价格立马我爱编程！( ’ ∇ ’ )シ┳━┳つ。
    如果是个人项目，可能早就速速躺平了。但同时看着明杰还在群里认真干活，她真的又敬业又靠谱又耐心！谁又忍心摆烂呢！最终还是一边说着想放弃想下一轮再说吧，一边又不约而同坐在电脑前攻坚克难龟速爬行。如果不是明杰， Alpha冲刺可能也不会有现在的成果了（虽然也还需要很多完善就是啦）。
    这些天每天都跟电脑形影不离，泡在活动室废寝忘食、笔耕不辍，光我的part就写了两千多行代码，数了数最终版有六千七百多行。最后页面还原了原型设计，也实现了之前计划的几乎所有功能。完成一个项目的成就感和那一刻的快乐，真的是无可替代！也在这个过程中，熟悉了微信小程序的前端，和很多操作，还有了点虽然我现在什么都不会但需要什么我就能学会的小小自信，感觉虽然我还是很菜，但慢慢地在努力，在进步了。
    当然，也有了很多很多经验教训： 第一是，实操类的东西还是要边学边上手做啊…！原本先看了网课，看完以为技能加载完毕可以大有所为了！打开电脑直接 {while(True) 意识--;}，最后还是边一步步搜帖子边学边做的。 第二是，更意识到了设计文档的重要性，在最开始就要有个全局把控，原本是按面向对象那样，把树洞帖子都写成组件的，后期发现这样很难进行页面和组件间的数据传递，又花了很多时间拆掉组件重新组织逻辑框架。 第三是，小组作业很多细节一定要提前商量好。在进行前后端交互的时候才发现，变量命名全不一样，就不能直接整个数组赋值，很多函数调用事件逻辑也不相符，改着改着改得面目全非，重新开了一个项目，又顺带意识到了github的重要性…. (oﾟvﾟ)ノ。 第四是，审美上还得加加油！我觉得前端界面很好看了，但没有意识到和别人差距还是比较大的。最后，心态一定要好，别总畏难，总想着我不行，努努力，我可以的！

• 林珏

  • 总结：在这次的团队alpha冲刺中，一开始进度缓慢，边看网课边写代码实在是太慢了。学了个基础就开启了面向百度编程。大概学会了小程序前端的wxml，wxss和js语言的使用。页面之间的连接，需要加强和队友的沟通。微信开发者工具没有协作功能，实在是太不方便了，至少传了十几个版本。后面两天我们三个前端坐到一起，感觉工作效率更高了，一个人比较容易摸鱼。有问题可以随时提出，和队友们一起商量，提高了解决问题的效率。在此要特别感谢我们前端小组的C位—邵明杰同学。在debug的时候，她总会提供帮助，找到盲点。也是她写了接口，我们直接套用了接口模板。在连接后端接口的时候，就很爽，只要给参数，就能拿到想要的数据。充分体会到了团队协作间的强大的支持和信任。

• 陈妍羽

  • 总结：经过这一轮的冲刺，感受到要完成好以前没有接触过的任务是不容易的，首先要学习很多相关的知识，然后再将理论运用于实践，这样的过程中可能会遇到很多困难。同时也体会到事先规划好细节的重要性，提前把可能出现的情况都考虑到能够避免很多本不必要的问题。除此之外还应该及时、尽早地和团队的队员进行有关交接任务的沟通，这样能够避免出现双方各做各的的情况。

• 孙巧

  • 总结：在完成任务过程中，由于对编写接口的不熟悉，遇到了很多问题，其中包括对数据库的操作等等，这个过程真的很考验我的百度能力。还有后期在自己调试接口并且和前端连接的时候，有时候会在特殊情况下出现一些bug，和小伙伴一起debug的过程很枯燥，但是成功之后真的好开心。这次收获还是挺大的！