事后诸葛亮
Posted wengchenhua
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了事后诸葛亮相关的知识,希望对你有一定的参考价值。
alpha阶段的问题总结
1.项目没有做出合理的规划,需求跟实现工具这些也没有很好的确定。
这个问题我大概是要背锅的。本身项目选的就是功能偏复杂数据交互量比较多的(我只是想写需求偷点懒的QAQ没想到后面这么惨……),然后后面的东西都是想到啥都做啥。然后发现做不出又要改。导致后面整个项目的需求都没有确定下来。显得十分混乱。
没有规划也导致之后分工完全没法划分。然后工作量基本上只能集中在几个人头上……(头都是大的)
2.团队整体比较懒散,没有很好的凝结到一起
好吧,我确实不是很会当组长,只是习惯拿到任务就开做,完事交完任务收工。组织团队这点确实没做到实处。
然后本身成员的分布就很散(还有很多是学长),大家都是水水一波然后就没然后了。组织起来相对别人也要麻烦很多。
没有明确分工。组在一起也不知道要干啥……
3.成员任务进度完成效率跟质量不高。
日常偷懒。没有上课就不想写代码。然后快要交了临时赶,基本上来说这个都没法有高质量的产品吧……emmmm
还有就是分工不明确,导致全组任务只有少数人做。无形之中也加大了干活成员的任务量。
需求跟语言的不断变更,导致很多次进度都要推倒重来。浪费了很多时间。更难以抽出时间把质量提高(都用来重刷进度了……)
在beta阶段需要做出的改进
1.需求任务确定清楚,并做好分工。
这个在alpha阶段是吃了大亏的。需求任务没有确定导致了整个做的时候都不知道要做哪里,找资料学习的时候也不知道从哪下手。分工不明确直接导致做事的就3个人。剩下一般全是找不到人。
2.加强团队内部的交流。提升团队凝聚力
前面alpha阶段我们基本上没有团队交流(突然羡慕别的组日常站离会议)。beta阶段可能要试着多组织几次团队交流了。面谈的效果确实也比群里交流的好(毕竟群里找不到人啊根本……)
3.提升下任务完成效率
emmmmmm,这个问题就比较头疼了。毕竟懒。感觉很多任务都是能拖就拖,拖一天是一天。然后到块结束的时候。哦豁突然翻车。拖延症的问题还是要即使改掉。想到了就得赶紧做。这样才能更快更好的开发。
然后还有一个就是……开发前一定要把流程功能还有数据走向之类的东西弄清楚。这个在alpha阶段我也是吃了大亏的。最开始就想着赶紧开发出来一个功能点。结果什么都没搞得清楚就想着赶紧做。然后各种简单到爆的地方一卡就是好几天,还完全不知道问题出在哪。因为这事也没少麻烦大佬。后来还是大佬带着我把流程整个的走了一边,然后自己又重新的把流程认真的理清楚了一次。这才差不多搞清楚要怎么弄(然后后面效率起飞。基本一天一个功能点就能落实出来。)。所以beta阶段还是要考虑先弄清楚问题的实质,然后弄清处理流程再动手比较好。毕竟磨刀不误砍柴工嘛。
团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
最开始的设定是大家都按照自己的能力去接。当然结果并不理想。划水的日常不冒泡。
再者就是大部分东西对于所有人来说都是新的。所以都是重头学。并没有什么经验。也不是很好分工
2. 团队成员之间有互相帮助么?
有一点吧。毕竟搞不定的时候会找靠谱学长一起聚一下把进度啥的理一下。然后确定一下下一步的进程安排(然后那天效率可能会突然加倍emmmmm)
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
基本上都是自己解决吧……搞不定的就直接删掉了……
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
感觉学到了挺多东西的。先不说因为各种转语言一轮下来起码新解除了4 5 门语言……跟着大佬走了一边js跟node.js建立服务器的流程。也算是自己能用框架建立起服务器了。还能进行数据交互(虽然说前端页面跟JS前端功能的交互问题还没有搞定……)。整个的流程走了一边。后来切到别的语言的时候看起来也不会一点头绪都没有了。切换起来相对还是轻松了很多。(哦还学会了MDN查文档+超好用的开发者工具(虽然还是不是很会用))。
如果重来一遍的话。最需要改进的感觉就是项目需求的确定。这个问题老师已经不是一次的指出了。虽然这跟我们组的情况有点关系。但是最主要的。还是我们从一开始就没想好要怎么做。想到啥都想往上加,后面觉得做不出又删。觉得哪里不合理又在改。整个需求就一直没有确定过。超级混乱。这个也无形之中给开发带来了极大的麻烦。(搞的后面都不知道哪些地方要开发,要开发点啥,找资料学习的时候也完全没有头绪。)然后还有整个语言框架的确定。这次的项目光语言框架这些我们就已经换了3次了。虽然都是说本着哪个好做的做的哪个。但是每一次切换就相当于我们之前的功劳全部白费(毕竟两个完全不同的语言……没法互通啊……)。导致后面进度一直都是卡死的。根本没法推进。这些问题在beta阶段必须彻底的落实出来。不然感觉也没办法开发下去了。
总结:
12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。
做得好的:
增量交付:产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。
这个只能说是我们能做到的。因为水准问题。所以我们尽量选择的都是直接一个一个模块开发。然后开发好。再做下一个模块。保证每一个都可以使用。
唔……其他的好像完全都没做到啊emmm
做的不好的:
§ 结对编程(Pair Programming)
这个基本上没有做到。感觉整个团队并没有很多见面交流的次数。基本上都是各自为阵。更不要说一起结对编程了。(而且本人也不是很喜欢组队……所以这点上本能也有点排斥吧。)
§ 每日站立会议(Daily Stand-upMeeting)
基本没做到。一个是大家都挺忙,没什么时间抽出来再聚一下来开会议。还有就是整个团队很散整个就是日常找不到人。而且本来我们也是分散在不同年级。交流很少。大概也只有交作业跟上课才有可能聚到一起。顺带我还挺懒的。日常也是选择自己在寝室敲代码研究项目开发。并没有想过要喊着大家去开个会议讨论一下进度(毕竟喊了也不一定找得到人eMmmmm)
总结:
感觉alpha阶段我们问题是真的很多……希望beta阶段能有所改善吧。
顺带吐槽。有一个规划好的流程&确定好的任务需求。是真的很重要啊。
以上
以上是关于事后诸葛亮的主要内容,如果未能解决你的问题,请参考以下文章