Alpha冲刺之过后诸葛亮

• 组长博客
• 做业博客

项目Postmortem

设想和目标

咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

咱们的软件针对的是福大学子来到食堂会犹豫不决没法决定吃什么的痛点，但愿作出一款软件能够根据你们的口味帮忙决定吃什么。其中，用户只须要回答简单的问题就能够获得结果，解决了广泛存在的“选择恐惧症”。软件的定义仍是比较清楚的，这来源于咱们生活中本身也遇到的问题。在编写需求规格说明书时，咱们对典型用户进行了清晰的定义，而且经过问卷调查明确了市场上是存在对于咱们的软件的需求的。

咱们达到目标了么（原计划的功能作到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

原计划的目标大部分都已经完成。在实际的开发过程当中，咱们将一两个功能放到了beta版本实现。

核心功能有在alpha冲刺结束时按时交付。尽管此次冲刺延期了一星期答辩，但大部分功能在一周前也已经基本完成。

咱们的软件分为学生端和商家端，目前完成了学生端的一个发布版本，但尚未公开向用户发布。

和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

上一个阶段团队尚未开始实际开发。若是说团队现场编程做业是上一个阶段的话，咱们团队的软件工程质量的确有提升。主要体如今如下几个方面：

1. 任务分工更加清楚了，每一个人有明确的分工，你们之间的配合也从无到有，到熟练。
2. 有详细的文档编写、代码注释风格要求。
3. 团队成员的技术水平经过学习获得了必定的提高。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

在项目的规划阶段对于一些具体细节的思考度不足。例如讨论时以为都讨论的差很少了，但具体实践时具备难度不得很少占用一些时间。

改进：提升本身的编程能力、以及对于编程语言和框架的熟练度颇有必要。

计划

是否有充足的时间来作计划?

以前有充分的时间来讨论、构想整个软件的框架，以前布置的每一项做业——立项报告、需求规格说明书、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冲刺过程，咱们作得比较好的有：

1. 第四条：“业务人员和开发人员在项目开发过程当中应该天天共同工做”。团队现场编程是常有的事。
2. 第五条：“以有进取心的人为项目核心，充分支持信任他们”。前端组和后端组各有一名组长，分组管理，在他们的带领下每个组都把各自的工做完成的不错。
3. 第六条：“面对面的交流始终是最有效的沟通方式”。例如Alpha站立会议、团队编程、开会讨论等等。
4. 第九条：“不断关注技术和设计，才能愈来愈敏捷”。后端组有本身内部的技术文档和全部接口设计文档，积累了经验。

团队贡献比例

组员	贡献比例
赵畅	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结束，进行过后诸葛亮会议，暂无其余技术上的收获