第06组Alpha冲刺总结
1. 基本情况
-
组长博客:郝雷明
-
答辩总结:
问题一:动态删除可以在我的动态进行删除,社区没有办法直接删除自己发的动态
问题二:轮播图是固定的,之后可以根据实际需求,加入广告商的图片
问题三:二级评论目前还没实现
问题四:动态出现是根据发布的时间顺序排列,不能优先看到认识朋友的动态 -
全组讨论的照片:
-
评估团队中每个人对本次作业的贡献比例:
(1) 工作流程:
按照组内组员讨论出来的想法,
->制作出ui图
->不断修改完善ui图
->确定界面和功能
->开始实现基本功能
(2) 组员分工:
详情请见之前的博客
(3) 组员工作量比例:
姓名 | 工作量 |
---|---|
郝雷明 | 8% |
方梓涵 | 15% |
杜筱 | 12% |
鲍凌函 | 11% |
董翔云 | 11% |
黄少丹 | 9% |
詹鑫冰 | 7% |
曾丽莉 | 9% |
曹兰英 | 9% |
吴沅静 | 9% |
2. 思考与总结
2.1. 设想和目标
- 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
Q: 解决的问题:为考研学子提供一个交流经验和提供题库资源的平台;
定义:小程序功能定位清澈
有典型用户和典型场景的描述:
- 上岸的学生:通过上传自己觉得很好的资源到“小福有研”,发布自己考研的经验贴到动态页面;
- 备考的学生:利用社交功能记录自己的每一天,题库页面以及搜索页面查找自己需要的资料,上传自己觉得有价值的题目及答案;
- 有考研意向的学生:通过浏览平台上各个页面,对考研有一个整体的框架构想。
- 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
Q: 原计划功能:全部做到(虽然有些不是特别符合要求)
交付时间:按照要求交付
用户数量:不太清楚 - 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
Q: 由于小程序还没通过审核,用户量暂且未知,
之后会补充 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
Q: 不要低估了任何一个项目的开发难度和工作量
改进:每个成员之间沟通更加紧密;
2. 计划
- 是否有充足的时间来做计划?
Q: 有足够的时间准备,团队分工还是较为明确的 - 团队在计划阶段是如何解决同事们对于计划的不同意见的?
Q: 通过线下线上讨论的方式,及时沟通,互相理解这个很重要! - 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
Q: 团队每一个成员基本完成都完成了 - 有没有发现你做了一些事后看来没必要或没多大价值的事?
Q:
姓名 | 反思 |
---|---|
郝雷明 | 存在即有意义,纵然有些不合理,但不影响大局发展,也有学到一些不一样的 |
方梓涵 | 没有,都是需要完成的任务 |
杜筱 | 没有,为完成那些功能实现,做的事都是必要的 |
鲍凌函 | 有,走了一些弯路,最终选择了最合适的云开发完成功能实现 |
董翔云 | 没有,做的事都有用,有的是现在,有的是以后 |
黄少丹 | 没有,踩的坑都能让我懂得如何更好地避开未来的坑,总结经验 |
詹鑫冰 | 有,踩了很多坑 |
曾丽莉 | 没有,目前做的都很有必要 |
曹兰英 | 虽然现在有些事现在看起来没必要,但是以后总有一个时刻会觉得有用吧 |
吴沅静 | 有,测试初始文档设计太麻烦了 |
- 是否每一项任务都有清楚定义和衡量的交付件?
Q: 是,分工将任务已经具体化,但在后端的时候,还是存在有人不清楚自己的任务的现象 - 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
Q: 基本是按照计划进行;
项目出现的意外:bug异常的多;
风险:时间分配还是比较紧张,
原因:没有准备缓冲区,之后beta会安排缓冲区; - 在计划中有没有留下缓冲区,缓冲区有作用么?
Q: 这个恐怕没有,整个计划没有设留缓冲区 - 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
Q: 嗯,之后的时候会考虑增加缓冲区 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Q: 有效的团队合作会使项目事半功倍;
改进:无
3. 资源
- 我们有足够的资源来完成各项任务么?
Q: 有,人力肯定不缺,因为做的是小程序,其他资源,像时间也不是特别紧张 - 各项任务所需的时间和其他资源是如何估计的,精度如何?
Q: 没有估计,分到任务后都是尽力完成,也有专门的负责人催促;
后期完善的时候,会估计修改代码的时间等等一些资源配置 - 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
Q: 测试的时间,人力和软件/硬件资源是否足够 - 你有没有感到你做的事情可以让别人来做(更有效率)?
Q: 应该没有吧 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
Q: 有效的团队合作会使项目事半功倍;
时间的分配合理促使项目更加顺利进行;
改进:无
4. 变更管理
- 每个相关的员工都及时知道了变更的消息?
Q: 基本上是每个相关的员工都及时知道了变更的消息。
(但存在:参加开会的成员不知道自己的任务,但是其他人都已经知道各自的任务,任务分配已经很明确了) - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
Q: 根据剩余的时间和原来的需求规格说明,来决定“推迟”和“必须实现”的功能,
现阶段,小程序存在少量的bug和搜索功能存在问题。 - 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
Q: 我们团队一致认为:小程序功能基本实现作为出口条件 - 对于可能的变更是否能制定应急计划?
Q: 还没有遇到特别紧急变化;
如果十万火急,应该会立即开会并指定口头上的急需计划。 - 员工是否能够有效地处理意料之外的工作请求?
Q: 有员工能力较强,可以意料之外的工作请求;
但是也存在员工无法有效处理意料之外的工作请求(点赞取消功能)的现象 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Q: 有效的团队合作会使项目事半功倍;
改进:无
5. 设计/实现
- 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
Q: 大家都由参与设计小程序最初的功能;
事实证明:是合适的时间,也是合适的人。 - 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
Q: 有,协商讨论一同解决。 - 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
Q: 有计划使用单元测试,或者测试出小程序的性能 - 状态还是有很大区别的;
原因是项目开始时的文档是基于我们的空想完成的,实际开发过程中不断地在调整。当然需要更新(事实上我们也确实在做这件事)
Q: 目前还没有变化 - 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
Q: 社区功能,因为功能更加复杂;
小程序未发布,现在真机调试,没有什么重要的bug - 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
Q: 目前复审的准则:功能是否可以正常使用,没有特别严格执行代码规范 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Q: 有效的团队合作会使项目事半功倍;
改进:适当的文字记录会议内容。
6. 测试/发布
- 团队是否有一个测试计划?为什么没有?
Q: 有 - 是否进行了正式的验收测试?
Q: 正在完成,预估beta阶段结束后,测试文档将定稿了 - 团队是否有测试工具来帮助测试?
Q: 有 - 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
Q: 通过微信小程序开发软件自带的功能跟踪效能 - 在发布的过程中发现了哪些意外问题?
Q: 还没有发布(现在未知) - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Q: 测试是一个很难的事情,并没有想象的简单;
前期要尽可能考虑测试实施的可行性,测试计划改了很多次
7. 团队的角色,管理,合作
- 团队的每个角色是如何确定的,是不是人尽其才?
Q: 根据每个人的偏好和团队需要进行分配;是人尽其才 - 团队成员之间有互相帮助么?
Q: 有 - 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
Q: 线下会议讨论 - 每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):
-
我感谢 方梓涵______对我的帮助, 因为某个具体的事情: 耐心指导如何使用github与微信小程序开发者平台的链接_____。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Q: 学会了云开发,使用github进行团队合作,mock设计UI,各种软件设计前端页面;
改进:前期自主的学习相应知识,
8. 总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
Q: 可重复级 - 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
Q: 规范阶段 - 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
Q: 分工更加明确 - 你觉得目前最需要改进的一个方面是什么?
Q: 使小程序的功能更加完善,例如点赞和举报功能实现
3. 敏捷开发
1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户;
举例:这是我们团队的共识,小程序是先将整个框架做好后,
通过不断的调试bug,达到产品基本可用之后,我们再进一步优化产品
2-欢迎对需求提出变更 - 即使在项目开发后期,要善于利用需求变更,帮助客户获得竞争优势;
3-要不断交付可用的软件,周期从几周到几个月不等,越短越好
4-项目过程中,业务人员与开发人员必须在一起
举例:团队每一个人既是开发者也是业务人员!
5-要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务
6-无论是团队内还是团队间,最有效的沟通方法是面对面的交谈
举例:在程序开发阶段出现:
一名后端成员,在其他后端任务都快要完成各自的任务的前提下,还不知道自己要做什么!
我们通过线下的会议,由专门的负责人一步步指导,以确保任务可以顺利进行!
7-可用的软件是衡量进度的主要指标
8-敏捷过程提倡可持续的开发,项目方,开发人员和用户应该能够保持恒久稳定的进展速度
举例:整个项目都是连贯的,UI前端后端测试很少出现间隔或者耽误进度的现象;
其中后端与前端的页面上有一点点的疑问,但也很快就解决了!
9-对技术的精益求精以及对设计的不断完善将提升敏捷性
10-要做到简洁,尽可能减少不必要的工作,这是一门艺术
11-最佳的架构,需求和设计出自于自组织的团队
12-团队要定期反省如何能够做到更有效,并相应调整团队的行为。
举例:每次博客编写前都有组内都会举行会议,讨论每一个人的接下来的任务内容。
特别是运动会期间,前后端的任务分配以及几天前的测试与后端的对接上。