Android海尔项目养成

写在2016/3/20小组讨论前

今天是第三次小组讨论，有了昨天的经验后我今天提醒了大家9点半要到，而且提前说了下要求。不知道到时候大家能不能有积极性。

想想不足吧：

1. 之前安排任务的时候应该具体要求做到什么程度，比如做一个功能demo或者是直接整合到程序里面，要求的越具体目的也就越明确。我担心这一次大家都直接写了一个demo然后大家发现还需要时间整合到项目里面，然后又要花一段时间，这样就会导致大家一种拖得习惯。目表越明确，就越有目标，判别一个完成度也就越清楚。
2. 还记得上一次说，激励，适当的鼓励和批评，做的好的就鼓励，做的不好的就批评。应该给大家一个映像你做的什么我都是清楚的，所以你不要想蒙混过关。然后就是希望大家积极性不会不高吧，我会让大家看到我们项目的进程。这样可以激励大家

等讨论完毕后再看吧！！！组合大家一起工作真的不是意见容易的事，而且我们还没有保证项目质量，仅仅是保证了项目能进行，我会考虑项目质量怎么保证的

开完会后总结下吧：

先说下问题

1. 这次过然不出我所料大家都写了个demo，然后没有合到项目里面。不过也好，大家都说自己完成了，明天我猜可能会暴露许多问题，譬如发现接口用不了，或者是自己的模块会有bug，或者更甚者是没有做完，如果没有做完我觉得应该适当的说下（批评下）
2. 这个时候暴露了一个什么问题就是项目没有接口文档，我问下他们怎么做他们其实都不知道该怎么做，幸好就是我们是一个小团队对这些还是挺好处理的，大家都在一起。我也就提议明天项目整合的时候可以问问，大家也都说好。如果是大项目的话那就不行了，所以呢下次如果还有项目的话，1）我会要求大家写个大概的需求文档，当然我们这些是自己开发的可能不会和软件工程要求的复杂，时间可以简短点，但是要写，而且初步软件功能的框架要有一个。如果后期大家讨论出什么功能也可以加。2）需要有设计程序的大概的框架，如后台啊什么的，这个我也比较薄弱，不知道该怎么设计，到时候学吧。还有呢这一步要做的就是命名规范，先把功能命名的规范大致定下来，如果有问题的话可以再改。3）接口文档，这个毋庸置疑吧，一定要写，最低的要求是别人看了你的文档大概就可以知道应该怎么写了。
3. 其实有一点好处就是我以为大家都积极性可能不高，其实还行吧，大家积极性不会很低，你要相信大家那样才能做出好成绩。

项目做到这时候给我的感触是：

1. 幸好我们是一个小团队啊，什么的大家沟通不需要任何成本。接口文档这种东西都不需要可以，团队就4个人，你要怎么实现问问我就行了，我不懂问问你。真是好啊，不过这种都是玄幻的，只是乐一乐，如果在大项目感觉沟通成本肯定会提高，那个时候这些步骤真的是缺一不可啊。
2. 我现在是对所有的技术都有一点了解，他们做的方面，大概可以想到怎么做。但是如果要我负责一个我没有一点经验的项目，当你面对一个没有一点了解的项目时候我应该怎么做，应该有一个即使你不具有项目经验也可以带动这个项目的步骤。好吧，就是这些，我会慢慢成长的。good good study day day up