Alpha 过后诸葛亮

写在前面

• 林燊大哥
• 一路走来，好不容易，终于完结了。

设想和目标

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

• 解决的问题
  • 用户在进店以前没法得知店铺的优劣，经过现有产品获取店铺信息须要手动输入店铺名，繁琐且耗时。而咱们的产品能够经过扫描店铺招牌的方式来获取店铺信息，其中扫描的方式分为普通拍照和AR两种，步骤简单且高效。
• 定义是否清楚
  • 通过咱们前期的需求分析、问卷调查、组内决策等一系列审核后最终定义下的软件，咱们认为这也是兼具完备定义以及强健性的一款软件。
  • 在咱们看来，定义得十分清楚，若是有疑问的小伙伴欢迎你们来交流~
• 典型用户
  • 常常在城市广场（例如永嘉天地、万达广场等）消费的顾客
  • 初来乍到福州，想去周边城市广场了解、餐馆的顾客
• 典型场景
  • 设想这样一个场景：当你在广场上，面对一排又一排的店铺，而你想知道某家店的评价等信息时，现有软件的工做流程为：

而若是使用咱们的产品则变为：

其中效率的提升是显而易见的。

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

• 原计划功能实现状况
  • 基本上实现，除了没能将服务器搭在云平台上。
  • 前端实现简介、可用性强的界面
  • 后端算法彻底实现，但鉴于“强迫症”，咱们仍然会在后续作出改进。
  • 数据部分数量过少，没有达到预期目标，仅收录27家商铺。
• 是否按原计划交付时间交付
  • 是的，在答辩当天咱们展现了咱们的成果，尽管咱们熬了夜才完成。
• 原计划预期的用户数量是否达到
  • 原计划没有预期可以有用户使用，只是在咱们团队内部进行测试。

3. 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么?咱们离目标更近了么?

• 用户量和预想的一致。
• 用户对重要功能的接受程度仍是超出预期的，当把扫描招牌识别店铺名的功能作出来的时候，团队成员都感到很神奇。

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

• 遇到的困难真的是不可胜数，甚至单独写一篇博客都不为过。下面从技术方面的问题和非技术方面的问题中各说几个吧。
• 技术方面：
  • 在训练CRNN模型的时候，在数据集分配上不是很合理，致使模型效果不佳。若是在数据集充足的状况下，将全部数据集按照8:1:1进行分割，分别分配给训练集、开发集和测试集。若是数据量小的话，按9:1分配给训练集和测试集。这样就可以提高模型效果。
  • 开发过程当中常常遇到服务器链接不成功的问题，一开始认为Okhttp有帮咱们自动开子进程，后来才发现十分不稳定。咱们发现仍是本身手动设置一个子进程来的更加的稳定。
  • 不要低估了任何一个项目的开发难度和工做量，开发人员的人数最好要比一开始预期的要多，不然一旦发现工做量太大，这时候想再加入新人来开发，会更加耗时。一样开发人员多，能够有更多的时间和精力来把项目作得更好。否则就会像咱们一个，几个开发只能肝肝肝！
  • 前端界面不精美，这个问题咱们也很绝望啊，因此说团队必定要有一个女生，九个男生的审美，咱们真的尽力了！
  • 算法部分在考虑摩尔纹的前提下很难有较好的识别结果。
• 非技术方面：
  • 低估了前端开发的难度，分配的人手不足。可是由于你们都是新手，当咱们意识到这个问题的时候，已经来不及从新分配人手去学习了。
  • 一开始过于草率的选择开发基于安卓系统的应用，后来才意识到或许采用微信小程序开发能够更省时并且效果更好。
  • 在冲刺阶段和两门考试以及其余实践课程的做业deadline冲突严重，组内成员时间严重不足。并且部分红员还须要兼顾学院的学生工做，时间更加不足。至少在咱们看来，这是个无解的问题...
  • ...

计划

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

• 咱们很早就开始了计划，时间上是很充足的，可是咱们没有足够重视这个环节，并无投入过多的时间在这个方面，这也是算是个教训。

2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？

• 咱们团队在解决成员之间的分歧的时候仍是比较愉快的，基本上你们都会很直白的表达本身的意见，而后你们讨论，在讨论中解决问题。

