课程信息
| 课程 | 软件工程1916|W(福州大学) |
|---|---|
| 团队名称 | 修！咻咻！ |
| 作业要求 | 项目Alpha冲刺 |
| 团队目标 | 切实可行的计算机协会维修预约平台 |
团队信息
| 队员学号 | 队员姓名 | 个人博客地址 | 备注 |
| 221600126 | 刘忠燏 | http://www.cnblogs.com/Downstream-1998/ | |
| 221600207 | 黄权焕 | https://www.cnblogs.com/hyry/ | 队长 |
| 221600328 | 苏明辉 | https://www.cnblogs.com/ahuigg/ | |
| 221600330 | 吴可强 | https://www.cnblogs.com/masgak/ | |
| 221600331 | 向鹏 | https://www.cnblogs.com/xiang-peng/ |
事后诸葛亮
整理：黄权焕
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
问题：我们软件为福大师生解决向福大计算机协会预约维修困难的问题，解决计算机协会统计预约情况困难问题。
定义：清楚明白，已多次和协会反馈获取迭代需求
描述：对典型场景描述较少，典型用户做过一些分析，但总体而言还是传统模式的需求分析，没有故事。
2. 是否有充足的时间来做计划?
充足的时间是个永远达不到的词，计划时间事后想起永远不足
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
摆事实，讲道理。用户的问题你的方案能解决我不能，那么依你。反之亦然。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划工作并没有做完，没做完的基本上我们考虑的较少使用的部分，或者是较难完成的部分。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有的，因为对后端框架的不熟悉，我们曾经尝试用老师教导过的单例模式去优化数据库链接类，然后发现这些都已经存在了。因为对前端框架的不熟悉，我们增用纯HTML重构页面，后来发现bootStrap构建更加美观实用。
3. 是否每一项任务都有清楚定义和衡量的交付件?
大部分没有，我们没有很明显的角色分工，大部分人前端后端都要接触。因为一开始写后端时发现前端无法正常支持开发，所以只能全力先构建页面。
4. 是否项目的整个过程都按照计划进行?
否，计划上没有预料到需要重构前端。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，我们在A冲刺前提前开展了一些工作，达到了为突发事件（重构前端）争取了宝贵时间。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将工作细化再细化，将缓冲区延长。
资源
1. 我们有足够的资源来完成各项任务么?
没有，很多资源是花额外时间寻找得来的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
开始精度很粗略，只有模块区分、权重和分值。后来无法严格安装这个开发（团内互助）。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
不足，测试只有尝试性的一个例子。好的测试工具也要收费
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
暂时没有，分工而言我们也曾进行前后端的分割，然后发现前后端开发进度不一，对功能实现各有各的理解，常有前端增加需求而后端不支持的情况。故，采取功能分割后，人员再统一负责前后端。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
没有，因为部分队员厌弃git,导致没有小粒度提交，更改通知、记录都不及时。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
小组讨论，扮演用户角色
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
出口条件并不太懂，接口有做一个事先约束，省了不少事。
4. 对于可能的变更是否能制定应急计划?
能，随机应变能力强，队员前后端都能临时补上。
5. 员工是否能够有效地处理意料之外的工作请求？
意料之外常有，但在站立式会议中一般都有思路解决
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计在需求分析阶段，有大家讨论，组长总结完成。是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
讨论，代入角色，彼此论证。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了单元测试。运用了单元测试的队员可以在之后的维护中节省不少时间。
4. 什么功能产生的Bug最多，为什么？
预约单相关功能bug最多，涉及到多张数据表，包括数据统计功能，也是依赖预约单而生成的，bug也很多。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审是队长会专门拿出时间和队员一起做页面整合和代码规约检查。在整合中发现错误，再进行修补。代码规范因为时间关系只解决能引起插件报错的部分。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，但因为时间问题没有彻底执行
2. 是否进行了正式的验收测试？
没有
3. 团队是否有测试工具来帮助测试？
没有
总结:
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMM：第二级 可重复级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范：磨合已过，规范初展。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
队内成员明确自身能力，开始习惯多人开发并积累了解决问题的经验，不再遇急抓瞎。
4. 你觉得目前最需要改进的一个方面是什么?
队内规范化，分工再细化且保证任务完成质量和效率
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
优先开发客户端和主要页面，已经提交多次原型保证协会需求。
-
即使到了开发的后期，也欢迎改变需求
实际上我们在页面重构时还在不断优化页面逻辑，比如将上门维修当作一个特殊的场次
-
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
站立式会议让我们能快速了解和督促同学完成任务，哪怕是视频会议都会拖慢效率
会议图片
交接计划
- 组内队员做好现有的代码注释和说明，部分难以解释的逻辑则由另建图表文档说明。
- 为新队员介绍组内每一个人分工和已完成部分，不独解释需求交接内容，而是让交流人员熟悉现在项目的进度和未完成之处
- 我们不打算让新队员完全只承接被交流队员的工作，而是考虑其擅长方向和技术能力，队内重新规划一次分工
- 让新队员安装好约定版本的Eclipse、MySQL、Tomcat、代码规约插件P3C，熟悉git操作规范等，以完成相关对接。