项目Postmortem
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件针对的是福大学子来到食堂会犹豫不决无法决定吃什么的痛点，希望做出一款软件可以根据大家的口味帮忙决定吃什么。其中，用户只需要回答简单的问题就可以得到结果，解决了普遍存在的“选择恐惧症”。软件的定义还是比较清楚的，这来源于我们生活中自己也遇到的问题。在编写需求规格说明书时，我们对典型用户进行了清晰的定义，并且通过问卷调查明确了市场上是存在对于我们的软件的需求的。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的目标大部分都已经完成。在实际的开发过程中，我们将一两个功能放到了beta版本实现。
核心功能有在alpha冲刺结束时按时交付。尽管这次冲刺延期了一星期答辩，但大部分功能在一周前也已经基本完成。
我们的软件分为学生端和商家端，目前完成了学生端的一个发布版本，但还没有公开向用户发布。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
上一个阶段团队还没有开始实际开发。如果说团队现场编程作业是上一个阶段的话，我们团队的软件工程质量的确有提高。主要体现在以下几个方面：
- 任务分工更加清楚了，每个人有明确的分工，大家之间的配合也从无到有，到熟练。
- 有详细的文档编写、代码注释风格要求。
- 团队成员的技术水平通过学习得到了一定的提升。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在项目的规划阶段对于一些具体细节的思考度不足。例如讨论时觉得都讨论的差不多了，但具体实践时具有难度不得不多占用一些时间。
改进：提高自己的编程能力、以及对于编程语言和框架的熟练度很有必要。
计划
是否有充足的时间来做计划?
之前有充分的时间来讨论、构想整个软件的框架，之前布置的每一项作业——立项报告、需求规格说明书、UML图绘制——都在不断地让整个软件的轮廓在我们的大脑中变得清晰。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段基本没有什么不同意见的出现。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本完成。没做完的部分有一部分需要较大的工作量而推到了Beta冲刺。
有没有发现你做了一些事后看来没必要或没多大价值的事?
PM很早敲定了一些接口文档，然而后来都废弃了。接口文档最后由后端实际设计前后端逻辑和设计数据库的人来完成。可见的确PM不要涉及太具体的代码部分的内容。
是否每一项任务都有清楚定义和衡量的交付件?
有的。在Alpha冲刺的初期，全组成员开会最主要就是讨论清楚整个业务逻辑，讨论完业务逻辑，我们再细分出各个任务，例如前端由几个页面组成，后端要写哪些接口，要设计几个表等等，这些具体的东西就是具体的交付件。把每一项任务分配给各个人，形成详细的任务分配。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本按照计划运行。有一个意外就是前端组组长请假回家了，导致前端组有三天空档期，没有按照原来预想的进度进展下去。（没办法预估啊）
在计划中有没有留下缓冲区，缓冲区有作用么?
本来是没有缓冲区的。但是老师出差，答辩延期了一周。一下子，队员紧绷的神经都放松了许多。然而，这多余的一周并没有什么实际的额外效果。因为我们团队在一周前也已经基本实现了大部分的功能。新的这一周，PM为团队新制定了一些额外的目标，但基本上都没有完成。这一插曲可以反映deadline是第一生产力这个经典的大道理。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
感觉目前整个团队的态势发展良好，只要维持住目前的节奏就好了。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
赵畅：进度管理十分重要，是我们学到的一课。Alpha冲刺进行到一半，这个时候突然有一个额外的作业——团队现场编程完成一个抽奖系统。这之前大家不紧不慢地学习框架学习语言，好像冲刺结束还有好多天，悠哉游哉。作业下来了，这时候猛然发现大家实际产出代码的能力是不足的，于是大家开始爆肝编程来解决这个问题。这项风险没有估计到，只能说too young too simple. Alpha冲刺结束后再翻《人月神话》，第二章写着“系统编程的进度安排背后第一个错误的假设是：一切都将运作良好，每一项任务仅花费它‘应该’花费的时间”。想起来是一套，做起来是另一套。好似编程语言、各种工具都易于驾驭，信手拈来，然而实际的开发中是会遇到重重困难的，一定要尽早开始，重视项目的进度（需要PM和组长多把控）。如果重来一遍，一定会要求队员尽快上手写代码，团队尽快进入能够有实际产出的创造阶段。
资源
我们有足够的资源来完成各项任务么?
有的。前端、后端各有一位小组长。这两位同学起到了领导作用。学习资源的话，网上的资源十分丰富够用。服务器方面，腾讯云10块钱一个月的产品也是完全足够应付目前我们的玩具产品（感谢腾讯云）。
各项任务所需的时间和其他资源是如何估计的，精度如何?
其实一开始我们敲定了各个任务，但没有衡量这些任务的完成所需时间，说实话在一开始大家都是零经验，很难有个确定的数字。
赵畅：不过这个情况在你真正去做了一定的开发后就有所改善，例如在有一天我完成用户接口后，获知写一个敲定好逻辑的接口后台代码需要的时间数据：写代码3个小时，debug+本地测试大概需要两小时。这部分时间这么长还是因为对于php和Web框架不熟悉的原因。如果把后台代码部署到服务器上让前端对接，在前端不熟练的情况下要额外多出一天的时间预算。这样子的精度还是足够的，方便PM和小组长把控进度。也方便其他成员参考，留出多少时间段来进行开发。
测试的时间，人力和软件/硬件资源是否足够?
测试的时间和人力不足够，感觉软件还有很多缺陷，代码也不够完善。大家学习开发知识的同时还要应付考试，为了完成基本功能就已经费神费心，基本任务完成就感觉已经可以交付了，对于测试和代码的健壮性不是太上心。
对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
PM：是。将头脑里的设想付诸实际，其实是一件很难的事，在项目中的体现就是虽然阅读了《material design》的设计教程，但要真正做出符合设计规范的UI界面比想象中困难很多。
你有没有感到你做的事情可以让别人来做（更有效率）?
恒达：前端界面要个确定的Ui和审美规格，重写3次才用框架的我眼泪掉下来。
*：有的，我觉得我写的接口后端组里的大佬们大概几分钟就写完了，而我花了两三小时，所以有时候会觉得其实我好像可以更适合web组，毕竟更多的开发经历是html。大概这就是“群佬我菜”的感觉吧。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
恒达：任务deadline的提前量如果能更精确就好了，这样子有利于项目进度的把控。
变更管理
每个相关的员工都及时知道了变更的消息?
Alpha冲刺时每两日一次的站立会议交流算是一个很好的方法。此外，线上交流很方便。如果有线上聊天解决不了的技术细节问题，组内（前端组、后端组）或者整个项目组就会进行团队现场编程来面对面解决。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实行的功能就是项目的核心功能和Alpha冲刺实际开发过程中遇到困难较小的功能。
推迟，一般是因为这个功能可能需要较大的工作量而Alpha冲刺的时间所剩无几，这时大家就做出推迟到Beta冲刺时完成的决定。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在需求规格说明书中的“Alpha验收标准”有清晰的定义。
对于可能的变更是否能制定应急计划?
因为需求和项目的具体逻辑是组内制定的，好像也没有那种变化程度太过急剧或者有提出什么十分刁钻的需求以至于要到“应急”的程度吧。
员工是否能够有效地处理意料之外的工作请求？
项目初期对于任务的划分基本上涵盖了整个Alpha冲刺过程。几乎没有意料之外的工作变更。一般来说组长布置给组员的额外的一些小任务（例如多加个按钮，某个逻辑有点什么小变更，多写个接口之类的）团队成员也可以及时地完成。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
感觉这部分我们团队做的还是不错的。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在Alpha冲刺的初期，全组成员开会讨论清楚整个业务逻辑。但这个不算真正的设计，因为很多内容和细节再实际开发的设计过程中都由重新敲定。
UI原型设计主要由PM来负责。
到了实际编码前的设计，例如设计逻辑、设计接口和表，主要由赵畅、王源和王彬来完成。（后端组组长和组员以及PM）
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
因为都到设计阶段了，有什么模棱两可的情况出现都会讨论清楚并敲定一个最终的方案。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有运用单元测试，但有测试驱动的开发，每个接口都有写测试用例，虽然可能不是很完善。
有设计UML。UML是很有效的，有的时候对于概念不清淅可以打开类图看看，在讨论逻辑时打开用例图和泳道图帮助理清思路。
开始的UML和现在的文档肯定是有差别的。例如数据库的字段名字、属性类型，类图中对于每一个模型的定义或多或少有删有减等。这些区别的产生是很自然而然的，这里引用《人月神话》中的一句话：“对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。”
我们倒是没有更新最初的UML文档，这些最初的UML图都始终作为参考，时不时地被打开。真正开发时用的接口文档都是重新写的。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
前端Android页面出现的Bug最多，包括例如动画效果在某些品牌的手机下会导致应用闪退，某些情况下地图数据在地图上绘制不出地标等。原因，就是在大多数情况下（运行的好好的）我们并不清楚是为何导致了这些BUG。可能是由于安卓生态环境的碎片化，各家厂商并没有遵循原生安卓的系统设计规范。还有就是有些Bug的产生触及到团队成员的知识盲区了。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
后端代码由赵畅负责代码复审，审阅代码、注释以及接口文档。后端这方面工作做的还是不错的。
志炜（前端组组长）：前端组并没有很严格地进行Code Review，大致merge到master大部分都是自己在进行的，部分存在没有完全遵守代码规范的情况。我的部分我觉得是没问题的 个人认为还是时间成本的问题吧，但还是应该规范起来，提高代码的整体质量。
测试/发布
团队是否有一个测试计划？为什么没有？
本来分布了一位同学专门负责测试，但最后这个计划搁浅。
展瑞：因为我本来的任务是负责测试的，但是同时也在后端组做事。期间有一段时间学习了一下测试的相应知识，发现了自己在语言上和一些知识储备都有相应的不足。开会的时候，基于我们的代码比较优秀的前提下，我们觉得测试任务可能不需要采用自动化测试，而且人工来测试。所以测试计划被拖后，直至死亡。
是否进行了正式的验收测试？
在后端，每个人都写好接口文档，都经历本地的测试，以及服务器测试，才交付前端进一步开发。在整合系完所有功能后，手动考虑多种情况进行测试验收。
团队是否有测试工具来帮助测试？
后端使用postman对每个情况都进行了测试。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
页面整合完后，在不同的机型上使用，出现了页面切换出现一些bug，以及部分机型有闪退的情况。
在发布的过程中发现了哪些意外问题？
发布了alpha冲刺后的第一个版本，发现了没有写logout的按钮。因为我们有token机制来使得一名登陆的用户保持两小时的活跃状态，超过两小时未有操作就需要重新登陆。然而我们忘了写退出登录的按钮，如果token过期，就永远无法再登陆，需要重装APP才可以解决这个问题。是个严重BUG。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
恒达：假如能重来，会在前端组内更加积极的交流，在前端组内也写上技术文档，提高前端界面质量。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
其实只有志炜算是一个熟练工，他作为安卓前端组的小组长是当之无愧的。其他人都是完全的新手，在分配角色时是自愿或被指定的，就很随缘。
当然最后的结果是大家都发挥了自己的作用，大部分人都能做自己擅长的东西。
团队成员之间有互相帮助么？
PM：有的。我们的管理方式为三位一体：PM、前端组、后端组。前端组由志炜带队，志炜有实际的项目经验，其他成员有问题都可以请求帮助。
赵畅（后端组组长）：后端组内有形成一份组内自己的技术文档，有任何问题都可以询问组内成员或者直接查询这份文档，里面很多问题都有组内成员积累的可行解决方案，省去了很多百度、google的精力。
志炜（前端组组长）：有的，自己Android也写的比较多，遇到的坑，爬出来的坑，相对而言多一些吧，同组的遇到问题时，能给予一些帮助。使用过的工具也较多一些，也能给出一些推荐。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
讨论之后由PM、前后端组长作出决定。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
- 我感谢王源对我的帮助，因为和他一起度过了几个讨论逻辑、写代码、debug、测试的夜晚。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
文垚（前端组）：我学会了Java和Android开发，特别是对Json数据的使用和理解，并且在队友的教导下学会的git的使用。如果历史重来一遍，和我会将回答问题界面的UI设计得再优美一点。
煌伟（Web端）：学到了一个团队是如何合作运行，每个人如何为团队更好地贡献自己的一份力量。如果历史重来一遍，我会在冲刺之前更加充分学习所需要的技能，而不是在冲刺阶段边学边做
志炜（前端组组长）：如果是对于我个人而言，可能需要做的就是再肝一些吧，但这学期开头肝了一个多月，快两个月吧，所以有点想进入点养生状态，所以这阶段即使有熬夜也没有特别晚就只到一点多两点左右，每天差不多可以说是事情都排得挺满的，也勉强完成。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们查阅了这个链接来了解CMM/CMMI是什么。讨论后认为，后端组的工作以及达到了已定义级(Defined)，因为后端组有实现技术工作和管理工作的标准化、文档化。后端组组长赵畅放出狂言“随便来个人我都能培训到他能写代码”。前端组水平介于初始级别(initial)和可重复级(Repeatable)之间。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
后端组：整个团队目前处于创造阶段。
前端组有不同意见：规范阶段吧，还有一些东西能再规范一些。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
对比Alpha开启前，我们项目组最重要的改进是真正的能产出代码，以及对于任务需要的时间有一个度量的标准。还有就是大家对于软件工程里的一些概念有了切实的体会，例如文档、项目进度管理、前后端的合作等。这些是只听理论课体会不来的。
你觉得目前最需要改进的一个方面是什么?
赵畅（后端组组长）：Alpha冲刺初期花在学习基础知识和熟悉框架、编程语言上的时间，应该提前去完成，需要提高积极性。
王彬（PM）：应该增强空余时间的紧迫感，这样才能避免出现突发事件时的措手不及。
文垚（前端组）：队员之间的沟通交流还需要进一步的加强，特别是在遇到某些难题时，更应该积极沟通，一起讨论出解决方案。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
参照《构建之法》P114页的敏捷开发原则，回顾我们的Alpha冲刺过程，我们做得比较好的有：
- 第四条：“业务人员和开发人员在项目开发过程中应该每天共同工作”。团队现场编程是常有的事。
- 第五条：“以有进取心的人为项目核心，充分支持信任他们”。前端组和后端组各有一名组长，分组管理，在他们的带领下每一个组都把各自的工作完成的不错。
- 第六条：“面对面的交流始终是最有效的沟通方式”。例如Alpha站立会议、团队编程、开会讨论等等。
- 第九条：“不断关注技术和设计，才能越来越敏捷”。后端组有自己内部的技术文档和所有接口设计文档，积累了经验。
团队贡献比例
| 组员 | 贡献比例 |
|---|---|
| 赵畅 | 19 |
| 王源 | 16 |
| 王彬 | 15 |
| 志炜 | 15 |
| 文垚 | 10 |
| 恒达 | 7 |
| 煌伟 | 6 |
| 展瑞 | 6 |
| * | 6 |
答辩总结
小组现场答辩评分
- 去掉一个最高分，去掉一个最低分，小组最终得分为79.86分
| 组号 | 组名 | 打分 |
|---|---|---|
| 1 | 爸爸饿了队 | 80 |
| 2 | 拖鞋旅游队 | 79 |
| 3 | 彳艮彳亍队 | 84 |
| 4 | 火箭少男100 | 75 |
| 5 | 起床一起肝活队 | 81 |
| 6 | 404 Note Found队 | 74 |
| 7 | 第三视角 | 81 |
| 8 | 小白吃 | 84 |
| 9 | 我头发呢队 | 79 |
第二组的提问
问题1:提给用户的问题是否多样化？
- 答:我们的问题库中目前有40道问题,每次用户需要推荐时我们会从问题库中随机选出三道题供用户选择自己的口味,在beta我们会酌情考虑扩充问题库的规模.
问题2:商家端的功能会有哪些？
- 答:商家端将基于web提供服务,目前已经做好页面的功能有菜品添加页面,商铺端注册登入页面,之后在beta阶段我们会继续实现用户口味分析报告页面
问题3:地图上的红点太密集了，也没有店铺信息，能否出线一项展示推荐产品具体位置的食堂的平面图？
- 答:地图上的红点代表每一个店家的位置,红点大小的问题我们已经找到了解决方法,在后续会使得定位点的大小随地图缩放等级改变.至于用平面图展示产品具体位置的功能我们已经在alpha版本中有所考虑目前需要手绘食堂平面图并收集各个店铺的相对位置来支撑我们的功能.
第三组的提问
问题1:用户口味是长期形成的，如果用户的选择类型一致，会不会出现一直重复推荐某一道菜品的情况？如果会，那么你们是如何处理矫正的？
- 答:我们也考虑到这个问题,所以我们在alpha版本的推荐算法中只针对用户明确拒绝的菜品更新用户的口味,并且我们的推荐算法并不只推荐一道菜肴而是了概率排名前几位的菜品随机推荐给用户,一定程度上预防重复推荐一道菜的情况.
问题2:菜谱更新麻烦，个人感觉如果要进行更新需要一个个去调查，过于麻烦，能否做到与商家合作，通过商家更新信息来做到实时更新
- 答:菜品更新只能靠人工这个问题我们也很无奈,不过我们是起步中的开发小组在食堂看来没有什么话语权,如果未来我们得到其他方面的资源支持会考虑与商家合作更新我们的菜品信息.
问题3:请问你们提供给用户测试的题目有多少呢？真的能够准确的测试到吗？
- 答:我们的问题库中目前有40道问题,每次用户需要推荐时我们会从问题库中随机选出三道题供用户选择自己的口味.用户的口味是一个主观的问题,我们只能力求通过我们的问题获取用户当时的一个口味偏好.
第四组的提问(暂无)
问题1:
- 答:
问题2:
- 答:
问题3:
- 答:
第五组的提问(暂无)
问题1:
- 答:
问题2:
- 答:
问题3:
- 答:
第六组的提问
问题1:您好，你们的PPT很是精美规范，具体介绍了你们的算法和代码规范，这方面值得借鉴 。但UI界面设计就略显逊色，有想过在这方面进行改进吗。
- 答:分两方面回答:1.PM个人喜欢简洁大方的UI设计这在一定程度上反映到了产品的UI设计上,但美丑仁者见仁智者见智. 2.产品目前处在alpha开发阶段我们会在后期针对UI进行相应改进以期符合主流审美.
问题2:您好，你们的PPT显示的实现功能看起来有点少，你们以前设下的功能还有多少未实现，可以简要说明一下吗，如果已经全部实现，可以说下后续是否会增加附加功能吗?
- 答:在alpha开发阶段我们将开发精力放在了产品核心功能--菜品推荐上,在之后我们的安卓端预计还会添加美食地图的内容,店铺风云榜功能,以及提供用户浏览推荐历史记录的功能,这部分功能的接口已经在alpha阶段的后端设计中做了铺垫,会在beta继续完场上述功能.
问题3:你们软件的商家功能还未实现，可见你们的进度稍慢，后续你们要调整自己队的队员分工和完成时间，来提高进度?
- 答: 在alpha阶段我们的前端将主要精力放在了开发安卓端应用上,但商铺端的页面我们也已经基本设计完成但未在alpha答辩中展示出来:请看我们的商铺端页面
第七组的提问
问题1:是否考虑过提供菜品的相关介绍？
- 答:鉴于并没有现成的福大各个食堂的菜品介绍数据来源,而凭我们目前的力量对每道菜添加菜品介绍也并不现实,所以我们暂时不会考虑添加菜品介绍的功能.
问题2:地图有很多地标，可是并不知道这些具体指示的是哪一家店？
- 答:鉴于目前数据库中并没有足够的用户信息,我们会在beta阶段将地标设置成显示商品信息的按钮,一旦按下地标就会显示出该商家的店铺信息与热门菜肴.
问题3:如果提供多个备选的菜品我还是不知道选哪一个怎么办?
- 答:我们的app只能做到提供就餐建议,最后用户吃什么的最终决定权属于用户
第八组的提问
问题1:推荐算法是否需要用户的用餐数据？
- 答:我们的推荐算法会参考用户的过往选择记录,并根据每个用户的偏好生成用户的口味画像,在推荐时会依据用户口味进行推荐决策
问题2:问答的问题与用户的使用喜好相关吗？
- 答:我们的问题库中目前有40道问题,每次用户需要推荐时我们会从问题库中随机选出三道题供用户选择自己的口味
问题3:有没有开发附加功能以增加用户黏度的计划？
- 答:我们的产品理念是将app做成一款方便的工具,当用户有不知吃什么的选择困难时就会想起我们的app,而在其他时间我们也并不想抢占用户宝贵的时间
第九组的提问
问题1:PPT已经很完整的展示了功能，但是感觉UI界面设计比较简陋，在今后打算怎么改善？
- 答:分两方面回答:1.PM个人喜欢简洁大方的UI设计这在一定程度上反映到了产品的UI设计上,但美丑仁者见仁智者见智. 2.产品目前处在alpha开发阶段我们会在后期针对UI进行相应改进以期符合主流审美.
问题2:PPT已经很完整的展示了功能，但是感觉UI界面设计比较简陋，在今后打算怎么改善？
- 答:同上
问题3:在推荐菜品这方面打算怎么处理？
- 答:我们将继续跟进商家的菜品更新
团队讨论合照
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 5 | 5 |
| · Estimate | · 估计这个任务需要多少时间 | 5 | 5 |
| Development | 开发 | 0 | 0 |
| · Analysis | · 需求分析 (包括学习新技术) | 0 | 0 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 0 | 0 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 240 | 240 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 240 | 240 |
| 合计 | 245 | 245 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 12 | 12 | 单元测试的写法 |
| 2 | 0 | 500 | 12 | 17 | Axure RP 8 原型设计工具 |
| 3 | 300 | 800 | 16 | 33 | C++爬虫、regex正则表达式匹配 |
| 6 | 0 | 800 | 15 | 48 | UML类图的制作 |
| 7 | 0 | 800 | 20 | 68 | 软件需求规格说明书的书写 |
| 11 | 0 | 800 | 5 | 73 | Laravel后端框架安装，腾讯云服务器部署，团队git的使用 |
| 11 | 100 | 900 | 8 | 81 | git分支操作、MVC模型、最基本的http信息传递、基本的Eloquent数据模型写法 |
| 11 | 100 | 1000 | 6 | 87 | git多个远程分支同步操作、json发送与接收、http post方法、curl测试 |
| 11 | 200 | 1200 | 8 | 95 | php后台逻辑、移植数据库、数据接口、前端页面接收post表单返回值 |
| 12 | 300 | 1500 | 16 | 111 | 数据库调错、后端调错、password_hash、timestamp字段 |
| 12 | 200 | 1700 | 5 | 116 | git团队合作 |
| 12 | 100 | 1800 | 5 | 121 | postman测试 |
| 12 | 100 | 1900 | 3 | 124 | 数据库编码 |
| 13 | 0 | 1900 | 3 | 127 | alpha结束，进行事后诸葛亮会议，暂无其他技术上的收获 |