[分享]“自邮之翼”项目过程

前言

去年11月，在导师的建议下，自己基于对互联网产品/项目过程的理解和实验室参与项目的经历，以图示的方式简单完成了针对实验室团队情况的项目过程，命名之为“自邮之翼”项目过程。（自邮之翼原本是实验室内部项目的名称，后来亦渐渐成为团队的代号了）。

为什么要提出一个规范的项目过程？

首先，从实验室团队的特色出发，我们需要一个过程去提高项目的可控可管性，同时让我们适应互联网的步骤。团队成员，除了老师便是学生，基本在实验室工作1.5-2.5年（保研的多大四那一年），人员变更快；先前没规范过程的时候，项目的管控过分依赖于人，而由于人员变更快，管控的质量是很不稳定的，都是各人实验性地尝试，也没留下什么积累。同时，我所在的团队更多去做互联网相关的项目，在这方面经验少，亦需要一个过程帮助我们去理解互联网项目的过程，如迎合快速迭代，快速原型等特点。所以，希望能有总结出一个过程，帮助我们团队理解互联网过程，弥补成员变更快速等团队特点带来的影响，同时综合两方面特点提高项目的效率和速度。

其次，从学生自身的培养看，对项目过程有一个清晰全面的理解和把握有利于个人综合素质的提高。从项目中锻炼技术能力固然重要，但这个主要是靠自己的；除此之外或者说项目经历给我们更宝贵的财富应该是对项目过程的理解和把握。如果参与了不少项目，但还不知道项目从开始到交付甚至运维/迭代是如何一个完整的过程，可以说，从项目经历而来的收获是会大打折扣的。而且，在学生团队中，我们真的有机会去负责一个项目过程的管控工作，同时有机会犯错！我们提出一个过程，不是基于空想，亦不会提出后停留在理论阶段不进行实践，我们是真真正正去以之实践，过程会基于实践有反馈，会更新，会积累，会传承的

再次，还有许多小好处，比如带新人容易了，更方便交接项目了，等等。

过程简介

“自邮之翼”项目过程，是针对5-15人团队规模和偏向互联网应用/产品的，重视快速原型和迭代反馈的敏捷过程。（注：团队规模讲是的现实中我们的项目组团队规模，但从过程图看，并未体现团队规模）

概要图（只描述阶段和阶段的重要事件）和总图（细化，体现角色的职责和协作，等）如下：

（注：版本1.1，更新于2012.2.15）

简单过程其中的几个要点

一、快速原型

其详细过程如下图描述（借用2月做团队项目介绍会中自己的PPT，偷个懒。。）。从信息结构图到低保真原型到高保真原型，及其阶段所使用的工具和成果，都有描述。

在最新的一次原型中，我们并没直接使用Axure，而直接通过我们新完成的前端页面框架，完成简单原型，节省了从Axure原型到工程静态页面的转化时间。

（关于使用Axure的思考：由于我们难以积累一个内部的Axure组件库，也没法定向培养使Axure做原型的产品人员，而且我们一般都得身兼多职，完成原型也得做最终的页面设计，所以用Axure做的抛弃型原型还是有一定的成本的，而随着有我们内部的前端页面框架后，亦可以直接做静态页面了，而且做出的原型较Axure原型来说，更可谓高保真。 同时，我觉得Axure更适合不懂真正的UI代码但还得做出美观的demo的人，但要做出美观的原型，成本也不小，在没有积累内部组件库的情况下）

二、开发迭代中的TODO

先前我们使用TODO List，以0.5-1天为粒度去划分工作内容。引用老师的一句话：在过去的项目过程管理中，我们发现，如果一个工作的任务划分以月为粒度，那它的延迟粒度也是以月为粒度，如果是以周为粒度，则最终进度的拖延亦以周为粒度。所以，在开发TODO中，要求以0.5-1天为粒度去划分任务（其实说的是个人TODO，项目TODO表一般还是按3-5天，而分到个人TODO中会将任务再细分）。

先前我们一时没找着合适的工具去进行TODO的跟踪反馈，一直是使用wiki去记录；初期还好，但到后期就觉得混了。后来，觉得还是得找专门的项目管理工具，现在发现redmine不错。

注：TODO，更适合任务较明确的时候，在需求、规划阶段并不是那么好使。

三、使用wiki去记录公共文档

先前使用svn去管理公共文档，如配置文档，设计文档，等。但实在地说，svn不应该管理像PDF,DOC这类文档，而且找起来也费劲。最后引进wiki后，管理配置文档的确是不错，做一些简单的设计说明，以及一些需协作的文档。关于更复杂的文档内容，比如visio什么的，虽说wiki能传图，但觉得还是不太好。后期自邮之翼（FreeWings）2期有Free分享，虽说不太完善，但亦解决这类的文档的存放问题。

四、开发迭代

从Free分享的实践来说，一般一周一次迭代，完成一个次版本功能，和数个三次版本修订，1-1.5月完成整个过程的release迭代（也可以说是主版本升级）。

当然，一般来说，下次release迭代亦得看过程总结而定，一般不会直接想到下一个release需求。

后期上线后，随着用户使用和反馈，以及前期规划的功能修订，工作量是不少的，所以一般release上线后进入这个阶段了。

……其余略过

反思

再借用以下这张图说一下反思——过程模型还待持续地探索和发展。

除了下述的问题之外，还有许多问题没说明。比如，就一个互联网应用而言，运营推广是很重要的。但实话说，这是学生团队难以做好的，毕竟更偏向于项目实践中技术探索和学术研究，不可能花时间做运营推广工作；即使做，个人觉得也是不值的。除此之外，从个人经历来说，我觉得一个应用在上线之后的运维更新阶段是很有必要突出的，在过程模型中没体现，虽说可以简单理解在下一个release迭代过程中。

除了这些之外，上述许多内容，亦很可能是不完备的，需要在实践中不断思考总结更新的。比如之前说的快速原型，在最新一个项目中，我就提前了直接使用前端框架完成，没必要再走Axure，这次探索似乎较为成功，相比之前原型-->静态页面设计阶段的效率上看。但以后是否都如此，还待达成共识，毕竟最近这次这样做也考虑到项目较为紧急。

而且，我认为，过程都是无法细化到项目成员的所有工作的，以及项目可能遇到的所有情况的。过程模型只是帮助我们理解一个项目的过程，和对我们后期进行各阶段工作有一个最初的方向的指导，一切还是得以实际情况为准。所以是参考过程模型但不限于参考模型去实践，而实践最终会反馈于过程模型以提高模型的可适应性和合理性。

写在最后

拖了很久终于抽时间写完了。完成这个过程模型，去年对外对流过一次，今年给团队新人进行项目介绍会时也专门完整讲了一次，自己觉得还是挺骄傲的。同时，了解到软件过程这个坑其实挺深的。以前学软件工程里的CMM，增量模型，有一定理论意义，但实践起来觉得挺难实施的，或者不够完备。而工业界较火的敏捷过程，如Scrum，之前简单了解了一下，并没有具体去学习，因为自己更倾向把它们理解成思想，而非具体的方法论。而有些方法论，比如“5分钟站立会议”，试验过，但最后中咔嚓掉了，觉得不适合我们自身的例会；后来想想，如果只是3-4人小组，现在我们椅子一转，谈些工作，也就5分钟的事，我想也许5分钟站立会议是针对这种细粒度的会议会话吧……

完成这个过程，最大的感触是，还是得有实践经验后，才能总结出来的。比如，学管理的人，没参与过管理是无法理解管理学的。 如果没经历过软件过程，学习软件工程也是难以体会的，更不用说理解了。