设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要针对大学生社交，还有日常的校园互助、校园小应用；
1.信息壁垒
2.信息可靠性不知晓
3.社交圈子窄
4.资源无法合理利用
5.问卷调查困难
6.学校开展活动，学生参与积极性不高
在选题报告中有详细的定义；
在选题报告对典型用户和典型场景都有清晰的描述；
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的功能基本完成；
原计划并没有完成完整项目的打算，所以尚未可以交付；
原计划未列出用户数量要求；
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
软件工程的质量提高了
会议的效率；编码的规范；如果用工作量/时间来衡量的话，相比团队建立初提高了1.5-2倍；
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
Alpha阶段并没有预估上线和拥有用户；
我们目标更近了，论坛社交模块基本完成；只剩余一些校园小应用，可以再后续第一版本发布之后，进行增量开发；
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在最早的团队的会议中忽略了团队建设，而只是讨论分工，导致大家虽然在一起做项目，但是感情并没有建立起来；在后续的合作中发现维系一个高效的团队，这种互相认可和情感交流是很重要的
在制作文档的时候过度拘泥于老师的题目要求，为了完成而完成，而未真真切切的去考虑软件工程思想的要求；文档服务于软件工程，应该主要着眼于项目的实际，做出切实可用的文档；
在预估Alpha工作量的时候，预估的工作量是没有太大偏差，但是缺少对能否按时完成的估计；
我们会做什么改进？
做好团队建设；
在后续的文档制作中更加用心，着力于服务项目的开发；为后来者留下一个好的基础（老师询问是否愿意将项目传给下一届，我们是十分愿意的）；
预估工作量和安排计划之前，应该统计一下成员可以付出的时间再进行计划安排；
计划
1. 是否有充足的时间来做计划?
在Alpha冲刺前我们花了数天的时间来分配学习任务，后面又有对计划和分工组织会议进行讨论；
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们对于计划的意见比较统一；计划是组长提出，队友分析讨论的结果，因为很早就对成员进行了分工，所以并未出现意见冲突；
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
未完全作完，还剩余前后端对接的工作；
对成员的时间、精力缺乏统计和考量，拟定的工作量太大（十天335小时的工作量）；
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
接口设计这一块设计了一些暂时没有用到的接口；现在看来是可以放到beta阶段做的；
前端使用weex作为主界面，对于h5和小程序不支持，其实完全可以使用vue来写，这样平台都能通用；
5. 是否每一项任务都有清楚定义和衡量的交付件?
对每一项任务都有一个测试和验收，验收测试之后才进行下一部分的开发；
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
按照计划进行，未出现什么意外；
没有遇到什么称得上风险；代码按照原定的安排有序开发；如果前后端对接没有完成是风险的话，没有估计到是因为对成员的时间、精力缺乏统计和考量，拟定的工作量太大；
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有留下缓冲区；
缓冲区有利于应对突发事件；处理项目的风险；
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
缓冲区设立应该怎么考量？其实队员除了软工实践这门课程还有其他很多事情要忙；按期完成工作都是一个挑战；
如果要靠队员通宵来定义这个缓冲区的话，不设置也罢；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
技术上：后端学到了spring boot的开发；前端学到了vue、uni-app、weex的入门知识；测试上对于测试工具和测试方法有了更深刻的理解；
团队上：我们更加熟悉团队协作来完成项目这个流程；对于一些软件工程的理论和思想在“做中学”中有了更深刻的理解；
如果重来一遍，我们可能还是会选择这些技术栈，因为这些技术实用，并且上手并不太困难；
资源
1. 我们有足够的资源来完成各项任务么?
资源上主要只需要时间资源；这方面我们是短缺的；
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
对于后端，按照每个接口2个小时；前端一个界面4个小时；精度比较准确，我们实际的开发所需时间相差不多；
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
对于测试，我能专门安排了一个队友来进行测试的工作，对于软件有免费的软件使用，硬件并无太高的要求，这些都已满足需求；
美工设计/文案在之前的原型设计、选题报告等都已经完成了；这次Alpha并无这些资源要求；
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
从现在的成员满意度来看，大家对自己的工作情况、工作成果都是比较满意的；学习的技术也是自己原先想学的，所以技术上并没有这一块的想法；
但是对于博客的撰写，成员“星夜、痕”的文笔不错，如果让他来做，应该会比衡与墨做的更好；
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训，因为没有惨痛的过程，所以没有什么教训；
经验这一块来说，项目实时进度的把控对于PM来说很重要；在Alpha冲刺之前就要充分设计和考虑项目需要用到的技术，并且提前布置成员学习，这样才不会在Alpha阶段手忙脚乱；
改进：时间的分配需要慎重考量，过重的工作量会导致无法预期完成；团队的前端和后端应该进行更多的交流；在会议讨论工作之余，要做好团队建设；
变更管理
1. 每个相关的员工都及时知道了变更的消息?
通过每日会议和实时的qq讨论，大家没有错过实时的变更消息（其实也没多少变更消息）；
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
在Alpha之前就觉得好了优先完善论坛和帖子功能，先不完成校园小应用；这一方面的考量是来自于工作量的估计；时间不足以我们完成所有的功能；
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在之前的系统设计验收标准中有明确的定义；
4. 对于可能的变更是否能制定应急计划?
能；应急加班；哈哈，大家都很给力；所幸没有什么大的变更，仅仅是接口参数调整啊，界面增加按钮啊，这样的一些小变更；
Alpha后换人这个变更，对于换人，由于技术上并没有完全依托于某一个成员，并且比较困难的部分也在Alpha阶段完成了，所以换人对于项目并没有太大的影响；
5. 员工是否能够有效地处理意料之外的工作请求？
没有遇到；基本是按照预期的流程计划走的；工作安排会提前协调好；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
验收很重要，前一步骤没有验收好会导致后面的工作做的不好；
应对变更的最好方法就是平均的安排任务，尽量不要把任务和技术积压到一个人身上；还有就是提前布局，无论是技术学习还是工作安排；
改进的话，对于队友的学习情况缺少反馈和帮助，导致队友上手较慢，所幸安排学习的早，不然会导致突发情况的时候过于倚重某个成员，计划无法变更；
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在Alpha之前就进行了设计工作，大家一起完成的；
是合适的时间，合适的人；
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，在原型设计之前的需求分析中，大家都进行了很细致的讨论，这为后面的设计工作做了铺垫；
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
使用Junit来进行了单元测试；使用Jprofie进行了性能分析；
这些工具很有效，在移交测试人员进行测试之前就减少了很多bug；
uml相比alpha之前有了一些字段的增加，在实际开发中漏发现之前漏考虑了；
有对uml的文档进行更新；
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
每个功能都有差不多的bug产生，因为队友对于框架熟悉程度不够，对于后端开发理解不够；
Alpha阶段 尚未发布，项目还未完成；
Alpha阶段 尚未发布，项目还未完成；
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
测试时同时检查了代码规范； 整合时再度检查了代码规范；
是，严格执行了代码规范；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计必须要充分，这样开发才会省力；
改进人力检查代码规范很辛苦，应该给ide装上一个检查代码规范的插件；
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，先测接口，再验收界面，再测试前后端对接后的成品；
2. 是否进行了正式的验收测试？
是；对于不合格的部分回滚开发人员修改，直到测试通过；
3. 团队是否有测试工具来帮助测试？
使用postman进行接口测试；Junit进行单元测试；
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用Jprofie进行了简单的效能分析；
是有用的；但是还是不够全面；
改进：增加对后端的压力测试；
5. 在发布的过程中发现了哪些意外问题？
Alpha尚未发布；
我们学到了什么? 如果重来一遍, 我们会做什么改进?
测试要全面而具体，并且回滚要及时并且严格；单元测试应该融入到项目开发之中；
改进：编码实现对接口进行自动化测试；对后端进行压力测试；
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
从成员的原有技术栈、成员的兴趣来考量；
除了衡与墨觉得“星夜痕”的文笔更好，如果让他来撰写博客会更好之外基本人尽其才；
2. 团队成员之间有互相帮助么？
会；遇到问题会一起讨论然后解决；
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
解决最好的方式是线下交流；事实也验证了这一点；
感谢总结：
221600219 衡与墨
最感谢的是 真·大熊猫 ，谢谢你对我的包容和理解，并且主动在项目中承担了很多的工作，分担了很多的压力，你的责任心有时候让我自惭形愧，和你合作真的很幸运，希望你能考研到理想的学校；
其次感谢fishkk，对于很多后端的工作，都安排到了你的身上，感谢你一直的支持和理解；
感谢星夜、痕，在有些时候，我提出问题的方式太尖锐，感谢你一直以来包容我，理解我，和你搭档真的很开心；
感谢其他的队友：kilig、巴啦啦魔仙、lc，你们一直都很信赖我，非常积极的完成工作，项目的顺利进行，离不开你们；
221600240 真·大能猫
我感谢组长衡与墨对我的帮助， 因为app前端从未接触过，对我来说是一个全新的领域，是组长给了我入门的途径以及在开发过程中帮我解决了一些我解决不了的问题，也感谢所有队友对我负责的模块的建议，让我能更好的完善我的工作。
221600212 kilig
我感谢 组长衡与墨 在包括结对在内的整个软件工程，给我带来许多帮助，积极带领我们的团队有条不紊的完成任务，承担了很多责任，在这次活动负责的测试任务也让自己收获不少，这次的冲刺对于我今后的学习是一个很重要的指导。
221600235 fishkk
我感谢 组长衡与墨 对我的帮助， 因为某个具体的事情: 对于没有后端开发的经验我来说，在后端开发过程中因为过于依赖前端发生了一些不必要的疏忽，感谢组长大人的及时提醒和指正，这对于我今后的后端开发学习是一个很重要的建议和指导。
221600236 巴啦啦魔仙
我要感谢 组长小墨 这个项目做到今天这个地步他的付出是相当重要的，他有过做项目的经历，针对我们每个人都能很合理的安排任务，对于技术也懂得比较多，告诉我们应该学习什么技术。如果没有他，该次软件实践，我可能就像和以往的实践课程一样应付了事，不会学到这么多东西，没机会接触到何如组织一个大型的项目。还有，他今天请我喝奶茶了，谢谢组长的奶茶。
221600103 lc
我感谢队友真·大能猫和组长小墨的帮助，在这次项目中我们负责前端开发。当我在开发界面的过程中碰到了困难时，通过求助得到了他们及时的帮助。我也因此在这次开发过程中学到了不少知识，也在不知不觉中养成一些好的习惯，学到解决问题的好方法。
221600205 星夜、痕
我感谢小墨对我的帮助。在Alpha冲刺之前，小墨就为我们统一推荐提供了一系列方便快捷的软件：IDEA编译软件、navicat 数据库软件、postman测试软件。之后还给我们寻找到spring boot入门视频以及spring boot web进阶 和 Hibernate注解的慕课网教学。也就是说，在 Alpha冲刺之前，小墨就为我们做了很多铺垫。然而，在实际写代码的时候，我还是出现了一些问题，而且是很严重的那一种。在写代码的时候，我依旧是采用以前写代码的方式，创建自己的一个项目，然后参考网上教程和队友们写的代码，自己写一份。举一个简单的例子：就像是当时我不了解 token 接口的怎么写，然后我就把小墨写的token接口一句一句的照搬到自己创建的项目中。但后来是长平点醒了我，我们是一个团队，况且github的作用便是把自己写的代码融入到团队项目中，善于运用队伍里已有的方法，而不是根据自己的需要，从团队代码中扣取一部分来自己创建的项目中。这大概是一种里程碑式的心态转变，也让我更喜欢和热爱我们的团队。再次感谢小墨队长。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
档次二：CMMI二级，管理级；
这个级别的表述：
在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段；
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
效率上、人员默契上、技术能力上都得到了较大的提高；
你觉得目前最需要改进的一个方面是什么?
改进：开发专门的测试脚本，方便测试；
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
4 -> 我们的业务开发人员都在校内，业务和开发兼顾；
5 -> 我们充分信任队友；
6 -> 我们每天面对面交谈（每日立会）；
8 -> 开发速度稳定；每天都有规定的进度安排；
12 -> 在每次每日立会都会对之前的工作进行反思；
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用专门的idea插件来提高规范编码；
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
重构使用微服务架构，解耦系统，分成多个服务，降低系统的耦合度，提高系统的容量；
3. 其它软件工具的应用，应该如何提高？
多查阅idea、Hbuilder x的使用教程；
4. 项目管理有哪些具体的提高？
分工上、工作量预估上；
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
还未上线，暂时没有这个考量；可以实现对应的接口和管理界面来呈现每日/周活跃用户等数据；
6. 项目文档的质量如何提高？
减少口语化；多使用标准的项目文档词汇来进行描述；
7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
重视团建，营造良好的团队气氛；
8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
理论来源于实际，实际不能只看理论；在实际中思考理论是更可取的方法；
事后诸葛亮讨论会议照片
我们在觅蜜喝奶茶，一起聊天，总结alpha的收获并思考改进的方法；
