(Beta)Let's-Beta阶段展示博客

 

康家华：http://www.cnblogs.com/AmazingMax/

马阿姨：http://www.cnblogs.com/oushihuahua/

刘彦熙：http://www.cnblogs.com/xixibaba/

张启东：http://www.cnblogs.com/jirufeng/

林珣玙：http://www.cnblogs.com/kanelim/

仇栋民：http://www.cnblogs.com/nightcool/

 

效果演示

Before——项目选择与前期准备

 

创意来源：

我们的创意来源主要源于我们自己的切身体验，日常生活中，我们理工科学生的交际圈相对较为狭窄，当我们想要结识一些具有相似兴趣爱好的伙伴时，缺乏一个渠道或者平台来满足自己的需求。另外，现代人更多地喜欢线上交流，滋生了诸如低头族，宅文化这样的社会现象，我们希望有一个能够发起线下活动的平台，让人们更多地与身边人进行实际交流。

 

软件定位及用户调研：

 同好活动交流平台

    · 弥补生活中缺少同伴一起参与想去的活动的遗憾、为交际圈小的人提供与兴趣相投的人结伴的途径

    · Let's能够提供他们一个途径或者选择

    · 适用用户是所有人群

    · 主要客户群是的年轻人，比如大学生、年轻白领等。这些人群会有比较强烈的好奇心和活动积极性  

     http://www.sojump.com/jq/5981768.aspx

 

平台与开发环境：Android Studio 1.5

 

坚果云的使用：坚果云可以方便地在本地创建一个团队共享文件夹，我们用坚果云服务管理日常的通知、任务提交、工程资源文件、个人进展汇报等。(我们在Beta阶段仍然贯彻使用了坚果云的管理模式，实现了文档的高效管理)

 

团队的分工： 在阿尔法阶段初期我们先对项目的几个主要模块进行了划分，这样能够对项目的整体规划有一个较为清楚的认识，并且方便进行分工，另外我们还确定了各个模块之间的关联结构，以利于各个成员之间的协作沟通。

（下图为Alpha结束后进行的第一次会议中决定的Beta阶段的开发计划）

 

在贝塔阶段开始的时候，我们结合阿尔法阶段的开发经验，选择将不同的任务以及难度和重要程度赋予优先级别，在每个阶段集中力量去完成优先级别较高的工作项目。

 

APP演示

 

Doing——版本变动与开发历程

 

Git的使用：

两项工程，80+100次提交记录

TFS的使用：由于在阿尔法阶段我们没有正确使用燃尽功能，所以最后的燃尽图效果很不理想，在事后分析的总结中我们一致肯定了TFS对于团队开发效率的提升功效显著，在贝塔阶段的开发过程中始终贯彻着敏捷开发的模式，在开发初期将所有的任务分配项提前分配给每位团队成员，之后坚持每日对开发进度进行实时的更新维护。

每日的daily scrum中都会对当日的燃尽情况进行记录。

DailyScrum ：

此外我们坚持着DailyScrum的开展，为此还特地买了一块白板在宿舍内，将每人的今日任务以百分比的形式展示在板面上，这样既可以更方便地了解到开发的进度情况，还可以起到一定的督促作用。

Daily Scrum 12.20: http://www.cnblogs.com/Chronos/p/5061023.html

Daily Scrum 12.19: http://www.cnblogs.com/Chronos/p/5058527.html

Daily Scrum 12.18: http://www.cnblogs.com/Chronos/p/5056258.html

Daily Scrum 12.17: http://www.cnblogs.com/Chronos/p/5055111.html

Daily Scrum 12.16: http://www.cnblogs.com/Chronos/p/5050441.html

Daily Scrum 12.15: http://www.cnblogs.com/Chronos/p/5047240.html

Daily Scrum 12.14: http://www.cnblogs.com/Chronos/p/5046940.html

Daily Scrum 12.13: http://www.cnblogs.com/Chronos/p/5043890.html

Daily Scrum 12.12: http://www.cnblogs.com/Chronos/p/5041423.html

