第六次团队作业——Alpha冲刺之事后诸葛亮
目录：
##一、设想和目标1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的问题是学院、社团在发布活动通知和进行签到统计时过程繁琐的问题。定义得也比较清楚，包括具体的通知活动的发布、学生参与活动的报名、统计和签到。在需求说明书中有对通知发布者、活动发布者、活动参与者的典型场景进行描述。
2.是否有充足的时间来做计划?
有充足的时间，但时间利用得并不充分。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过小组一起协商讨论来解决意见冲突。
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
Alpha版本的用户目前只有我们小组的成员，基本功能还是如期实现了，但是一些额外的功能尚未实现。
当然离目标更近了！
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
最开始的时候，我们预期的alpha版本的功能更复杂，但是随着项目进行，砍掉了很多与核心功能没关系的“花瓶”功能，专心写主要的功能。。。重来一边的话，我们将一开始就抓住重点，进行开发。
二、计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
并没有完成，还有一个“发布者”的签到功能，尚未实现。
因为前端一直在美化其他界面，没来得及做这个界面，所以后端功能实现了也没法添加进去。项目进行到最后乱了阵脚。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
黄志明（PM）：在大家尚未会使用github的时候上传了源项目文件。后来使用 git的时候，已经换掉了仓库。
李严（V）： 去找了droiddraw软件来做控件布局，本来想是一个方便使用的工具，然而= =还不如直接在Android studio上敲代码来的效率高
格格（V）： 纠结于按钮大小，背景图等一些元素！
橙汁（V）：调试虚拟机，太费时间，直接真机
志兴（M）:一开始对一些云服务提供方给的函数进行了封装，但也许是因为基础上的不足或理解错误，写出的代码有问题，在测试时有一些不明的bug，后来照官方文档直接调用函数就正常了。
牛姐（V）：就是对界面的调整吧，感觉栋哥对我们的界面的设计很无语的感觉。
佳恺（M）：我认为在项目中我因为纠结于封装与数据库数据交互的查询方法而浪费了大量的时间
3.是否每一项任务都有清楚定义和衡量的交付件?
嗯。。。定义还是比较模糊的。主要是界面中，该有的都有，功能中，能使用的都能用。就可以了，具体到什么样的界面叫“好看”没有详细定义、什么样的功能算“完整”，也没有定义。
4.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并没有。最开始的分配发布者界面的橙汁，去参加ICPC，所以发布者的界面拖到了后面才勉强完成。然后就是突如其来的两场期末考，大家得找时间复习。。。复习之余还得写代码（毫无经验），还是比较痛苦的。
因为估计这种东西是很玄乎的，把任务布置下去，大家之前都没做过相关的工作，说自己一两天能完成，完全是扯淡。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
没留什么缓冲区，因为计划赶不上变化。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来将设置时间点，定时定点检查假面以及功能。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍，一定严格按照计划，不要拖拖拉拉！
三、资源
1.我们有足够的资源来完成各项任务么?
我们用的是Android Studio来写程序，AS和虚拟机在电脑上太占内存，每次一调试都要等上半天，最后我们改用用真机测试来节省时间。数据库方面我们直接用网上的，花时间学习了下对数据库服务器的操作。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
开始时估计界面排版会写的很快，于是分配先写界面，剩下的熟悉逻辑功能，等界面完成后接着写。但后来发现并不是这样，界面写了好几天才完成，熬夜写完了逻辑功能。
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
简单的进行了模拟用户测试，测试了各个界面的功能，基本完善，但还没进行真实用户测试。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
黄志明（PM）：我可以把发布者界面给牛姐做，这样风格更统一而且美观。。。最后看她一直在改我的界面改到快吐血，感觉挺尴尬的。。。
李严（V）： Android studio 的安装与配置，= =向来编译软件都没有很顺利地安装好过，这次也不例外。当有了问题，各种百度无果后，必要时一定要向队友求助！！！硬生生搞了两天后，无果，结果把电脑给队友，一晚上就好了
格格（V）：我觉得工作完成的还算及时把！效率的话，有经验的人自然更有效率了，一样的基础的话，应该差不多！
橙汁（V）：写界面排版的人可以继续写相应界面的逻辑功能，自己写的界面自己更熟悉，写起来也方便，但由于都是初学者，学的不全面，只能分开写。
志兴（M）：有，在写代码这件事上，主要是由于自己基础不行，加上注意力不集中，遇上问题要很久才能解决，而队友比较专注，做得比较快。
牛姐（V）：我没感到自己做的事要别人来做，倒是觉得分给其他人的侧滑应该交给我来做，这样就不会太引起后面的麻烦。
佳恺（M）：我认为自己的工作可以交给其他人来做，但效率并不会得到提升，并且我认为我遵守了《软件需求分析报告》的代码命名规范，使得我负责部分的代码可读性较高
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们将重新分配下任务，让大家做各自熟悉的工作
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
团队大部分在一起编程，消息传播很快
其他还是通过我们项目的qq群来传递变更的消息的，每天晚上还有站立式会议。
但是有一点要自我批评，拖延症状，不经常Pull最新代码，部分组员的工程文件落后于最新的版本。但所有push的更新都会在工作组中提及。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
从用户的角度出发，决定哪些功能是必备的，哪些是附加功能，哪些是可有可无的，排出优先级。
根据我们项目的具体情况，我们首相要实现项目的基础功能。我们的项目最主要的功能大概有以下几点，活动的查看、活动发布与编辑、人员报名参加活动以及相关的注册登录。
完成了这些功能就已经有了一个活动管理平台的样子了，这些是我们“必须实现”的功能，其余的相关的功能，就可以在beta阶段逐步的添加进来。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
Alpha的出口条件简单粗暴，即没有导致crash的大bug，预期功能健全完善。只有一个移动端的平台，所以“做好了”的直接效果就是安装我们的APP各个功能以及排版都能够实现其应有的功能，这也是比较好测试的。页面整合后，能够通过各项的测试，这样就算是“做好了”。
4.对于可能的变更是否能制定应急计划?
基本没有，出现的几次应急情况都是我们的成员熬夜补救的。
5.员工是否能够有效地处理意料之外的工作请求？
可以处理，PM给定工作请求时会分配给较为积极的组员和比较有经验的组员，大家做事都很积极，基本上都是抢着做，虽然在处理问题上的处理问题的能力有待提高，但是针对具体问题有着具体的解决方案，执行起来也很快。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
用Git，用Git，用Git，重要的事情说三遍，大家开始使用git有点迟了。出现了多人修改完之后导致覆盖的问题，这些部分都不太多，所以还没有造成较大的影响，不过这种现状确实是要改改了！！
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
界面原型设计在早期就已经由橙汁完成了，真实际界面的设计与原型还是有一定的差别比如按钮大小，字体大小，背景等等！因为找不到原来的背景图了。后期也考虑是否修改原型，因为设计出的界面无法适应所有分辨率的手机，控件都会有所偏差！
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有的。就比如之前有过关于发布者身份是否与参与者的身份合并，是放在同一界面，还是分开作为不同身份，分开登陆。最终少数服从多数采用分开登陆的方式。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有运用单元测试，基本都是每个人测试自己的模块，在遇到实在不懂得问题，大家一起讨论，在测试结果符合后再合并到一起。测试过程没有采用工具，基本是手工测试，遇到问题就修改
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
因为每个人测试自己的模块，所以有些人的不是很了解。就登陆界面来说，在登陆的时候会出现第一次正确密码可以登录，以后再次登陆就会失败。后来修复了。其他的还有就是侧滑框的实现不是很理想
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
一开始，制定了代码规范。然后就没有然后了，各自采用各自的命名⋯⋯呜呜！等合并的所有的界面的时候就遭报应了
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
贯彻落实代码规范
六、测试/发布
1.团队是否有一个测试计划？为什么没有？
有，但是没有依照计划进行
原因：alpha版本的时候团队进度比较小，以至于deathline还有在修改代码，留给我们的测试时间就大大减少了，导致测试计划没有如期进行
2.是否进行了正式的验收测试？
说起正式验收测试，并没有。但是说起非正式验收测试，一大堆。
3.团队是否有测试工具来帮助测试？
有，在网上有百度到J是一个很好的测评软件，但是后来由于功能的太多欠缺，以及不太懂测评
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
手动调试来跟踪软件的效能；测试工作有用，能够测试出bug，但是很难找到bug存在的准确位置和真正原因，正就是所需要改进的地方。
5.在发布的过程中发现了哪些意外问题？
由于测试和完善做的不是很全面，导致我们组在7点钟还在活动室里调试，寻找bug，登录注册用户= =在此之前一直都没出过问题，谁知在汇报前期，竟然⋯⋯ 这很尴尬啊，还好最后找到了原因，发布才能够顺利进行
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
用git及时整合，及时测试。
七、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
1. 在Alpha冲刺之前，我们团队有针对我们的项目做过需求分析以及项目计划
2. 在Alpha冲刺阶段，尽管我们小组一开始没有通过github进行项目管理，但是每天会向组长汇报自己的工作量以及工作进度
3. 在Alpha冲刺之后，团队有了类似项目的开发经验，一定程度上可重复类似项目的软件开发
4. 小组有测试人员，通过案例测试充分保证了软件Alpha版本的核心功能的使用以及质量地保障
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
1. 在Alpha冲刺之前，我们团队每个人都没有项目开发的经验，虽然每个人都有一定的JAVA语言基础，但是并不知道自己适合于MVC框架中的哪一部分
2. 在Alpha冲刺阶段，组长根据MVC框架以及每个人在Android学习的进展程度来分配任务，UI界面设计交给了Android语言学习进展较快的队友来做，偏向JAVA语言方向的Model和Control就交给剩余的人
3. 在Alpha冲刺之后，团队的每个人并不能体现出自己的强项和自己的代码能力，所以在项目开发过程当中任务的分配还是没有一个具体的指标，就是这个任务交给谁来做都可以，所以团队还处于磨合阶段
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
1. 有真正地项目开发的经验，对一个软件开发的过程不会像当初那么迷茫
2. 团队有了一个一起开发软件的经历，营造了团队组员之间融洽的气氛和难以割舍的感情
4.你觉得目前最需要改进的一个方面是什么?
项目管理以及项目进度的把控。在Alpha冲刺阶段，每个组员的任务安排下去之后，组长没有对项目的整个进程进行把控，组员也没有每天向github上面提交代码，尽管这是组长每天吩咐的事情，但在组员那边没有得到落实，大家在自己电脑上的项目进行代码开发，造成最后项目的整合时class文件命名的冲突，界面风格的不统一，以及对逻辑功能的实现造成了一定的困扰。
