(Beta)Let's-M2后分析报告
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
在M1阶段我们对用户需求进行了调研，同时M1阶段我们的开发目标就是为了解决用户发起、参与、查看、搜索活动等一系列需求；而M2阶段我们要解决的问题是，用户与用户之间的联系，以及加强各种功能的完整性（如活动管理、活动评分、活动评论等）。对于典型用户与典型场景在之前的博客中已有详细描述，或者也可以参看我们的发布博客。
2. 是否有充足的时间来做计划?
Beta阶段最可惜的地方就是时间不足，由于Beta阶段中后期与考期、编译考核、数据库大作业、数模等诸多任务对撞，导致我们主要的开发精力只能限制在Beta刚开始的冲刺阶段内。这也导致我们部分预定的功能无法正常上线，如推送和IM通讯。两者均有雏形，但由于存在一些bug未解决，因此无法发布上线。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
Beta阶段出现分歧时，主要还是参考这个部分开发人员的意见。希望能把决定权放在最了解问题的人手上，其他人起辅助作用。这点也是和Alpha阶段不同的地方，因为在Alpha阶段有时PM可能不了解前台的一些工作（比如对MD的设计理念不够了解），导致在出现分歧时做的决定不合理（对界面设计的要求不符合MD规则）。因此Beta阶段当出现分歧的时候，其他人出意见，但主要决定权还是在负责此事的开发人员手上。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
未完全完成。未完成的部分有：消息中心、消息推送、IM模块。其中IM模块和消息中心已经有雏形，但还存在一定问题未解决。有关消息这块没做完主要是到后期开发时间太少，而且整体难度比较大，因为没有现成的模块，需要从零开始搭建，开发难度较大。另一方面，还是由于Android Studio的编译效率比较低，导致开发效率较低。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。在Beta阶段我们吸取了Alpha阶段的教训，采取敏捷开发的模式，将用户需求中比较重要的部分放在首位，集中精力开发，因此完成的都是比较重要的功能欠缺。
3. 是否每一项任务都有清楚定义和衡量的交付件?
有。Beta阶段整体任务分为几类：团队博客攥写、后台开发、前端设计。其中对于团队博客攥写这部分，由PM分配任务确定好Deadline后，成员必须将文档在既定时间前存放至坚果云；对于后台开发，每次修改的代码都需要push到远程仓库，并且有对应的comment，除此之外，后台还需要攥写需求文档（即后台功能需要前端设计出什么样的界面，要实现什么功能，需要有什么控件，有什么限制之类的），这些需求文档也要统一放至坚果云下；对于前端设计，我们统一在坚果云中存放了每一个界面的设计稿，由于有修改，各种设计稿也有迭代版本，统一进行管理。
4. 是否项目的整个过程都按照计划进行?
大部分功能都按着计划走。但由于IM模块牵涉到的机制太多，因此IM模块的完成在任务列表上一拖再拖，后来由于时间问题也没办法继续优化。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区。为了预留缓冲区，计划中的发布时间是在12月底，但后来因为期末各种大作业的原因，拖到了一月才发布，但此时缓冲区也发挥了作用。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
若能够继续，在接下来的开发中将会更平均合理地安排任务。在早期开发过程中，由于PM（兼开发人员）接手完成了大部分后台功能，导致其他开发人员没有过多机会接触一些开发流程，对部分知识比较生疏。而在Beta的开发过程中，PM不得不继续完善之前开发过的功能，无法将精力和经验放在更难攻克的IM模块上，这也导致IM的开发效率比较低。因此，任务的均配是一个待修改的方面。
资源
1. 我们有足够的资源来完成各项任务么?
机器的限制还是蛮大的。尤其Google强推Android Studio后，大部分成员的电脑跑这个吞内存的家伙都非常吃力，且编译时间浪费挺多。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
由于经历了Alpha阶段的开发，PM对整体成员的开发能力，各种功能的实现难度都有了更深的了解。因此从经验上能更准确地判断某个任务需要耗费的时间。除了IM模块之外的其它任务估计时间都是比较精确的。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
由于发布较急，没有花太多功夫用于宣传上，因此没有过多的用户测试。大部分还是靠开发人员自己测试，机型也较有限，只能用身边人们的手机和平板。但Beta阶段我们在软件中加入了反馈功能，允许用户提供Bug反馈。我们会通过这些反馈来进一步维护软件。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
这点在IM模块的开发上体现比较明显。由于PM在之前的开发过程中积累了较多的经验，因此能够更快速地定位出问题。然而因为其他原因，最后IM模块的开发并不是PM负责，也从一定程度上拖延了时间。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
每次有更新都会push到远程仓库，并且在坚果云或群组中发布更新的消息，确保所有成员的代码是最新同步的。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
Beta阶段采用敏捷开发的模式，从用户需求量最大的部分出发，并且以“最后可发布的版本”需要哪些功能来界定哪些功能必须实现，哪些是可以推迟的。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
4. 对于可能的变更是否能制定应急计划?
由于计划制定初期预留了缓冲区，因此如果遭遇紧急变更能有时间给团队制定方案，同时任务一般都由两人共同承担，不会存在若有紧急情况先前的任务就无法进行的情况，一人可以调配来处理紧急情况，另一人可以继续原来的工作。
5. 员工是否能够有效地处理意料之外的工作请求？
这些任务通常分配给较为积极的组员，从完成情况来看这些组员能够有效地完成这些意外请求。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
Beta阶段的设计分为对早期界面的改进，以及新界面的设计。早期界面的改进由PM提出修改要求，前端设计人员来完成；对于新界面的设计，需要由后台开发人员提出需求，并攥写需求文档，需求文档中需要包括：该界面的功能，该界面的控件，你预想中界面的雏形以及界面的限制等。需求文档是前后台进行交互的窗口，并且要求需求文档在预计开发时间前2-3天攥写完成，提交给前端人员。前端人员根据需求文档再去完成设计稿。通过实践证明，整体设计的流程，时间和任务分配都是比较合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
吸取了Alpha阶段的经验，在设计工作上统一按照设计稿进行。考虑到PM对设计方面的了解不够，因此不进行过多干预。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
单元测试要求在提交代码前要完成，没有借助其它工具，因为多数模块与安卓机的交互有关，直接在机子上运行测试。
4. 什么功能产生的Bug最多，为什么？
活动的交互部分产生的bug最多，因为此处逻辑比较复杂。在代码实现中甚至嵌套了好几层监听器用于实现此部分功能，多线程加上复杂的逻辑使得这部分的bug比较难处理。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
团队开发中没有专门进行代码复审，代码复审基本上都在各自调他人bug的过程中完成了。。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
我们制定了测试项，从界面显示，交互功能到后台情况都有涉及，并且针对多种机型测试，编写了测试矩阵。
2. 是否进行了正式的验收测试？
发布Beta前进行了最后一轮测试。
3. 团队是否有测试工具来帮助测试？
无。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
利用TFS记录Bug List，利用OSC的代码质量分析工具对代码质量进行检查，加上最后的测试。这些测试从一定程度上减少了许多细节bug，但不足的是机型较少。
5. 在发布的过程中发现了哪些意外问题？
最终的release版本APK在部分机子上无法安装运行，但这些机子的系统已经高于软件要求的最低版本。以及部分机型上显示的错位，空余等。
我们的感想
康家华
本学期的课程默不做声却十分有默契地挤在一起，现在也终于挤在一起结束了。赶在明天的答辩之前，对M2做一个总结。
用一个字来形容M2——“赶”。几乎所有的事情都是赶出来的，我自己的时间完全不能由我自己来安排。每天的任务从早上开始，一直覆盖到晚上甚至明天凌晨。我们在冲刺阶段中有几天是把daily scrum搁置了，因为遇到了编译和数据库两门课程设计的夹击，所以我们不得不暂时放下工程。冲刺阶段结束之后，我们又不得不把工程放下，依旧是因为编译和数据库的关系，就连数学建模也在临近期末的时候插了一脚，导致我们有连着十天左右的没有继续工程。不要问我课程孰轻孰重。
为什么？我们的项目是做一个APP，而且还是安卓的。做APP不像做网页那样，有很多已经很完善的框架，即搜即用。做安卓的APP要考虑系统的版本，设备的适配，如果想要更高级的UI效果，还需要根据版本的限制来做兼容等等。使用Android Studio最新版在Windows 10的操作系统下编译一次时间极限最快1m30s，有时AS抽风给你拖到10m+你还死活关闭不了，和网页对比效率简直天差地别。所以我们的时间就是这样一点一滴眼泪一般从脸上滑走，但是实际上每个人都欲哭无泪。
不过好在我们赶在编译课设催命之前把总体的功能全部实现了，并且完成了发布。在整个M2中，我无数次翻阅Material Design的设计文档，从整体的设计风格，细节到字体的大小和边距，在我的竭尽脑力之下终于把之前的设计全部推翻重改。现在，除了一个界面因为当时设计的关系没有实现MD，总体上我们的APP可以称得上是一个Material Design风格的APP了。不过还有一些动画、页面切换这些UI因为时间不够没有来得及设计，也是挺遗憾的。
M2答辩就在明天，仁者见仁，智者见智，我们的APP实力不容小觑！
仇栋民
在M2阶段，我主要参与了活动评分功能、手机位置与活动地点的距离计算、删除与退出活动等功能的开发。整个M2阶段我在做的工作都直接与用户对于我们这款软件的主要功能相配套的其他需求相关。这一点认识我在开发过程中，逐渐加深，我们的软件设计是为了解决用户的一个或多个主要需求——寻找同好活动或朋友，但是在满足这个需求的同时，作为用户一定会同时产生其它许多附带需求，一个比较好的软件应该对此类需求有一个界限界定，究竟哪些配套需求是需要自己的软件解决的，而哪些又是冗余的。就我们的软件而言，在首页给用户提供按不同方式的活动排序显示，显然能够有助于用户更快更好的发现自己适合参加的活动，这能够很大程度的提升软件的用户体验。
另外在进一步的功能开发中，我还发现软甲的新旧版本兼容也是一个很难处理的问题。因为新功能的开发，会涉及到数据库版本的修订，新旧不同的数据库数据定义在同一份代码的运行中，会带来许多空值、空指针等查询问题。我们在快速开发过程中，为了保证原来的用户能够不重新注册也可以使用我们的新功能，只能采取在代码逻辑中人工判断的方法来解决。
刘彦熙
在阿尔法阶段中，我们团队精诚合作，全力以赴，取得了不错的结果，我个人而言也很有收获，在贝塔阶段中，我们面临的困难更为严峻。
首先，随着学期将尽，越来越多课程需要提交一些大作业，记得最为艰难的一周中，我们先后提交了编译的阶段测试、数学建模课论文、数据库课程设计等作业，在这样的压力之下腾出时间写软工确实是殊为不易。
另外，在阿尔法阶段我们实现的功能都相对基础简单一些，贝塔阶段的工作任务较之之前无论从任务难度以及任务量上都应该说有了极大的提升，并且随着程序规模的提升，每每做出改动可能会对之前的程序产生的影响都要考虑在内。
即便如此，在如此的不利条件下，我们的组员还是排除万难，交出了一份较为满意的答卷。
但是在这个过程中，很遗憾，我个人没能做出什么贡献，在贝塔阶段，我和张启东主要负责IM模块的工作，经过权衡我们选择了使用bmob的即时通讯的SDK，由于提供的案例程序代码量较大，在前期的工作中我两出现了分歧，我想要去摘取碎片式的信息，在需要用到什么功能的时候再从代码中去找相关的实现方式，而他觉得直接将我们需要的所有功能从源程序中找一个闭包出来，添加到我们自己的项目中，然后将一些UI风格进行修改较为方便，因为工作模式不太统一所以前期进展缓慢，我在采用自己的方法执行的时候也遇到了诸多问题，无力解决的情况下无奈也采取了他的工作模式，之后的工作中，我俩通过对案例的分析与调试，一点一点的将问题细化，从推送收发，到实时更新，从消息接收处理到头像显示，一点一点地将问题细化，在这过程中遇到了很多困难，几天时间不间断地对着电脑一点一点调试，虽说自认为付出了努力，但是由于对相关原理的不熟悉，只是通过阅读源码还是有很多问题没办法解决，加之消息中心的实现无暇顾及，而如果没有消息中心，即时通讯的功能也显得很鸡肋，在发布之前我们还是没有来得及将这部分功能妥善完成，所以最终的发布版本中，只能无奈放弃了这部分的功能。
尽管结果不尽人意，但是过程中我还是收获到了很多启示，最重要的一点在于在以后的工作中要做到在理解要完成的功能的实现原理之后再开始工作。理论永远是指导实践的不二法门，认识到这一点才能将工作进行妥善的规划与执行，才能统筹全局，走在正确的前进道路上。
马瑶华
持续几周的BETA阶段结束了，下面来总结一下我的收获以及感想。
首先BETA阶段有别于ALPHA阶段，其中最大的问题就是时间问题。虽然在一开始的设想有许多要改进的地方，然而计划赶不上变化。在期末阶段许多事情赶在了一起，给软件工程所分配的时间也就自然地减少了。因为有编译这门高难度课，时间的安排颇显得捉襟见肘。好在小伙伴们都是熟悉的伙伴，项目也是原来的那个不用重新适应了。
在BETA阶段，我们的主要任务是基于ALPHA版本的软件做进一步的更新和完善。其中我所参与的UI部分要进行一个大的改进。需要将没有风格可言的界面修改为类似于material design的风格。在我研究了material design的官方文档后初步有了一个计划，并且按照PM的要求，接写来用ps做了几个页面的设计图。从设计图来说，总体的效果还是不错的，需要注意的部分包括MD风格，美观性和一致性都有了改进。在设计的过程中我也参考了许多现有APP的样式，我本人的收获也是很大的。
BETA阶段给我的还有一个感受就是，我们的应用是要上架在真实市场的，而非学校里自己小打小闹的产物。一切都要向市场上的成熟应用看齐。如何有竞争力，如何从一个安卓菜鸟一下就向最酷炫最前沿的理念看齐，真的是个不小的挑战。以业内的标准，而非一个学生的课堂作业的标准来衡量作业，这是第一次。
在BETA阶段中，大家需要在一个团队中共同做事，颇像一个开发小组。如何互相沟通、磨合，如何互相衔接，都是需要自己在实践中去学习的。好在组员们非常给力，给了我很大帮助，PM以及其他人非常负责，非常感谢他们，他们身上有许多我需要学习的品质。
张启东
M2阶段主要是对我们做的LETS的升级。我们主要在关注、评论、IM和界面几个方面进行的升级。我们按照功能进行了分工，平均是两个人做一个功能。M2阶段和M1阶段就有了很大地不同。因为M1阶段，几乎是我们一块做的开发，所以工程中每个部分都很熟悉，对整体有较好的了解，而M2阶段，完全是新做一个功能，然后融合到原来的工程里面，这就使我对整体工程的把握变少了。应该说这样更符合软件工程的思想，比如到了大公司，我肯定只是做软件的一部分。另一个不同点就是我们M2阶段是以功能为主导，通过实现一个功能来学习一系列的技术，而M1阶段是以技术为主导的，最初功能为空，每学会一个技术，就把它能实现的功能加进去。这使得M2阶段的难度增长了很多，因为新增一个功能要学习太多的功能，而且由于时间有限，不可能从零开始一点点的做新的功能。这就只能找一个现有的工程，进行抽取和融合。这个过程中出现了很多难以解决的问题首。先是xml类的问题，比如manifest.xml中的activity的说明，layout中的布局，使用的图片等等。这些从一个项目转移到另一个项目时，很多需要更改。下一个问题是Bmob的消息发送机制，它把发送的函数实现写在一个sdk中，我们无法查看，所以并不知道它的实现原理，然后仿照它的消息发送写，就是不成功，这里浪累了很长的时间。而且要是完全使用被引入的项目的数据结构，需要改变数据库的结构。这个我们最初竭力避免的，但是最后通过android studio的反汇编，努力读出了必须是用一个新的类，必须改变数据库的结构。
以上是关于技术方面的感悟。另外还是感觉到一个团队不应该全都是搞技术的人。张炯老师说过，一个团队里如果有人只是负责想法或者管理，一点代码也不写，这也是合理的。从公司的角度看，这确实是正确的，我感觉在公司并不是程序员就是最NB的。但是在我们的课程中，我们无法模拟到公司的环境，还是做得以技术、代码量为重。有点感觉我们所有的队伍都缺少系统的测试、缺少定期进行规划。缺少系统的测试是说，每个队伍都认为可以一边写一边测试，甚至认为测试是浪费开发时间。编译课程的学习让我认识到了测试真的是一门艺术，有的同学的测试就十分完善，测试数据覆盖面很全，测试思路十分清晰，测试结果显示也十分清晰。还有缺少定期规划，大多数队伍都是开始定了计划，本次迭代要开发哪些功能（当然可能也有队伍没有规划，就是有空就写点，写多少算多少）。但是，随着学业压力的增大，大家都先去写哪些最着急的作业了，比如编译、数据库、数学建模，导致软件工程开发时间不够了。这时应该对任务进行重新规划，以期仍然能够按时发布，而大多人都仍然开发着原来计划的任务，导致到截止时间时，项目并不是一个完整的整体，最后是截止时间的一次次的推迟。
总的来说，还是认为这样的软件工程课是很棒的尝试。从这门课中，确实学到了很多知识，收获了很多前大班所没有收获的。技术上学习到了安卓的很多知识，让我比较轻松地通过了本学期的安卓课程；团队合作上，增加了一定的经历，有了很多感受；项目管理上也积累了一定的经验，比如对git、对文档有了更深的认识。
付出越多，收获越多，这门课程很难得，需要珍惜。
Yes! We Are And Always Are Chronos!