Daily Scrum 12.11: http://www.cnblogs.com/Chronos/p/5040858.html

Daily Scrum 12.8: http://www.cnblogs.com/Chronos/p/5030912.html

 

项目的整体变动：

三个版本、两次重构：我们的项目先后有三个版本，期间经历了两次彻彻底底的外观重构。第一次重构是必然的，由于所有成员先前都没有安卓开发的经验，我们只能在尝试中摸索，从我们熟悉的Eclipse到完全陌生的Android Studio、从一个个默认的系统控件到经过精心设计实现的UI元素，但因为全体组员的尽职尽责，我们第一次的转型十分成功，不仅在UI上给人眼前一亮的感觉，在功能上也实现了既定关于活动的各种基本操作。

第二次的重构是我们精益求精的偏执，我们希望Lets的设计能够更遵从原汁原味的Material Design风格，同时我们更希望它的功能能够提供一个完整的用户体验，于是第二次的重构我们不仅在UI上下足了工夫，更是在整个开发模式，对软件功能的定义取舍做了全新的改变。

 

前后端交互的管理：

在阿尔法阶段协调上存在一些问题所以贝塔阶段之初就决定采取这样的工作模式。我们要求：任何一个后台功能在进行开发前需要提前2-3天提交需求文档，该需求文档的内容包括以下四个方面：需求功能的整体介绍、页面需要使用的控件类型、开发者预想中的页面雏形、对功能的一些限制和补充说明。提交完需求文档后，前端设计和实现人员需要根据实现难度和后台人员进行协商，在最终确定一个双方都同意的可行方案后，即可开始设计实现。2-3天内，设计人员能够将基本的xml框架，设计思路理清。后端人员同时可以利用这段时间进行基础功能的开发，这时的开发可以不注重任何界面效果，它甚至可以只是一堆默认控件的堆叠，但它必须要和需求文档一致。这样在得到设计人员的设计后，即可一同开始设计界面的实现，此时的后台功能应已完成。“需求文档”就像一把同步锁，引入了它之后，我们的前后端协调交互变得有条不紊，工作效率也大大提升。

 

设计需求文档的展示：

 

前端的概念设计图以及手稿：

 

敏捷开发模式与出口条件：

在Beta的开发过程中，我们吸取上次的教训，始终保持敏捷开发的模式。对于不必要，性价比不高的功能，我们给予其较低的开发优先级。始终将主力用于必要功能的实现。那么什么样的功能才是必要不多余的呢？首先必须从用户的角度出发，按照测试场景代入，如果我们是用户，我们希望它能有什么样的功能来满足我的需求？另一方面，我们需要考虑到有限的时间和庞大的工作量，因此，通过出口条件也可以协助我们确定什么样的功能是必要的。

如果说在阿尔法阶段我们以“木桶效应”来拟喻应用的出口条件，在这一阶段，“齐头并进”才是我们所想要达到的效果。因此，任何会造成用户功能完整性不一致的地方，都是我们开发的重点。

 

具体的某些功能实现过程中遇到了哪些困难：

IM通讯的发送与接收（广播机制、多线程操作、UI的实时更新等）

活动管理和关注功能（关联多个数据表，操作逻辑复杂）

整体界面Material Design化（各种细节的追求，小到边距、字体，达到控件的风格，页面配色等）

 

After——发布情况与总结反思

 

发布到了哪些平台:

 

腾讯应用宝：http://op.open.qq.com/index.php?mod=appinfo&act=main&appid=1104889725#mobile|center

百度手机助手：http://shouji.baidu.com/software/item?docid=8103349&from=as

安卓市场：http://apk.hiapk.com/appinfo/com.example.lets/1

91应用市场：http://apk.91.com/Soft/Android/com.example.lets-1-1.0.html

预期下载量：200次

收集用户反馈的方式：我们一直十分注重用户的反馈，为此专门在应用中一个显眼的位置添加了获取用户反馈的渠道：

下面就是在近期我们收到的一些用户反馈

Bug修复：

