团队作业7——Alpha冲刺之事后诸葛亮

事后诸葛亮分析

一、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决的问题：我们的软件就是给用户休闲益智用的
- 最主要的功能就是让用户解答10道24点题目，需要用户开动脑筋，所需时间视个人能力而定，从5分钟到正无穷不等
- 在之前的博客中都有清晰的描述

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 达到目标了，可玩
- 原计划的功能全部做完
- 按原计划时间交付了
- 现在用户为
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
没有上一阶段
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
预期alpha阶段后用户量是20人，现在是22人注册。基本一致，我们希望直接与这些用户进行沟通，能得到更加直接的反馈意见，所以也没有找太多的人试用我们的软件。现在收集了不少提议，我们会在下阶段改进。从无到有，当然离目标更近了。

二、计划

1. 是否有充足的时间来做计划?
什么计划？每天的还是这个阶段的？问问题可以问得明确点。这个阶段就是计划要完成的工作量，但是因为大家对于自己的技术都没什么底，所以没有细分。每天的计划都是当天立会直接制定的，也没太多的时间。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
僵持不下就DEV拍板，不然就少数服从多数原则。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
都做完了。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，每日立会大家一起交流昨天做了什么，遇到什么困难。因为我们都是在一起写程序的，所以这一步多余了，不适合我们的团队具体情况。但是作业要求，就这样吧。所以大家每日立会最重要的就是，站在一起想想今天博客的每日立会要怎么写，嗯。
还有就是每日立会都要拍照，每次会要开完的时候，还得叫个人过来给我们拍照，顺便寻思一下今天谁露脸，谁不露脸，姿势怎么摆比较好看。如果忘记拍照了，还得等人齐再摆拍一张。

5. 是否每一项任务都有清楚定义和衡量的交付件?
并不是，因为每一项任务我们在之前都不知道能具体做到什么程度，所以只能说至少要做到这样这样。一个最低要求。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
有，写注册的时候，竟然没有限制长度，这样就导致显示用户名的时候太长的用户名显示不完。
风险应该是有的，因为我们的考虑没那么多。现在知道存在sql注入的风险，但是当时没时间搞。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有，缓冲区对于我们团队来说还是蛮奢侈的。我们觉得缓冲区就是用来调整自己的，从身体和心态上。所以我们alpha阶段之后迎来了长长的缓冲区。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
有修改，好像用户相比于功能更喜欢界面做得好看点，我们着手要在beta阶段以提升用户体验为主要目标。

三、资源

1.我们有足够的资源来完成各项任务么?
三点：①人力资源，够了，大家都是渣渣，但是写的程序又不算太难，只要大家都愿意把自己的个人时间都砸进这个项目当中就够了。②时间资源，如果能多一点时间用来睡觉，是最好的了。③学习资源，安卓开发的资料还是蛮多的，还有场外的技术支持，很棒。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
其他资源是什么资源？所需的时间每天都会做一个大致安排。精度不高，要么就是想简单了，要么就是太不自信时间估计得太多了。
3.测试的时间，人力和软件/硬件资源是否足够?对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
都够了。并没有低估难度，美工设计是我们在alpha阶段弱化的点，我们需要有的放矢，文案是我们觉得最难的部分（包括写博客还有软件需求规格说明书）。大家都比较喜欢和计算机打交道，这些反而更加头疼。
4.你有没有感到你做的事情可以让别人来做（更有效率）？
我们一致都认为有，因为我们是现学现卖，如果是有经验的开发人员，起码他们不用在乎技术不过关的问题。而且原型设计的很多东西，确实需要专门琢磨的。

四、变更管理

