敏捷软件开发管理实践 (一) ——让人的资源多起来
第1部分 开篇语项目管理作为一门独立的学科，已经发展了很多年，并为实践提供了丰富的理论依据。而软件开发的项目管理，虽然也属于传统项目管理的范畴，但是由于软件工业本身的特点，很多在传统项目管理理论中被证明行之有效的理论和方法，拿到软件开发的项目实践中却常常达不到预期的效果。软件开发的项目管理与传统项目管理的这种差异究竟在哪里呢？这个问题已经有很多人在研究并成果丰富，一致的结论性的原因就是：软件开发中的项目管理本质是人的管理。
人作为项目管理的主要素主导着整个项目的成功和失败，所以对于软件项目开发管理者来说，需要引起足够重视的一点就是要重视人——在软件开发中，这将主导技术、效率、质量。
本文内容上没有阐述敏捷项目管理与普通项目管理的区别，也没有完全按照计划——分工——执行三个环节来论述，更多的是作者随想随写的一些经验之谈。软件的项目管理也是整个软件工业没有“银弹”的一个重要方面，很多时候，经验比理论占据更重要的地位。文中的很多内容对于有实际项目管理经验的同行来说，可能能够产生一些共鸣，如果这样，本文就起到总结经验的作用。对于那些尚未有取得这些经验的同行来讲，本文中的实际案例和场景可以帮助增进这些读者的感性认识。
第2部分 让人的资源多起来软件项目开发的核心资源就是人，在一定的项目规模和资本规模下，人的资源是受限的。项目中考虑人的资源常常以人数来计，但是实际中我们都清楚，工作量是以任务来分解和总和的。这就说明人和任务之间存在一个关系，这个关系就是角色。
1.1. 角色（Role）角色是对工作任务的职责抽象，与具体的职位有着区别。一般情况下，角色和职位是多对一的关系。敏捷风格的项目管理认为在产品（软件）开发过程中，成员所承担的角色虽然有其固定的一面，但是可以赋予它更多变化来改变工作的分配模式。举例来说，A的职位是项目经理，但是同时也是优秀的设计师，那么，可以认为A承担了项目经理和设计师两个角色。
在软件开发管理中，角色其实非常丰富。常见的角色如：项目经理、需求分析师、系统设计师、开发工程师、测试工程师。对于大型项目，比如基于J2EE的项目，根据实际项目中的技能需求，需要各种类似专家的角色，比如人机界面工程师，部署工程师，配置管理员，DBA等。
敏捷的项目管理中要求角色不是固定的，一人可以担任多个角色，这样才可以充分利用已有的资源。如同电网的电力资源一样，资源的存在和分布有时是难以改变的，但是其是否充分利用依赖如何调度。
角色是项目中任务的具体承担对象，从角色角度而不是职位角度考虑资源的分配，有利于合理分工，保持资源的平衡。对于存在多个项目并行工作的情况，这一点非常有意义。我们知道，一个公司的DBA不会太多，多个项目并行工作的时候，可能各个项目都需要DBA的协助，但是从人员编制上，DBA可能仅隶属于某个具体的项目组。这个时候如何解决资源的分配呢？同样，优秀的架构师对于整个公司来说也会是稀缺资源，我们如何让这些稀缺资源发挥更大的作用呢？当然，可以考虑从人力资源编制上解决这个问题，比如成立独立于跨项目组的专门的架构师组，总体设计组等。但是，实际情况往往是人力资源制度的改革步伐永远会远远落后于实际需要。况且，从资源模型本身来看，资源本质上是与角色捆绑的而不是与职位捆绑的。
从管理的角度，我们希望资源可以最佳利用。绕过人力资源编制，实际上可以采取特殊的运作模式来达到这一目的。方法就是，赋于比职位多得多的角色，让人具备多个可分配的单位。在这一点可以用CPU的多线程来比喻。
案例：
2001年的时候，公司有Milkyway和Apollo两个项目在同时运行，两个项目都是电子政务项目，采用J2EE技术实现。当时公司是首次接手电子政务项目，对于Web页面所需要的大量美工虽有考虑，但是最终只招聘到一个合适人选。在Milkyway项目组中，大家都知道开发人员Alen喜好摄影，其实是一个图形制作爱好者，Photoshop高手。当美工资源已经成为事实上的开发瓶颈时，我给领导提出了一个建议：是否可以让Alen也充当美工角色呢？可以在开发任务上为Alen消减一半，让他有另一半的时间去让我们的工作产品漂亮起来。后来跟Alen商量让他兼美工这一角色，他愉快地答应了。我想，对于一个图形制作爱好者来说，还有什么工作比干自己喜欢的事情更愉快呢！
1.2. 虚拟团队(Virtual Team)虚拟是相对现实而言。虚拟团队一经发明，已经在互联网上广泛流传。所谓虚拟团队，是指没有实际的组织形态，但是有具体的任务目标；团队成员虽然来自各方，但是为着共同的任务目标而进行工作。
虚拟团队和实际团队比较，优势在于：组建灵活，反应快捷。
实际的团队往往根据长远的任务目标而设立，一经设立，成员即往往有了固定的身份。比如，项目组往往根据产品模块的任务目标而设立，一般来说在项目的生命周期中会一直存在下去。但是实际的项目工作开展过程中，一方面存在很多跨项目组的工作要做，另一方面存在很多短期的任务需要调度资源完成，这个时候固定的团队就难以胜任工作任务的分配。
虚拟团队本质上是根据任务对资源的临时性组建。前面我们已经通过角色把资源独立化了，现在通过虚拟团队，我们可以把独立的资源再通过任务目标而集中起来。
案例：
在上面谈到的Milkyway和Apollo两个项目案例中，当Milkyway项目推进到开发完成60%的时候，系统的基础框架已经基本可以在浏览器中看到。这个时候，架构师发现系统的响应很不理想，这个发现其实并不出乎意外。尽管公司是首次接手基于Web的项目，根据多年的经验还是预测到了可能存在的性能瓶颈。目前的任务就是需要立即组织部分专家来诊断性能瓶颈的准确所在，并敦促项目组成员调整代码。可是面临的问题是公司的测试工程师并不熟悉基于Web项目的性能测试，如何寻着额外的资源呢？另外，还有一个问题，性能问题来源于架构和代码，需要对系统结构和代码最熟悉的系统设计师和开发人员参与才行。这个时候Apollo项目正进入详细编码开始阶段，根据任务分配情况，管理层觉得部分设计师可以抽调部分时间来参与Milkyway项目的性能优化。为此，成立了Milkyway项目性能优化虚拟团队。
Milkyway性能优化虚拟团队
组成成员：
1. 所有Milkyway项目的开发成员和设计师
2. Apollo项目组的Wiki和Polo（两位经验丰富的设计师）
负责人：
Wiki担任负责人和组织者。
目标：
全方位优化Milkyway的性能，达到客户认可的各项系统响应时间指标
任务：
1. 一周内给出Milkyway项目的性能测试报告和性能优化具体指标
2. 三周内给出一期优化分析报告
3. 持续跟踪性能，从第四周起，每两周给出性能测试报告
执行：
1. Milkyway的所有成员需要配合Wiki的组织工作，并接受安排的合理任务
2. Milkyway项目经理Cobo协助Wiki安排工作
3. 测试部经理Anny，配合Wiki安排测试设备和数据准备。
本文地址：http://com.8s8s.com/it/it32714.htm