Alpha冲刺 - 事后诸葛亮
Alpha完成情况表
Stardust（安卓端）
| 模块 | 预期计划 | 现实进展 | 完成度 |
|---|---|---|---|
| 登录/注册 | 登录时，从服务器拉取的数据并同步数据库。获取的数据有：用户名、密码、记录集链接。并从七牛云上下载所有记录html文件存到本地数据库。 | 实现了同步个人信息，没有实现同步用户记录 | 50% |
| 验证用户名和密码字段、密码和确认密码匹配后向服务器请求注册，根据返回数据，提醒成功失败，成功后跳转登录页面 | 完成 | 100% | |
| 用户输入用户名及密码，若字符格式或字段长度不符则给予警示；若无误，则将用户输入发送到服务器，根据返回数据，失败则提醒失败，成功则跳转到星空首页 | 完成 | 100% | |
| 主页 | 日期选择器，对应查找显示本地数据库中该日期的记录信息 | 基本完成，但存在越界崩溃的bug | 95% |
| 光点元素随机分布，有一定动画效果；特定的光点后，跳转到对应的流星记录界面 | 完成 | 100% | |
| 文章 | 每天第一次点击“文章”时，从服务器获取文章集链接，当天之后的点击仅从本地缓存读取。解析文章内容并将文本发送给服务器端。 | 基本完成，但不是按照第一次点击更新文章列表，而是24小时刷新 | 98% |
| 根据用户点击的特定文章，获取文章全文内容并展示 | 基本完成，但不能处理来自微信的文章图片无法加载的问题 | 95% | |
| 记录 | 新建记录，支持纯文本、图片、音频输入，保存后将记录存入数据库并上传七牛云 | 没有实现载入音频；图片的显示过大；复制粘贴带有格式的文字会出现bug | 75% |
| 记录分享：将请求发送服务器，然后将标记记录为分享状态，更新本地数据库；记录删除：先上传服务器，然后删除七牛云文件、更新本地数据库。 | 完成 | 100% | |
| 流星 | 每天第一次点击时，从服务器获取流星集链接，从七牛云下载，并将其缓存到本地，当天之后的点击仅从本地缓存读取。解析流星html文件，渲染到页面。根据用户点击的特定流星跳转流星详情页。 | 完成 | 100% |
| 个人信息 | 修改信息：判断用户名/密码字段长度和字符限制（和登录注册同规则），若不符规定则给予提示，若无误，则提交用户更改的信息给服务器（如果是修改头像，需要先将头像上传七牛云，然后将头像资源链接给服务器），成功则显示最新更改，失败则弹窗提示 | 基本完成，但存在清空文字时“保存”按钮仍可点击的bug | 95% |
| 系统工具包 | 过期后更新用户的token | 完成，但是是昨天被用户用GG了刚修好的bug | 100% |
| 广播方式判断无网 | 基本完成，但只是给与简单的toast提示，没有相应措施 | 95% | |
| 动态获取权限 | 完成 | 100% | |
| 当系统访问文件时路径为空时的异常处理，例如：db文件被删除->提示报错，强制登出；例如：记录的html文件被删除->去服务器端获取 | 完成 | 100% |
Gravel（服务器端）
| 模块 | 预期计划 | 现实进展 | 完成度 |
|---|---|---|---|
| 用户 | 根据 body 中的用户名查询用户表，若不重复，将用户名和密码加入数据库，返回200、用户名；若重复，返回409。 | 完成 | 100% |
| 根据 body 中的用户名、密码查询用户表，若匹配成功，更新用户 Token 字段，返回 200、用户 id、用户名、用户 Token、刷新 Token、Token 过期时间；若匹配失败，返回 401。 | 完成 | 100% | |
| 验证用户刷新 Token，返回 200、用户 id、用户 Token、刷新 Token、Token 过期时间；若验证失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，返回用户 id、七牛上传 Token、刷新 Token、Token 过期时间；若验证失败，返回401。 | 完成 | 100% | |
| 进行登录验证，返回 200、用户 id、用户头像 URL；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，将 body 中的 URL 替换数据库，返回 200、用户 id、用户头像 URL；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，将 body 中的 account 在数据库中查重，若不重复，替换数据库，返回 200、用户 id、用户名；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，将 body 中的 old_password 与数据库比对，若比对成功，将 new_password 替换数据库，返回 200、用户 id；若匹配失败，返回 401，若比对失败，返回 403。 | 完成 | 100% | |
| 记录 | 进行登录验证，将记录 URL、点击加号时间、内容存入数据库，返回 200、已存入的记录 id、URL；若匹配失败，返回 401。 | 完成 | 100% |
| 进行登录验证，将路径中记录 id 对应行的 URL、内容、是否分享存入数据库，返回 200、已修改的记录 id、URL、是否分享；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，将路径中的记录 id 对应行标记为已删除，若删除成功，返回 200、已修改的记录 id、URL；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，返回 200、用户所有未删除、未被 block 的记录 id、URL、点击加号时间、是否分享；若匹配失败，返回 401。 | 完成 | 100% | |
| 进行登录验证，返回 200、随机被分享的记录 id、URL、点击加号时间；若匹配失败，返回 401。 | 完成 | 100% | |
| 文章 | 文章来源：KnowYourself，编写可复用的定时爬取脚本，利用 XXX 爬虫爬取 URL 存入数据库 | 完成 | 100% |
| 进行登录验证，若某文章 id 对应行未被填充，将文章 id 对应的 URL、发布时间、作者、标题、内容存入数据库，返回 200、已存入的文章 id、URL；若匹配失败，返回 401；若全被填充，返回 403。 | 完成 | 100% | |
| 进行登录验证，若all_random=1，返回的都是随机文章，默认值为1。查询数据库，取出前 10 条，返回 200、文章 id、文章 URL、是否随机推荐、是否需要抓取；若匹配失败，返回 401。 | 完成随机部分，匹配部分仅有方案而未实现 | 50% | |
| 情绪 | 对记录/爬取的文章内容提取关键词，存入对应数据库 | 完成 | 100% |
| 对解析的记录/爬取的文章内容分析情绪，存入对应数据库 | 已实现，但没有在项目中应用 | 90% |
分工及工作量比例
（markdown不支持合并单元格真的很糟心啊）
| 成员 | 主项 | 子项 | 工作量 |
|---|---|---|---|
| 031502522 刘晨瑶 | 项目进度把控、代码复核和签入、组织会议、撰写博客等 | 14% | |
| 031502541 张昭锡 | 安卓本地数据库建立 | 11.6% | |
| MVP框架搭建 | |||
| 主页 | 日期选择 | ||
| 光点元素 | |||
| 031502517 李永盛 | 服务器框架搭建和测试 | 14.8% | |
| API 设计与测试 | |||
| 用户接口 | 处理登录 | ||
| 处理注册 | |||
| 更新用户 Token | |||
| 获取七牛 Token | |||
| 获取头像 | |||
| 修改头像 | |||
| 修改用户名 | |||
| 修改密码 | |||
| 记录接口 | 记录存储 | ||
| 记录恢复 | |||
| 记录删除 | |||
| 记录修改 | |||
| 获取流星 | |||
| 031502533 熊立强 | 底部栏 | 13.6% | |
| 文章 | 文章列表 | ||
| 文章详情 | |||
| 记录 | 新建记录（+号） | ||
| 记录编辑 | |||
| 记录查看 | |||
| 记录分享 | |||
| 031502113 胡俊钦 | 服务器拉取数据同步到本地的处理 | 12% | |
| 登录/注册页 | 登录 | ||
| 注册 | |||
| 个人信息 | 个人信息查看 | ||
| 个人信息设置 | |||
| 031502328 骆景钊 | 系统工具包 | 登录过期后获取更新token | 10.4% |
| 服务器端返回错误代码的判断 | |||
| 无网异常判断 | |||
| 流星 | 流星列表 | ||
| 流星详情 | |||
| 031502331 苏伟鹏 | 服务器搭建和测试 | 11.4% | |
| API 设计与测试 | |||
| 记录接口 | 关键字提取 | ||
| 文章接口 | 获取文章 | ||
| 更新文章 | |||
| 关键字提取 | |||
| 031502506 陈龙江 | 安卓组代码复审 | 12.2% | |
| 安卓端各模块测试 |
任务量评估主要参考 Alpha 开工前的分工表格（http://www.cnblogs.com/thousfeet/p/7780408.html），并且根据实际情况（花费时间和完成情况）做了一些微调。
团队总结
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
想解决的事情在Alpha阶段就是核心功能写记录、分享记录、阅读文章这几个功能，做到易用、精致。其中，为了解决学生云主机带宽太小的问题，将记录和图片都存储在七牛；并且考虑了.db文件被误删、图像文件被删除等等异常；UI精美是一吸睛亮点。虽然功能看似单一但其实是花了不少功夫。
典型用户和场景在项目开启前已在博客中有相应描述。2.是否有充足的时间来做计划?
时间都是挤出来的，所幸放在了金工实习期间，朝九晚五且没有作业，一有时间都在做项目。然而Beta版本就相当尴尬了，因为下周末还有考试。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段似乎没有太多的分歧。
计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本上整体完成度还是比较高的，唯一没做完的就是文章推荐算法。虽然Alpha阶段的计划本身就是在应用中使用随机推荐，优先去把可用的app先做出来，但要能够做出推荐的解决方案。但其实完成程度只是能提取文章的正负面情绪和一组带权重的关键词并存入数据库，而没有真正去把算法实现出来。其中主要原因是服务器端采用的laravel框架两个后端同学都不熟悉，学习线很长，到最后几天才真正产出代码，并且安卓组的四位同学也是新入门上手开发，难免遇到不少困难和问题，因此作为PM在项目进行中整个重心也都偏向安卓端，甚至没有把“必须把算法做出来”这件事向负责的同学强调清楚，导致他爬完文章库、写完文章模块接口、提取了情绪偏向和关键词就没再继续了（不过也有那段时间他在复习一场考试的原因），最后推荐算法没有真正实现。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
似乎没有。
3.是否每一项任务都有清楚定义和衡量的交付件?
定义是比较清楚了（那张开发表格），把表格中提到的模块和相应细节做完就是完成交付。
4.是否项目的整个过程都按照计划进行?
基本是这样的。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
没有，因为不是真正上班全天开发，既然是课余，自己安排的时间随时都可以是缓冲区，只要每天的按时完成交付就行。并且几乎每个人都并不是只有一个模块是事情要完成，比如立强在完成解析文章的逻辑之后在等小鹏的接口，但小鹏这时候还没交付，立强就先去继续做记录模块的事情了，在立强完成记录之前对于小鹏的进度都是缓冲区。
6.将来的计划会做什么修改？
在Alpha阶段以来感觉开发步调还算比较稳，所以在计划上暂时不做修改。
资源
1.我们有足够的资源来完成各项任务么?
有的。每个人都有电脑并且都预先装好了开发环境；腾讯一元云主机做服务器虽然带宽凄凉了点但好歹能应付；七牛云有免费的10G存储空间来装用户的记录和图片（到现在用了100M），在目前还算够用。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
因为课业原因，所需要的时间很难估计，只能大致的去切节点，精度不高。
3.用户测试的时间，人力和软件/硬件资源是否足够?
目前用户群体较小，还看不出资源匮乏的情况。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
感觉团队的每个人都各司其职不可或缺，要说换别人做更有效率只能是粒度比较小的时候，比如安卓埋点诸葛IO的使用立强已经学过了，就直接让他写了本是小胡负责的模块下的用户反馈功能。
变更管理
1.每个相关的员工都及时知道了变更的消息?
线上交流非常方便。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
共同商讨 + PM最终决定。
3.项目的出口条件（Exit Criteria）是否得到清晰的定义?
在项目之前的博客中有定义，也就是Alpha验收标准。
4.对于可能的变更是否能制定应急计划?
因为不是服务外包，所以不存在说变就变的用户需求。因此基本没有做这方面工作0 0
5.员工是否能够有效地处理意料之外的工作请求？
scrum冲刺的前提似乎本来就是此阶段定下需求后不做改变0 0？因此几乎没有意料之外的工作变更，要有也是比较小的增改需求，比如对光点的动画要求/反馈途径之类，团队成员也能够尽快有效的去处理。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在项目动工前、需求分析阶段就有开始做相应的设计工作。原型设计基本是由我来完成，开发细节的设计是由永盛、昭锡和我初步拟好一起讨论决定的。基本是合适的。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计有具体到比较细节，因此模棱两可的情况比较少，即使出现了是通过商讨解决。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
只有登录注册模块用了单元测试。没有采用测试驱动开发的方式，因为亲身体验过这样做虽然会有好处但同时也会非常非常的耗时。之前有博客贴出过一系列的各种UML设计，但是事实上一堆眼花缭乱的图都不如那个开发表格清晰明了。
4.什么功能产生的Bug最多，为什么？
各模块多多少少都有bug，但没有哪个特别多的。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
安卓端代码复审有专门的龙江同学负责。代码规范在一开始就有定义并且团队花了一个晚上的时间专门约出来一起研读和讨论过。
测试/发布
1.团队是否有一个测试计划？为什么没有？
2.是否进行了正式的验收测试？
3.团队是否有测试工具来帮助测试？有的，见测试报告博客。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有专门的工具，试了试华为开发云的测试，但还不是太能看懂结果报告的用处。
5.在发布的过程中发现了哪些意外问题？
一个是，限定的运行环境是Android 5.0以上，因为现在市场上绝大部分的安卓设备都早已更新到5.0以上了，甚至现在已经不少是Android 7.0以上。在第一批内测的时候有反应安装后无法运行的，最后确认了一下发现那位用户居然是4.0的系统。另一个是，token过期的问题在开始就没有得到很好解决，并且也没有被测试出来，用户安装一周之后发现好多功能都用不了了，才发现是token过期的问题。
PS： 在写这篇博客之前，我又翻了一遍《构建之法》8.6章的计划和估计，然后无意中看到了这个练习题：
有点小疑问的是，以一半的速度完成了一半的计划，那岂不是已经走到了预估时间的终点，又何来的“余下的时间”呢？0 0
完成项目过程中的体会
昭锡：
Alpha阶段其实感觉团队还是蛮融洽的，虽然中间出了一点小打小闹，但那也证明大家有自己的想法，提出自己的意见，想把这个事情做好。而且在这个过程也确实感受到PM的重要性，虽然PM较少参与编码，但在队员情绪调控，整体项目节奏上等节点发挥了独一无二的作用，这也纠正之前一直觉得只要开发人员就能做完这种想法。
再来说说自己吧，其实在软工和这之外的课程之间还是蛮纠结的。由于自己在Android这方面是开荒状态，所以在前期基本放弃了部分课程来学习Android相关。但是，站在Alpha的终点回过头来看，时间是否真的紧迫到需要基本放弃课程听讲的状态，而这样是否有全心地学习Android相关。有句话说“不要用战术上的勤奋掩饰战略上的懒惰”，或许就是这样。当然，多付出的时间也有它的价值，只是达到的效果远远不如自己想的。
另外谈谈在编码中遇到的一些问题，其实都是些小问题，但也就是这些小问题坑坏了自己。根据日期选择数据库相关的记录，其实都是很简单的一条查询语句，但是在编码按照MVP分层时候，在Presenter层显示具体时期不小心进行了自增（Java中月份从0开始），然后将这个数据传到Model层进行数据库查询，一直都无法得到正确的结果，一直以为是逻辑处理错误，调试了很久才找出错误所在。这些都是粗心使然。
永盛：
- 熬夜写项目什么的肥肠习惯了
- 面向 Google 和文档编程
- 每天从东二讨论吧回来的寒风是很冷的
- 整体来说，最匮乏的是预估的能力，缺少一些有效的方法来确认什么时候能写完这部分逻辑、什么时候能学完这些知识、服务器的瓶颈如何估计
- 和队友的合作还是很愉快的
- 一切基于沟通
- 希望接下来加油努力吧
立强：
这次软工实践应该是我第一次体会到 Learning By
Doing，这句话的意义了吧。开始做软工之前，还只对Android有一点点的了解，做完alpha版本之后逐渐掌握，熟练Android基础，接下来的时间打算深入学习Android，熟悉各种框架。团队协作的时候，与上次同学录合作相比，现实中发生了一些小冲突，同学录中更多的是代码中的冲突。Android开发中，在他人模块没有写好的情况下，自测自己写的模块的时候，有一定的困难，需要等待他人模块，针对这一点似乎能用AndroidStudio
自带的测试功能对自己的模块进行测试，这样能够提高的并发度。在编程的过程中也有遇到需要优化的地方，虽然程序能够正常运行，但是卡死在“文章列表”的加载，这一点也是非常的头疼痛，通过学习观看其他模块的代码，很快的就解决了这一问题，所以在团队集体编程，或者私下编程的时候如果有自己的想法，或者不懂的东西，要及时的请教他人，或者上网搜索，才能有效的解决问题。
小胡：
从同学录到软工Alpha阶段结束，经过了半个月的时间，每一天都是忙里偷闲，在上课和其他琐事之余，赶紧趁机偷偷打一波代码。很充实的过了这半个月。还好是在电气实践期间，虽然实践的时间跟上课时间其实差不了太多，但是至少有周末，周末才是真正输出的时候。不过，有一点还是很好的，电气实践不用带脑子。根本不用担心电气实践会睡着或者是听不懂什么的，所以，放心大胆的夜里修仙，没有后顾之忧。这是最开心最没有负担的熬夜。平常如果偷偷熬夜的话其实压力还是很大的，因为这绝对是恶性循环，会给第二天的课程带来不可逆的影响，就这一点来说，电气实践来的真是时候。其实，能有一批人一起熬夜，一起揪头发，一起掉头发还是不错的，当然，能不掉还是不掉的好……
景钊：
alpha阶段的冲刺带给我的是许多不一样的体验。可能你会在室友已经在休息的时候，还在调着自己的bug。可能你会失去很多娱乐的时光，把它花费在工程的编写上。我记忆深刻的是自己在编写工具包和服务器交互的模块的时候，完全不了解什么是交互。找了很多资料，看了许多代码，也询问了同学。那两天是比较慌乱的，怕自己的模块没有完成，影响了大家的进度。幸好有小组的立强大神点拨了我一下，自己在后来的编写上才有了一定的突破和进展。团队的编程远远大于个人的奋战，你遇到的困难可以提出来，大家帮忙解决，有什么建议也可以提出来，这样大大促进了团队的开发效率（其中同学录的小练手的帮助是巨大的）。自己的个人收获上，感觉服务器是个很神奇的东西，Android的第三方依赖包也是很厉害。对Android方面的知识还是充满好奇的。
小鹏：
在项目之前，熟悉PHP语言以及tp框架的使用，在项目中，学会了laravel的使用。团队之间沟通很重要，理解也很重要，在这短短半个月中，处理爬取文章URL，内容解析（这是android端做的，但我在自己用PHP也尝试过，觉得蛮好玩的），然后有用过接口去对文章的情绪分析
关键词提取啊，感觉很有意思！学会了蛮多。教训：不要纠结于什么，实事求是，动手去做，做了才能发现问题，才能去改正。
龙江：
前期因为比赛离线了一段时间，导致跟不上项目的进度，以及花了很长时间去重新看android的相关内容。再来是测试learning，面向百度编程有时候的结果就是一整天都不知道做了什么，心态容易不稳...最后就是感觉teammates都炒鸡棒的啊，作为一条有希望的咸鱼，keep
learning吧！
晨瑶：
有一个疑问，为什么软工实践的学分只有2？既然是按照学时来算的话，我觉得应该给20吧。（逃
前几天课堂展示的时候看到其他好几组的产品真的都很棒，感到了软工神奇的迷之力量，能引燃才几个人的小团队爆发最大的潜力2333
看到有一个团队在Alpha演示的打分中对SWSD的评价是“执行力很强”，实话说被表扬还是很开熏的（这只团队给每个作品的评价都很认真啊，很感谢~）
想起在组队之初，队友之间还略显生疏，于是在开了第一次团队会议之后，我为了记住每个队友的情况，翻看了7个人的博客，然后在OneNote上特地码了一篇笔记，写了点自己对大家的第一印象。
（胡老师那个真不是我的锅，是谁git命令行折腾到两点然后第二天满脑子git的...）事实证明真的每个队友都很棒，能感受到那种认真和努力是一件很令人感动的事情，每次觉得特别累的时候想的都是不能辜负那样努力的队友啊，所以一定要做的更好。
其实在 Alpha 阶段开始之前，团队里就开过五次会，第一二次（9.25）是聊聊天了解情况和确定项目要做什么，发现在那时候讨论的雏形和现在最终的样子还是有相当大的差异的2333
之后开始用 teambition 管理计划团队任务，并且布置了一个所有人都要完成的安卓小练手，做的是一个简易的日记app，然后第三次开会（10.16）进行了初步分工，以及分享对竞品app试用的感受，并且所有人带上电脑演示验收小练手（后来在开发过程中证明这个小练手作业发挥了非常巨大的作用），包括课堂小测同学录也是，作为团队协作的初尝试，团队很是认真的对待这件事，然后整个剧情就是挖坑、跳坑、填坑。要不是在正式开启主项目之前没有那次的同学录团队开发和及时的反思、总结、制定规范和约束，真的难以想象面对 Stardust 这样比同学录大太多的工程，仓库会是怎样的一片丑陋的 commit 和令人崩溃的无数冲突。
第四次（10.21）讨论了很多开发的细节，挖出了很多没有考虑到的坑，也因此愈发觉得有必要挖掘到每一个细节，铺垫了后面那个超级无比详细的表格的诞生。这其中其实也是永盛的坚持，一定要把表格造出来。然后永盛、昭锡和我花了非常多的时间（可能有三天多的时间，但凡有时间就马不停蹄的讨论和写表格）最后才终于写完这个巨大的工程，拿到团队里讨论、确定细节和修改又花了两天，打印出来
A3 纸印了整整 4 张，详尽地说到非常细节的实现上，事实证明也确实给整个Aplha阶段的开发带来了非常大的帮助，每个人都在对这张表格的讨论和确认之后对自己到底要做什么有了基本的眉目。
第五次（10.30）是对拟好的Github规范、Android规范和PHP规范的一起研读和讨论修改，端了两台电脑安卓组坐一边服务器组坐一边，一起一行行读规范。
（算是把teambition的功能用得淋漓尽致了）在整个冲刺的过程中，整个团队的步调还是相对稳重的，从每天的 commit 可以看出进度一直在平稳的推进，开始时候比较慢，以为刚上手并且没做两天就转去做同学录了，然后从同学录完工的后一天开始正式赶工。
然后说说自己的感受吧。作为团队的 PM ，自己其实还是有不少地方需要反思的。
首先最致命的一点就是对服务器端的不了解，之前没有任何相关技能点的沉淀，不管是在进度的追踪还是完成情况的评判上，都常常感到很无力。举个最显见的例子就是一直到 scrum 的第九天，永盛还在看 laravel 文档学框架，得知这种情况我可以说是非常焦虑了，那天晚上在开完 scrum 回去的路上，我就问他为什么每天都是看文档，看了第 n 天文档了，能不能告诉我一个日期，预估一下到底什么时候可以完成哪些的学习。他的回答是不知道，因为也是刚开始接触这个框架，有非常多东西要从头看文档学，而且文档还很难懂。我说，应该不需要每个点都去学吧，需要用什么学什么这样？他说确实是这样学，但是还是很难给个准确的估计，然后解释说这个需要积累的，到了一定的阶段就能厚积薄发飞快的上代码。我表示将信将疑，但是也接受了这个解释。最后果然是最后三四天永盛同学每天几十个几十个 commit 的疯狂修仙写代码，最后到那天 12 小时极限编程的他肝完了全部的接口，到第二天早上8点我开始查进度的时候，永盛发了一份接口文档终板，然后表示要去睡觉了有事再叫他，我...？？？目瞪口呆。虽然一开始有点不太能接受这种“厚积火山喷发”的设定，不过还是给与队友绝对的信任。
第二点就是在安卓端和服务器端的跟踪偏重上，我几乎可以说是 80% 的精力都给了安卓组，在了解服务器端的情况花的时间比较少，不过既然 Alpha 做的是 MVP 也无可厚非，但在 Beta 版本的第一要务就是将文章推荐算法、分享信息垃圾过滤实际应用到项目中，我必须要花大量的时间放在服务器端而非安卓端了。
以及 Alpha 的 scrum 博客没有拿到最高分，反思一下最大的问题是没有贴 commit 记录或学习博客。经常是 commit 虽然还没交，但是在开 scrum 时候就差一点马上做完了，或者是虽然做完了但另一个模块也还正在做，不想马上 pull request，于是当天就没有截图。一边在群里说了下以后尽量当天的代码当天能交 commit ，pull request 的粒度大一点小一点没关系，不过这个锅还是我得背，因为完全可以后面晚一点把截图补上。但是学习博客可能就比较尴尬了orz，作为有理想的程序员（大雾），基本上都表示并不喜欢文档工作，“写代码都来不及还让我写博客” 2333。
在课堂展示时候助教提到的“ master 超前于 dev 分支好几个 commit”的问题，但是团队的规范一直是 dev 分支开发，稳定后才合并 master 的，也就是但凡动到 master 分支的人只可能是我。我后来想了半天是怎么一回事，对照了两边的 commit 才反应过来，是因为我合并的方式是从 dev 发起一个 pull request 到 master，然后再在 Github 上 merge，这样在 master 分支就必然会比 dev 多出 merge 信息。然后一个原因就是偷偷在 master 改动了 README.md ，这个确实是我的锅orz
虽然在整个 Alpha 冲刺中，有困顿有疲惫，但是队友们，包括在一些事情和矛盾的解决上，都给与了我绝对的信任，很感动。附上第一个用户试用时候在看“流星”时候截图过来说“巧遇制作组”的小胡的灵狐之光，可以笑一年：
完美复现了记录模块载图片巨大无比的bug...
最后总结一下 SWSD 在这段时间来的风格，踏实稳重、团结、没有过多不必要的束缚，一切以效率优先、认真对待一切建议和看法。正是因为大家一直以来的认真和努力才能让一个完全从0开始学习、没有大腿自己就是大腿的开发小队短短半个月不到能够产出一个完成度不低的可用产品。
Beta也要继续加油呀~
下阶段展望
登录
- 在token过期前记住登录状态
主页
- 不同光点标记： 颜色小圆环绕？
- 第一次翻到某一日期时，首先同步服务器端的记录数据并存到本地数据库
文章
- 加入收藏文章功能
- 根据用户喜好个性化地推荐文章
记录
- 可选择记录的背景颜色
- 被标记为分享的记录在编辑页标记出“已分享”，并有“取消分享”按钮
- 去除“保存”按钮，改为退出时自动保存
- 加入插入音频功能
-
生成图片导出记录功能
xxxxxxxxxxxxxx
xxxxxxxxxxxxxx
---2017.11.21---- 采用密文保存用户记录
流星
- 加入点赞互动
- 举报功能
- 过滤垃圾分享
用户
- 用户页增加收藏（对应于文章收藏的功能）
- 增加系统通知（对已举报流星审核的反馈）
其他
- 底部栏选中的动画效果改为向上浮起并显示文字
- 增加新手引导
- UI改进（解决明暗色差太大问题）
- 在等待加载时的变灰转圈遮罩，防止等待不耐烦时暴击按钮结果闪退（各个模块都需要）