原问题博客地址：http://www.cnblogs.com/R-81/p/5873996.html
ASK：
Bug的定义根据开发者与使用者的分析角度不同，有着很大的区别，如何使开发者能够有效的感受使用者的角度，使软件更具人性化？
ANSEWR：
其实在团队项目和试用必应词典作业实践考察中，我逐渐觉得开发者几乎是不可能预知到使用者角度所认同的bug，开发者眼中的
bug是指对代码负责，代码的正确性要有保证，代码的安全性和稳定性上不会出现问题，经过单元测试、白盒测试都不会出现问题，那么
开发者就会认为自己的程序上已经没有bug了，而且就像尹宝林老师说的一样，程序员是“自负”的，出现任何问题第一时间也不会认为是
自己的程序有问题，至于使用者角度的bug，就更难发觉到了。所以我认为，使开发者有效感受使用者的角度这个工作，并不是开发者的
任务，而是测试人员的工作，负责测试的人需要选取没有参加过开发，对于程序内部实现了解的越少越好的人来进行使用测试，依据其使
用后的感受，反馈给开发人员进行程序上的修正，这个过程并不是开发人员甩锅，把工作丢出去，而是类似于旁观者清的理论将工作分离
开，得到不会被自己认知蒙蔽的想法和感受。
ASK：
面对代码量比较大的工程，如何做到有效的管理和控制？
ANSWER：
我觉得通过整个团队项目的过程，这个我问题我已经有了深刻的认识。首先团队需要一个专门的项目经理来负责整个项目进度的规划
和任务的分配，在项目的最开始需要把整个项目的工作量进行一个列表，把任务划分成一个一个小块，分配到每个人身上，根据项目的截
止日期规划时间安排，留出一定的时间富裕来应对特殊情况。在项目进行中，每个人要分工明确，将功能划分到各个模块，每天每个人完
成任务后需要进行一定的反馈工作，比如上交到git上，和项目经理也要有一定的通知反馈，报告完成进度，如果没有完成，需要说明问题
出在了哪里，调用一些富余时间迅速解决掉。总之就是有专门的管理进度的人，其他人根据分配到的任务完成自己的工作并且及时反馈。
ASK：
在开发流程中，如何从“写了再改的模式”的模式中脱离出来？
ANSWER：
这个就像大泥球里面说的差不多，首先开始的时候需要进行一定的设计，在代码实现阶段根据之前的计划逐步完成，在代码实现的过
程中难免会遇到突发情况，需要加入一些修改修正来弥补之前没有预料到的问题，问题在于这样的行为是有增无减还是有所修正，如果是有
增无减，那么就是无限的重复写了再改的过程，最终还是落得大泥球的效果。所以除了需要最开始的设计，在实现过程中还要尽量避免一次
性代码的出现。
ASK：
在构建软件工程的过程中，从何时开始考虑用户体验的问题？
ANSEWR：
用户体验这块可能在项目的前期就需要考虑，原因有二，其一用户体验是前端比较关注的问题，因为前端界面用户体验不好的问题导致
的用户流失，这部分的流失掉的用户很难再争取回来，而且非常可惜；其二，用户体验的优劣有时候也会影响到后端功能的实现，有些功能
可能后端认为是一个很有意义的功能，花费了大量的时间精力去完成，但是发现用户体验并不够好，这样的话这部分的投入就是一种浪费，
如果将这些所花费的时间用于用户体验良好的功能，可能会有更好的效果。
其他问的问题：
问题（1）（3）问的好像有点偏，对于当初自己问什么问出这样的问题感觉不可思议。
新的问题：
项目中难免会遇到突发情况，那么预留出多少比例的时间比较合适？10%左右？
因为在我们的项目中就发生了完全没有想到的突发问题，在解决的时候花了很多时间，导致进度有一段时间的卡顿，我们也预留出了一些时间
面对可能出现的问题，我想知道在实际工程化项目中，一般都是预留多少的时间呢？
项目经理如何在完成自己本职任务的情况下保持和队友间的友好关系？
这一点我觉得真的是挺想知道的，虽然看起来有点搞笑，但是在项目实现的阶段，我真的好怕项目经理啊，每次要是项目经理找我我交不出来
东西都觉得特别尴尬，项目经理也挺辛苦的，又完成自己的任务又要管理整个团队，但我还是好怕他……
知识点总结：
1、需求阶段：
在项目开始之前要做好用户需求的调查，统计分析用户需求，根据结果分配各个功能在实现上的重要程度。
2、设计阶段：
充分考虑需求分析，设计应该先于动手实现，好的设计可以节约之后的实践，草率的设计可能会使实现阶段发现更多的问题。设计从整
体到局部，从结构到细节，确定每个人负责部分。
3、实现阶段：
减少新技术的使用，每一项新技术的使用都有可能引发新的问题，这也可能会占用更多的时间。按照设计文档构建代码，出现新的问题
之后，有影响到其他人的改动需要及时通知队友。
4、测试阶段：
每完成一个部分，就对这个部分函数进行单元测试，这样可以快速的定位问题出现的位置，不要等到把所有的代码都完成之后，再来测试，这
样需要这股排除问题出现的位置。
5、发布阶段：
发布的版本应该是最稳定的版本，开发者需要告诉团队各自的bug有什么、可能的危害是什么、是否能够修复，选取最稳定的版本，之后
的功能添加和优化可以在后续补上。
6、维护阶段：
发布并不是项目的终结，维护是一个团队对于项目负责的表现，维护阶段应该保证项目的正常运行，出现问题和故障应该定期进行修复和
纠正。