**
这是过程非常艰难，体验非常恐怖的一次项目过程。
**
原本预计是 5 天开发，5 天测试，实际是 10 天开发，5 天测试（还没有算上途中的一周多的加班，最晚加到第二天早上 4 点，期间还有 一天的周末加班），这个项目可谓是做的惊天地泣鬼神了，项目人员也都身心俱疲。为此，特记下此次惨痛教训，以备后用。
对于开发时间预估的不到位
就从时间预估上来看，由于几乎都是新人，互相之间也不是太了解，自己对项目的观感也不是很到位，导致预估的时间与实际自己进行开发的时间相差甚远，而且项目开发早中期，并没有识别到即将出现的风险，团队没有及时发现末期的潜在雷点竟然有如此之多。导致是最后一天才发现问题的严重性所在，但是已经无力回天。
分工的错误
没有很好的对自己有个定位，导致分工出现的很大的偏差，且不说任务均分，在任务的分配上没有考虑各自的技术栈，导致后期在实际上手之后发现难度（此处难度发现也是在极其后期的时间点发觉，没有提前识别），为此，在自己擅长的方面，建议做的迅速一些，而多把时间放在自己并不擅长的部分，如果自己将大部分的开发时间已经投入到自己所擅长的部分，到后面，就会使用极短的时间去处理自己并不擅长的事情，自然有很大的几率出现风险，对于自己，任务分工的时候不要盲目的接受任务，而是要考虑是否能够保时保质的完成，切勿接收超过自己能力范围以外的任务，即使有少部分任务超出自己的能力，需要在任务分配的时候就提出来自己觉得可能会出现的问题，让团队有准备，团队会根据情况来提供帮助或者是重新分配任务，不要想着接着任务去闷声发大财。
太过于乐观
在项目的开发过程中，对实际的问题以及处理表现的过于乐观，对于问题的具体处理过程没有一个很好的把控，导致实际的预估处理完成时间被一拖再拖。使用的是新的技术，还是那句老话好，凡事用最坏的打算。
问题处理方式错误
针对一个问题，太长时间没有解决，未能及时抛出，或者是转向其他问题，过于执着。遗留的问题，没有做一个记录，导致后面遗忘问题，埋下地雷。
对于一个问题，超过 30 分钟不能独立解决的，需要向团队人员求助。
对于求助无效的问题，需要做一个记录，然后转向其他问题，不要再继续花时间研究这一个问题。
解决其他同优先级的问题之后，再回头看看遗留问题列表，再进行一次问题处理
页面数据处理不合理
数据是双向绑定还是单向绑定未能整体的处理，部分是双向绑定，部分是单项绑定，需求分析的时候没有仔细了解业务，使用旧系统，遗留了很多在什么什么条件下可操作，什么条件下不可操作类的问题，也致使后期需要进行页面上数据绑定的清理。对此
1. 编码前一定要仔细研究老系统、老业务文档、老代码，从中尽可能多的挖掘出业务上的内容，
2. 新系统的表现一定要与老系统一致，新旧系统对比检查效果，以免漏掉逻辑
3. 对于页面数据绑定方式，如果不了解，一定使用双向绑定，无法操作的再进行禁用，避免后期清理的麻烦。
4. 做一个小功能就要保证一个小功能 work，不要做到一半就转战，然后没有任何问题记录，以后就忘掉，再后期才能发现这类问题。
开发过程不严谨
在整个开发过程中，埋下过多问题，未能及时抛出开发中的问题，对于功能性问题与 UI 问题区分不到位，导致后期残留的 功能问题过多，单模块的测试无法进行（致使开发一度吃掉测试的时间，项目的整体时间更加滞后）
代码书写不规范
代码书写的不规范，导致后期介入开发的过程十分痛苦，三个人改同一套代码的时候尤为明显，会浪费很多时间去处理代码上未能理解的东西，此处我认为，
1. 不需要现在就写出很漂亮很符合规范的代码，但是至少在变量命名，方法命名，接口命名等 命名上面尽量做到业务相关，不要出现诸如定义一个 kendo 的 GridView 对象，不要使用 dataview，dataview2 这种命名，这种命名在一段时间之后自己都看不懂.
2. 注释是个好东西，代码尽量写出该写的注释，无论是针对此处代码的，还是针对逻辑的，都应该写上，以便看你代码的人快速理解你当时的思路，能够更加迅速的做出调整。而不是简单的把代码写出来，这样的话交流成本太大，会导致介入效果极差。
3. 代码结构，不要写的天马行空，正如那句话，功能谁都能实现，关键是看实现的好坏，代码结构上的混乱会让阅读代码的人十分痛苦，很容易被饶进去不能理解代码。
介入的过程不正式
在准备介入的时候，没有充分的分析余下的工作量以及问题点（只是口头询问，没有让需要介入的人做出一个问题点整理），导致发现 bug 一直不减，就只有加班，人就越发的疲劳，陷入恶性循环中。介入之后也没有对问题模块进行仔细划分，而是人人拿着就开始做，初期介入甚至还没有互相交流各自正在修改什么，后面发现，修改的时候通过 oc 让大家知晓自己正在处理的问题，也没有做太具体的分工，导致介入整体效果不是很好。
Git 的不熟悉
在此次开发过程中，问题经常能够发生，就是由于 merge 代码的时候所导致的，或者是自己所做的部分代码丢失，或者是删除掉了别人远端的修改，致使做了过多的重复操作。
1. 为此应该进行一次 git 培训，提高基本的 git 操作技能，以及 merge 的时候应该进行的处理方式。
2. 目前暂时先沿用 Jovi 提供的方式，本地两套代码，一套用于开发，一套用于同步，通过 bc 来进行对比 merge ，降低代码丢失率。
3. 其次在 merge 的时候如果遇到和自己修改有出入或者自己不确定使用哪部分，应该叫上对应的开发一起进行 merge 操作，以防自己误删别人代码。
4. 养成良好习惯，每天下班前提交一次merge 后的可运行的完整代码（何为完整？即当前的代码是能够完成某些任务的，而不是某些地方代码只写了一半就提交），在上班开始 coding 之前一定要 pull 最新的代码下来再继续 coding工作。
项目风险处理不到位
没有预估到项目可能的风险，项目出现风险之后的焦虑不冷静，致使整个团队的工作状态都十分低下。
1. 正如一个爸爸的盆友告诉我，作为一个男人，应该有自己应有的担当，别人慌了你不能慌，及时你心里也慌，必须在短期内调整。也不能让别人知道你慌。
2. 问题已经发生，慌张没有任何益处，冷静下来思考问题如何解决才是出路，抱怨除了抱怨什么都带不来。
3. 好好整理现在项目的状况，整理出余下需要的工作量，以及重新再把余下的问题进行分工处理。
4. 详细制定细小的目标，每天三个时间点应该达到的成果。
5. 团队 oc 随时交流问题处理状况，隔一段时间询问问题处理进度。
6. 不光有制定力，还需要执行力，在指定的时间点内，必须要完成指定任务，达到预期目标（因此对于计划的制定与计划的实行都要有很高的要求，计划必须要制定的是可达到的目标，执行必须要全心全力）。
7. 对于处理缓慢的问题，主动提出切换问题处理，自己无法暂时无法处理，需要及时抛出