1.每个相关的员工都及时知道了变更的消息?
大家都聚在一起写程序，自然及时知道了。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实现的功能，我们已经提前计划好的，这是绝对不容许变更的。
至于推迟的，可能大家突然觉得有什么地方实现不够优雅，那我们会估计一下自己剩下不多的时间，再看看任务的难度，如果不能完成就推迟，可以就抓紧做。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
完成我们冲刺之前制定的必须达到的计划，即可以在这阶段出口。
4.对于可能的变更是否能制定应急计划?
有啊，我们本来要把计算交给服务器的，后来发现速度实在是太慢了，所以临时变更，改成在前台计算，不过因为之前结对编程有写过，所以稍微改改就好了。
5.员工是否能够有效地处理意料之外的工作请求？
我们应该可以的，主要我们一般都要熬很晚才能完成当天计划的任务，所以基本不存在PM临时改需求的情况。

五、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
从头贯穿到尾，主要由侯帅军和张朝玮完成。是合适的时间、合适的人，主要他们很喜欢。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，就事先商量好了，决定好了我们觉得最好实现的又可用的用户界面。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有用单元测试，觉得还是蛮有用的。这些就可以在确保模块都正确无误的情况下，将他们结合起来。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
24点算法。因为要考虑的情况是所有模块中最多的。不过都修好了。在发布之后，发现用户名太长显示不全的bug，因为当时设计/开发的时候没人提出这个问题。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在工作进行对接的时候，会复审对方的代码，因为要厘清别人具体做的事情。并没有严格执行，因为即使真的有一两个操作符旁边没留白，我们互相也都看得习惯。

六、测试/发布

1. 团队是否有一个测试计划？为什么没有？
没有，因为我们知道老师一定会布置这个作业。不需要做重复的事情。
2.是否进行了正式的验收测试？
按照老师的要求进行验收测试，是不是正式的。
3.团队是否有测试工具来帮助测试？
有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用老师提供的方法进行测试。如果从后验知识来看，没什么用，因为我们占用的资源都非常少，暂时也没有什么改进的地方。
5.在发布的过程中发现了哪些意外问题？
有，修改完最后的代码忘记重新生成APK了，导致一开始放上去的是未完成的APK，不过很快就发现了:D

七、总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
CMMI二级：管理级
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
磨合阶段
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
实现了从无到有的改进
4.你觉得目前最需要改进的一个方面是什么?
用户体验，大家都说用户体验很差
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
①以有进取心的人为项目核心，充分支持信任他们。我们的主力是最有进取心的（嗯！），我们只能信任他，没有别的方法。
②业务人员和开发人员在项目开发过程中应该每天共同工作。每天还共同睡觉、共同吃饭呢，这有什么。
③无论团队内外，面对面的交流始终是最有效的沟通方式。说了很多遍了，我们都是线下合作。
④时时总结如何提高团队效率，并付诸行动。配合越来越默契，每天睡觉前还要想想昨天做得有哪些不好，这样每日立会才有东西说。
6.我们学到了什么，如果历史重来一遍, 我们会做什么改进?
①.就是其他课的作业一定要及时的完成，不然既要冲刺又要对付其他课的作业，真的来不及。
②.要做好睡不饱觉的准备，或许是我们团队比别的团队相比底子比较差，所以花了更多的时间。
③.技术能提早准备是最好的，但是我们为了节约时间只能现学现卖。
④.不要找借口，大家都很忙，我们有三个学生社团主要干部，三个考研，一个考公。时间不够就少睡点，反正大家一起熬夜。
如果历史重来一遍，我们会好好吃饭、好好睡觉。即使减少任务量，即使往后拖几天也要保住狗命。
7.照片

8.成员贡献

排序	姓名	可验证贡献	团队贡献分
1	李嘉廉	24点算法、部分工具类实现、后端数据代码、游戏功能	40
2	张翔	部分工具类实现、界面优化、排行榜适配器、下拉菜单、结果页面	18
3	林正晟	单元测试、部分工具类实现、游戏界面、服务器更新数据、结果页面事件	17
4	张朝玮	欢迎界面、主界面、排行榜界面、注册实现	16
5	侯帅军	登录界面、注册界面、排行榜界面、随机生成题集	15
6	陈伟泽	编写博客、分配任务、更新代码规范、界面优化、欢迎界面	14