一、设想和目标
做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
-
项目的背景是随着现在网络普及，社交变成了年轻人的一大重头体验，在众多社交平台中，注重隐私性和私密性的社交平台很少，我们要做的就是单纯性和隐私性并存的社交平台。
-
意义：意义在于能够提供一种隐私性的社交平台，当今的社交平台其实并不是一个完全开放的世界，人们在公共空间越来越大的同时，也愈加需要自己的个人空间。
-
解决的问题（按特性来定义）：
①交互性：用户不仅仅只是能够发表帖子、点赞、评论，还可以使用时间轴记录生活，供个人回忆。查看地图，获取热点区域。
②直观性：地图的深浅颜色快速获取最活跃的周边信息、生活分享或美食评价。不再迷惘于广大的城市，而没有目标。
③单纯性：追求更为单纯的分享，而不是参与商业性的带货行为。不必在浏览他人分享时，让广告映入眼帘。
④隐私性：提供匿名发帖、匿名评论的功能，无需创建多个小号来宣泄烦恼，减少多个账号切换的繁琐。
-
典型用户使用场景描述：某22岁女大学生在和同伴出去吃火锅的时候，想要分享这一部分的生活，于是打开daily6+1后发帖，选择自己想要关联的地区，于是这一帖子就被加到了这个地区，大家点进这个部分的地图的时候就能看到她发的“火锅贴”，与此同时，她又把这份帖子关联到了自己的时间轴动态，戳上标签，方便之后打开时间轴后对生活进行回顾。
项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)
- 原计划的功能除了语音图片搜索，其余全都做到了。
- 拓展部份：邮箱验证码，管理员操作，对关注用户信息的浏览。
- 不足部分：地图界面的UI不是很理想，没有能够做到理想中的不规则分块和气泡，退而求其次使用了方块进行划分。
和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
- 和alpha阶段相比，质量提高在了任务分配的粒度确实细化。之前都是将一个大功能直接丢给组员，要求组员自己解决其中的细化，这次分配任务的时候已经将大功能分为了很多个细小的功能，单从“分配量”来说，我们分配的任务量每个人达到原来的2-2.5倍，但是实际“工作量”却只有原来的“0.7-0.9"
设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
- 设想用户量大概在500人。
- 用户对于我们的主要功能：地图功能和时间轴功能的接受与我们的预想相一致。但是这仅仅是在功能角度的接受，在界面和UI方面，结果实在差强人意。这说明功能本身十分具有新意，但是界面还需美化。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
- 美工和UI真的很重要。
- 作为组长来说，会更加督促组员的代码规范和代码的能力，组员在开发过程中一边学习一边开发效率实在是提不上来。然后也会对整个项目的规划更加合理，不会让α冲刺太过忙碌而β冲刺过早结束，有一个较好的延续性。
- 可能会找身边比较熟悉设计的人来帮忙进行UI的审核，我们更像是专注于代码的编程，但是对于UI的熟悉程度确实不足。
- 再给同学们一些熟悉github的时间，他们好像对于Github的基本操作还是不够到位，不会使用Merge也不会使用IDE对GIT进行相应的操作
- 设计工作应该更加细节，有很多功能的衍生是我们在接触这类事务之前无法想象的，比如我们没想到”如果要限制关注，还需要另加一张数据表才能做到“
- 关于html的一些学习应该跟加深入，不了解cookie和seesion的话，开发着实举步维艰。
二、计划
和alpha阶段相比，每天是否时间规划的更好?
- 由于alpha阶段我们的时间很紧，所以项目在alpha阶段基本就开发完了。β阶段就是查漏补缺。
- 如果单说β阶段，由于时间比较充足，所以只花了三天进行开发，后续的时间都是测试和上线的调试，所以可以说时间更加充裕，规划也自然更加放松和合理。
- 如果说整体时间规划，可能是因为scrum的开发模式的原因，使得一开始的开发都会比较紧张，随后的一轮一轮scrum都是查漏补缺，所以不会有那么紧张，后续的时间规划也自然的会更加好一些。
团队在beta阶段是如何解决队友对于计划的不同意见的？
-
①提出观点：在站立式会议上提出自己的问题以及观点，提出设想的方案。
②自由讨论：有想法的人提出自己的观点，其他人听取意见，有想法继续讨论，直到所有人都表达完自己的观点为止。
③最终决断：最终决断权交付在组长手中，最终的结果都较为合理并高效，能够让组员按需完成
你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 仅仅只有原计划的”语音和图片查询“没有做完，因为项目的规划把这个放在了”可拓展“的特殊地位，我们在这种地位的还有另一个操作"邮箱验证"和”热门算法”，我们认为这两者的重要程度相较更大，于是我们优先开发了这两个任务，在开发完成之后已经进入了预定的测试阶段，我们判定为了这个搜索只能算锦上添花，并不算是硬需求，所以我们战略性的放弃了这个功能，转而进行测试以保证项目能够正常使用。
是否每一项任务都有清楚定义和衡量的交付件?
- 对于所要完成的任务，总体上的定义未出现问题。但是一些细节，没有考虑周到。
项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 意外在于项目上线阶段，页面的配置，由于vue更偏向单页面开发，所以现在网络上的教程都偏向于单页面配置vue，而我们的项目是多页面-单页面同时存在的，使得我们的配置并不能完全按照网络上的教程进行，所以我们为了找出自己的配置方式大概花了两三天进行探索。
- 并发风险大的超过了我们的想象。由于之前并没有在服务器上使用应用的经验，所以没法正确的估计我们的“小水管服务器”到底能承受怎样的压力，事实证明，限速1M带宽的服务器的并发支持数并不可能太高。
在计划中有没有留下缓冲时间，缓冲时间有作用么?
- 有缓冲的时间，大概预留了两天。
- 确实有用。由于实际开发的进度比预想的大概都要快一两天，当然，除了上线阶段。所以预留的缓冲时间都分配给了上线配置阶段，使得我们的项目最终能够正常上线。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 考虑实现上的难度，以及需要多注重细节
- 将任务粒度减小，让完成的功能更贴近需求。
- 前后端开发时间适当减少，留余时间以备解决问题。
- 补充更多的知识，以防不时之需。
三、资源
有足够的资源（可以是时间、开发资源等）来完成各项任务么?
- 就软硬件资源来说不足，由于服务器、云储存等的限制导致我们的开发没办法尽力，被客观条件所限制了。
- 某些同学的时间不足，要准备考研、实习、面试等等，所以时间并不能完全用于开发。
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 通过经验估计，根据阿尔法冲刺和之前的开发经验估计。
- 精度只能在天附近正确，如果遇到某些高难的可能会差上不少。
和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 项目完成比较早，所以测试的时间相对比较充足。人力资源足够，但是软硬件的资源不足。
- 美工和文案确实不在我们一开始构想的难度之中，然而事实证明这两部分才是最正面影响用户体验的部分。
变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
- 变更的组员工作难以掌握，因为家里不方便参加会议，所以对它的工作程度掌握的并不清晰，没办法做出弹性调整。
- 如果未变更项目的开发效率应该会更高。
- 变更的组员所学参见总结博客。
- 由于我们的项目α阶段开发的比较完全了，所以后来者只是在上面砌砖，不会伤筋动骨，所以没有作应急计划。
有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
-
小组的成员水平都比较接近，工作的分配难度也比较接近，如果把A的这部分分配给B可能效率会更好，但是对B来说，他其余的工作量分配给别人未必效率会更高，团队是一个整体，我认为单这样考虑未必合适。
-
①人员安排：这次的项目开发难度主要在于前端，开发过程中才发现前端任务较重，导致后期后端任务完成，前端任务还在开发或者测试，必要的话需要作出人员调整。
②精度提高：这在项目完成的各个部分，都能体现到细节的重要性，单单完成功能实现，在使用时才发现到许多不足之处。需要通过提高任务的精度，提高效率和质量。
四、设计/实现
项目是否经历重构？为什么需要重构？
- 否
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
-
①单元测试：单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。让后端的代码更加健壮。
②UML：因为在实现过程中，设计上的不断改变，最初的UML能起到的作用较小，甚至需要更新UML文档
什么功能产生的Bug最多，为什么我们在设计/开发的时候没有想到这些情况?
- 帖子平台界面的BUG最多。
- 已经预料到了这部分的BUG最多，因为这是整个平台的基础，代码量会比较大，所以相应的BUG肯定也会更多。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 前后端将代码规范的任务交给第三方插件处理，比如后端的JAVA的阿里代码规范和前端使用的eslint。较为依赖这些插件，复审工作进行得较为粗糙。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计工作所花时间不足，导致粒度较大，所以在开发过程中还是有很多细节没有注意到。需要多考虑设计细节上的问题，这样才能让实现过程更加顺利。
- 在这次开发设计中，使用UML的次数较少，原因在于不熟悉UML的使用，并且实现过程中不断修改设计，导致UML的不断更新，不足以跟上设计。之后还需改进这方面技能的提升。
- 这次的代码依赖第三方插件的使用，也较为信任。导致代码复审较为粗糙，之后项目完成后，也需要将这块的时间增加，让代码更加统一。
五、测试/发布
和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
- 有，因为时间比较充裕，测试的时间也比较多，自然测试的效率和完整性也更好。
- 在测试的广度上，能够将每个功能都测试到了。
团队是否有一个测试计划？
- 有，在开发阶段，前后端编写、拼接过程中，在完成一项功能后便进行测试，最后整合后再进行最终测试，总体来说是自下而上的一种测试方法，直到所有功能达到预期。
团队是否有测试工具来帮助测试？
- ①单元测试（IDEA，Junit）
②RESTClient（接口测试）
③Mocks（前端）
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
-
测试效果：效果明显，能够在发现错误时及时更改，对程序的实现很有帮助。
改进：添加测试用例的数量，以及改进测试的策略。
在发布的过程中发现了哪些意外问题？
- 发布后，用户使用过程中发现新的问题，在修改后，仍然有些问题无法得到及时解决。这往往和环境有着不可分割的关系。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
-
①测试工具的使用，简化了测试过程，提高效率。
②测试是个枯燥的过程，需要考虑很多边界问题，并且碰到问题，会感到烦心，但解决后也将收获成就感。
③前后端分离的测试，也许会是符合预期的，但整合后，结果不一定如意。需要多考虑整合上的一些问题
六、团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
- 阿尔法冲刺结束后功能已经基本完成，所以人员几乎是重新分配的。
- 分配原则基本按照阿尔法的开发进度参考每个人的水平进行分配。
- 每个人都在开发阶段有事做，并且在同一天结束了工作，我认为这已经可以说人尽其才了。
团队成员之间有互相帮助么？
- 在遇到问题时，我们会互相讨论找寻解决方法。在找到好的方法时，我们会互相分享。在自己的模块完成后，也会着手帮未完成的队员分担任务。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 当遇到有合作方面的问题时，会进行讨论，从而选择其中高效的方法，不会偏向于自己少做事的方向，也正是这样的想法，才让问题更便于解决。
七、总结
组员们自我总结
- 自我总结见冲刺博客
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 管理级。我们尚且无法做到量化和数字化管理流程，也没有一个固定的管理流程。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范，大家都能按照之前的计划按部就班的完成。
八、提高软件工程的质量
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
-
①代码规范：代码规范可以通过编程软件中的插件，来简化这样的过程，不仅比人工自检的效率更高，准确性也更好。
②代码复查：代码复查是有代价的，甚至有时是巨大的，因此代码复查不宜频繁，最好一份代码只审查一次。
所以可以推选出一人专门负责审查和管理代码，从而从管理上有效地提高软件开发的代码质量。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
- 采用现有的成熟框架配合自己所学的框架知识进行提高。
- ①在添加新功能时进行重构。
②在修改bug时进行重构。
③在代码复审时进行重构。 - ①软件易于被理解
②软件重构更简单
③再开发时BUG更少
其它软件工具的应用，应该如何提高？
- 测试工具的使用十分重要，可以通过网上学习自动化测试，减少测试上不必要的时间开销。
- git的使用，熟能生巧
- IDE的使用，比如IDEA和的git操作以及方便的模板配置。
项目管理有哪些具体的提高？
-
①通过站立式会议掌握项目动态与进展，
②通过项目的功能分解让开发进展大化小，更加实际，功能成员的配属能让开发后出现Bug直接追源，快速解决问题
项目文档的质量如何提高？
-
①需要更多的项目经验，能够准确的判断目前的限制条件能做到什么样的程序规模；
②需要更加细致化的考虑，在设计功能和分工的时候照顾到细节
对于人的领导和管理， 有什么具体可以改进的地方？
-
①以身作则，不仅需要督促组员，也需要让自身具备说服力；
②要多了解组员的开发进度，掌握整个项目的开发进度，并且对其个人能力有所了解，方便下次配置更加适合他的功能项目。