IBM敏捷转型纲领 - 纪律

因为，我们认为在企业里，项目的透明度和团队的自由、敏捷一样重要。我们之所以这么认为，因为我们相信：

敏捷需要纪律、需要过程，XP就是个拥有各种纪律的敏捷方法，敏捷因此绝不是无政府主义
敏捷不需要管理-错误的认识；团队自我组织、自律自持、自知之明，仍然需要管理，否则是如何敏捷转型的
能够为团队定制可持续性开展活动的过程或者方法，是真正运用敏捷核心价值，实现敏捷框架的过程
敏捷方法、实践过程的设计、使用以及过程的管理均是敏捷转型的重要环节之一

在我着手设计、撰写Rational中国的敏捷开发过程的同时，我和我的团队和踊跃的参加到全球敏捷社区领导团队的各项工作中，其中一项对我形成巨大影响的应该是和IBM的CoC团队以及首席方法论学者ScottAmbler对即将发表的一本新书“Discipline Agile Book”的评审工作。需要指出的是，我对于我的导师、前辈的Scott Ambler先生的书是缺乏勇气自诩“评委”的，但是令人嫉妒也罢，走运也罢，我真是太荣幸地被邀请加入此书的评审活动中了。

下面我简单描述下背景信息，Rational在中国的研发产品有如CC、CQ， RQM， RPE， RTC等等，而这些产品都有着浓厚的“地方特色”，CCM产品族CC和CQ产品从瀑布式、RUP、敏捷开发到今天已经在中国有十多年的基础和历史，产品结构和功能非常强大，对上面的任何一个功能的改动都会影响到过去十几年开发者留下来的历史代码，而无论是对团队技术的挑战，也为产品的下一个发布带来较大的风险。

RPE 产品刚刚跟随Telegoic的并购进入IBM中国，产品的研发流程、方法看似有着很好的可塑性；中国团队也刚刚经历了2年的建设和成长，团队从测试团队发展成了开发支持团队，团队的配合比较默契。而团队成员的技术、能力、工作经验也相对过去丰富和成熟了好多。只是，RPE产品在中国的市场还不成熟，同时RPE的“元老”团队拥有最好的技术，对产品的话语权也最重，而不幸的是，这个元老队伍是有控制欲的坚持自己原有流程和方法的典型，在一年前所有的开发工作都是在家、实验室、PC机上完成，项目的透明度几乎为0，可以说产品完全取决于个人能力而不是团队协作。

研发中心还有RTC和RQM团队，这两支团队在Jazz统一的敏捷模型下工作，但因为Jazz团队非常庞大，中国的队伍所占比例很小，参与具体的开发和测试工作比较多，而鲜有参与产品团队建设和过程改进、架构设计的讨论，我与这个队伍的Lead沟通时发现，他们埋头于细节工作，很难看到全局，因为没有对比，也感觉不到敏捷实施前后以及将来进一步改进会对他们有何影响，对于我希望整合一套适用于Rational中国的统一开发过程显然缺乏参与兴趣。而我也担心如果真的以他们做为过程改进工作的切入点，我更担心他们会因此力不从心，而反而招致不必要的来自资方的挑战和压力。

统一Rational中国的研发流程是为了持续改进

这项工作的开展必须有远景设计和充分理解当前在环境下“存在即合理”的最佳实践，而这些实践必须是可以从这个完整的过程中摘取出来、拿来学习，提升价值，改进后普及于一般团队的活动。例如敏捷开发的持续化集成、测试驱动开发这些实践活动，我相信还有更多的智慧等待我们去发现，总结。总之，我信奉可靠性的转型，而不是颠覆。

