过后诸葛亮（团队）

班级：软件工程1916|W
做业：过后诸葛亮（团队）
团队名称：Echo
做业目标：完成Alpha冲刺的过后诸葛亮

目录

• 设想和目标
• 计划
• 资源
• 变动管理
• 设计/实现
• 测试/发布
• 团队的角色，管理，合做
• 总结
• 照片
• 组员交接工做及方案

设想和目标

一、 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 咱们的软件主要针对福州大学的物业管理，用于解决目前福大物业消息通知不及时、水电缴费麻烦的痛点。

• 对于定义，咱们以为很清楚。

• 对于用户和场景，咱们也作了较详细的描述。

二、 咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

基本达到，详见总结随笔

三、 和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

上一阶段主要都在作设计、需求这块，若是硬要说提升，那就是有产品成果了。

四、 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?

还没推广，暂时没考虑用户量

五、 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

在实现过程当中没有出现大问题，但若是历史重来一遍，咱们会将文档等写的更加详细一些。

计划

一、 是否有充足的时间来作计划?

咱们在alpha冲刺前就完成了计划，因此是有充足的时间来作计划的

二、 团队在计划阶段是如何解决同事们对于计划的不一样意见的？

咱们若是出现不一样意见，主要采用了集体讨论的方式，在天天的会议中提出并讨论审议。

三、 原计划的工做是否最后都作完了? 若是有没作完的，为何?

没有所有作完，物业管理端的缴费信息导入、人员导入都还没作，主要是由于时间以及对文件读取不熟。

四、 有没有发现你作了一些过后看来不必或没多大价值的事?

没有

五、 是否每一项任务都有清楚定义和衡量的交付件?

是的，基本都有

六、 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

总体上按照计划有序推动，没有什么大的意外。主要遇到的问题是在先后端对接时发现了一些bug。在一开始就有估计到会出这些bug了。

七、 在计划中有没有留下缓冲区，缓冲区有做用么?

有的，咱们提早预留出了时间给对接工做

八、 未来的计划会作什么修改？（例如：缓冲区的定义，加班）

由于咱们的得力干将kwm被迫换组，后续的管理端计划可能会根据具体状况稍做修改。

九、 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 学会了如何进行团队协做，以及如何更加合理的安排时间。
• 若是再重来一遍，咱们应该仍是会按照原来的计划走。

资源

一、 咱们有足够的资源来完成各项任务么?

有的，前端后端以及测试用的工具都比较成熟，有大量的学习资源。

二、 各项任务所需的时间和其余资源是如何估计的，精度如何?

首先肯定咱们的任务，再根据任务难度和任务类型分配以及每一个人想要的发展方向，给每一个人分配任务，最后肯定每一个任务的完成时间。

三、 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?

• 人力、软件资源充足，硬件上，因为是使用腾讯云的学生机，因此配置较低
• 美工等资源，因为在前期原型设计的时候已经较为完善，因此也没有什么问题

四、 你有没有感到你作的事情可让别人来作（更有效率）?

咱们团队成员都是按照本身能力来分配任务，因此彷佛没有出现这样的状况。

五、 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

• 团队之间要多多交流，尤为是遇到问题的时候，可能其余人那就有好的解法。
• 若是再重来一次，咱们仍是会继续好好利用这些资源的

变动管理

一、 每一个相关的员工都及时知道了变动的消息?

由于天天都会开会，有什么问题也会在群里讨论，因此消息传递效率仍是有保证的。

二、 咱们采用了什么办法决定“推迟”和“必须实现”的功能?

经过开会讨论共同商议决定的。

三、 项目的出口条件（Exit Criteria）是否获得清晰的定义?

在需求报告里的性能、界面需求等模块中有比较清晰的定义。

四、 对于可能的变动是否能制定应急计划?

基本没有。

五、 是否可以有效地处理意料以外的工做请求？

没碰到意料以外的工做请求。

六、 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 目前除了在alpha阶段后kwm被迫换组，没有遇到什么变动状况
• 若是在重来一遍，可能就是会提早作好这种换人的准备吧

设计/实现

一、 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

设计工做在一开始的选题及原型设计的时候就完成了，由团队全部人员共同参与完成，是合适的人和合适的时间。

二、 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

没有碰到模棱两可的状况，通常一块儿讨论后就会有结果。

三、 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 团队运用了单元测试、UML等工具帮助实现。
• 有效。单元测试有效地帮助测试了每一个类的debug，uml帮助咱们理清用户、需求、系统功能单元之间的关系。
• uml文档暂时尚未区别。
• 可能须要完善下uml文档。

四、 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?

• 在报修投诉模块的bug最多，主要是一些边界条件没考虑清楚
• 发布以后，发现有的报错信息未处理，直接提示给用户，不够友好。由于时间比较赶，没有注意到这些方方面面

五、 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 代码复审由队员随机抽查github上的代码的格式、风格、命名是否符合规范。
• 除了管理员后端外，严格执行了代码规范。

六、 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 代码规范很重要
• 若是重来一遍，咱们会强制给每一个人的idea上装上阿里巴巴的插件

测试/发布

一、 团队是否有一个测试计划？为何没有？

有。

二、 是否进行了正式的验收测试？

尚未到验收阶段

三、 团队是否有测试工具来帮助测试？

有，使用了Junit和Robot Framework等工具进行测试

四、 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？

还未进行软件的效能测试。

五、 在发布的过程当中发现了哪些意外问题？

没有遇到问题

六、 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 咱们学到了测试的重要性。
• 若是历史重来一遍，咱们会花更多一些的时间在学习自动化测试上。

团队的角色，管理，合做

一、 团队的每一个角色是如何肯定的，是否是人尽其才？

团队的角色是根据团队成员各自选择喜欢或熟悉的方向肯定的。有作到人尽其才。

二、 团队成员之间有互相帮助么？

有。

三、 当出现项目管理、合做方面的问题时，团队成员如何解决问题？

还未出现过这样的问题。

四、 每一个成员明确公开地表示对成员帮助的感谢 （而且写在各自的博客里）：

• 黄少勇
  感谢kwm在我完成任务过程当中给予的帮助，即便被迫离开团队，也要继续指导我完成团队布置任务

• 黄种鑫
  感谢kwm在前端给个人帮助，虽然小程序开发和web开发有必定的差异，可是框架的一些思想仍是相同的，kwm对于我对框架的理解有了进一步加深

• 孔伟民
  感谢kwm对个人帮助（你问kwm是谁？我不懂别问我我不知道），他在我玩手机的时候叫我起来干活，在我遇到问题的时候帮我百度...即便离开团队，也身在曹营心在汉。

• 李东权
  感谢kwm对个人帮助，即便离开团队，也能超额完美的完成团队安排的前端任务，而且能正常与个人后端相对接，合做愉快

• 林弘杰
  感谢kwm对个人帮助，在进行接口对接时及时发现了问题，对我进行反馈，让我发现了我测试脚本的不足

总结

一、 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?

我以为团队目前的状态属于成熟度级别2 － 已管理，正在迈向级别3

二、 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?

我以为咱们到了磨合期，正在迈向规范期。

三、 你以为目前最须要改进的一个方面是什么?

我以为目前最须要改进的方面是前端和后端之间报错信息的统一。

照片

组员交接工做及方案

1. 熟悉项目：查看alpha冲刺前的需求文档、设计文档等
2. 熟悉开发内容：查看API相关文档、前端代码相关说明等
3. 开始接手前端开发工做