设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
-
alpha阶段软件要解决的问题是：北航学生没有一个方便快捷的渠道，去查看各个社团信息、新闻文章、举办的活动等社团资讯。
-
具体来说，没有一个集北航社团各种资讯于一身的平台：如今每个社团有自己的公众号，用户一个个去关注和查看文章十分麻烦；社联推送的社团介绍等也比较有限；社团举办的活动基本只能通过社员群、朋友圈、公众号文章的方式来进行宣传，不方便用户获取信息。
-
要解决的问题定义得很清楚，也是我们在设计功能是时的主要考量依据。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 功能：原计划的最核心的三个功能（展示新闻、社团信息、活动）都做到了，同时还加入了一些非核心功能（比如按类别筛选新闻）。
- 交付时间：原计划4.18晚提交微信审核，实际熬了会儿夜，在4.19凌晨提交审核，并幸运地在4.19晚18点通过审核、发布上线。
- 用户数量：截至4.25，即发布后的第6天，达到了452的用户量，尚未达成“发布后一周内达到500用户量”的目标，但已十分接近。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
没有上一阶段。
附：虽说我们是基于学长的项目，但是两个项目实际开发的内容差别很大，特别是我们alpha阶段的目标是一个学长完全没有考虑的产品。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
与我们的预期一致：用户没有什么大的吐槽，反馈的内容大都是数据不够多，这一点我们会在beta阶段尽快开发出 让社长录入信息的接口，来保证小程序的数据可以更丰富、更准确、更实时。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
我们会把UI设计也加入到alpha阶段中，而不是延迟到beta阶段。
计划
是否有充足的时间来做计划?
- 是的。我们做计划的流程是：
- 每周开始前，由PM定下前后端在本周的任务和目标，并尽量分配具体到每个人的本周目标，同时声明一些特殊时间节点，比如A同学的B任务必须在周x前完成，因为B任务是另一位同学的前置条件。
- 然后，每个人根据自己本周的目标，以及自己本周其它个人事情的安排，列出自己的每日计划，也可以提出对自己的任务进行转移和调整。（自己做的计划，跪着也要完成）
- 这样做计划的方式，能让团队成员自由把控时间，这样比PM直接分配每日计划要更方便、更人性化、更有可行性，做计划的效率也充分提高！
团队在计划阶段是如何解决同事们对于计划的不同意见的？
成员可以对自己的本周任务提出疑问、调整或转移，PM会解释自己这样计划本周任务的原因，若还有问题，则由成员们讨论解决。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 大多都完成了。
- 没有做完的原因主要包括：
- 自己的时间没有安排过来，有其它的事情
- 项目整体目标有变动，原本计划的工作暂停、取消或延迟。
- 该任务难度较大，或不是本阶段的核心任务，权衡后决定暂停、取消或延迟
是否每一项任务都有清楚定义和衡量的交付件?
大都有清楚定义和衡量的交付件，主要是以下几类：
-
后端开发任务：代码、接口文档
-
前端开发任务：代码、开发版二维码
-
PM：博客按期提交、更新issue、数据整理文档等
-
其它调研任务：调研结果小文档，或demo代码
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 基本上是按照计划进行。
- 有这么些小意外：
- 后端人员在花几天时间浏览了学长代码之后，决定重写。
- 跳转公众号文章需要使用web-view组件，该组件要求小程序是企业号。
- 无法实现最美好的梦想：自动爬取公众号文章并在小程序前端渲染。
- 未估计到的风险：后端由于需要重写，因此进度较慢，不过后来还是抓紧赶上了进度。为什么没有估计到：因为一开始后端人员初步浏览之后觉得可以直接用他们的代码，但是后来“浏览代码并决定重写”这个过程也耗费了很多时间。
在计划中有没有留下缓冲区，缓冲区有作用么?
有。其实成员做每日计划的时候，大都会自觉在最后1-2天写上“机动分配”。而且其实PM会把真正的ddl提前，PM已经陆续设置了3个发布ddl（逃
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
会把重难点的地方、核心的功能等的完成时间往前移动，以保证核心功能的完成度。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- alpha阶段开发的第一个星期，是由PM直接指定每个人每天或每两天的任务，结果是大家有些天时间多但任务少，有些天时间少但任务多，安排不都个性化、不够合理、总是需要调整。
- 如果历史重来一遍，我们会从一开始就由个人制定每日计划。
资源
我们有足够的资源来完成各项任务么?
基本还算足够，团队整体的时间和能力，我们收集的数据和需求等，都基本能够完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
由每个人制定每日计划时自己估计，精度较高。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 还算足够。测试分为前后端，前端测试直接由PM完成，后端单元测试由该单元的编写者负责测试，后端覆盖率测试由振亚完成，后端压力测试由廓然完成，分工还算合理，资源还算足够。（虽然还蛮肝的
- 是的。比起事先的预估，PM觉得博客写起来实际还是很费时间的，前端也觉得前端的美工设计（寻找模板）比较难，所以我们的前端alpha阶段以整洁为原则，暂无设计元素。
你有没有感到你做的事情可以让别人来做（更有效率）?
- 有时候有这种感觉。不过，虽然有人在这个任务上能做得比我更有效率，但他还是应该去做他该做的事，每个人发挥自己的最大优势，才能使整个团队更有效率。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 我们会从一开始就由个人制定每日计划，这样才能把每个人的时间资源进行充分的利用。
- 前端测试将交给至少2个人进行，如果时间够的话，可以是串行进行，时间不够则并行。
变更管理
每个相关的员工都及时知道了变更的消息?
是的，不紧急的在每日例会上通知，紧急的变更消息直接由PM私聊通知到位。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
PM根据对项目进度的整体把握、需求优先级、需求实现难度等做出权衡和判断，然后在例会上大家可以对此提出质疑。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 兼容性：对Android和IOS操作系统、不同版本的微信都兼容。
- 易用性（用户友好）：底部导航易用，功能入口明显，交互结果的弹窗提示等。
- 功能正确性：各功能正确，页面跳转正确。
对于可能的变更是否能制定应急计划?
是的。对于很重要的变更，我们还会制定plan A 和 plan B.
员工是否能够有效地处理意料之外的工作请求？
- 经常出现的一个情况是，后端将接口设计并实现后，前端发现之前写的请求数据文档还差点东西，于是向后端提出新的接口。
- 成员们能够有效处理。团队成员具有自己的判断力，会先判断这个意料之外的工作任务是否真的必要，经常会向PM提出质疑，甚至请求调整该任务。团队成员的主动判断和质疑，以及PM的及时沟通和处理，使我们能够有效地处理意料之外的工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们会让功能更加明确，让前后端对需求的理解更加深入，同时给接口设计阶段留更多的时间，让前后端和PM都能够认真地从各自的角度去审核接口设计的质量，进而减少前述的变更情况。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- alpha阶段第一周（计划和设计）进行。
- 主要由PM完成功能、需求、原型方面的设计和计划，由少昂和雨飞完成技术架构方面的设计和计划。
- 是的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有遇到小细节上的模棱两可，但这些可以暂不理会，毕竟现实和计划是有差别的，计划时更多的是考虑全局的东西，特别细节的东西不需要过于纠结，模棱两可即可。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 我们运用了单元测试、代码覆盖率插件、gitlab代码管理、issue进度管理、墨刀原型设计、xmind思维导图等来帮助设计和实现。
- 这些工具蛮有效的。
- 我们没有uml文档....
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 登录功能，一是因为大家做小程序开发的经验不足、测试不够充分，二是因为之前我们为了让小程序的用户和网页端的用户能够互通，因此设计的小程序用户是需要注册的，但其实这两种用户可以不互通，根本原因还是PM在需求的沟通和传递上没有到位，导致登录功能一改再改。
- 微信用户名如果包含特殊字符（比如表情图片），那么在授权登录时，会弹出登录错误，但是仍能进入主页使用小程序。
- 因为缺乏微信小程序开发经验，而且测试时没有充分使用其它多种手机进行测试。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 后端由少昂复审振亚和廓然的代码。前端代码暂无复审机制。
- 还算严格，不过还有待复审和改进。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们会让功能更加明确，让前后端人员对需求有比较深入的理解，同时要求所有关于接口变动的商议都必须在团队群里进行，不能私聊。
测试/发布
团队是否有一个测试计划？为什么没有？
有。
是否进行了正式的验收测试？
是的，在alpha阶段的最后3天，我们进行了正式的、全面的验收测试。分为前后端，前端测试直接由PM完成，后端单元测试由该单元的编写者负责测试，后端覆盖率测试由振亚完成，后端压力测试由廓然完成，分工合理，完成度较好。
团队是否有测试工具来帮助测试？
是的。后端代码覆盖率测试使用了插件；小程序自带性能测试指标工具。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 后端进行了压力测试，前端使用的是小程序自带的性能测试指标工具。
- 从软件实际运行的结果来看，这些测试工作还是有点用处的。
- 需要改进的地方就是没有在各种机型上进行小程序的前端性能测试。
在发布的过程中发现了哪些意外问题？
发布时比较顺利，微信审核一天即通过，没什么问题。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
如果重来一遍，我们会把测试做得更充分、更细致，这就需要我们提前完成开发任务，给测试留下更多的时间。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
主要是根据成员的意愿，同时会考虑团队的需求，来确定每个人的角色。有些人是想做自己擅长的，这些人是“人尽其才”，有些人想挑战没有经验的角色，我们也尊重他的意愿。
团队成员之间有互相帮助么？
有的。主要是 后端内部、前端内部之间互相帮助，比如遇到问难时请教经验比较丰富的成员，或者觉得任务难度较大，请求进行协助，
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
小问题可以线上聊天解决，比较重要的问题一般会提上会议议程，在每日例会中讨论解决。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI的第二级，即管理级。我们的项目在实施时能够遵守既定的计划与流程“在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查”。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段后半期。团队成员目前能够进行较好的合作，但是还需要继续磨合，毕竟beta阶段开发的东西和alpha很不一样。
你觉得目前最需要改进的一个方面是什么?
在接口设计和复审确认阶段，需要留更多的时间，由前后端和PM三方人员参与，以减少后续更改接口的数量。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
这里是敏捷开发的12条原则，其中我们做得最好的是：
- [4]业务人员和开发人员在项目开发过程中应该每天共同工作。
- 具体来说，就是我们每天都开例会，交流需求、功能、和技术，同时PM会在团队群、前端群、后端群中把握进度、协调解决问题。
- [10]保持简明——尽可能简化工作量的技艺——极为重要。
- 在alpha阶段中，我们围绕“展示社团的介绍、新闻、活动”这一核心功能进行，确保了核心功能的完成度较高、用户体验较好。虽然功能不多，但是很明确，因此做的很完善。
- [11]只有能自我管理的团队才能创造优秀的架构, 需求和设计。
- 我们的每日计划制定由个人来完成，具体的：由PM定下每个人/小组的本周目标，同时声明一些特殊时间节点，然后，每个人根据自己本周的目标，以及自己本周其它个人事情的安排，列出自己的每日计划，也可以提出对自己的任务进行转移和调整。这样，成员们自我管理，执行自己制定的计划，同时接受团队其它成员的监督。
- 每日例会上，每人汇报今日进度，互相监督，然后积极讨论自己今天遇到的困难等，并对前端的页面提出意见，不断进行完善。
下个阶段要改进的地方
- 测试：把测试做得更充分、更细致，这就需要我们提前完成开发任务，给测试留下更多的时间。特别是，前端测试要交给至少2个人进行，如果时间够的话，可以是串行进行，时间不够则并行。
- 前期的规划和设计：需求设计和原型设计要更加明确。
- 需求理解、接口设计和变更：前后端人员都要对需求有更加深入的理解，同时给接口设计阶段留更多的时间，让前后端和PM都能够认真地从各自的角度去审核接口设计的质量，进而减少接口大量变更的情况，同时要求所有关于接口变动的商议都必须在团队群里进行，不能私聊。
- UI设计：继续完善UI，寻找好的模板，或者寻求社联帮助。
- 规范性：数据库模型设计要更加规范、代码风格要更加规范。
照骗
会议时间：2019年4月26日 12:00-13:00
会议地点：F座和G座之间的二楼沙发
照骗：
忘了拍照片了，为了证明我们真的开会了：
-
这是会议地点：
-
这是会议前一天统计大家会议时间：
-
这是PM准备的会议内容：
其实这次会议不仅是事后总结，还讨论了beta阶段大致计划和团队内部角色变化。其中，beta阶段计划还需更细致地整理成一篇博客，团队内部角色变化结果已经确定如下：
| 成员 | 分工 |
|---|---|
| 少昂 | 后端组长，负责架构设计、用户系统、数据模型、部署工作，并指导振亚、廓然、雨飞进行接口设计和开发，保证接口质量。 |
| 振亚、廓然、雨飞 | 后端组员，负责接口设计和开发，以及后端测试。 同时负责网页端（简陋版） |
| 青城 | 前端，负责小程序的新闻、活动模块。 |
| 李大 | 0.5个前端，负责小程序的社团模块。 0.5个PM，负责分配任务、进度把握和记录、例会主持、成员协调。 |
| 静芬 | 0.5个前端，负责小程序中我的页面。 0.5个PM，负责需求调研、功能设计。 |
| 宇飞 | 负责联系社联，需求调研，UI设计，宣传和推广。 |
PS：【5.14更新】在实际实行过程中，发现0.5个PM并不可行，因此PM仍由静芬担任，成员变动仅：雨飞由小程序前端，转为网页端全栈。