3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?

• 俞辛
  • 我原计划的工做是写博客以及文档。没有都作完。有两篇博客是有钧昊同窗帮我完成的，没作完是由于我因为实验室的事情去了南京两天，没有办法完成博客。
• 柏涛
  • 我原计划的工做是使用QQ登陆和数据的上下传。使用QQ登陆和数据的下载部分完成，数据的上传遇到了一些bug，还没有解决。没有java和安卓开发基础，在开发学习过程当中会遇到许多不可预知的困难，不知道该怎么解决。
• 宇航
  • 我原计划的工做是制做相机AR模块，协助界面制做。相机模块已制做完毕，AR模块未完成，部分界面制做完毕（主体导航栏，活动中心）协助制做了登陆用户等界面。
• 燊
  • 我原计划的工做是完成算法的并行化设计和完成推荐算法，推荐算法完成，并行化设计由于服务器硬件缘由没有完成。
• 宏岩
  • 我原计划的工做是拍摄数据集并对拍摄的店铺照片进行标注、爬取永嘉天地店铺的简介和评论信息，把爬取的信息导入数据库并与后端链接。数据集拍摄和信息爬取的任务已经完成，数据库链接方面还有一些问题，最后只能经过txt文件的方式解决。未能实现的缘由之一是本身对时间的分配不当，中间还去南京参会，致使没有时间去了解数据库的远程访问问题。缘由之二是未能和开发组达成共识，共同讨论数据的要求，致使后面仓促的开发。
• 喜源
  • 我原计划的工做是前端、上传照片至服务器和短信登陆。有作完，可是身为开发组的组长，整组总体的实现没有完成的很好，我有着不可推卸的责任。
• 志豪
  • 我原计划的工做是制做一个好看耐看秒天秒地的前端。没有作完。最后实现的前端只能说勉强能看，不能让你们满意。缘由：审美不行，时间不足，不够用心。
• 恺翔
  • 我原计划的工做是训练可识别商店名的CRNN模型。有作完，目前对现有数据集训练模型，正确率达到98%。
• 钧昊
  • 我原计划的工做是完成商铺招牌检测，基于YOLO算法的实现以及算法服务器端的架设与接口，有作完。目前对现有数据集训练，设定IOU>0.5为正确标准的状况下正确率可达到90%，但因为对于大目标如商铺招牌的容错性较高，因此实际效果更优。

4. 有没有发现你作了一些过后看来不必或没多大价值的事?

• 存在有部分事情没有太大意义，但难保在Beta冲刺上
• 好比云服务器上的搭建，咱们在测试算法的过程当中就发现了单核CPU的运行效果不佳的问题了，但还是抱着试试看的心态来尝试继续搭建，最终效果也不尽如人意。
• 可是咱们计划在Beta版本将服务器仅做为咱们一个云端数据库，这样也能使咱们事先配置好的低廉云服务器也能发挥出自身的做用。

5. 是否每一项任务都有清楚定义和衡量的交付件?

• 每一项任务都有很清楚的定义，但未必都有清楚的衡量标准，由于例如前端美感这一类随开发人员审美变化大的任务没办法定下标准。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

• 并无整个过程都按计划进行。云服务器没能投入使用，由于咱们购买的服务器性能不足以运行咱们的程序，而性能的好的服务器买不起。**（柯老板要不要考虑一下天使投资？）

7. 在计划中有没有留下缓冲区，缓冲区有做用么?

• 没有，由于计划时不了解缓冲区的概念。

8. 未来的计划会作什么修改？（例如：缓冲区的定义，加班）

• 未来会将任务集中在一段时间完成，而不是平摊到整个任务周期。

9. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 学到了长痛不如短痛，一次性完成任务是最好的。

资源

1. 咱们有足够的资源来完成各项任务么?

• 除了购买服务器所需的资金外，其余资源十分充足。不管是技术方面的人才仍是文档方面的人才，多如牛毛。

2. 各项任务所需的时间和其余资源是如何估计的，精度如何?

