简时——alpha阶段问题总结随笔
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
简时——alpha阶段问题总结随笔
这个作业属于哪个课程
这个作业要求在哪⾥
团队名称TimeMaster
这个作业的⽬标描述项⽬进展状况
作业正⽂
其他参考⽂献……
⼀、设想和⽬标
1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型⽤户和典型场景有清晰的描述?
设想解决⾃制⼒⽐较弱需要借助该软件进⾏专注处理事务的问题;定义清楚;有清晰描述。
2.我们达到⽬标了么(原计划的功能做到了⼏个?按照原计划交付时间交付了么?)
达到专注使⽤⽬标,但是原计划的附属团队以及宠物并未很好实现。
3.有什么经验教训? 如果历史重来⼀遍,我们会做什么改进?
时间上出现紧迫;对进度安排更加合理,对代码架构更加层次分明,对任务分⼯更加合理,对具体的代码编写有⼀个更清晰的认识。
⼆、计划
1.alpha 阶段是否每天有充⾜的时间来做规划安排?
⽤于规划安排的时间还是⽐较⾜够的。
2.团队在 alpha 阶段是如何解决队友对于计划的不同意见的?
我们会在每天的会议上讨论下⼀天的计划安排,如果出现了不同意见,我们会进⾏讨论,决定出⼀个⼤家都满意的计划,如果⽆法达成⼀致,会根据不同的计划进⾏投票,少数服从多数。
3.你们原计划的⼯作是否最后都做完了? 如果有没做完的,为什么?
基本都完成了,但是还是有部分没有解决;因为⼀些技术上的问题短时间内不知道怎么去解决,只能先放⼀边。
4.有没有发现你们做了⼀些事后看来没必要或没多⼤价值的事?
编写代码时提前写下很⼤⽆⽤的接⼝。
5.是否每⼀项任务都有清楚定义和衡量的交付件?
基本清楚。
6.是否项⽬的整个过程都按照计划进⾏,项⽬出了什么意外?有什么风险是当时没有估计到的?为什么没有估计到?
⼤体按照计划进⾏,但是可能任务是并⾏的,计划是串⾏的,整体进度基本⼀致。
7. 在计划中有没有留下缓冲时间(加班),缓冲时间有作⽤么?
有预留了缓冲时间;作⽤就是最后阶段我们可以更从容得解决⼀些突如起来的bug,不会⼿忙脚乱。
8. 我们学到了什么? 如果重来⼀遍, 我们会做什么改进?
对于项⽬要有整体的计划和进度安排得当,避免出现项⽬⽆法按时交付,同时管理团队要积极活跃,多多交流;加强团队之间的交流,问题都是可以合作解决的。
9.beta 阶段安排概览
继续完成之前的任务,然后完成的组员可以进⾏增加任务的编码
三、资源
1.有⾜够的资源(可以是时间、开发资源等)来完成各项任务么?
开发资源⽐较⾜够,时间稍微有点紧凑。
2.各项任务所需的时间和其他资源是如何估计的,精度如何?
根据⾃⼰以往的经验来判断代码量的多少以及⼀些类似项⽬的经验进⾏所需的时间和其他资源的估计的。
3.测试的时间,⼈⼒和软件/硬件资源是否⾜够? 对于那些不需要编程的资源 (美⼯设计/⽂案)是否低估难度?
测试的时间,⼈⼒和软件/硬件资源相对⽐较⾜够;对于美⼯设计低估了⼀定的难度,因为发现⼀个好看的页⾯不是那么容易设计的。
4.有没有感到某个成员做的事情可以让别⼈来做(更有效率)?
的确存在分配上的不合理。
5.有什么经验教训? 如果历史重来⼀遍, 你们会做什么改进?
要提前学习项⽬使⽤的⼯具和资源,避免冲刺阶段的时间浪费导致紧迫;在开始冲刺前先进⾏所要⽤到的⼯具的学习。
四、设计/实现
1.设计⼯作在什么时候,由谁来完成的?是合适的时间,合适的⼈么?
由从前⾯的⼏次作业完成,⼤家讨论根据功能完成;是。
2.设计⼯作有没有碰到模棱两可的情况,团队是如何解决的?
出现过分配任务表达不清,但是有在后续汇报中点明。
3.团队是否运⽤单元测试(unit test),测试驱动的开发(TDD)、 UML, 或者其他⼯具来帮助设计和实现?这些⼯具有效么?⽐较项⽬开始的 UML ⽂档和现在的状态有什么区别?这些区别如何产⽣的?是否要更新 UML ⽂档?
应⽤了IDEA的JUnit;有效;根据答辩和⼩组讨论进⼀步完善UML。
4.什么功能产⽣的 Bug 最多,为什么我们在设计/开发的时候没有想到这些情况?
基本都有BUG,但是都有解决,出现BUG主要是代码编写上的问题,对框架的不熟练,在功能逻辑上BUG较少,出现的原因可能是前后端对功能的具体⽤法存在些许分歧。
5.代码复审(Code Review)是如何进⾏的,是否严格执⾏了代码规范?
通过⼩组会议,基本执⾏代码规范。
6.我们学到了什么? 如果历史重来⼀遍, 我们会做什么改进?
设计要达到正确有效,不要模棱两可,会存在很多问题,提前熟悉开发⼯具对实现很有必要;更加严谨的设计和熟练的使⽤开发框架。
五、测试/发布
1.团队是否有⼀个测试计划?
测试由编码⼈员⾃⾏进⾏测试。
2.团队是否有测试⼯具来帮助测试?
JUnit、postman
3.团队是如何测量并跟踪软件的效能的?从软件实际运⾏的结果来看,这些测试⼯作有⽤么?应该有哪些改进?
进⾏压⼒测试;有⽤;加强压⼒测试。
4.在发布的过程中发现了哪些意外问题?
存在缺陷功能以及不完全符合需求的功能。
5.我们学到了什么? 如果重来⼀遍, 我们会做什么改进?
测试是⼗分重要的,我们并没有专门的测试⼈员,每个⼈进⾏⾃我测试可能会出现盲区,所以测试需要进⼀步学习;加强测试,进⾏更多的测试。
六、团队的⾓⾊,管理,合作
1.团队的每个⾓⾊是如何确定的,是不是⼈尽其才?
任务分配前先进⾏前后端开发的分离,⾃⾏选择前后端开发,⽽后分配具体功能模块。
2.团队成员之间有互相帮助么?
有,会在会议上进⾏问题提出和解决。
3.当出现项⽬管理、合作⽅⾯的问题时,团队成员如何解决问题?
进⾏线上交流。
七、⾃我总结
1.组员们⾃我总结
陈俊延:在这次的冲刺中,我了解到了我在编码中的不⾜之处,因为我⽐较喜欢先按要解决的问题编写基础的代码,之后才会对问题的细节进⾏分析处理,这导致我的代码后期要经过多次的修改,浪费了宝贵的时间。
并且,我还知道了,我⾃⼰之前以为已经掌握的JavaEE还存在着⼤量我不理解的内容,如果没有百度的帮助,⼤多的问题我都解决不了,这坚定了我要认真学习的决⼼。
除此之外,我们组员之间的交流还是不够,很多代码写完后,才发现不达标,要重新写。
所以,在beta冲刺中,我认为要加强会议之下的交流。
⽽不是什么问题都在会议上提出,这样会加快问题解决的速度。
叶如茵:在进⾏团队alpha冲刺编码中,由于没有过安卓项⽬开发及前后端分离开发的经验,整个冲刺阶段需要学习的知识还是很多,由于⾃⼰的基础并不是很扎实,编程能⼒也不是很强,加上时间⽐较紧迫,整个过程还是有点难的,压⼒也很⼤。
但是通过慢慢边学边实践的过程让我学会了很多新的知识,也提⾼了⾃⼰的编程能⼒,对于遇到的困难和bug也更加从容应对,通过查找各种资料及论坛解决问题。
整个冲刺过程让我get了很多新的知识。
但是⽬前的界⾯做的还不够完善,希望在beta冲刺中能够更加优化。
陈伟杰:是我第⼀次进⾏冲刺项⽬团队合作编码,以前没参加过类似的编码活动,收获还是很多。
⾸先对于这次冲刺,⽆疑是⼀次⾮常好的机会进⾏项⽬开发体验,我很开⼼可以直接就结合本学期学习的spring配合开发,这是两开花,锻炼了项⽬后端开发同时进⾏j2e的实践帮助很⼤;其次是冲刺是线上进⾏的,往后肯定会遇到这种情况的,线下合作的实践很多⽽线上却很少,感觉⼤赚⼀笔,毕竟越来越往⽹络合作发展了;然后就是我学会基本的使⽤了很多新的⼯具,例如postman、redis数据库、ngrok等,这是⼀个不错的体验,了解了如何进⾏后端控制层的测试和本地服务器转外⽹的操作;最后是在冲刺中体验了类似⼯作的感觉,每天都有⽬标和回忆,这是极好的,当然在前⾯的收获中也有困难,⾃⼰的专业知识仍旧很匮乏,需要再不断的学习,为了开⼼打代码,还是需要更加努⼒,团队合作也需要更加紧密⼀些在这种隔着屏幕的情况下,所以还是希望在beta可以带着饱满的热情对待。
许俊鑫:这是我第⼀次进⾏团队合作编程,过程中因为⾃⼰⼀个⼈独来独往久了,和队友的沟通较少,还是得加强沟通。
还有就是对于Java EE技术的知识掌握不够多扎实。
林⽻希:安卓端,接下来有待实现和优化的部分还有很多:待办部分,没有完成不同状态下不同颜⾊的设定;数据统计部分,统计的点较少;⽩名单还没有实现;锁屏部分疑似出现bug,alpha冲刺的时候没有注意到。
还有就是在和服务器进⾏连接的时候,时快时慢。
⼀开始的时候脑⼦⾥设想过很多效果,但由于⽔平有限,不能完全实现。
做到后⾯的时候,会觉得之前的⼀些设计很鸡肋,不太想去实现,例如积分,不过⼤概已经砍掉了。
总得来说,是很神奇的经历,在短时间内学习⼀门技术并应⽤在团队项⽬中。
感觉⾝边学过安卓的⼈很少,如何真正的做⼀个app也是摸着⽯头过河,也挺担⼼⾃⼰做的架构到后期会不会⾃我冲突,不过就⽬前来看⽐预计的顺利。
⾼⾬欣:这次团队作业没能真正参加前端部分,感到⾮常遗憾,错过了⼀次团队合作的体验,以及经验。
即便如此,接触新的编程知识还是很充实。
这⼀次的⼯作量还是相当⼤,整理起来并不简单,计划表上的每⼀个完成背后都是复杂的编码,还有遇到的困难。
希望下次可以调整好状态,冲冲冲!
⼋、在 Beta 冲刺提⾼软件⼯程的质量
1.代码管理的质量具体应该如何提⾼?代码复审和代码规范的质量应该如何提⾼?
按照前后端分为两⼩组,由组长进⾏审查。
代码复查是有代价的,甚⾄有时是巨⼤的,因此代码复查不宜频繁,最好⼀份代码只审查⼀次。
同时,代码复查者应当对所审查的代码负有责任,即能够⼤胆地审查并指出被审查者的问题,并要求被审查者限期整改。
毫⽆疑问,项⽬开发⼩组的组长来担当此责任是最合适的。
组长可以有效地审查和管理⼩组成员。
通过以上的组织形式,代码复查可以简便有效地在项⽬组中开展起来,从⽽从管理上有效地提⾼软件开发的代码质量。
2.其它软件⼯具的应⽤,应该如何提⾼?
提前学习使⽤,由组长提前带头使⽤,然后交予组员。
3.项⽬⽂档的质量如何提⾼?
严格按照规范模板编写,切合实际的记录每⼀个要点
4.对于⼈的领导和管理,有什么具体可以改进的地⽅?
加强团队沟通交流。
5.什么是在下个阶段要改进的地⽅?越具体越好
1. 完善功能,将上⼀个阶段没有做好的功能进⼀步完善改进,例如团队宠物待办使⽤逻辑和完成判定等
2. 补充还没有完成的功能,例如找回密码,专注成就等
3. 优化前端界⾯,使得更加美观,交互更⼈性化
4. 完善前后端对接,例如团队的前后端对接
5. 加强进⼀步测试
6. 优化代码结构。