Alpha 事后诸葛亮(团队)
所属课程 | 软件工程1916|W(福州大学) |
---|---|
作业要求 | Alpha 事后诸葛亮(团队) |
团队名称 | 待就业六人组 |
一、团队信息
- 团队名称:待就业六人组
- 团队描述:同舟共济扬帆起,乘风破浪万里航
- 队员信息:
队员学号 | 队员昵称 | 个人博客地址 | 备注 |
---|---|---|---|
221600306 | XRK | http://www.cnblogs.com/XR-K/ | |
221600307 | Yellye | http://www.cnblogs.com/CloudLong/ | |
221600315 | 黎焕明 | http://www.cnblogs.com/lihuanming/ | |
221600319 | Litm | http://www.cnblogs.com/litm/ | |
221600327 | oirving | http://www.cnblogs.com/oirving/ | |
221600329 | supermingjun | http://www.cnblogs.com/supermingjun/ | 组长 |
二、设想和目标
-
我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
软件想要解决的问题:想要改变目前福州大学校园招聘信息只能通过网站单项发布,传播不广,缺乏互动的现状,提供一个对等的信息发布平台,企业可以发布、审核招聘相关信息,用户可以获取信息、报名应聘。一个平台,把之前繁杂的步骤化繁为易,让招聘变得更加高效、快捷。
团队对于软件定义清楚,对典型用户和典型场景有充分且清晰的描述:详见选题报告之真实用户调研和用户场景分析
-
我们达到目标了么(原计划的功能做到了几个?)
原计划Alpha阶段完成功能:详见需求规格说明书博文之预期计划,在十天的Alpha冲刺中,我们完成了原定计划中所有功能。团队合格的完成了Alpha冲刺。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
整个冲刺阶段进展还算顺利,如果历史重来一遍,我们会把项目文档写得更加详细。
三、计划
-
是否有充足的时间来做计划?
alpha冲刺之前,经过了选题报告、需求规格说明书、原型设计、系统设计和数据库设计等阶段,我们对alpha做了详细的规划。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的?
举手表决
-
你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
做完了,毕竟五一假期团队成员,牺牲了假期,全程在开发。
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
-
是否每一项任务都有清楚定义和衡量的交付件?
没有
-
是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
由于明确的分工,合理的计划安排,整个过程都按照计划进行了。
没有什么风险是前期没估计到,后面才发现的。
-
在计划中有没有留下缓冲区,缓冲区有作用么?
冲刺的十天里,前六天都在上课,白天基本没时间用于开发,后四天在五一假期,部分组员回家,往返学校都需要时间。这些应该都是缓冲区。
-
将来的计划会做什么修改?(例如:缓冲区的定义,加班)
每个人都应明确缓冲区的具体时间段,不要在缓冲区以外的时间仍在休息
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍,我们会让安卓开发的组员,更早的对安卓开发进行学习。
四、资源
-
我们有足够的资源来完成各项任务么?
硬件资源充足,团队成员开发环境冲刺第一天全部完成搭建。
人力资源充足,团队成员基本擅长Java,其中有3个人开发过安卓应用。我们团队是为数不多的有女生的团队(而且有两个),女生在UI开发方面比较有优势。
学习资料:github上有很多开源的项目可以学习和借鉴,另外助教也很热心提供各方面的解答。
-
各项任务所需的时间和其他资源是如何估计的,精度如何?
我们将每个功能划分为UI,交互和接口三个部分,分别由UI设计人员,安卓开发人员,后端开发人员进行开发。根据每个任务的难度和类型分配给每个人,最后确定每个任务的完成时间及其资源。
-
测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间不足,这次的alpha冲刺过程,因为一大半时间在上课,一大半时间在假期,每个组员都有自己的事情,所有对于项目的开发,团队几乎全程在赶进度,在测试时间上时间并不充分。
美工设计和文案很重要,在原型设计的时候,我们没有特别的重视,这次的alpha冲刺,界面主要是根据原型开发,在答辩的过程中,普遍被评论UI可以继续美化。
-
你有没有感到你做的事情可以让别人来做(更有效率)?
这次团队分工主要是:
221600307 负责原型UI设计和测试
221600306 和 221600327 负责学生端APP开发
221600329 负责企业端APP开发
221600315 负责Java后端接口开发
221600319 负责Java后端算法设计
虽然221600307 和 221600327 没有安卓开发经历,但是我还是把他们放在了安卓开发上,因为每个组员的能力都不同,每个人擅长的也不同。但不能因为一个人做事更有效率,就把每件事都交他做。而且本来Learning by doing 这个思想就贯穿在我们这次软工实践当中,这样的安排可能会促进他们学习。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
团队继续加强沟通,加强互助,任务分配明确且尽量均等,避免有人任务过重,有人清闲。
五、变更管理
-
每个相关的员工都及时知道了变更的消息?
沟通的渠道非常多,每天的会议,QQ群及时聊天等,而且我们团队成员四个男生宿舍邻近,两个女生也在同一个宿舍,如果变更的消息,都能及时通知到每一个人。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据实现难度和每个功能相互的关系,比如没有登录注册功能,那其他功能有什么用?没有岗位信息发布功能,那对岗位的简历投递功能有什么用?然后通过开会讨论共同商议决定的。
-
项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
在需求规格说明书中有详细的说明
-
对于可能的变更是否能制定应急计划?
没有,紧急情况全靠加班。
-
员工是否能够有效地处理意料之外的工作请求?
在alpha冲刺阶段没有遇到意料之外的工作请求
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
提前制定好变更应急计划。
六、设计/实现
-
设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
系统设计和数据库设计是在需求分析做完之后开始的。由组长牵头,全组人共同完成的。
是合适的时间,合适的人选。
-
设计工作有没有碰到模棱两可的情况,团队是如何解决的?
没有遇到这种情况,团队开会之后都能确定下来方案。
-
团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
团队运用了单元测试、UML等工具帮助实现。
有效。单元测试有效地帮助验证了程序中的每一项功能的正确性,UML通过用例驱动,帮助我们把现实中的问题抽象成面向对象的解决方案,以便进一步的编码。
在需求分析之后,根据老师和助教的建议,我们更新了部分的UML类图。
-
什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在简历创建和投递功能产生的bug最多,主要是因为数据库对时间的数据类型,接口返回的时间的数据类型,安卓APP中所使用时间的数据类型,不同,导致频频出现类型转换等错误。
在答辩的时候,发现学生端获取的岗位信息中的标签和企业发布的岗位信息的标签有出入,原因是企业端和学生端所使用的的标签数据版本不一致,导致部分标签序号没有对应上。后面将统一从服务器获取最新的标签表,来解决这个问题。
-
代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
代码复审由审查者评审代码的格式、风格、命名是否符合规范。
因为我们的代码规范是根据阿里巴巴Java编写规范制定的,所以我们给idea装上阿里巴巴的规范plugin,进行检测。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了如何用测试工具辅助设计和实践。
如果历史重来一遍,我们会多应用自动化工具进行代码的测试和复审。
七、测试/发布
-
团队是否有一个测试计划?为什么没有?
有
-
是否进行了正式的验收测试?
有
-
团队是否有测试工具来帮助测试?
有。具体使用工具可在测试篇博客查看。
-
团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
开发时在Android Studio上进行了实时的性能监测,开发完成后也使用Jprofile对代码性能进行了测试,itest对手机安卓端应用进行了性能测试。
-
在发布的过程中发现了哪些意外问题?
发布最新版本后由于一个日期解析错误所以点击求职意向模块就闪退,后来加急抢修了。有惊无险。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
实时对模块进行测试和最终进行集成测试非常必要,可少走很多弯路。如果重来一遍会更早开始制定测试计划,提前开始进行测试工作。
八、团队的角色,管理,合作
-
团队的每个角色是如何确定的,是不是人尽其才?
这次团队分工主要是:
221600307 负责原型UI设计和测试
221600306 和 221600327 负责学生端APP开发
221600329 负责企业端APP开发
221600315 负责Java后端接口开发
221600319 负责Java后端算法设计
在分工的时候,充分考虑了团队成员每个人的优势,比如221600319喜欢爬虫,221600315热衷Java,221600306、221600329都有安卓开发经历,221600307有美工基础等等。
-
团队成员之间有互相帮助么?
有,因为部分成员对一些技术是新学习的,团队一些大佬会经常为他们解惑。特别的,我们有一个小组成员221600315,较熟悉github相关操作,出现github相关问题,他都会热心帮助,作为组长,我感觉现阶段我们团队的氛围良好~
-
当出现项目管理、合作方面的问题时,团队成员如何解决问题?
没有出现相关问题,如果出现,会开会集体讨论解决。
-
每个成员明确公开地表示对成员帮助的感谢 :
221600329 : 我感谢K哥对我的帮助,因为他是我们组的中流砥柱,一个人撑起了后端的一片天。
221600306:我感谢K哥对我的帮助,在写前后端交互的时候有不懂的地方都可以问他。然后Git版本控制自己不是很熟悉,对于有冲突的地方就很手足无措,都是K哥教的好,现在都可以自己解决冲突分支 了!
221600307:和其他队友一样,我也要感谢K哥对我的帮助,作为团队中名副其实的大佬,他在团队中起到了很大的作用,对我的帮助也不言而喻。另外就是我的室友小榕,我们俩经常在一起,遇到困难一 般都是问她,总能帮我解决问题。
221600315:和大家一样,我也要感谢K哥,感谢他给我的帮助,以及感谢各位团队成员齐心协力,才能完成本次作业,希望大家在β冲刺依旧能够齐心协力取得更好的成绩。
221600327: 首先还是感谢K哥,他教会了我很多,基本有自己解决不了的问题都会跟他探讨。还有就是感谢团队成员的一起努力和理解,团队氛围真的是很重要的东西,很幸运能跟这么棒的同学在一个团队。
221600319: 我感谢k哥对我的帮助,github之前几乎没有用过,这一次开始用的时候
九、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
输入可重复级(Repeatable)档次。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合-->规范
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队成员间可以更好的配合和协作。
十、讨论的照片
十一、队员交换情况
任务交接
- 此前我(221600307)在组内负责的工作是客户端UI设计和测试,原计划是β阶段优化界面,在队员搭建的界面结构的基础上尽量还原UI原型,使页面更加美观,并继续完成测试工作。因此对于新队员的学习建议是:
- 学习简单的测试和Android开发,对Android界面编写尽量熟悉,并仔细查看之前的文档和原型。
- 组内很多同学对于Android开发很熟悉,由于不清楚新成员对Android的掌握程度,所以希望比较擅长的同学能带着新成员一起学习。
培养计划
- 原成员是UI设计和测试人员,所以我们对新成员制订了下面的学习计划。
- 学习基本的安卓六大布局。
- 带领新成员阅读文档、编码规范和原型设计。
- 让新成员了解接下来的Beta阶段的功能需求,使其加快融入小组
- 原成员带领新成员学习简单的测试,使其能够做好原成员的测试工作。