敏捷激活三步曲.docVIP

敏捷激活三步曲 　　在敏捷正在成为软件开发主流思想的今天，如何有效地在一个组织实施敏捷却才刚刚起步。从了解敏捷起步到相信敏捷，最后用敏捷的方式思考，本文提出了一种非常有效的让敏捷开发落地的策略。 　　 　　“敏捷”是时下的IT圈子里一个非常吸引眼球的词汇。很多人误认为敏捷就是一种软件开发的流程或者实践，而其实敏捷是一组开发流程和实践的方法论。这种方法论的背后是2001年由17位资深软件开发专家在美国犹他州的一个会议上总结出的敏捷思想。时至今日，敏捷思想激活逐渐成为了软件开发业的主流。全球不同规模、模式的IT组织已经从实施敏捷开发流程及实践中取得了巨大的成功。而我国不少的IT组织也开始了解、学习敏捷思想，希望自己的组织能从实施敏捷中获益。 　　然而，一个组织要接受一种新的开发模式并不容易。笔者对近期参与的一些敏捷项目进行了总结，在此与大家分享组织实施敏捷的方法以及组织实施敏捷过程中需要注意的一些问题。 　　为帮助大家理解，文中使用的敏捷词汇简单解释如下。 　　●故事: 描述一个有价值的需求的文档。 　　●迭代: 一个开发周期，往往是一组故事完成的周期。 　　●XP: 敏捷倡导者Kent Beck提出的一组软件开发的方法。 　　●Scrum: 一种敏捷项目管理方法 　　 　　组织保证 　　在谈论怎样在一个IT组织、企业实施敏捷之前，首先从组织架构上予以保证。那么，什么样的组织架构最适合敏捷？ 　　很多IT企业采用矩阵式组织结构，其中既有按职能划分的垂直领导系统，又有按产品（项目）划分的横向领导关系。一个项目团队的成员来自不同部门，隶属关系仍在原单位。很多时候一人同时参加数个项目，其中尤以质量管理人员（质量分析师、测试员等）最为普遍。这样的组织结构下，每个项目成员一般受双重管理（所在项目及隶属部门），这种组织结构存在的问题是明显的: 首先，双重管理容易破坏项目团队的整体性，部门领导和项目管理者容易产生步调上的不一致; 其次，由于团队管理的复杂化，项目透明度不高，很少有融入客户（业务部门）的机制，其后果是不能围绕客户和市场的真实需求来展开开发工作。 　　对比上面提到的矩阵式组织结构，敏捷组织需要弱化职能部门的划分，更多由跨职能、面向价值交付的团队构成。大家可能会立刻问: 这样的组织结构价值在哪里？下面我们就从三个方面来分析其价值。 　　敏捷组织价值一: 　　统一的团队 　　在传统结构下，团队采取“会战”方式组成，人员之间很容易因职能隔离，导致团队内垂直划分，从而不能成为一个统一团队。各职能成员容易各自为政、目标不一。一个典型的现象是，开发人员常常在内心抵触质量管理人员提出的要求，而质量管理人员又总是对开发的系统缺乏信心，项目管理者很多时候感到力不从心，不能激励团队成员，更无法谈到融入客户、拥抱变化了。 　　由于敏捷组织弱化了职能部门，敏捷团队成员全职投入到项目组中，增加了每人的团队归属感。原来一个人同时被分派多个项目的做法显然是不利于团队建设的，与之相反，敏捷组织要求员工积极参加到自己团队的日常活动中，鼓励员工参与不同职能的工作。 　　 　　图1简单展示了一个迭代过程中业务分析人员、开发人员、质量管理人员及项目管理人员的日常工作。我们可以看到，除了每个职能例行的工作之外（如质量管理人员要完成上个迭代的故事测试，然后投入到这个迭代新故事的测试工作中），作为一个团队，大家要共同参与如“迭代开题”、“上迭代回顾”等集体活动。以“下个迭代计划”为例，项目管理人员需要安排组织会议、控制会议时间; 业务分析人员要解释下一个迭代故事的选择; 开发人员及质量管理人员则要了解相关需求，同时提出可能要进一步细化或要求重新评估的故事。通过这样一系列的活动，项目管理达到了高度的透明。同时我们可以看到客户（客户代表）被融入到团队中。远离客户的团队不可能是一个敏捷的团队，客户的参与是保证最终价值交付的关键。 　　从上面的讨论中，不难想象如果不是具有高度自组织能力、统一的团队，是无法贯彻敏捷开发思想的。这样的参与度，也让每一个团队成员很快拥有项目的主人翁精神。一言以蔽之，敏捷组织通过强调集体共有及发挥每个成员主观能动性来打造统一团队。 　　敏捷组织价值二: 　　价值驱动 　　谈到价值，首先就要明确什么是价值。对于软件开发项目而言，答案其实就在下面这个问题里。 　　假设在两个项目开发过程中市场都在不停变化: 项目A按时、按预算交付所有计划功能，不幸的是项目本身未能给客户带来任何帮助; 项目B因为响应变化，所以延时、超出预算交付了部分功能，但却帮助客户取得了盈利。传统项目管理方式下我们说项目A是成功的，项目组完成了计划。现实却恰恰相反，项目A没有带来任何的价值，因为它对使用者没有帮助。在现今IT市场需求快速变化的时代