1.事后诸葛分析
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 要解决的问题：我们的软件需要解决用户打卡的问题。
- 定义清楚：包括具体的新建活动、新建打卡、首页搜索、奖励机制等功能。
- 清晰的描述：在之前的部分博客对于典型用户和典型场景有着清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 我们没有全部完成预期的目标。
- 原计划的功能做到了：新建活动、新建打卡、我的活动、我的打卡记录。
- 按照原计划的时间交付了，但是小程序还没有发布。
- 我们的预期用户量是30人，但由于小程序尚未发布，所以目前的用户量只有我们团队6人。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 上一阶段？刚刚完成Alpha阶段的我们应该是一个从无到有的过程吧。关于团队软件工程的质量是挺高的，由项目PM安排任务，队员们积极参与且积极讨论。团队之间能够及时交流，并且互相配合，凝聚力强，显然可见团队的软工质量高。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- Alpha版本尚未发布，目前的用户量只有我们团队6人。虽然仍有不完善的地方，但是基本功能如期实现。我们离目标更近了！
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
-
经验教训颇多，详见团队作业6——展示博客（alpha阶段）
-
如果历史重来一遍，我们会提前学习微信小程序、PHP等开发预备知识；我们会在遇到问题时及时向老师或学长提问，而不是自己调试，耽误过多时间。
二、计划
1. 是否有充足的时间来做计划?
- 也不算有充足的时间来计划，但是我们有抽时间开会，然后做出近阶段的安排和每个人要完成的任务
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 进行讨论，然后选出大家都觉得可行的计划。我们团队比较和谐，不会有人坚持己见的问题，会听取其他队员的意见，然后一起挑出最好的想法
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 有没有完成的，比如本来打算在首页实现搜索和最新活动的功能，最后放在beta阶段完成。因为刚接触微信小程序，需要学的东西比较多，在开发过程中也是一直在摸索，开发进度偏慢。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 柯智青（PM）：之前一直以为云服务器上微信小程序的开发环境下的phpMyadmin就是服务器上的数据库，一直在尝试与phpMyadmin建立连接，浪费了很多时间
- 郑晓丽：一开始写了文本框，想弄个边框，结果一开始不会，弄了个圆点下边框，一开始还跳了很很久，最后全部撤掉弄了个实线边框就好了。
- 郭炜埕：听说编写微信小程序和编写网页差不多，所以在项目一开始我投入了大量精力学习HTML和其他网页编程知识。后来发现微信小程序与网页编写语言内容虽然相似，但仍然存在一些区别。如果再来一次，我会选择直接学习微信小程序的内容，这样对于项目应该会更快上手。
- 廖怡洁：有，刚开始没有连接后端的时候感觉前段很多工作都有点浪费，不过其实都还是在练手，也不会觉得很没必要。
- 黄晓杨：我觉得做的任何事情都不是无用功的，就算是刚开始做错了，后来改回来了，那也是一种对错误的认知，逐渐进步吧。不过有一点可以说是有点浪费时间，就是那个我们使用的MySQL，其实有图形界面版的，而我们使用的是敲命令，这样子下来速度相对就会慢很多，工序也比较繁琐。
- 包梦榕：（可以说从一开始写博客我就觉得没有必要吗。。。。）认真的，首页最新话题的上拉加载Alpha阶段还未实现，但是花了挺久的时间去码字，最后只能暂且被搁置了。
5. 是否每一项任务都有清楚定义和衡量的交付件?
- 没有每项，但是提交代码就是和看板上完成的任务还有分配的博客任务就是我们的交附件
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 基本是按照计划进行的，就是途中出现了一点意外，就是在获取用户ID的时候，是有权限的，所以要获取他的openID，我们团队就卡在这边了当时，好在后面顺利解决了。风险的话暂时没有遇到，如果之后遇到没有考虑到的原因应该也是因为经验不足，毕竟在此之前大家都没有接触过微信小程序。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 没有，缓冲区大概就可以帮助我们在中途就便修复bug，更快发现问题，避免到最后出现不可修复的问题
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 会留出缓冲区，在中途的时候修复bug什么的。更加集中利用大家的时间，因为感觉大家聚在一起效率更高。
三、资源
1.我们有足够的资源来完成各项任务么?
一共分四点叙述：
- 首先是人力资源，我们组的成员都不是大神级别的，而且大家在做项目这方面的经验都比较匮乏，所以主要就是看每个人的自学能力，但胜在我们的想法很多，而且彼此之间会有很好的交流沟通，遇到问题相互帮忙，所以这也是我们能顺利结束alpha阶段的重要原因。
- 其次是时间资源，我们组里有两个成员要考研，而我们日常的上课，写作业也占去了我们很大比重的时间。我们一般都是选择课间休息来进行小组讨论，站立会议等。集中学习和冲刺的时候，我们就会选择晚饭过后的时间，可以说是将空闲时间都尽量挤出来的。
- 再者是学习资源，我们都是在慕课网，图书馆，百度，自己找了资料来学习的，资源可以说是很丰富了。
- 服务器资源，我们是采用了腾讯云服务器，已开始接触也是一脸懵逼，都是后来慢慢摸索才掌握的。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
- 这个任务所需时间是我们安排好的，在冲刺博客上，燃尽图的看板上，码云上，我们都有对任务的完成时间有一定的安排，限期内完成，精确到每天。当然了，项目难度还是超出了我们的预期，我们所花的时间比预期时间还要多的多。
3.测试的时间，人力和软件/硬件资源是否足够?对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的时间还是很充足的，因为我们是小程序，只需要手机扫一扫就可以真机测试了，比较方便。人力资源的话前面有提到，软硬件资源的话主要都是网上就能找到，所以资源充足。
- 对于美工设计，确实是低估难度了，做出来的页面比较简单，没有达到刚开始设想的那样的美观，但也是有自己的小亮点。文案的话，主要是大家一起写的博客，其实很大程度上是觉得写的东西很重复，很啰嗦，又需要很多词藻去诠释，就比较需要动脑筋。
4.你有没有感到你做的事情可以让别人来做（更有效率）？
- 柯智青（PM兼后端）：我的界面应该由前端来做，这样风格会统一一点。当时，后端还不知道该做什么，然后前端进度又比较慢，就一起帮忙搞前端了。
- 黄晓杨（后端）：我觉得我负责的这一块还是可以的，其实后端是一个整体，如果能交由一个人做会减少很多不必要的相互磨合，但是只是一个人做的话，任务量又会很大，不切实际。其实我更想去做前端，设计界面这种事感觉比较适合我，我也更喜欢。
- 郭炜埕（前端）：在这次敏捷冲刺过程中，我主要负责前端界面设计。我觉得同样的工作如果让团队里的包梦榕同学来做，效果应该会更好，因为她对于界面设计比我更加细致，做出的UI界面也会更加美观。效率就不一定了，大家效率都很低。
- 郑晓丽（前端）：我负责的是我的活动和活动详情页面，关于界面，感觉交给做前端的其他几位伙伴会做得更美观，效率也会更高。因为觉得自己代码工底不好，比起她们也也不够细致。
- 廖怡洁（前端）：虽然我负责的任务也都完成了，但是我觉得自己的前端页面设计得并不是很好看，可能如果是其他成员能做得更好。
- 包梦榕（前端）：其实我的话，主要负责的界面在Alpha阶段并未实现，是第二阶段的一个重要模块，倒是有参与琐碎的事，我的队友他们前端有比较熟练的，按这么来说是可以交给她们的，但是每个人都得自己先尝试可行与否吧，在瓶颈面前也可以互相交流讨论，也无所谓是谁的任务啊，所以我觉得这个问题对我来说没有实质性的意义。
四、变更管理
1、每个相关的员工都及时知道了变更的消息?
- 在一个团队中，最重要的事情就是当有新的变化或者更新时，必须让所有成员都在同一时间知道，这样才不会导致成员“白做事”，浪费人力物力，我们团队在这方面做得挺好，因为都是隔壁宿舍的，所以交流非常方便，有任何变更，大家都能及时了解到，由PM带领着互相传递信息。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 我们团队是在开会商讨中决定什么任务推迟以及什么功能必须实现的，比较民主，而且大家意见也比较统一，有利于共同完成项目。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
- 我们项目的出口条件定义得比较清晰：界面较美观，能实现基本的打卡功能：可以新建活动、在对应的活动下新建打卡，并且能查看自己参与的活动以及以往的打卡记录，后端数据能随用户创建的相应记录变化而实时更新。
4、对于可能的变更是否能制定应急计划?？
- 我们团队对于变更能及时地做出应对，开紧急会议，立即商量解决方案，并且制定和规划好接下来的步骤路线和方向。
5、员工是否能够有效地处理意料之外的工作请求？
- 我们团队的成员都能够有效地处理意料之外的工作请求，在一个项目中经常会意料之外的状况，我们在共同商量和讨论的情况下都能找对应对方法，一起面对。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 原型设计在需求与设计阶段，由包梦榕、柯智青两位同学共同完成,其中，包梦榕同学在项目开发中负责前端工作。在原型设计初期，我们小组进行了一次讨论，讨论出我们项目的大致的模型，然后再由设计人员完成设计。是合适的时间，合适的人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有的。在原型设计初期，在新建完话题后，是考虑直接跳转到话题详情页进行打卡选择，后来觉得功能有点重复，考虑新建完话题跳回首页。经过团队成员的协商讨论，最终采取了后者。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 没有运用单元测试，在项目冲刺阶段，小组成员各自都要学习新的知识，本身时间就比较紧，进度又偏慢，所以并没有运用到单元测试。还有就是不太清楚对于微信小程序项目测试代码要如何来编写。
- 在原型设计时，采用了墨刀工具来进行设计
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 新建打卡功能产生的Bug最多，在开发的时候没有考虑到一些特殊的情况，例如，在新建打卡时，先选择活动，并未判断活动已经结束或者该活动尚未开始的情况。微信小程序中的url路径要求是https开头的，然而我们的服务器在SSL证书的安装上还存在问题，所以还没有发布。我们在设计/开发 的时候考虑问题还是不够全面。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 每个人在完成自己负责模块的时候，会进行一下复审，查看是否有冗余代码，是否符合代码规范。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
- 我们团队有测试计划，不过测试阶段耗费的时间不长，六个队员找个时间聚在一起进行测试效率高。
2.是否进行了正式的验收测试？
- 有进行算不上太正式的验收测试。
3.团队是否有测试工具来帮助测试？
- 无测试工具。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 我们团队用的是手动调试的方法来测量并且跟踪软件的效能，大家一起找bug,也挺有效率的。
5.在发布的过程中发现了哪些意外问题？
- 我们的小程序暂未发布，但就体验版而言，出现了域名不合法的问题，因此无法发布。
七、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
- CMMI二级：管理级
- 在Alpha阶段，团队有进行了需求分析调研、原型设计、WBS分解、数据库E-R图设计等前期准备。在冲刺阶段，首先小组人员进行了任务的认领，然后召开了每日例会，对每日要完成的任务以及开发过程中遇到的问题进行说明。对于代码提交到git上，有一定的要求。比如前端的话，每个界面建立一个目录，然后把代码统一放在page目录下。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
- 规范阶段
- 关于项目进展过程中的一些事项，小组成员聚集在一起进行讨论。在项目开发遇到问题时，大家都在想办法一起解决。小组成员在认领任务时都比较积极主动，能够互相理解。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 清楚了微信小程序开发的基本流程，不会像刚开始的时候摸不着方向
- 实现了微信打卡小程序的基本功能，也积累了一定的项目开发经验。
- 团队成员经常聚在一起讨论问题，敲代码，小组成员之间的感情更加深厚，同时也增强了团队的凝聚力。
4.你觉得目前最需要改进的一个方面是什么?
- 目前，最需要改进的一个方面是项目的进度把控。在Alpha阶段，可以看到我们在冲刺时间内，燃尽图并没有燃尽，项目的进度延后了，以至于在发布和测试阶段,我们还在完成冲刺阶段该完成的任务，也导致了我们的小程序无法如期发布。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 原则：无论团队内外，面对面的交流始终是最有效的沟通方式。事例：在Alpha阶段中，针对项目的一些分工，项目中的遇到的问题，接下来的安排，我们经常是聚在一起讨论交流。在敏捷冲刺阶段，经常是几个人聚在一起敲代码，对于开发过程中遇到的一些问题可以及时的交流，能解决的尽量解决。
- 原则：时时总结如何提高团队效率，并付诸行动。 事例：在敏捷开发中，我们经常是聚在一起敲代码，其中有个问题是，人一多，突然谈到某个话题，可能就会聊个几分钟，还有就是每次聚在一起敲代码的时间一般是3~4个小时，有点太长了，到后面精力无法集中，效率也不高。到后面就做了调整，敲代码期间，严禁讨论与项目无关的事情，每次冲刺控制在2个半小时左右，让大家集中注意力进行开发。
八、全组讨论照片
2.团队成员在Alpha阶段的角色和具体贡献排序
| 名字 | 角色 | 团队贡献排序 | 可验证的贡献 | 团队个人贡献分 |
|---|---|---|---|---|
| 柯智青 | PM、后端开发 | 1 | 安排任务，每日的进度追踪，实现前后端的交互，服务器的配置，完成我的界面设计，部分原型设计 | 29 |
| 黄晓杨 | 后端开发 | 2 | 架构设计，数据库的设计和搭建，前后端的交互，服务器的配置 | 25 |
| 郭炜埕 | 前端开发 | 3 | 用户需求分析调查，撰写第一版软件需求规格说明书，新建界面及新建话题界面设计及部分界面跳转 | 18 |
| 廖怡洁 | 前端开发 | 4 | 发表动态界面设计，我的打卡动态界面设计、分析及测试程序，完成WBS分解 | 17 |
| 包梦榕 | 前端开发 | 5 | 原型设计，完善入口界面，首页界面的设计，部分界面连接 | 16 |
| 郑晓丽 | 前端开发及测试 | 6 | 用户需求分析调查，协助分析及测试程序，书写部分文档，我的活动界面及活动详情界面设计 | 15 |