• 各项任务所需的时间和其余资源的估计是基于团队成语过往经验以及询问前辈所得，十分粗糙。
• 精度方面，咱们没有确切估计，可是相比于咱们咨询的过往前辈，咱们在本项目上的耗时相对更多一些，可是质量方面却无从考究。

3. 测试的时间，人力和软件/硬件资源是否足够?

• 测试的时间，人力是够的，由于开发的速度并不会太快。硬件也是足够的，组内有须要的测试设备（一台安卓机）。软件的话则不太够，由于没有测试的经验，纯手工测试。

4. 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?

• 过后来看确实是有所低估，致使成果不够美观。
• 美工方面的确是一个须要咱们花时间去作的问题，咱们在Beta阶段也会付诸努力来完成但不只仅限于美工这件事。

5. 你有没有感到你作的事情可让别人来作（更有效率）?

• 组内来看的话，每一个人都在本身最合适的位置上，可是若考虑到效率这一方面的话，确定多少回存在有差别性。
• 适合的位置并不表明完成地相对更有效率，因此多少会有一点。

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

• 开发组的同窗任务量过大，即便有的人不擅长开发，为了任务的推动也应该转去开发。

变动管理

1. 每一个相关的员工都及时知道了变动的消息?

• 在咱们的分组内的成员都知道了变动的消息。例如开发组有本身的群，随时在群内交流。

2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?

• 通常是PM根据实际状况决定。

3. 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?

• 咱们计划要完成的功能就是咱们的出口条件。

4. 对于可能的变动是否能制定应急计划?

• 能，文档组的同窗在本次任务过程当中就承担了 “救火队员” 的任务。

5. 员工是否可以有效地处理意料以外的工做请求？

• 若是与当前的任务不冲突的前提下，可以很好的解决。

6. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 计划赶不上变化，不管如何都会出现意外状况（好比现场编程任务难度大，影响了alpha版本开发的进度）。在计划的时候要设置缓冲区以应对未知的变动。

设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

• 设计在分工结束后就由各小组组长完成，目前看来时间是合适的，人选则未必是最合适的。

2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

• 有，比方说不肯定这个任务能不能按这样的设计实现，解决方式询问有经验的前辈。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？

• 测试是在安卓开发神器Android Studio里面进行的，开发组成员表示仍是很好用的。

4. 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 状态仍是有很大区别的，缘由是项目开始时的文档是基于咱们的空想完成的，实际开发过程当中不断地在调整。固然须要更新（事实上咱们也确实在作这件事）。

5. 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况？

• 服务器的算法Bug最多，由于测试的图片有多种多样的复杂状况（例如柯老板课上说的被树挡住了招牌的大部分文字）。开发的时候就考虑到了，可是这个是要经过大量的训练才能解决，开发过程当中只能尽力而为。

6. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 时间紧任务重，未能进行代码复审，也未能严格执行代码规范。

7. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 代码复审应该随时进行，而不是等项目完结后再进行。代码规范亦是如此。

测试/发布

1. 团队是否有一个测试计划？为何没有？

• 只有一个十分粗糙的计划，就是每完成一个功能以后就进行测试。

2. 是否进行了正式的验收测试？

• 因为经验不足，未能进行验收测试。

3. 团队是否有测试工具来帮助测试？

• 开发组采用Android studio进行测试。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？

• 暂无这部分的工做。

5. 在发布的过程当中发现了哪些意外问题？

• 软件暂未发布。

6. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 分配足够的人手进行测试，同时测试计划应该紧随开发计划以后指定，并随实际开发进度调整。

团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？

• 角色主要是成员自荐，基本上自荐以后就完成了分工。目前看来基本上达到了人尽其才。

2. 团队成员之间有互相帮助么？

• 这个是百分之百有的，我相信任何一个组都有，由于每一个人都会遇到困难，这不可避免，所以就须要进行团队互助。

3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？

• 不论什么类型的问题，咱们团队的解决方法第一步都是团队讨论，而后进行集思广益解决问题。

每一个成员明确公开地表示对成员帮助的感谢：

• 我感谢朱志豪同窗，在我写代码写类的时候，他会请我喝奶茶

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 咱们学到了沟通是解决问题的惟一途径。在这个方面，我认为咱们团队是作得比较好的，改进的部分暂时未发现。

---

总结

