第一次团队会议
-
会议基本信息
- 团队序号:1
- 团队名称：辅核
- 团队口号：以辅助为核心，全队为半径
- 团队成员：张家林(队长),王建,王喆鋆,刘天梓,刘青洹,王柯然,金炜嘉
- 会议召开时间：2020年9月19日(星期六)19:30
- 会议召开地点：图书馆二楼中厅
- 参与人：张家林,王建,王喆鋆,刘天梓,刘青洹,王柯然,金炜嘉
- 缺席人员及缺席原因：全勤，无缺席
- 会议照片：
- 博客撰写人:张家林
-
通知团队成员阅读《构建之法（第三版）》第5、6、8、9章，思考相应问题及团队成员回复的截图。
-
团队成员发布到团队沟通群的对问题1、2、3的思考的截图。
-
团队成员发布到团队沟通群的对问题4、5、6的思考的截图
-
通知团队成员开发时间和地点以及会议流程安排及团队成员回复的截图。
-
会议流程安排(包括会议计划耗时，以及各个阶段的计划耗时。)
阶段名 预计耗时 讨论团队成员分工 5分钟 探讨项目以及其可行性并确定项目 30分钟 讨论项目可能存在的问题以及疑惑 15分钟 确定项目最终解决方案 15分钟 合计 65分钟 -
经过讨论确定的团队成员最终分工的详细描述，重点说明团队内的不同意见有哪些，经过怎样的讨论及权衡取舍得出了最终一致的意见，每位成员在团队内担任的职务以及团队决定令其担任该职务的原因。
- 张家林、金炜嘉主动担任开发工程师(后端)，王喆鋆、刘青洹主动担任开发工程师(前段)，我们在讨论时对我们是否应该有UI设计师以及测试工程师的岗位安排出现了不同的意见
- 刘青洹认为我们应该将UI设计师的岗位与开发工程师(前端)进行合并，前端在制作页面时对页面进行设计，张家林认为我们应该有UI设计师，这样前端开发工程师可以减少对页面的修改，很快做出满意的版本
- 在我们经过投票以及对各个团队成员重新介绍了自己的技术栈仔细了解后，发现刘天梓和王柯然对代码编写不是很擅长，故最终选择刘天梓愿意担任UI设计师岗位，王柯然担任测试工程师岗位。
- 在第一轮讨论结束后我们发现PM岗位还未有人担任，但是王建对前端开发比较擅长，与具有实际经验的张家林沟通后，团队成员共同决定由张家林同时担任PM与后端开发工程师
经过讨论我们最终确定的团队成员分工以及职责如下表
职位 人数 成员 职责 项目经理＆产品经理(PM) 1 张家林 负责需求分析、产品概要原型设计、项目目标、计划、进度、质量、风险管理等相关工作 UI设计师 1 刘天梓 负责页面UI设计、并提供页面原型设计图 开发工程师(前端开发工程师) 3 王建、王喆鋆、刘青洹 负责前端页面制作及前后端交互 开发工程师(后端开发工程师) 2 张家林、金炜嘉 负责后端架构设计、代码编写 测试工程师 1 王柯然 负责对实现的功能编写测试用例并使用测试工具进行测试 -
经过讨论确定的团队模式、团队开发流程，重点说明团队内的不同意见有哪些，经过怎样的讨论及权衡取舍得出了最终一致的意见，说明为什么认为是该团队模式以及为什么选择该团队开发流程。
- 经过讨论我们最终决定采用交响乐团的团队模式，每个人在自己擅长的岗位各司其职，共同完成项目开发。
- 在讨论过程中我们多数对初期组件时的主治医师模式进行了否定，因为在技术都互相不成熟的情况下，很容易使此种团队模式变为书中所说的“一个学生干活，其余学生跟着打酱油”
- 我们在使用业余剧团模式还是交响乐团模式产生了一些不同意见，张家林认为我们应该使用业余剧团模式，根据不同的项目与技术选用，进行不同的成员职责搭配
- 经过分析业余剧团模式和交响乐团模式的优缺点，我们最终采用决定交响乐团模式
- 分析结果：
- 交响乐团模式：
- 优点:各司其职，重在执行
- 缺点:可能导致团队氛围过于呆板
- 业余剧团模式:
- 优点:在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
- 缺点:在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。
- 交响乐团模式：
- 经过讨论，我们最终决定使用敏捷开发模型进行本次项目开发，我们一致认为敏捷开发模型比较适合我们的项目，我们在项目过程中可能会经常对需求进行变动，将系统分成多个子模块进行开发便于我们迅速的对项目进行迭代升级并完善项目
- 经过讨论我们最终决定采用交响乐团的团队模式，每个人在自己擅长的岗位各司其职，共同完成项目开发。
-
团队最终确定要开发的软件以及为什么要开发该软件的原因，重点说明团队内的不同意见有哪些，经过怎样的讨论及权衡取舍得出了最终一致的意见。
- 经过讨论，我们最终确定要开发的软件是图书管理系统
- 不同的意见：
- 张家林希望开发校园健康分析系统
- 王喆鋆希望我们开发团队成员空余时间确定系统
- 讨论过程以及权衡取舍
- 我们首先对张家林的需求展开了分析与讨论，认为他的需求虽然具有创新性，也贴合当前疫情下实际，但是获取授权以及数据存在较大难度，而王喆鋆的需求我们认为其关键算法实现难度较大，以我们的技术无法实现其关键算法
- 我们在否定了成员提出的需求后，希望重新提出需求，但是由于缺乏创新思想，经过了一段时间后没有人有新的提议
- 鉴于上述情况，张家林提出了图书管理系统，我们一致认为这个系统难易度适中，适合团队磨合。
-
团队制定的项目计划以及阶段性目标并描述团队是如何制定该计划和确定阶段性目标的，重点说明团队内的不同意见有哪些，经过怎样的讨论及权衡取舍得出了最终一致的意见。
- 我们将项目的开始时间定为2020年9月21日(星期一)，预计开发周期为12周
- 在讨论过程中我们没有出现不同意见
- 由于我们使用的是敏捷开发模式，所以我们将系统切分为管理员端与用户端，并将系统拆分为多个子模块进行开发
-
管理员端
子系统名 需要实现的功能 系统关键模块 用户注册、登录、日志记录 权限管理子系统 配置用户权限，使系统可以根据用户权限显示不同的用户菜单 用户管理子系统 对系统中的用户账号进行管理，可以在后台新增用户、删除用户、修改用户信息、查询所有用户并配置用户权限 图书管理子系统 对图书的增删改查 图书借阅子系统 借还图书、并自动发送超期提醒 -
用户端
子系统名 需要实现的功能 系统关键模块 用户注册、登录 用户管理子系统 可以对个人的用户信息进行管理 图书借阅子系统 在线预览、线上预约
-
- 我们将项目分成四个阶段进行开发
- 需求分析与系统设计阶段(1周)
- 完成对项目的需求分析，并产出需求说明书、系统原型
- 系统UI设计
- 基础开发框架搭建
- 项目一期开发(系统关键模块、权限管理子系统与用户管理子系统) (3周)
- 完成系统关键模块开发与测试
- 完成权限管理子系统的开发与测试
- 完成用户管理子系统的开发与测试
- 项目二期开发(图书管理子系统与图书借阅子系统) (7周)
- 完成图书管理子系统的开发与测试
- 完成图书借阅子系统的开发与测试
- 项目完整测试与上线(1周)
- 项目在测试环境下进行完整测试
- 项目上线
- 需求分析与系统设计阶段(1周)
-
给出完成第一个阶段性目标所需要完成的任务以及每个任务的负责人，此处应该获得每个成员的确认，可以在会议记录中列出让团队成员挨个确认签字。
-
第一阶段项目目标
需要完成的任务 负责人 完成对项目的需求分析，并产出需求说明书、系统原型 张家林 系统UI设计 刘天梓 基础开发框架搭建 王建、王喆鋆、刘青洹、张家林、金炜嘉 -
第一阶段实施计划
-
第一阶段实施计划明细
- 9月21日:
- PM对项目进行需求分析，并书写需求说明书
- 9月22日:
- PM完成产品原型并将原型提交至码云仓库
- UI设计师将原型下载到本地，进行优化
- 9月23日:
- UI设计师优化原型
- 9月24日:
- UI设计师提交优化完成后的原型
- 软件工程师开始构建项目
- 9月25日
- 软件工程师上传构建完成的框架
- 9月21日:
-
-
根据会议流程计划给出会议种各个环节实际花费的时间，并反思超出的时间是因为什么原因产生的，该如何避免。
阶段名 预计耗时 实际耗时 讨论团队成员分工 5分钟 10分钟 探讨项目以及其可行性并确定项目 30分钟 45分钟 讨论项目可能存在的问题以及疑惑 15分钟 20分钟 确定项目最终解决方案 15分钟 15分钟 合计 65分钟 90分钟 -
在此次会议中，我们发现我们除了最终确定项目解决方案阶段都有超出预计耗时的情况。
-
综合整个阶段，我们发现在整个会议进行过程中，成员不是很主动的去提出问题，多数需要通过引导才能很好的对一个问题进行讨论
-
在讨论成员分工阶段，我们就是否应该有UI设计师的问题以及部分岗位安排有过一些讨论，讨论的过程使我们超过原定耗时
-
讨论项目可能存在的问题以及疑惑阶段时，我们都希望自己提出项目，但是对成员提出的项目简单分析后，发现有很多以我们现有的技术难以实现或无法实现的内容，由于缺少创新性思维，导致团队成员在提出项目时花费的时间过多。
项目 问题/难点 校园健康分析系统 需要获得授权调用企业微信API，获得授权概率低，编写虚拟数据可能数据结构与现实不一致 考试或者收集分析系统 需求不明确 南门刷脸系统 缺少硬件设备、人脸数据、人脸识别算法 团队成员空余时间确定系统 共同空余时间计算算法 -
在讨论项目可能存在的问题以及疑惑阶段，由于缺乏开发经验，无法很好的对可能存在的问题进行提出
-
综合上述问题，我们提出了如下的避免方案：
- 在正式召开线下会议前，可以尝试利用微信、腾讯会议等软件与成员多沟通，召开线上会议
- 在开始会议时，帮助成员整理本次会议内容以及思路，提前引导成员对会议内容进行思考
- 一些非必须线下会议讨论的内容可以在线上解决
-
-
仓库相关信息
-
给出团队会议记录的截图。
