第03组 Alpha事后诸葛亮
一、组长博客链接
二、总结与思考
Part1 设想和目标
1．我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 主要解决：拼车不易拼到车友的情况，节省一定费用。此问题在需求分析报告中已经定义清楚。
- 典型用户：在校大学生（没钱打车那种嘘）
- 典型场景：放假时需要打车从学校到火车站，在拼拼小程序上发布拼单拼到有共同需求的车友，一起打车前往火车站，既可以省钱又可以有一两个车友。
2．我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 我们还未达到最终目标，原定的功能做了8个，未能按照原计划交付。由于小程序还在测试阶段，用户暂时只供组内测试，希望快点做出更加完善的产品出来供更多人来测试嘿嘿嘿。
3．用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量：小程序未完全达到理想目标，用户量还无法估量（我们组的程序小哥们一定加倍努力）（程序小哥们辛苦了）
- 接受程度：用户对重要功能的接受程度还无法估量。
- 离目标更近了么：我们有离目标更近了，小程序正在测试中，希望能够做出更加理想的产品供用户使用。
4．有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 在产品进度方面：在Alpha冲刺阶段前期完成任务较快，这值得表扬，但是我们程序小哥们后期考试比较多，节奏就慢了下来，致使后期的任务完成进度减慢，有一些功能短期内实现不了。如果历史重来，希望能严格制定计划，在前期较空闲的时间抓紧完成小程序，后期较多考试可相对减轻任务负担。
- 在小组任务分配方面：没有给程序小哥们很多小弟，技术力量不足，但是我们程序小哥们真的很厉害，人那么少还能赶出这样完整的产品出来，真的很佩服，真的辛苦是真的累，我们小组能交出来这样的作品和程序小哥们的爆肝付出密不可分，组长真的要跪了，组长知错了，希望别的组员一起跟上，分担压力。如果历史再重来一遍，我们一定安排更多的人打代码，让不会的人硬学代码（哭），也会安排更多测试人员一起测试，及早提出意见和建议，完善我们的小程序。
Part2 计划
1．是否有充足的时间来做计划?
- 是，有充足的时间来做计划，但由于想得比较轻松，没能仔细安排计划，只是大概分配了一下任务，往后计划由组员各自安排自己的任务计划。
2．团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 团队在计划阶段没有什么不同意见，如果有的话，大部分情况下遵从少数服从多数的规则。
3．你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 杨雨丝：原计划工作做完了，那啥......是对分配任务掌握的不是很好。
- 李钒效：原计划的工作没有做完，除了软工，还有别的学习任务和考试等，和期望的进度肯定会有差距
- 宋娟：我的事情基本完成，因为好像没什么事情（）
- 张铮：工作基本都做完了，就是最近事情实在多，特别是数据库这门课
- 朱玥轩：原计划的工作都做完了
- 林郁昊：原计划的工作完成度90%，剩下一点点没有做是因为我还要分出精力去做后端部分，而后端一个bug就要查改半天，十分花时间，好在我提前把前端做的差不多了，不然真的可能崩。
- 吴崎：没有，因为知识的欠缺，对整体的进度的把握不好
- 于婕：原计划的工作准备部分都有完成。但是因为alpha冲刺答辩没有视频展示部分最后也就没有制作视频。
- 许钰梅：都完成了，写博客还是比较简单的
- 吴之昊：没有完成，学生工作太多了，没得睡觉。
- 郑木平：负责后端部分，难度较大部分没做完，课太多了
4．有没有发现你做了一些事后看来没必要或没多大价值的事?
- 杨雨丝：不知道是我们任务不够明确还是啥，我觉得我们组产品经理不是很行呜呜呜（就是包括我），我没有做好产品进度规划把。
- 李钒效：有做了一些感觉并没有多大意义的事，比如写博客、做文档，这些时间花在技术学习上我觉得会学到更多的东西
- 宋娟：焦虑或者是思考的时间太长了，其实时间可以拿去干别的……浪费在焦虑和紧张上真的不太好
- 张铮：没发现做了什么没必要的事情
- 朱玥轩：暂时没有
- 林郁昊：因为想把地图做的好看一点，花了挺多时间研究微信小程序的地图组件，但是有地图的页面其实完全没有实际作用，不过我个人觉得蛮好玩的。
- 吴崎：我不觉得我做了没有价值的事，每件事对我来说都是新的，我可以从中学到新东西。
- 于婕：因为最后没用到。感觉做的啥都没啥价值 心很累OTZ。
- 许钰梅：没有，写博客也是要思考的有意义的
- 吴之昊：我的时间实在是太少了，暂时还没想出做了什么没有价值的事情。
- 郑木平：没价值的事也不是真的没价值，至少你知道了它是没价值的，这也是价值
5．是否每一项任务都有清楚定义和衡量的交付件?
- 一开始没有考虑这个情况，没能给每一项任务下一个清楚定义和衡量的交付件，导致后面有些任务节奏有点乱。
6．是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 并没有完全按照计划进行，在完成项目的时间段中碰上了考试，主要开发人员既要复习考试又要小程序开发，时间赶不及，任务无法按原计划完成。风险可能就是当时没能想到有些功能实现起来很麻烦而且紧跟着两三门考试，再加上平常还要上课，完成任务时间非常少。
7．在计划中有没有留下缓冲区，缓冲区有作用么?
- 有留下缓冲区，基本每个时间段都大概安排了任务，但是由于安排很多任务，已经接近原计划了，计划在Alpha冲刺阶段完成基本功能。
8．将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 可能会考虑一下组员的课程和任务的难度，进一步安排计划，争取更好地利用空余时间完成任务。如果不能在估量时间内完成任务，就加班一下尽量完成任务进度。
9．我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 制定计划不能太过粗略，而且要更合理地安排组员任务，不能把任务都丢给那么两三个人，而且要更抓紧空余的时间，尽早地完成任务，防止后期的意外情况。如果历史重来，会重新安排组员任务且制定更详细的计划，更大地调动组员积极性，尽量让每位组员都能参与进来，共同学习共同完成任务。
Part3 资源
1．我们有足够的资源来完成各项任务么?
- 教材教程的资料资源足够，但时间资源并不足够，剩于未完成的页面和功能没有那么完善。
2．各项任务所需的时间和其他资源是如何估计的，精度如何?
- 各项任务所需时间和其他资源主要由负责完成任务的组员估计，精度一般，只大概估计一下，有一些情况当时未能考虑进去。
3．测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的时间，人力和软件/硬件资源不太足够，不能按时完成原定目标。对于那些不需要编程的资源没有低估难度，美工设计和文案也很考验审美和脑力，真的太难了！
4．你有没有感到你做的事情可以让别人来做（更有效率）?
- 杨雨丝：有，感觉到了Alpha阶段，我这个不太懂技术的组长真的有点菜！！！
- 李钒效：这要看是什么事，比如学感兴趣的前端，效率会高，比如学数据处理这样，提不起兴趣，有兴趣定会有更高的效率
- 宋娟：有！！！我的事情几乎都可替代_(´ཀ`」 ∠)__ 我不配
- 张铮：我的任务都很简单基本，别人做也不会效率高
- 朱玥轩：我觉得我的事让别人做应该更有效率一点，因为我是从零基础学起，剪辑视频感觉其他人可能都会一点
- 林郁昊：我分配到的任务是前端，所以初期我基本不管后端，对于后端知之甚少，结果要到ddl了，由于不可抗力，我也得去做一些后端相关的工作，主要的时间花在学习后端上，效率比较低
- 吴崎：因为每个人都有自己的分工，所以我觉得我做的事不可以让别人来做
- 于婕：感觉别人都有不同程度的贡献。就我一个人在疯狂划水。这个问题我都不知道该说什么（哭）
- 许钰梅：可以让别人来做，不过效率应该都差不多
- 吴之昊：暂时没有。
- 郑木平：请问别人是什么人？
5．有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 要充分利用资源，抓紧空余的时间，尽早地完成任务，防止后期的意外情况。如果历史重来，会在前期比较空闲时间安排多一点的任务，在后期组员忙于考试时减少任务。对于功能方面，加大测试力度，完善功能，尽量扩张测试面！
Part4 变更管理
1．每个相关的员工都及时知道了变更的消息?
- 如果有变更，会在群里艾特全体成员通知大家，保证消息通知到位。
2．我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 我们以实现功能的难度以及基本功能和拓展功能的划分来决定。
3．项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 项目具备了能完好运转核心功能及其他相关的基本功能。
4．对于可能的变更是否能制定应急计划?
- 一开始并没有制定应急计划，等到碰到突然地变更时才临时改变计划，导致后期的任务完成得比较匆忙。
5．员工是否能够有效地处理意料之外的工作请求？
- 若出现意料之外的工作请求，会根据组员现有的任务情况来判断哪个组员比较适合完成，在给予分配，保证能完成请求。
6．我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 安排任务时也要考虑一下突发情况，预想好会出现的情况并考虑解决办法。如果历史重来，会再考虑周全些，把一些可能出现的意外情况也考虑进计划安排里。
- 需要增强对项目的测试，好完善功能。
Part5 设计/实现
1．设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作是在Alpha冲刺快开始的时候，由组长组织会议，组员共同讨论决定。是合适的时间合适的人。
2．设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 小组共同讨论解决。
3．团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 暂时还没有，大家目前只是通过自己使用来提意见，接下来阶段将正式测试。
4．比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 区别有，但是完成情况已经逼近了理想情况。区别产生于对小程序不是特别熟悉，还有一开始的想法太过完善，具体实现时，代码并能有效解决那么多问题，无法做到尽善尽美。否。
5．什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 服务器的算法Bug最多，时间紧任务重，未能进行代码复审，也未能将测试环节完善。
6．代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 小组内互换审查，严格执行了代码规范。
7．我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 代码复审应该随时进行，而不是等项目完结后再进行。测试要及时赶上。
Part6 测试/发布
1．团队是否有一个测试计划？为什么没有？
- 有，计划在项目大致完成时进行测试。
2．是否进行了正式的验收测试？
- 还没有进行正式验收测试，因为小程序还未达到最终理想状态。
3．团队是否有测试工具来帮助测试？
- 目前如果需要测试的话，可能暂且先使用软件本身自带的测试功能进行测试，还没有专门的测试工具。
4．团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 小程序还未完全完成，暂时不考虑测量和跟踪软件性能。测试工作的效果和需要改进的地方还无法得知。
5．在发布的过程中发现了哪些意外问题？
- 项目还未完成，还没有发布，所以还没有什么意外问题。
6．我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 完成任务要抓紧时间，不然连测试都没什么时间进行。如果历史重来，会抓紧时间完成任务，好进行测试，同时，也对测试工具了解多一些，提早做好测试计划。
三、答辩总结
Part1 团队的角色，管理，合作
1．团队的每个角色是如何确定的，是不是人尽其才？
- 秉承着自愿原则，由组员意愿自己选择任务角色。部分组员人尽其才；但有部分组员基础较差分配任务较少，未能人尽其才。
2．团队成员之间有互相帮助么？
- 有，成员间相互帮助完成任务，不局限于自己的任务。
3．当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 目前成员间合作比较和谐，没出现什么问题。
- 我感谢郑木平对我的帮助， 因为某个具体的事情:在小程序出现bug时，我无法解决找他帮忙时他都会帮忙一起解决，跟他合作很愉快
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学会了相关任务的知识，队友间的合作也越来越顺畅。如果历史重来，会再好好安排一下团队的角色，争取更大的人尽其才。
Part2 总结:
1．你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 初始级别
2．你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 团队目前处于磨合阶段。
3．你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 任务安排得更清晰了些，团队成员之间更加熟悉了，配合也更好了些。
4．你觉得目前最需要改进的一个方面是什么?
- 成员中有开发经历的人比较少，任务分配得比例不是很好，而且时间的安排上也不太合理，导致部分组员任务较重，在任务分配和时间安排上还需要改进一下。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 避免不必要的开销
- 尽可能多地减少项目计划和文档，与其讨论要做什么，然后再写下来，不如赶紧动手去做，否则，就是在浪费时间在工作的工作上。
- 开会时没有把任务分配的太过细致，而是大家直接着手去做，直接列出问题，虽然Alpha阶段没有完美的将我们的小程序写完，但是已经完成了大部分功能。
全组讨论的照片
Part3 答辩总结
1.评估团队中每个人对本次作业的贡献比例：
|||||||||||||||||
|:-😐:-😐:-😐:-😐
| 角色 |姓名|具体任务|最终得分|
| 组长、产品经理 |杨雨丝| 评审表、修改博客 |3%|
| 副组长、开发人员 |林郁昊| 前端设计、部分后端 |40%|
| 组员、开发人员 |吴之昊| 前端设计 |1%|
| 组员、开发人员 |郑木平| 后端设计 |34%|
| 组员、产品经理 |宋娟| 主讲人 |6%|
| 组员、后勤人员 |许钰梅| 撰写博客 |5%|
| 组员、宣讲人员 |李钒效| PPT制作 |5%|
| 组员、后勤人员 |朱玥轩| 视频制作、提问 |1.5%|
| 组员、后勤人员 |吴崎|评论以及评分、提问|1.5%|
| 组员、后勤人员 |于婕|视频制作、提问|1.5%|
| 组员、后勤人员 |张铮|评论以及评分、提问|1.5%|
| 合计 | | |100%|
PS:评论以及评分已经在附加分中体现、本组技术人员分配的较少所以贡献比例较为不均衡
2.求出本组的现场答辩得分：去除最高总分，最低总分，求平均分（保留1位小数）
51.2
3.其他组对本组提出的问题
- 第一组：信用等级是拼完之后要给拼的所有人评分吗？恶意评分该怎么处理？
- 答：有差评机制，恶意评分可以举报。- 第二组：会不会出现定位不正确的情况？
- 答：暂时没有。- 第四组：是否能将地图定位的速度提高一些？
- 答：正在努力中，定位速度已经蛮快的了，接下来可以继续改进。- 第五组：私聊功能还是挺有必要的，或者提供跳转微信、qq方便进行交流
- 答：谢谢提醒，但是好像会使得- 第六组：如果想要导航的是一个经纬度而不是具体的地方怎么办？
- 答：输入经纬度。- 第七组：能否增加其他联系方式？
- 答：想在beta阶段添加行程分享。- 第八组：会面地点的精确度是否可以提高？
- 答：会面的地点已经是具体地点。- 第九组：你们视频中显示的订单是已拼一人，为什么你们点进去后显示了两个人的资料，你们又还没加了这个拼单
- 答：因为点进去是，第二个人，我加入了，原来有一个（发起人），所以是两个。
- 第十组：希望能提供私聊功能，不仅仅限于电话
- 答：谢谢第十组的建议，我们正在考虑在小程序中添加私聊功能。- 第十一组：电话似乎有一点隐私的问题，可以用虚拟的吗
- 答：暂时- 第十二组：是否考虑地图选点功能？
- 答：有考虑，正在努力加上，谢谢十二组同学的提醒。
4.个人PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 80 |
| Estimate | 估计这个任务需要多少时间 | 60 | 80 |
| Development | 开发 | 1500 | 1680 |
| Analysis | 需求分析 (包括学习新技术) | 600 | 400 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 20 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 30 |
| Design | 具体设计 | 50 | 30 |
| Coding | 具体编码 | 650 | 1000 |
| Code Review | 代码复审 | 50 | 40 |
| Test | 测试（自我测试，修改代码，提交修改） | 100 | 120 |
| Reporting | 报告 | 100 | 105 |
| Test Repor | 测试报告 | 30 | 30 |
| Size Measurement | 计算工作量 | 20 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 50 | 60 |
| 合计 | 1660 | 1865 |
5.个人学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 8 | 8 | 通过搜索资源、观看教学视频，基本对于程序实现有了一个大概的思路 |
| 2 | 0 | 0 | 16 | 24 | 完成了原型设计 |
| 3 | 431 | 431 | 15 | 39 | 通过搜索资源、观看教学视频，掌握的pygame的大部分用法。将基本的前端功能实现了，网络接口还没有弄好，所以细节部分不知道怎么做 |
| 4 | 210 | 641 | 13 | 52 | 学习了动画精灵，通过pygame动画精灵，简化了扑克牌的载入和显示，将完成度提高，只剩下网络接口部分了 |
| 5 | 116 | 757 | 7 | 59 | 与后端对接，学习了网络接口的知识 |
| 6 | 500 | 1257 | 20 | 79 | 学习了小程序的基本用法 |
| 7 | 800 | 2057 | 32 | 111 | 基本掌握小程序wxml与wxss |
| 8 | 1000 | 3057 | 26 | 137 | 小程序拼单流程前端设计完毕 |
