Beta阶段事后诸葛亮分析
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Beta阶段事后诸葛亮分析相关的知识,希望对你有一定的参考价值。
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
要解决的问题:老师用上课时间点名,不仅浪费宝贵的上课时间,而且容易出现,有些同学帮没有的同学答到的情况。希望通过我们的产品,老师上课之前能够通过微信平台完成一次点名功能,能够自动生成本次为来到教室的学生,达到省时省力的效果。
典型用户:集美大学老师
场景如下:
周五早上上课时间到,马哲老师走进教室,扫了一眼,学生人数发现,来的不是很多。马哲老师,先是表扬了一下来的同学,然后拿出手机,打开微信,点开点名系统,点击生成一次点名,讲台下的同学,纷纷拿出手机,一阵拍,提示完成签到,时间一到,老师点击结束此次点名,然后自动生成未到的学生,然后老师登记一下这些同学,就可以快速开始今天的课程。
2. 我们达到目标了么
基本功能都实现了,但是有些功能还不是很完善:学生请假上传假条的功能,老师统计考勤比较麻烦。但是由于功能尚未完善产品还未发布。而对于原计划的用户数量的肯定是尚未达标,因为我们的产品还未正式发布,用户暂时只有测试人员。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对重要功能的接受程度和预想的基本上一致,通过线上采访老师、同学以及接触测试我们的产品,他们对我们的系统评价还是不错的。这对我们的肯定很大,觉得有做下去的必要,我们也在努力靠近目标、满足用户的需求。
计划
1. 是否有充足的时间来做计划?
差不多每次开会都比较匆忙,大家课多。毕竟大三下学期了,是时候考虑下自己的前进道路,有的队员准备考研以及考公,不能有充足的时间来做计划,只能是做一些比较粗略简陋的计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
统一讨论,少数服从多数。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
大体基本完成,但是很粗糙,后期囿于时间和能力,一些需求没有完成
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
本地管理代码
5. 是否每一项任务都有清楚定义和衡量的交付件?
大部分吧,一些任务无法用交付件衡量,但是都有分工
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
微信将企业号升级为企业微信,对于办公有了更为便捷的开发选择,这个是外部因素
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
在beta阶段中有留下缓冲区 , 用于大家自我调整,以及做一些自己的事情
8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
分工更加细致,更注意个人能力和任务的匹配
资源
1. 我们有足够的资源来完成各项任务么?
有足够的资源,互联网时代,百度,课本都是我们的资源
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
各项任务我们通过,讨论难度,代码量,组员的真实情况,指定多需要的时间,精度有偏差但是还在可以接受的范围内
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间、人力、软件资源都足够,我们对于不需要的编程资源我们没有降低难度,让每个人做自己最擅长的部分
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
想到过了,但是每个人都有自己要完成的部分,大家都自己完成自己的任务,所以最后也是自己通过查找资料完成从从苦难
变更管理
1. 每个相关的员工都及时知道了变更的消息?
答:大家都是一个班的,而且我们组有QQ讨论组进行交流。平时在上下课的路上,也会交流,所以消息传播的很快。大家会及时知道
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们经常开会交流,大家各抒己见,取其精华去其糟粕。这样很合理。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
答:这个嘛,我们没有明确的定义,一般都是凭感觉,大家也不会有不同的意见。
4. 对于可能的变更是否能制定应急计划?
答:可以制定
5. 员工是否能够有效地处理意料之外的工作请求?
答:能
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计工作是在,确定我们项目的时候就大家一起讨论设计工作,由组员一起完成,是合适的时间合适的人
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有碰到模棱两可的情况,组员是大家一起解决的
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
运用了单元测试来帮助设计和实现,工具很有效,帮助我们解决了很多逻辑上的问题,让代码更加完善
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
同学提交签到信息的时候产生的BUG最多,因为到提交大量的信息,特殊字符会出现乱码的情况,因为我们没有想到。
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
我们审查了正确性、可理解性、安全性,严格的执行了代码规范
测试/发布
1. 团队是否有一个测试计划?为什么没有?
答:没有具体的测试计划,因为测试计划难度有大。
2. 是否进行了正式的验收测试?
答:没有正式的验收测试。
3. 团队是否有测试工具来帮助测试?
答:微信测试工具。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
答:模拟实际运行环境运行,从效果来看肯定是有用的,可以测试功能是否成功和是否存在bug。
5. 在发布的过程中发现了哪些意外问题?
答:部分功能没能达到预期目标,存在bug。
团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
答:当然是人尽其才了,我们在小组成员介绍时候已经向大家展示过了每个人的才能。在实际的工作中,我们也是任人唯贤。
2. 团队成员之间有互相帮助么?
答:这个是必须的,团队之间就是要发挥“1+1>2”的本领,大家互帮互助,形成一个团体。
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
答:我们会进行集中讨论,并商讨出最好的解决办法;另外我们请其他小组的成员,给出合理的建议;我们还会去网上找资料解决等等。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
已定义级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
磨合度较高,团队气氛活跃
你觉得目前最需要改进的一个方面是什么?
个人能力的提升以及代码规范
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?
“以有进取心的人为项目核心,充分支持信任他们”
会议合照
团队成员在Beta阶段的角色和具体贡献
名字 | 角色 | 团队贡献分 | 可验证的贡献 |
代泽旭 | PM | 22 | 新增功能实现,代码完善 |
林至贤 | PG | 18 | 完善后台数据统计 |
林燕 | Test | 19 | 代码测试 |
周峰 | PG | 17 | 界面优化 |
童毅南 | Test | 19 | 代码测试 |
尼玛 | PG | 17 | 界面优化 |
何跃斌 | PG | 18 | 完善后台数据统计 |
以上是关于Beta阶段事后诸葛亮分析的主要内容,如果未能解决你的问题,请参考以下文章