tomvii

公告

日历

解决的问题
- 用户在进店之前无法得知店铺的优劣，通过现有产品获取店铺信息需要手动输入店铺名，繁琐且耗时。而我们的产品可以通过扫描店铺招牌的方式来获取店铺信息，其中扫描的方式分为普通拍照和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. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

事后来看确实是有所低估，导致成果不够美观。

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%

分工

工作流程

个人部分

PSP

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

|       | 	合计  | 800|770

学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	300	300	18	18	原型设计，爬虫关于python的urllib库及request库学习
2	0	300	8	26	钢铁直男们的审美进步“一点点”
3	500	800	12	38	Java爬虫、Tkinter界面
4	300	1100	11	49	tensorflow框架、神经风格迁移
5	200	1300	6	55	tensorflow框架、生成式对抗网络理论基础
6	100	1400	3	58	tensorflow框架、生成式对抗网络实现部分
7	200	1600	4	62	tensorflow框架、算法部分模块优化
8	100	1700	3	65	tensorflow框架、基于时间衰减因子的推荐算法

posted on 2018-12-02 22:25 tomvii 阅读(218) 评论(0) 编辑收藏举报

刷新页面返回顶部

导航

写在前面

设想和目标

计划

资源