团队作业6——事后诸葛亮分析
这个作业属于哪个课程 | 班级地址 |
---|---|
这个作业要求在哪里 | 作业要求 |
这个作业的目标 | 召开事后诸葛亮会议,发布一篇事后分析报告 |
团队会议图:
一、设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?软件目标:为网购爱好者与需要售货渠道的商家提供一个线上的购物商城。这个问题定义得非常清楚。典型用户网购爱好者,典型场景就是网购页面。
2. 我们达到目标了吗?
由于时间紧迫,我们只实现了当初设想的大部分功能,如消费者模块,对于商家模块支付结算生成用户订单的接口未实现。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量未达到预期目标,但较为接近。用户对重要功能的接受程度和我们事先的预想一致。我们离目标十分接近。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
教训是应该在计划之初应该结合实际确定真正能够实现的功能,如果重来会根据本阶段队内成员展示出来的学习能力以及抗压能力做出适当的调整,例如延长开发周期,组织技术交流分享会议等。
二、计划
1. 是否有充足的时间来做计划?是。
2. 团队在计划阶段是如何解决成员们对于计划的不同意见的?
通过讨论,提问,综合成员意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
没有,因为队内成员全是初次做项目,没有相关的合作开发经验,并对相关技术的了解一片空白,需要在兼顾其他科目学习的情况下学习相关技术的原理,因此时间窘迫。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是,对每项任务进行紧迫程度的评级,能让我们能够优先完成更重要的任务。
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
没有完美的按照计划进行,在开发的过程总是遇到各种问题。对开发难度低估,由于技术不够熟练总是出现奇奇怪怪的bug浪费时间。
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
有,为后端开发预留缓冲时间来任务不那么紧迫。缓冲区在一定程度上缓解了项目压力
三、资源
1. 我们有足够的资源来完成各项任务么?有,网上有相关的开发讲解视频以及博文,可以通过学习他们的经验来进行开发。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
通过网上相关视频以及博文学习该如何预估任务量,但预计任务量的精度较差,尤其体现在前后端交互的任务量预估上。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
足够,但在相关的软硬件资源上(由于缺乏经验,对测试软硬件的了解不足)并不足够。没有低估美工设计/文案难度,开始就在准备但是由于经验问题仍有不足。
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
没有,成员选择的工作均是各自最擅长的。
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?是的,组长通过微信群或者私聊来确保每个相关的队员都能及时知道变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们可能采用了基于优先级、影响评估、实现难度等多种因素的综合考虑来决定“推迟”和“必须实现”的功能。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
我们在项目开始前可能已经对出口条件进行了明确的定义,以确保项目能够按照预定的目标和质量标准完成。
4. 对于可能的变更是否能制定应急计划?
能,例如在本次开发过程中出现了部分任务进度跟不上计划进行的情况,并因此制定了调动其他成员参与该任务开发。
5. 员工是否能够有效地处理意料之外的工作请求?
能。有时候临时出现新的事物,成员能通过自学来了解新事物。
五、设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?设计工作在确定选题以后就开始由组长(兼项目经理)进行分析需求以及设计原型,并在制定完计划后组织相关成员共同完成系统设计。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
没有。
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
没有。
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
开发过程是后台连接数据库的交互部分,经常出现数据库数据类型与前后端匹配不上的情况,测试与发布过程是登录注册界面功能经常出现bug,理由是前端获取登陆注册数据的判断逻辑出现错误。
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
在项目冲刺初期由项目经理制定了代码风格规范,严格执行了代码规范,
六、测试/发布
1. 团队是否有一个测试计划?为什么没有?有测试计划。
2. 是否进行了正式的验收测试?
是的,针对各项功能都进行了测试。
3. 团队是否有测试工具来帮助测试?
部分测试采用了测试工具,例如进行各个单元测试时采用了相关的集成技术工具。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
在alpha版本完成后,对购物平台的各个模块进行测试,部分队员负责商家,部分成员负责客户。最后发现了一些之前没发现的潜在问题。
5. 在发布的过程中发现了哪些意外问题?
没有意外问题。
七、总结
1.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?可管理级别,项目的整个开发过程还是十分有序的,但是出于时间成本以及队员相关技术经验的匮乏而完成不够出色。
2.你觉得目前最需要改进的一个方面是什么?
团队应多面对面交流,增强团队凝聚力和互动性。
八、团队成员在Alpha阶段的角色和具体贡献
名字 | 角色 | 团队贡献分 | 可验证的贡献 |
---|---|---|---|
杨智雄 | PM和dev | 10 | 设计具体任务,修改博客初稿 |
张锦程 | dev | 10 | 相关数据库设计与后端开发,前后端交互的实现 |
雷志毅 | dev | 10 | 框架搭建 |
张继凯 | 前端dev | 10 | 管理前端任务 |
宋观瑞 | 前端dev | 10 | 前端页面优化 |
吕宏鸿 | 前端接口设计 | 10 | 前端开发以及前后端交互的实现 |
陈愉锋 | 测试 | 10 | 前后端的功能测试,以及测试计划的制定与博客编写 |
李耿豪 | 测试 | 10 | 前后端的功能测试,以及测试计划的制定与博客编写 |