下拉崩溃
不能更改个人头像（已修复）
不显示头像
百度地图（已修复）

活动信息修改加载图片（已修复）
在某些机型上软件装不上
图片加载有时不加载，有时会有残缺。
未知错误，偶尔点击活动会崩。
连击两次活动卡片会打开两次该活动的界面。

参与活动过程中后台数据记录的Bug(已修复)

 

测试：

Beta阶段我们将测试矩阵细化，并增添了对多种新功能的测试。

参考测试博客：http://www.cnblogs.com/Chronos/p/5093717.html

 

反思感想：

仇老板                                 

整个M2阶段我在做的工作都直接与用户对于我们这款软件的主要功能相配套的其他需求相关。这一点认识我在开发过程中，逐渐加深，我们的软件设计是为了解决用户的一个或多个主要需求——寻找同好活动或朋友，但是在满足这个需求的同时，作为用户一定会同时产生其它许多附带需求，一个比较好的软件应该对此类需求有一个界限界定，究竟哪些配套需求是需要自己的软件解决的，而哪些又是冗余的。就我们的软件而言，在首页给用户提供按不同方式的活动排序显示，显然能够有助于用户更快更好的发现自己适合参加的活动，这能够很大程度的提升软件的用户体验。

康家华                                                

在整个M2中，我无数次翻阅Material Design的设计文档，从整体的设计风格，细节到字体的大小和边距，在我的竭尽脑力之下终于把之前的设计全部推翻重改。现在，除了一个界面因为当时设计的关系没有实现MD，总体上我们的APP可以称得上是一个Material Design风格的APP了。不过还有一些动画、页面切换这些UI因为时间不够没有来得及设计，也是挺遗憾的。

刘彦熙                                                                    

在M2阶段我收获到了很多启示，最重要的一点在于在以后的工作中要做到在理解要完成的功能的实现原理之后再开始工作。理论永远是指导实践的不二法门，认识到这一点才能将工作进行妥善的规划与执行，才能统筹全局，走在正确的前进道路上。

马瑶华                                                                                                

BETA阶段给我的还有一个感受就是，我们的应用是要上架在真实市场的，而非学校里自己小打小闹的产物。一切都要向市场上的成熟应用看齐。如何有竞争力，如何从一个安卓菜鸟一下就向最酷炫最前沿的理念看齐，真的是个不小的挑战。以业内的标准，而非一个学生的课堂作业的标准来衡量作业，这是第一次。

在BETA阶段中，大家需要在一个团队中共同做事，颇像一个开发小组。如何互相沟通、磨合，如何互相衔接，都是需要自己在实践中去学习的。好在组员们非常给力，给了我很大帮助，PM以及其他人非常负责，非常感谢他们，他们身上有许多我需要学习的品质。

张启东                                                                                                                               

总的来说，还是认为这样的软件工程课是很棒的尝试。从这门课中，确实学到了很多知识，收获了很多前大班所没有收获的。技术上学习到了安卓的很多知识，让我比较轻松地通过了本学期的安卓课程；团队合作上，增加了一定的经历，有了很多感受；项目管理上也积累了一定的经验，比如对git、对文档有了更深的认识。

付出越多，收获越多，这门课程很难得，需要珍惜。

 

总结：                                                                                                                                                            

一个学期的开发过程中，我们经历过技术上的迷茫，经历过设计上的偏执，经历过组内成员的分歧与争吵。但我很开心，无论如何，我们的组员在小组需要他们的时候从来没有说过不，包括今天展示时，我们仍是全体出勤，我能够站在这里自豪地向大家展示我们的APP，这都是我们共同团结努力的成果。

无论是Alpha阶段没日没夜地赶工，还是Beta阶段纵然在编译、数据库、数模和考期等多重因素的施压下，我们仍然没有停止开发的步伐。我相信其他组的成员也有目共睹，我们的付出从git的提交记录也可见一斑。

最后，陪伴了我们半个学期的白板，之上的任务也终于都清空了。

 

 

                                                        THE END