1. 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?

• 处于初始级。咱们的开发过程基本符合下面的定义。尤为是 “成功依靠的是我的的才能和经验” 而不是成熟的软件工程管理制度。

软件工程管理制度缺少，过程缺少定义、混乱无序。成功依靠的是我的的才能和经验，常常因为缺少管理和计划致使时间、费用超支。管理方式属于反应式，主要用来应付危机。过程不可预测，难以重复。

2. 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?

• 处于磨合的阶段，正向规范的阶段迈进。由于在alpha中，咱们没有一个规范的制度或者说相关开发文档，在接下来的开发中，咱们会注意改进。

3. 你以为团队在这个里程碑相比前一个里程碑有什么改进?

• 在团队的分工以及协做能力上大大提高。

4. 你以为目前最须要改进的一个方面是什么?

• 一个规范的软件开发制度。
  对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。
• 主张简单
  • 一开始咱们计划主界面作的十分复杂，有许多入口，相似下图
    
    而基于主张简单的原则，咱们的主界面十分简洁，突出了咱们的主要特点功能。

• 软件是你的主要目标
  • 开发过程当中，不是必定要写的文档（指没写这个文档软件就没法开发）的文档咱们都没有写。
• 拥抱变化
  • 咱们时刻有计划外的人手（文档组、测试组、数据组）能够应对开发过程当中出现的变化

现场讨论图片：

Q&A

第一组

• 以目前的服务器配置,在高并发场景下,是否依然能保证服务器的相应效率?
• 答：目前测试用的服务器配置只有单核的CPU、2G内存、并且没有GPU加速，即便是跑算法都显得有些吃力；若是考虑高并发的状况下，如果有较优的服务器配置，配合上相似thriff框架，是能够在必定程度上保证高并发场景下的效率的。
• 在演讲中说到,为了小范围场景下的准确率使得算法倾向过拟合,这是否会影响产品后期的扩展?
• 答：过拟合只是为了在现有数据集前提下达到更优的效果，按期扩展产品的同时，咱们也须要按期更新咱们的模型，对于较倾向于算法的软件这样作也是不免的。
• 是否考虑过用本身的电脑进行内网穿透来运行相应算法以此弥补低价服务器的性能瓶颈?
• 答：目前服务器已经搭建在本身的电脑上了，课上仅仅是吐槽了一下！

第二组

• 社区功能是用来干什么的？
• 答：很差意思，本次alpha冲刺时间有限没有来得及完成；计划于Beta阶段完成，主要是用于多用户间沟通分享的一个平台。
• 是否能收录相关店铺的菜单，方便用户进行评价及分享？
• 答：固然，店铺相对应的信息，咱们也是都会收录的，这也是一项十分耗时的工程。
• 推荐店铺功能是基于什么样的算法？
• 答：目前是计划采用相似基于时间衰减因子的推荐算法，基于用户历史记录来提升推荐的置信度，但后续可能会略有修改！

第三组

• 单核服务器问题的解决？
• 答：目前服务器已经搭建在本身的电脑上了，这也能弥补低价服务器的性能瓶颈。
• 美工界面方面如何改善？
• 答：计划经过屡次组内沟通来进行修改了，咱们也会在Beta阶段投入更多的人力资源来完成UI以及前端开发上。
• 店铺种类问题,多样性如何解决？
• 答：题目中的“多样性”能否理解为多类商铺？关于多样性店铺识别的话，主要是基于目标检测+文字识别模块来完成的。

第五组

• 美工界面问题怎么解决？
• 答：计划经过屡次组内沟通来进行修改了，咱们也会在Beta阶段投入更多的人力资源来完成UI以及前端开发上。
• 算法方面很详细，感受真的没什么能够说的，就是有点复杂看的人不太懂。
• 答：这一点，咱们会在后续的PPT制做上改进的，咱们仅是为了展现一下alppha开发的部分流程。
• 识别问题，虽然大家的识别功能已经很是好了，可是还能够继续增强。
• 答：感谢贵组的鼓励。

第六组