因此，这项工作我非常有兴趣参与。我很明白，一个优秀的过程设计、方法论设计一定是能指导不同成熟度的团队的、也适用于不同习惯和规则、适用于不同复杂程度的领域，以及不同分布程度的组织结构的。这个过程有意忽视企业软件研发、甚至是一般软件研发价值体系中的细枝末节，用“最少的步骤“实现最大的价值流（Value Stream）”，即促使产品安全和快速的投入市场的商业价值；同时可以通过调整“过程参数”来满足差异性团队各自的差异性附加价值，换句话说，就是在公式中某些数值调整过后，就能够实现“额外的期望”，例如“团队的成长”。我把这套寄予厚望的方法叫做–
Rational 敏捷之路。

详述IBM 敏捷过程 Discipline Agile Delivery（DAD）

“规范敏捷交付（DAD）方法框架是一个以人为本，学习型的、混合型敏捷方法。它有一个风险驱动、也是价值驱动的全生命周期的，符合企业规范的过程。” – DAD的定义

从定义中，我们可以看到DAD方法框架有几个重要的构成元素：

1）以人为本 – DAD的团队应该是自我管理、自我意识、自律的；在DAD中，我们鼓励由跨职能的人组成跨职能团队的策略。团队内部不应该有层次；团队成员应该被鼓励去发展跨职能技能去满足执行工作的需求，而不是在他们的领域专业内纵深发展。因此，敏捷方法淡化以技能名称的角色划分，而DAD的角色是可以使用多种技能， DAD的五个主要角色是：利益相关者（Stakeholder），产品负责人（Product Owner），团队成员(Team
Members)，团队负责人（Team Lead）以及架构负责人（Architecture owner）。

请注意，测试人员和业务分析人员并不在DAD过程框架的主要角色中。相反，一个通才的队员应该是能够做多件事情的，这包括了业务分析和测试。一开始，团队中曾经专职测试的成员可以志愿去帮助做业务分析的工作，甚至可以去做做Scrum Master。这并不意味着每个人都需要成为一切技术专家，但它确实意味着团队一员，他们应该是愿意去学习和掌握任何所缺少的技能的。

2）混合型敏捷 - DAD的许多战略和实践从两个主流的敏捷方法SCRUM， XP，以及其他方法来源OpenUP，RUP，Kanban等而制定的。
a）SCRUM - Scrum的的重点是项目领导力和需求管理借鉴。

b) 极限编程（XP）- XP是DAD开发过程、实践的重要来源，包括但不限于 持续集成（CI）， 代码重构（Refractory），测试-驱动开发（TDD），团队所有制，简单设计，代码规范等等。

c）统一过程（UP）：DAD采用了许多来自UP的敏捷实例，包括的OpenUP和Rational统一过程中敏捷特色的实践和项目治理策略。

d）Kanban看板，即通过减少KANBAN数量来减少在制造品的中间存储，和通过可视化的方式显示在制品库存状态。这正是一个Lean哲学的方法框架。而Lean的七项原则（杜绝浪费，建立高质量为目标，创造知识，推迟承诺，快速交付，尊重个人，并优化整体）也注入了DAD的概念。

图3. DAD是一个混合敏捷方法



3）全生命周期过程 - DAD的生命周期延长了SCRUM所专注的构建周期，明确显示完整产品、方案的交付生命周期，从项目的开始到发布产品、解决方案或投入生产（或市场）。

4）符合企业规范的 - DAD团队经由企业组建，构成企业生态系统一份子，他们从企业有纪律的敏捷开发环境中，获取企业的有效资源和捕捉企业内部系统的各种机会而发展。
a)充分利用企业资产：有很多企业的资产DAD团队应该用，或者至少知道哪里有 。

b)加强你组织的生态系统：产品研发，至少，我说是至少，应该融入企业的生态系统，即能够与运营人员、技术支持人员、服务人员紧密合作，将产品的价值以最短的时间传递给客户的系统。

c)开放和诚信的监测：虽然敏捷方法是基于信任，但聪明的治理策略是基于“信任但要核查，然后引导”的心态。

5）风险驱动、也是价值驱动的 - 在DAD过程框架采用了一种被称为风险、价值驱动的方式，十分有效。