全组讨论照片
GitHub地址
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：解决当前社团管理问题，定义比较清楚，有清晰描述。具体说明
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：我们当前完成了社团活动申请、社联审批活动、社联评价活动、社团信息编辑这几个活动，但是还没有能够按时间交付，并且因为小程序的原因，用户数量没能达到预期。
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
答：有一些提高，主要是功能更多，需求分析更透彻（我们和社联有了进一步的沟通），我们将网页分为了社团管理者和社联管理者两个部分。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：不一致，离我们的目标更接近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：目标要制定更加合理一些，完全掌握上一届的代码花费的时间比想象中多很多，导致后期开 发的时间完全不够；如果历史重来，我们会在充分了解上届代码之后再制定目标。
计划
-
是否有充足的时间来做计划?
答：有充足的时间来做计划的任务分配。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：制定计划时是由PM设计初稿，开会时具体讨论细节，如果有人对计划有意见会在会上提出理由，大家觉得有道理就听取意见。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：没有都做完，比如可选地址的可视化没有做，文件上传也没做完，二者的难度都有些大，大家的相关代码知识有些不足。
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
答：在功能设计的时候，因为在之前的团队博客中没有找到网页端功能展示的部分（其实是有的），以为社团信息编辑没有实现，还专门将任务分配给了别人。
-
是否每一项任务都有清楚定义和衡量的交付件?
答：我们每一项任务都有清晰的功能定义，在交付时需要展示是否完成所有的功能，并且不能有bug，即必须展示在所有情况下我们的网页是否能够正常使用。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
答：没有，因为小程序和网页端的使用都花费了好长时间去了解，在PM规定的时间内并没有完成，导致后期的一系列工作都被推后，因为大家当时都忽视了重启项目和学习相关知识的难度，以为在四天内可以实现小程序和网页端的重启。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
答：有缓冲区的，每个任务期限都比较长，并且会因为计网实验等因素进行延长；有作用，缓冲区能够让他们有充分的时间开发，但是在一定程度上会产生拖延的现象。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答 ：第一部分的失败有很大部分原因是PM没有参与到代码的开发，导致对任务的复杂度没有一个很好的认识，对组员是否摸鱼了解不够清楚，下一阶段PM将加入前端或后端，来起到监督的作用。
我们学到了什么?如果历史重来一遍,我们会做什么改进?
答：我们学到了在对项目了解充分的情况下，不要轻易地做计划，任务的划分也不能太粗线条，粒度要细，争取每一天都要有进展。
资源
-
我们有足够的资源来完成各项任务么?
答：不太够，大家基础不够扎实，在使用之前的代码的时候容易出问题，并且不知道如何解决的可能性很大。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
答：各项任务所需的时间主要是往尽量充足的方向来分配的，目的是让大家尽量在截至日期之前完成，精度比较差，并且大家往往需要在截止日期之后才能完成。
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：足够，我们分配给后端两个人做测试工作，一共三天进行测试，美工设计尽量沿用上一届的思路，难度降低不少。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
答：可能我PM工作让他人来能够更合理的安排时间吧，这次我安排的时间表，完全没能按照这个来，感觉突发事件太多了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：在选择项目之前一定要仔细评估所选项目的上手难度，如果历史重来我们会仔细研读每个项目的介绍。
变更管理
-
每个相关的员工都及时知道了变更的消息?
答：知道，因为我们每次变更都会先和PM联系，然后发公告，确保每个同学都能知道变更信息。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：必须实现的功能一般是那种会影响到整体进度的任务，比如网页端的重启，只有重启网页端之后，我们才能在这个基础上进行开发，能够推迟的功能一般是指那种开会讨论之后认为能够给我们的工作锦上添花，但是不是刚需的功能，如：活动场地的可视化。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：在截止日期前能够完成尽可能多的功能，并且目前已经完成的功能在使用过程中不会出现致命bug，则我们的项目就能够出口了。
-
对于可能的变更是否能制定应急计划?
答：是可以的，在我们得知小程序没有审核通过后，小程序扫码登录就无法使用，我们立刻就实现了一个账户密码登录的应急方案，不至于我们没办法进行后续的开发。
-
员工是否能够有效地处理意料之外的工作请求？
答：能够，当我们发现我们最开始预定要组员完成的任务上一届已经实现时，我们能够很快的给组员分配新的任务，并且组员能够很快的进行工作。比如分配给黎明同学的社团信息编辑发现已经实现时，PM将主页修改的任务分配给了他。
我们学到了什么? 如果历史重来一遍,我们会做什么改进?
答：我们学到了在面对突发情况下及时变更计划的方法。如果重来一遍， 我们应该将更多的任务设置为必做。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作是在PM完成和社联的沟通之后，也就是在第一周的时候进行设计的，只是进行了功能的设计，具体风格由网页具体负责人自己设计。时间不太合适，那个时候网页端的具体情况还未知，人挺合适的。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：这个倒没有。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
后端的单元测试：
进行了rail test
前端测试：
| 1.在社团/活动的讨论区进行发言和点赞 | 2.申请入社 | 3.申请认证为社长 | 4.审核或拒绝入社申请 | 5.在所在社团的讨论区进行删除、置顶 | 6.网页端录入和导出数据 | 7.小程序端增删社团管理员 强制删除社员 | |
|---|---|---|---|---|---|---|---|
| a.游客 | |||||||
| b.北航学生 | √ | √ | √ | ||||
| c.某社团的管理员 | √ | √ | √ | √ | √ | √ | |
| d.某社团的社长 | √ | √ | √ | √ | √ | √ | √ |
新功能的测试
1、 在权限都正确的前提下，进行页面内部功能测试，按照下表中的功能树进行检查。
2、 页面之间互相影响的测试点，包括：
-
多个页面有活动的点赞、关注信息，是否一致。
- 多个页面有社团的关注、入社状态信息，是否一致。
-
社团的讨论区和讨论详情页的一致性。
3、页面跳转和页面栈。
新功能验收标准：
| 页面 | 功能描述 | 验收标准 |
|---|---|---|
| 活动审批 | 社团用户上传活动审批的材料，社联用户审批 | 社团用户能够上传材料，社联用户能能够审批 |
| 社团管理 | 社团管理页面 | 社联管理所有社团，社长管理所属社团 |
| 活动评价 | 社联对社团活动进行评价 | 社联可以对社团活动进行打分及评价 |
| 账号注册 | 注册账号 | 注册账号 |
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：开发过程中遇到过如下bug：
1、用户无法注册——开发过程中没有绑定微信，重复注册默认同一个账号
2、无法获取用户身份——数据库里没有相应的用户身份
3、材料无法上传——没有对象存储服务
4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：没有。没有。
我们学到了什么? 如果历史重来一遍我们会做什么改进?
答：我们学会了如何对api进行测试，如何在服务器如此容易宕机的情况下对代码进行测试。
如果历史再来一遍我们会尽量使用一个内存尽可能大的、处理器尽可能好的服务器，除此之外 严格执行代码规范。
测试/发布
-
团队是否有一个测试计划？为什么没有？
答：有。
-
是否进行了正式的验收测试？
答：社联正在进行验收。
-
团队是否有测试工具来帮助测试？
答：没有。（后端有单元测试和压力测试）
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：服务器硬件不行，CPU长时间保持在80%，经常死机。测不了。是代码用react的问题，node太占cpu、内存了，是上一届遗留的问题，我们估计需要更换一个比较好的服务器，或者大改代码。
-
在发布的过程中发现了哪些意外问题？
答：服务器经常宕机，用户超过三个就很有可能宕机。
我们学到了什么? 如果重来一遍我们会做什么改进?
答：我们学到了如何锻炼自己的心态，在服务器炸掉的时候耐心等待它恢复正常。如果重来我们一定买一个比较好的服务器，然后认真的规划一下测试方法。
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
答：团队角色一般采取认领的方式，大家先在群里讨论出前端和后端的具体分工，然后大家自行认领，基本上算得上人尽其才。
-
团队成员之间有互相帮助么？
答：有互相帮助，后端的api开发难度比较大，负责服务器和审核的同学一般会帮忙完成。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
答：一般通过PM来寻找合作的同学，尽量发挥PM的协调作用。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。
- 吴桐雨：我感谢全体组员对我的帮助，因为某个具体的事情:郗哈颉帮助对接社团活动审核模块，作为一个后端新手，他甚至指出了我的前端代码中的错误；徐雁齐、黎明经常不畏惧我的百般骚扰，解答我对前端代码的疑惑；叶志翔、张家榕任劳任怨帮忙加数据解决我对账号权限的疑惑；李堂训在发现前端没有进展时对我们进行了灵魂拷问，促使我加快进度。
- 颉哈郗：我感谢徐雁齐对我的帮助，因为某个具体的事情:一起完成了社团评价模块，并且一起讨论了很多前后端共同存在的问题，我的收获颇多。
- 徐雁齐：我感谢张家榕对我的帮助，因为某个具体的事情:帮助我一起解决了网页端二维码无法显示的问题，指导我后端服务器的基本使用并对二维码问题提出了很多有用的建议，大大推进了我在前端的工作。
- 张家榕：我感谢叶志翔对我的帮助，因为某个具体的事情:帮助我一起解决了数据库从excel迁移到服务器上的MySQL的问题，大大加快了我在后端的工作。
- 叶志翔：我感谢李堂训对我的帮助，因为某个具体的事情：在我因特殊情况不能参加例会时，积极与组员沟通，重新安排时间，让我和其他人的交流更加密切。
- 李堂训：我感谢黎明对我的帮助，因为某个具体的事情：前端代码的整合工作都是他做的，并且每次面对我提出新的要求的时候，都能很快解决。
- 黎明：我感谢吴桐雨对我的帮助，因为某个具体的事情：在写前端页面的时候，因为她设计的UI让我写起来更容易，而且她和学长联系解决问题，这对我的帮助非常大。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：CMMI一级，完成级，项目目标和要做的事情都很清晰，但是在完成项目的过程中，往往会遇到很多的困难，完成具有很大的偶然性。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：属于磨合阶段，大家彼此之间已经能够初步合作但是之间的沟通还是不充分。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：这是第一个里程碑，只知道下一个里程碑一定要比这个好。
你觉得目前最需要改进的一个方面是什么?
答：大家的拖延症，布置好的任务往往无法按时完成。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 业务人员和开发人员在项目开发过程中应该每天共同工作 。我们基本上每次会议时间都会超过1个小时，在这个时间里大家一起讨论问题，解决问题，并且向PM提出一些资源上的要求。
- 可用的软件是衡量项目进展的主要指标。每次例会我们主要通过展示自己部分代码的效果来确认工作量。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
答：当前代码主要是组员写好之后互相分享代码，然后将别人修改的部分添加到自己的代码中，一般是完成一整个功能之后才会上传到
GitHub，并且代码编写也很少按照上一届的代码规范。下一阶段应该严格按照代码规范文件的要求进行编写代码，任何新增代码及时添加到
GitHub相应的分支。 -
项目管理有哪些具体的提高？
答：每日例会及时了解各个成员的任务进展，对任务做出合理的调整。
-
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
答：这次因为小程序没有通过的原因，用户只有10个。
-
项目文档的质量如何提高？
答：想一些代码规范和命名规则，主要使用上一届的文档说明，我们将对这些文档进行修改，让它更适合我们组的开发。
-
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
答：绩效考核应该更加严格，面对任务不能按时完成的情况，必须严格执行惩罚措施，不能因为有合理的理由就推迟任务。
-
对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
答：我对代码规范必须是一个人负责比较认可，因为，我们当前的代码因为赶工期，代码没有严格按照之前的风格进行书写，如果代码下一届继续开发，可能会带来阅读上的困难。