• 算法确实强大，但用户界面才是用户对产品的第一印象，因此若是没有挖到人才，怎么解决用户界面的美化？
• 答：挖人这一说辞仅是开开玩笑，咱们很相信咱们的美工——志豪同窗！咱们也会经过后续的软件迭代来解决美化问题的。
• 团队主要宣传算法，那团队贡献度计算是否偏重算法？
• 答：咱们更主张按劳分配，算法只是咱们但愿展现的一个亮点。
• 推荐算法的依据，好比收藏、点赞之类的数据来源？
• 答：“爬虫”获取以及部分实体拍摄的数据。

第七组

• 能不能提个建议：下次展现，能不能别抛出那么多具体的实现算法？咱们认为用户不会想知道大家是用什么算法实现的，甚至用户也不懂，用户只在意大家实现的结果是什么样的。
• 答：这一点，咱们会在后续的PPT制做上改进的，咱们仅是为了展现一下alppha开发的部分流程，感谢您的建议。
• 识别出来的店铺信息包含什么？只有店铺名称和店铺简介？推荐部分会有什么内容？
• 答：包含有店铺名称、简介、用户评论信息等，基本上是法律容许范围内，尽量多的获取商铺信息，并选取返回给用户。推荐部分则是包含基于用户历史的一个推荐商铺。
• 服务器问题和流上传消耗过多流量问题怎么解决
• 答：目前已经将服务器搭建在本地容许，损耗流量问题，咱们会设定定时、定帧的方式来解决。

第八组

• AR识别做为特点功能是否有足够的吸引力？
• 答：我的认为AR是一个很是博人眼球的一个功能，也能吸引大量感兴趣的用户。
• 有没有考虑增长提升用户对产品需求度的功能
• 答：后续功能的话，会在Beta阶段由组内从新商讨后来决定，尽请期待。
• 组内对alpha版本的分工如何评价？下阶段,有没有要改进的地方？
• 答：咱们是以组内再分组的形式来完成分工的，你们也都一致认为这是很好的一种分工形式，每个小组也都有组长管理，最后汇总给PM。

第九组

• PPT已经很完整的展现了功能，可是感受UI界面设计比较简陋，在从此打算怎么改善？
• 答：UI界面的美工问题，咱们后续会由咱们组的美工担当——志豪同窗来监督、改善。
• 算法和UI界面设计的差距有点大，该如何改进
• 答：咱们认为算法和UI界面上的差距问题也很难知足每一个用户的需求，咱们团队也一致认为这样的衔接方案是十分简洁的。
• 今天只展现了部分核心功能，请问在从此还有那些必要的功能可扩展
• 答：从此还会考虑推荐商铺功能、社区功能的实现。

得分

第一组	第二组	第三组	第四组	第五组	第六组	第七组	第八组	第九组	平均分
67	77	73	83	70	70	75	84	66	73.57

贡献度及分工

贡献度

名	贡献度	工做量比例
燊	10%	10%
钧昊	14%	14%
俞辛	11%	11%
宏岩	10%	10%
喜源	12%	12%
柏涛	13%	13%
宇航	12%	12%
恺翔	10%	10%
志豪	8%	8%

分工

工做流程

我的部分

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	60	60
· Estimate	· 估计这个任务须要多少时间	20	20
Development	开发	300	200
· Analysis	· 需求分析 (包括学习新技术)	100	400
· Design Spec	· 生成设计文档	10	10
· Design Review	· 设计复审	60	90
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	15	20
· Design	· 具体设计	60	80
· Coding	· 具体编码	20	20
· Code Review	· 代码复审	20	20
· Test	· 测试（自我测试，修改代码，提交修改）	120	300
Reporting	报告	30	30
· Test Repor	· 测试报告	10	20
· Size Measurement	· 计算工做量	5	10
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	30	30
合计		860	1330

• 我的学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	300	300	15	15	熟悉了C++语言，了解了单元测试，代码覆盖率和性能分析
2	0	300	8	23
3	300	600	14	37	爬虫，代码能力更上一步
4	0	600	4	41	简单的uml设计
5	0	600	11	52	使用墨刀进行app原型设计
6	150	750	12	64	使用android studio写前端
7	900	1650	21	85	使用android studio设计前端和短信登陆初学服务器
8	800	2450	18	103	服务器接收和客户端发送，okhttp框架学习