结合工具来实现敏捷开发 - 6

从软件工程的角度来说，一个软件的开发必然需要从需求分析到编码到测试再到交付，虽然我们现在说的是敏捷，但是本质上以上那些步骤还是省不了的，从狭义敏捷上来说，它比较看重的是人与人之间的交流，所以对文档之类的东西不是很在意，但是说是这么说了，真正你做起来的时候，缺了文档管理，实在不敢想象后果，比如说这个功能本来是这个人设计的，后来他离职了，没有留下任何文档，轻轻地，我走了，不带走一片文档，其实，是没文档可带走。然后以后的人想修个Bug或者修改一些点，都无从下手的。所以，对于一个企业的敏捷开发，我们现在选择的是广义的敏捷开发方式，也就是一个遵守软件工程基本规律的敏捷开发。

所以，接下来说怎么用DevSuite解决方案来实施敏捷开发，我也会按照软件开发的步骤来一步一步说明。

首先当然是需求分析了，即使再敏捷这一步是省不了的，不然都不知道要开发什么产品了。DevSuite方案提供了一个工具叫做DevSpec来实现这一步。这个工具主要作用其实也是很简单，就是管理需求，一般需求无非就是几个来源，一个是客户的想法，一个是竞争产品有的功能（当然是我们没有的），还有就是公司自己想出来的功能。这些需求点来源很多很杂，然后描述又不可能都是很清晰的，所以需要进行很好的梳理、归纳总结。

在DevSpec里，每个功能都是以一个任务条目的方式来管理的，也就是说你要加入新的需求，就是新建一个任务，任务会有很多属性构成，主要就是标题、描述、状态和负责人，当然另外还有字段可以用，你也可以自定义N个字段和N个页面供你所需，这些配置起来都很简单。

上面说到需求点描述不是很清晰，所以需要梳理、归纳总结后才能被真正使用，DevSpec所用的办法就是设置工作流、状态和负责人。所谓的工作流就是说一个任务从开始到结束会经历一系列流程，比如需求任务一般会从新建-->设计中-->审核中-->可以开发，这4个过程就被称为4个状态，状态之间的顺序是可以自定义的，状态数量也可以增减的，所以如果你们公司的流程很简单的话，可以就只弄2个状态，一个叫做进行中，一个叫做完成，直接就是进行中-->完成。然后，每个状态都有一个主要负责人，负责当前需求任务在该状态下的工作，而当你完成该状态下的任务工作以后，你是不一定有权限把任务状态更改到下一个状态的，因为DevSpec对于更改状态也会设置不同的权限，可以是由另外的人审核后觉得合格才改变状态到下一个状态。这样做就可以防止你根本没做什么事情或者该做好的事情没有做好做正确就把这个任务打到下一个状态了，从而影响整个任务的进程。（当然DevSpec的日志功能也保证了即使出了这种问题后，事后也能追查到是谁犯的错）

所以一个需求任务在经过几个状态几个人的处理后，会从一个很大概的很粗略的轮廓，变成了一个开发和测试能够看得懂的功能点，从而就可以进入开发环节了。

（由于保密要求，我们自己公司的数据不能让大家看到，所以就从他们的培训材料中截了DevSpec的图供参考，这个是胖客户端的截图，一般我们公司主要用浏览器方式打开的客户端，也就是所谓的瘦客户端。）