导师互选系统 Alpha版冲刺总结

导师互选系统 Alpha版冲刺总结

一、设想和目标

• 我们的软件什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  我们的软件主要是要实现导师和学生双向互选的功能。功能定义清晰明确，在软件规格需求说明说中有相信的讲解。包括典型用户和典型场景的描述。
• 是否有充足的时间来做计划?
  有足够的时间来做计划。
• 团队在计划阶段是如何解决同事们对于计划的不同意见的？
  小组开会讨论协商。

二、计划

成员	Alpha版本分工	完成情况 满分（10分）
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版本主要没有完成的部分。分析一下原因，主要出在了两方面：

1. 团队间的沟通不足，出现问题没有比较好的交流。为了让新手比较多的获得锻炼，所以给新手安排的代码量比较多。随之也会出现一些问题，就是新手写的代码会有一些bug。有些bug其实可以问问组里比较强的同学，这样调试起来会快很多。但是alpha版本冲刺的时候，明显沟通不足。导致一个bug卡得够久，影响后面的进度。
2. 不够细化。模块之间有耦合，耦合的部分分工不够明确。导致后期整合四个模块的代码的时候调用别人的activity会出现各种bug。

• 有没有发现你做了一些事后看来没必要或没多大价值的事?
  在这次项目中，要提一下 陈少铭同学，少铭同学的编码能力挺强的。在项目开始初期，他按照自己以前的项目经验，牵头为个项目搭建了一个框架，并且加入了一些非常有用的工具类。举个栗子：解析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版本的展望

Alpha->Beta	过去的总结	未来的计划
团队沟通：	明显不足，出现问题未及时反馈交流，导致bug倍增（找bug之夜）	将安排每天晚上2个小时的一起工作时间，所有人不得缺席。一起码代码，有问题当场面对面沟通。出现bug，新手尝试无法解决，则老手上。（让bug胎死腹中。。）
原型设计	不够完善	整理细化要求
分工	不够细化。尤其是模块之间耦合的部分分工不够明确。	重新调整，细化分工。
UI	美工部门去参加比赛，UI虽基本做完但不佳且不够beautiful	beta的时候UI实力扛把子，会在原来的界面设计基础上有比较明显的提升。
代码规范	还ok	要求在写函数时，务必跟上注释。
测试	没有专门的测试计划，没有形成测试体系	组长将不参与编码，专心把握项目的进度，做好项目的管控，安排好任务和制定好测试计划。