项目管理大法归档 - 思维导图、原型工具、接口测试、设计模式、版本管理、单元测试、持续集成、代码审查、Bug 跟踪
项目管理大法归档 - 思维导图、原型工具、接口测试、设计模式、版本管理、单元测试、持续集成、代码审查、Bug 跟踪
太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
转载请保留此句：太阳火神的美丽人生 - 本博客专注于 敏捷开发及移动和物联设备研究：iOS、Android、Html5、Arduino、pcDuino，否则，出自本博客的文章拒绝转载或再转载，谢谢合作。
项目管理大法归档：
1、思维导图
如果你在想事情，而又不那么清晰明确，那么就用思维导图吧，它可以随着你的思维，很自然地记忆你思维的过程。
其实使用思维导图，并不需要很刻意地构建成什么样，相反，它就是记录，整体展示给你一个你自已灵乱思维的有序组合。
另一方面，思维导图应该像笔记一样，记录于平时，最终自动整理出的图反应了一段时间内你的思维过程。
与上面的使用方式正好互补。而我们更多是现想问题，现记录，以便思维能基于现在能继续进行下去，这中间选词描述可能成为困难，随便记些什么表达就好了。
2、原型工具
选择一种存在形式，也即鬼上身，或附体。
其实思维永远要基于躯体去承载和执行，那么思维导图整理出的东西，必定要选择一种方式去表达出来。
3、接口测试
借助外物，那么就得先了解外物，确定哪些可用，哪些不可用，以便计划路线。
而接口的定义分三种情况：一种是双方协商、一种是客户端定义（此时业务逻辑重心压在客户端，小型项目）、第三种是服务端定义，当然也需要客户端充分对需求和整体架构提出意见。
总之，脱离任何一方而制定出来的接口协议，必定是不完善的，只能是概要设计的一部分，在使用过程中，都会进行一定量的修改与完善，形成详细设计。
是先行分析制定详细设计方案，还是边走边看，边做边制定，这就看实际的人员能力和项目的需要了。
4、设计模式
把上面的东西组合起来，进行路线计划吧。
23 种设计模式，其实只要理解了类的继承、多态、复合、封装，并能灵活地从继承角度和派生角度去看这一体系结构，那么 23 种设计模式就不难理解了，
而且每种设计模式真正是为了解决一类问题而出现的，着重理解解决了什么问题要比记录写法更容易掌握和灵活运用。
"独孤九剑的最高境界是不拿剑"，设计模式运用的最高境界可能就是不受设计模式本身的限制，随时根据自已的情况去运用对象的性特组合。
5、版本管理
其实版本管理系统应该在更早阶段就应该在配置管理部分完成布署，这是 CMMI 的流程，它不光肩负着代码的版本管理，还有文档，更有一些文档工具是支持版本比较的。
之所以放到这里提到，主要是针对后两者，就代码而言。
或者现在的孩子们做开发，已经没有这样的习惯了，但我想那是一种应对现时环境的自我保护心态，相比之下，感觉现在的孩子的随性、无所谓等等心态更适合生存，反而是我们这些红旗下长大的一辈人，过重的责任心和约束自制，反而很容易被时下的环境所累，轻而易举地被 Cancer 击败。
回归正题，设计模式部分完成了整个工程的架构设计和框架搭建，那么接下来就是各个功能模块的编码实现，每完成一块儿，就要进行单元测试确保自已所实现的这一部分代码是完整、可用的，再提交到开发版本库中，
首先达到了最基本的代码安全备份的作用;
二是代码共享给团队其它成员;
三是下一阶段的开发基于此进行。
当然，这中间可能还会有开发到一半中途停止的情况，这个情况，当然是 Git 的本地版本库管理对代码进行版本控制才是较好的方案。而在团队中进行共享，无论是通过SVN还是 Git 服务器共享，都是可行的，相比较而言 Git 更靠谱。
当一个版本迭代所需要完成的所有单元模块都已经单元测试通过之后，进行集成测试，功能全部实现且健壮，再提交到审查代码库中，生成版本号，交由主管审查。
这里要说明的是，
一、集成测试并不只是在最后所有单元模块都完成时才进行，而是在每一个单元模块完成并集成到系统中（当然了，我们都是习惯直接在工程中去开发的，已经第一时间进行了集成）时，随时进行测试，测试的目标是这个单元路径上所关联的一切部分（因为你要到达此单元模块，必定要依赖其它模块的事务完成）。
二、代码审查针对单元测试进行才是最接地气的。代码审查库（Redmine所监管的版本库）的每一个接交版本，必须是开发版本库中进行了有 效单元测试并验证所开发单元模块功能可用，并且集成到项目中进行相关性测试也可用，不会引入新问题的情况下，才提交的。
相较笨重的 SVN，Git 的分布式版本管理特性和基于文件系统而非服务器的构建方式，更适合做代码管理和代码审核这样的二级版本管理所用。
当然使用本地 Git + SVN 的方案也是可行的，那么就要求开发者，不要轻易的有更改就提交到 SVN ，而是最终开发确认没有问题了再提交。
这中间存在一个本机宕机所带来的风险。这样考虑，提供开发版本服务器也是必要的，达到冗余备份的效果。
6、单元测试
无论是 Android 在 Eclipse 中使用 JUnit， 还是 iOS 在 XCode 中使用 OCUnit 或 XCTest，相比上面所讲述的单元测试方式，可能更有针对性。
在上面所述的单元测试过程中，其实已经有了持续集成的测试过程，也有了测试驱动的概念，因为测试用例虽没有写出来，但实际是按照预其去测试来分析实际单元模块存在的问题并进行改进的。
那么使用本节中的单元测试框架进协助进行测试，可以简化很多麻烦，对被测部分提供有效的预期前置。
但总体来讲，即使再好的单元测试框架，也是需要由开发者清醒的开发过程掌控来安排得当，才能充份发挥其效能，否则，单元测试框架就会变成不负责任的挡箭牌，而非懒人创造发明的助力。
7、持续集成
多余否，不多矣！
单元测试完成了，开发的功能模块功能实现了，可是加入项目中，一是加不进去，二是加进去配合不起来。
这开发的是神马东西呢？！可是一直有这种情况发生。因为没有责任心，而这个时代，就是个没有责任心的时代，就像“给员工发一个亿”实现不了，就可以当没说一样，这是这个时代的特征，而这种特征确保了他们能生存下来，因为这种心态让他们不那么焦虑，而我们这一代人过重的责任心确成为了我们的负担，甚至致命。不信，你看看现在的 Cancererer 们，有几个是能够拿得起、放得下、想得开、看得透、说做就做，做完可以不负责任的这类人？！确实没有的。那么 Cancer 时代的一个重要特征，就是新生代不再有那么大的压力给自已，他们天生就适应这个时代，当然责任。。。那是另一回事了，也是很重要的东西，关乎社会的进步。不过总体来讲，这一代人的心态，能保障生命的延续，难道我们也要像那些自称优等确要灭绝的人口负增长民族？！
所以包容、理解，才能更好地接近和混迹于这一代人中间，听得懂他们在说什么、看得懂他们在做什么，毕竟我们的余生是在他们维系的社会中度过，了解和理解很重要。
言归正传，之所有有持续集成，就是因为很多年的不持续集成！而不持续集成的原因是，机械化的开发，CMMI 应该是罪魁祸首。可是 CMMI 也没这样说啊，反问一下，引入国内的哪些技术是为了应用这门技术的，更多是如何用这门技术来管制的。这源于能动性，再深入不做探讨。
总之，持续集成本是不该出现的东西 ，因为开发就是个持续的过程，为什么会有不持续的事情发生呢？！
回归自然的开发，什么事情都没有了。
8、代码审查
Redmine 有一个一键安装包 Bitnami，可以快速构建代码审查系统。
它可以关联 SVN 或 Git 版本库，还可以关联邮件系统。
这部分有待进一步深入研究应用，后续补充体会。
9、Bug 跟踪
持续集成以完善的单元测试作保障，这是代码级的、功能级的，但绝不是业务级的、交互级的、用户体验级的。
而且在快速迭代的过程中，往往只考虑开发主线，而忽略了各种容错处理、安全校验。
我想，Bug 跟踪，应该是在不断的集成过程中和进行系统测试时，对发现问题的反馈，这是一种黑盒测试的结果跟踪，问题本身可能并不是问题的跟源。
而且这时所应该测出的不应该再有程序异常、崩溃等问题，而实际上是大大地存在的，这就要回归单元测试才能快速发现问题并解决。
而且有时一个问题，所牵扯的方面，并不指一个单元。
这就要求对 Bug 进行记录，并跟踪其整个解决过程。相比这种工厂式的生产过程，更容易出现 Bug，10 倍的人力投入，最终仅产生 5 倍的效果。
而把大任务进行模块化拆分，变成小系统，这样针对小系统的管理成本相对要低，沟通成本也低，回归人性，由人来保障软件的可用性，而非制度。
当然，制度可以规模化，但前提是你得把人先变成制度化的人，而且制度化的人，在离开岗位之后，其工作适应性很差，因为他是做重复性体力劳动的，不是脑力劳动。
Bug 跟踪，很有必要，清晰地了解 Bug 描述，针对地处理，并能在同一个地方反馈问题的解决过程和结果。至于其它的，感觉起不到什么作用，过份的管理，只能
让敷衍成为一种风气。
相比之下，人是有能动性的，充分激励和发挥人的能动性，再配以这些工具管理，才能如虎添翼。
管理，永远都是为了清晰、明了、有序，而非为了管理而实施任何手段，除了激励和发挥人的能动性之外。