导师互选系统 Alpha版冲刺总结
一、设想和目标
- 我们的软件什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是要实现导师和学生双向互选的功能。功能定义清晰明确，在软件规格需求说明说中有相信的讲解。包括典型用户和典型场景的描述。 - 是否有充足的时间来做计划?
有足够的时间来做计划。 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
小组开会讨论协商。
二、计划
| 504陈逸超 | 教师模块、学生模块V层代码、P层代码 | 7 |
| 505陈少铭 | 提供View层模板、android端P层模板、Model层模板、逻辑串联、修复bug | 9 |
| 511黄家俊 | php后台开发，MC层 | 9 |
| 515翁祖航 | 院负责人、系负责模块V层代码、P层代码 | 7 |
| 516黄瑞钰 | 需求分析细化、接口文档、UI美化 | 6 |
| 517毛仲杰 | ||
| 524王智强 | 博客整理、文档整理，协助后台开发、数据库数据录入 | 7 |
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作大概估计了一下，应该就只完成70%。完成的情况如下：教师模块、学生模块基本完成，院负责人模块、系负责人模块完成85%。UI和界面美化完成的情况比较差，这也是我们Alpha版本主要没有完成的部分。分析一下原因，主要出在了两方面：
有没有发现你做了一些事后看来没必要或没多大价值的事?
在这次项目中，要提一下陈少铭同学，少铭同学的编码能力挺强的。在项目开始初期，他按照自己以前的项目经验，牵头为个项目搭建了一个框架，并且加入了一些非常有用的工具类。举个栗子：解析JSON数据的工具类，让我们小组成员在解析JSON数据的时候只需要一两行代码即可！而且有很强的复用性。可能是其他组员刚接触到android不久，有个组员可能没有体会到别人封装的工具类的好用，自己动手写了一个可以解析JSON数据的utils。心里佩服他这种尝试的精神，但是其实事后总结，对于我们目前的项目而言，这其实相当于无用功。因为工具类已经封装好了，可以直接调用。可以确保项目的进度，但是他自己写了工具类，也是会有收获。是否每一项任务都有清楚定义和衡量的交付件?
有，因为学生导师互选系统角色较多。功能要求也较高，所我们前期花了大量的时间在功能的讨论上，以及对各个角色的定义。将来的计划会做什么修改？
和栋哥在进行需求上面的交流，根据栋哥的需求我们动态调整计划。在计划中有没有留下缓冲区，缓冲区有作用么?
项目在前期推进的时候基本上都按照原计划进行。到冲刺中后期，由于出现各种bug问题，忙于修复bug，项目的进度上面有一些拖延。不过经过努力，加班加点修复bug，并完成了大部分的功能。
三、资源
我们有足够的资源来完成各项任务么?
在资源方面，我们的资源还是充足的。测试数据php后台主要是采用工具postman测试接口的可用性。android端，我们在alpha版本暂时没有采用测试工具，主要是用Log打印工具，对各种bug和功能、以及数据进行测试。各项任务所需的时间和其他资源是如何估计的，精度如何?
完成任务的时间在刚开始还是可以把控的，可能是因为刚开始编码的难度都较低。在后期因为涉及跟后台数据的对接、activity之间的逻辑跳转，所以时间上面显得有点不能按期完成。陷入修复bug的深渊中....测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
修复bug之后，把功能实现就已经接近项目验收的时间了。在专门的用户测试这一块上面我们做的不够好，我们没有预留专门用来测试的时间不够多。基本上测试都是在开发的过程中，编码代码改bug测试的。没有在功能全部实现之后，在集中的进行测试，更深入的找寻潜在的bug...
UI用户体验方面，由于专门做美工的同学，参加国家性的比赛。UI基本做完，但是在冲刺快结束的后几天，有点匆促。
四、变更管理
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
团队小伙伴都住在相邻宿舍，更改信息传递上面没有什么延迟。几乎都会到宿舍当面说。项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目的出口条件，在alpha版本还没有太明白的搞清楚什么是项目的出口条件。对于可能的变更是否能制定应急计划?
对于变更，我们根据哪些人手头的任务完成之后，就先去接手。员工是否能够有效地处理意料之外的工作请求？
我们所有的请求都汇总到组长那边，再由组长统筹安排。
五、设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
界面设计主要是有黄瑞钰同学完成的。字体大小的定义和界面图片的边距都是由他负责。瑞钰的审美较好，PS用的很熟练。切图都由他完成。图标的边距，我们采取的是用“标你妹~啊“来自动帮我们处理完成，再加上人工手动调整。设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在界面设计方面其实，我们刚开始还是遇到了一些问题。就是在画原型的时候，考虑的不周到。比如手动添加学生信息，这个界面少了一些 输入框。少了这些输入框是必要的，也就是提交post请求必须传给后台的。所以当我们编码阶段的时候，还是有对原型和界面的设计进行讨论和修改团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
alpha版本没有运用单元测试。不过最近在学习juit怎么进行单元测试。计划在beta版本运用，还有一个bugtags也会运用。什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
我们项目bug最多的地方是在Listview列表和JSON解析。listview的适配器其实套路都差不多。但是listview里面的每个item有个按钮，点击按钮要实现一些跳转和intent传值这部分刚开始遇到有些棘手。JSON数据的解析，经过我们的后面开会的总结，主要是细心程度不够。比如返回的键值对的键应该是message，而后台开发的小伙伴一不小心写成了”mesage“，少了一个s，android端的小伙伴只按照文档，所以造成数据解析不出来。不过也是这个原因，我们慢慢摸索，懂得了在获得后台返回数据之后，将JSON数据先Log出来一下，再进行解析。发现错误也好沟通修改。代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
刚开始504陈逸超和515翁祖航都是在自己的分支上面写代码，完成工作量。505陈少铭等我们代码写完之后，他有帮忙审核，审核不行，会让我们修改，审核通过再合并到主分支。后面可能因为时间不怎么来得及，都在主分支上面开发和提交。下一阶段，会合理安排时间和进度。落实好，代码复审。
代码规范还行。有个要注意的点就是，写一个函数的时候就要随手把注释给写上，养成一种习惯。写完一个模块再回过头来注释，有的小伙伴采取这种方法。但是思考一下，这样不太好。
六、测试/发布
- 没有专门的测试计划，alpha版本都在忙着码代码，完成功能，修复bug。所以测试暂时还没做到。
- 下一个阶段我们调整一下结构。组长不参与编码，专心把握项目的进度，做好项目的管控，安排好任务和制定好测试计划。统筹协调组员之间的编码问题。
七、总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
磨合你觉得目前最需要改进的一个方面是什么?
沟通不足。
八、从alpha版本到beta版本的展望
| 团队沟通： | 明显不足，出现问题未及时反馈交流，导致bug倍增（找bug之夜） | 将安排每天晚上2个小时的一起工作时间，所有人不得缺席。一起码代码，有问题当场面对面沟通。出现bug，新手尝试无法解决，则老手上。（让bug胎死腹中。。） |
| 原型设计 | 不够完善 | 整理细化要求 |
| 分工 | 不够细化。尤其是模块之间耦合的部分分工不够明确。 | 重新调整，细化分工。 |
| UI | 美工部门去参加比赛，UI虽基本做完但不佳且不够beautiful | beta的时候UI实力扛把子，会在原来的界面设计基础上有比较明显的提升。 |
| 代码规范 | 还ok | 要求在写函数时，务必跟上注释。 |
| 测试 | 没有专门的测试计划，没有形成测试体系 | 组长将不参与编码，专心把握项目的进度，做好项目的管控，安排好任务和制定好测试计划。 |