事后诸葛亮

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阶段能有所改善吧。

　　　　顺带吐槽。有一个规划好的流程&确定好的任务需求。是真的很重要啊。

以上