一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决的问题（按特性来定义）：
①交互性：用户不仅仅只是能够发表帖子、点赞、评论，还可以使用时间轴记录生活，供个人回忆。查看地图，获取热点区域。
②直观性：地图的深浅颜色快速获取最活跃的周边信息、生活分享或美食评价。不再迷惘于广大的城市，而没有目标。
③单纯性：追求更为单纯的分享，而不是参与商业性的带货行为。不必在浏览他人分享时，让广告映入眼帘。
④隐私性：提供匿名发帖、匿名评论的功能，无需创建多个小号来宣泄烦恼，减少多个账号切换的繁琐。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
已实现的功能如下（按时间交付但未达到目标）：
①地图模块：地图气泡图实现了福建省区块，虽暂未完成其他省份，但已大致出现气泡图的雏形，之后不断扩宽至全国修改样式即可。
②帖子模块：能够完成用户的看帖、发帖、删帖、交互（点赞、评论、TAG）
③时间轴模块：能够对时间轴进行添加、筛选、删除
④个人空间模块：对个人空间的信息进行修改和筛选。能够看到关注列表，进入别人的个人空间。
3、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
①任务分的粒度太大了，在实现过程中有很多的细节没有考虑到，也导致燃尽图是中间突起，后端急速下降的状态。
②冲刺过程中的学习占比时间超过了预想，应该在冲刺之前就准备好技术栈，甚至在冲刺前就着手完成项目，会得心应手。
③设计工作考虑不足，后端开发过程中出现频繁修改数据库表的行为，导致已经设定好的类，需要重新添加修改。
④前后端的拼接并不如意想中那般顺利，很多细节上的问题，也将从这方面中衍生而出。
二、计划
1、是否有充足的时间来做计划?
有，规划安排归功于每日的站立式会议。
①今日进展：能够清晰了解到个人以及团队成员今天完成了多少任务，互相了解从而促进自身对工作量的要求。
②存在问题：讨论存在的问题，队员对此作出答复，也将更新明日安排的工作任务。不仅仅自身规划安排，队友也参与其中。
③明日安排：明确自己的规划安排，汇报说明也将提高完成工作的效率，不只是将安排停留在口头上，互相督促。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
①提出观点：在站立式会议上提出自己的问题以及观点，提出设想的方案。
②自由讨论：有想法的人提出自己的观点，其他人听取意见，有想法继续讨论，直到所有人都表达完自己的观点为止。
③最终决断：最终决断权交付在组长手中，最终的结果都较为合理并高效，能够让组员按需完成。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
①地图模块：地图模块前端实现的难度比预期要更大，也导致了各类问题的出现，无法达到预期效果。
②权限限制：只考虑到功能的完成，却没有意识到，在不同的用户下，所见到的界面是不同的。这里需要后端数据的再筛选和前端页面的整合，属于设计上的疏忽。
③细节：有些设计的功能有些是实现过程中才提出来的，还有些问题是到了即将截止才慢慢发现，导致解决问题的时间不够充足。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，有些所写的代码是为了意外发生，做好的防备工作。有些突如其来的设计想法，也可以为下阶段的开发提供便利。
5、是否每一项任务都有清楚定义和衡量的交付件?
对于所要完成的任务，总体上的定义未出现问题。但是一些细节，没有考虑周到。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
①意外：前后端的拼接所延伸出的问题，一些功能设计上的难度以及未考虑到的细节导致的程序不完善。
②原因：未留有足够的时间完成拼接工作，从而导致问题无法解决。细节考虑不够周到。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，缓冲时间的留取，帮助我们解决了部分问题，只是问题过多，导致缓冲时间转变成任务完成时间。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
缓冲区不能够定义为解决问题的主要时间段，而应该是留备细节上的改变，以及优化项目。
9、我们学到了什么? 如果历史重来一遍,我们会做什么改进?
①考虑实现上的难度，以及需要多注重细节
②将任务粒度减小，让完成的功能更贴近需求。
③前后端开发时间适当减少，留余时间以备解决问题。
三、资源
1、我们有足够的资源来完成各项任务么?
时间不足：由于项目的功能复杂，时间对于我们开发的项目来说，不算充足。
服务资源不足：资金原因决定了我们的服务器流量不会很大，也不会支持足够大的并行量。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
精度不足。
时间：时间上只是做了大体上的估计，按照时间完成模块功能，精度不足。
开发资源：开发资源大多数能够从网上得到，而所需的只是使用，当队友学会后也会将此分享。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
前端的测试的时间和人力资源不足，后端有余。
软件和硬件资源足以满足我们的开发需求，在使用上并未遇到问题。
美工设计比预期中的难度要高，大量图片背景的选取不一定合适，以及按键的放置选择。对于美工的低估确实超出了想想，一开始觉得如果走的是“简洁风”也许不需要那么多的工作，实际写下页面来其实简洁风要求的更多，布局和整体的呈现都不能随意呈现。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
部分技术上的问题，可能无法及时的学习并应用，所以可能会导致这样的想法，但是也不能肯定地说让别人做更有效率，可能的结果也不一定如意。
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
①人员安排：这次的项目开发难度主要在于前端，开发过程中才发现前端任务较重，导致后期后端任务完成，前端任务还在开发或者测试，必要的话需要作出人员调整。
②精度提高：这在项目完成的各个部分，都能体现到细节的重要性，单单完成功能实现，在使用时才发现到许多不足之处。需要通过提高任务的精度，提高效率和质量。
四、变更管理
1、每个相关的员工都及时知道了变更的消息?
每日的变更信息都会通过站立式会议记录总结，也正是这样的方式，让所有人都能够清楚地了解到变更的信息，不会导致开发模块的不一致性。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据时间和项目进度，组长仔细考虑后，最后经过各个模块负责人协商，决定“推迟”和“必须实现”的功能。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
出口条件只有大致的定义，但在细节上还略有不足。
4、对于可能的变更是否能制定应急计划?
在实现过程中，对于可能产生的变更，我们会提前准备好，以备应对修改设计，导致代码实现的修改。
5、员工是否能够有效地处理意料之外的工作请求？
是，在修改一些功能上的要求时，能够及时跟进修改，并在时间内提交达到预期目标的结果。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
①项目的出口条件需要更清晰，更细致的定义，不能够一概而过。
②在应急计划上，能够制定得更加全面，减少意外情况发生后，无法在时间内解决的情况。
五、设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计阶段整体是在上阶段系统设计进行的。设计由组长初始设计，后续各个组员加入。现在回顾起来，发现粒度太大，导致在开发过程中很多细节无法注意到，当初设计所花的时间不足，但人员的调动上合适，能够让所有人都参与。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
前端不同的开发人员的风格控制，采用了.less的预处理语言，在最终完成的时候合并可以通过预处理语言的改变统一，比如都采用.setBackground方法设计背景。通过这些通用方式，解决实现设计的问题。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
①单元测试：单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。让后端的代码更加健壮。
②UML：因为在实现过程中，设计上的不断改变，最初的UML能起到的作用较小，甚至需要更新UML文档
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
①BUG的产生多发于前后端的拼接和部署服务器上，前后端参数设置的问题，还有服务器的不稳定性。
②重要的bug发生于删除功能的权限设置，当时单单考虑到功能的实现，却没有考虑到不同用户处理不同的场景的情况。
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
前后端将代码规范的任务交给第三方插件处理，比如后端的JAVA的阿里代码规范和前端使用的eslint。较为依赖这些插件，复审工作进行得较为粗糙。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
①设计工作所花时间不足，导致粒度较大，所以在开发过程中还是有很多细节没有注意到。需要多考虑设计细节上的问题，这样才能让实现过程更加顺利。
②在这次开发设计中，使用UML的次数较少，原因在于不熟悉UML的使用，并且实现过程中不断修改设计，导致UML的不断更新，不足以跟上设计。之后还需改进这方面技能的提升。
③这次的代码依赖第三方插件的使用，也较为信任。导致代码复审较为粗糙，之后项目完成后，也需要将这块的时间增加，让代码更加统一。
六、测试/发布
1、团队是否有一个测试计划？为什么没有？
有，前后端编写、拼接过程中，在完成一项功能后便进行测试，最后整合后再进行最终测试，总体来说是自下而上的一种测试方法，直到所有功能达到预期。
2、是否进行了正式的验收测试？
进行的验收测试较为粗糙，仅为组内队员通过使用软件发现问题以及提供意见。
3、团队是否有测试工具来帮助测试？
①单元测试（IDEA，Junit）
②RESTClient（接口测试）
③Mocks（前端）
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测试效果：效果明显，能够在发现错误时及时更改，对程序的实现很有帮助。
改进：添加测试用例的数量，以及改进测试的策略。
5、在发布的过程中发现了哪些意外问题？
发布后，用户使用过程中发现新的问题，在修改后，仍然有些问题无法得到及时解决。
6、我们学到了什么? 如果重来一遍, 我们会做什么改进?
①测试工具的使用，简化了测试过程，提高效率。
②测试是个枯燥的过程，需要考虑很多边界问题，并且碰到问题，会感到烦心，但解决后也将收获成就感。
③前后端分离的测试，也许会是符合预期的，但整合后，结果不一定如意。需要多考虑整合上的一些问题。·
七、团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
前后端的确认，是提前进行自由投票选择的。每个人尽量能选择到自己所想要担当的角色，并且不影响项目开发，最终由组长确认并分配模块工作。
2、团队成员之间有互相帮助么？
在遇到问题时，我们会互相讨论找寻解决方法。在找到好的方法时，我们会互相分享。在自己的模块完成后，也会着手帮未完成的队员分担任务。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
当遇到有合作方面的问题时，会进行讨论，从而选择其中高效的方法，不会偏向于自己少做事的方向，也正是这样的想法，才让问题更便于解决。
八、总结
1、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
①代码规范：代码规范可以通过编程软件中的插件，来简化这样的过程，不仅比人工自检的效率更高，准确性也更好。
②代码复查：代码复查是有代价的，甚至有时是巨大的，因此代码复查不宜频繁，最好一份代码只审查一次。
所以可以推选出一人专门负责审查和管理代码，从而从管理上有效地提高软件开发的代码质量。
2、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
提高架构：
前端采用VUE框架，后端采用Spring boot框架。这些框架在开发上使程序架构更加统一。
重构提高质量：
①在添加新功能时进行重构。
②在修改bug时进行重构。
③在代码复审时进行重构。
衡量质量的提高：
①改进软件设计使软件更容易被理解
②帮忙找到bug
③提高软件的开发速度
3、其它软件工具的应用，应该如何提高？
测试工具的使用十分重要，可以通过网上学习自动化测试，减少测试上不必要的时间开销。
4、项目管理有哪些具体的提高？
①通过站立式会议掌握项目动态与进展，
②通过项目的功能分解让开发进展大化小，更加实际，功能成员的配属能让开发后出现Bug直接追源，快速解决问题
5、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
可以考虑通过数据库的用户注册数和登录服务器查看访问量来知道每日/周活跃用户等数据。
6、项目文档的质量如何提高？
①需要更多的项目经验，能够准确的判断目前的限制条件能做到什么样的程序规模；
②需要更加细致化的考虑，在设计功能和分工的时候照顾到细节。
7、对于人的领导和管理， 有什么具体可以改进的地方？
①以身作则，不仅需要督促组员，也需要让自身具备说服力；
②要有合适的奖惩激励，虽然一直跟在屁股后面催很招人烦，但是还是要不断的确定项目进度。
8、对于软件工程的理论，规律有什么心得体会或不同意见？
①在文档编写上，如果是团队一起负责编写，那么文档格式一定要提前规定完整，这样最后的整合也将避免过多的修改，占用过多时间。
②在代码需要去网上借鉴时，不能一味地抄袭，因为有时候拷贝下面的代码，还需要有一定的扩展，在代码规范上也不一定符合该项目的要求，需要合理并且规范地使用。
九、成员交接相关
1、新组员交接情况
张庭博
与旧小组的交接情况：交接的话其实没有什么特别的，因为功能开发的都差不多了，就只是给新成员介绍了组长和组长是如何分配任务的，接下来听组长的就行了。
在新小组的适应计划：在加入了新的组之后，我下载了群文件中的相关文档并进行了浏览，对新组的情况有了一个大致的了解，也和组长进行了沟通和交流，对自己的任务也有了一定了解，现在可以说能接替工作了。
组长
为新组员安排的角色：完成换组之后看了看新组员之前的工作，是后端，因为我们的项目在阿尔法冲刺的之后，大部分功能已经完成，只需要对项目进行功能上的细节填补即可，而且之前换出的组员的功能已经基本完成，所以安排了新进入的张同学作为后端成员，并且进入新功能的开发。（实际上来说换组对我们的影响并不大，换入的新成员就像开发一个新功能一样参与到项目开发中）
自己是如何面对之前的成员离开队伍的：项目在阿尔法冲刺已经完成了主要功能，被调出的同学也已经完成了他那部分的所有功能，虽然在感性上还是不舍得（毕竟是我亲爱的舍友）但是理性上并不会对项目有多大的影响，所以谁被换走了我都不会担心我们的项目无法交付。
具体做了哪些措施，是否有调整开发计划，开发计划调整了哪些部分？：反复说的就是我们的项目其实要补充的功能已经不是很多了，所以只是接受新的组员，了解他的技术栈，然后安排他进入新的功能的开发。对新的功能展望了一下，将与之前冲刺耦合度比较高的部分交给原先的组员进行，耦合度较小的交给了新的组员。开发计划没有大的调整，正常的计划就是在β冲刺写完之前尚且不足的功能，进行补足。如果从紧张度来说的话，β冲刺的紧张程度肯定不及阿尔法冲刺，甚至可能不到一半。
组长为新成员安排的任务：
- 换组第一时间，先让新组员交接和老组员的工作范围，了解自己需要编写的代码范畴和功能模块范围。
- 了解完工作范围后，让新组员了解我们的《系统设计说明书1.2》中自己相关的功能部分和我们的整体设计理念，让组员尽快的了解到他现在要开发一个什么功能，这个功能最基础的理念是什么。
- 完成系统设计说明书阅读后，将已经基本完成功能的α冲刺的项目打包让他运行，让他了解一下之前的老组员完成的功能和相关逻辑，顺便还可以让新组员成为我们的测试用户，试运行一下我们的项目后给我们提出可能存在的BUG和功能缺陷。
1.把已经配置完成的阿尔法冲刺项目发给了新成员，
换组事项的感想和收获：
张庭博：换组其实还蛮有意思的，可以到一个全新的环境，接触全新的人，了解不同的项目，这也增强了我对变化的适应能力，可以说是一次难得的体验。
组长：影响不大，开发不会产生巨大波动。以后的人员变动可能不会像这次一样顺风顺水，之后可能需要更高的紧张感，对组员有更多的了解，方便进行断层的修复。