ibm bpm开发手册_IBM BPM =敏捷开发吗？

典型的IBM BPM开发方法遵循迭代和灵活的途径，通常被称为敏捷。但是，IBM BPM方法与敏捷方法（例如Scrum或XP）定义的方法之间存在细微的差异。本文重点介绍了每种方法的关键方面，并说明了采用定制的方法可以使IBM BPM项目从中受益。

敏捷方式

在1990年代中期，敏捷方法开始认真出现，这是对历史上陷入困境的整体式瀑布项目的React。这些失败通常归因于范围和需求管理方面的问题，从而引起以下问题：

知之甚少
容易改变
范围复杂

对于大型项目，可能需要花费数年时间才能全面分析需求并开始形成解决方案设计。但是，到那时，由于企业已经对不断变化的商业环境做出了React，那些非常严格的要求通常可能无效。术语“分析瘫痪”是为了描述那些以重复的分析和设计模式不断锁定而无法交付任何有形价值的项目。

与其尝试通过一次交付构建整个解决方案来“沸腾海洋”，一种更灵活的方法的概念浮出水面，其中除其他外，它可以达到以下几点：

通过持续不断的增长提供解决方案。
定期与项目发起人，分析师和最终用户互锁。
避免进行全面的需求分析。
即使在解决方案交付的后期，也欢迎不断变化的需求。

最后一点是关键：它创造了敏捷（agile ）这个名字，即灵活性，能够吸收变化或未知的需求作为软件开发生命周期的正常部分。

范围管理

在一个软件项目中，通常有三个相互关联的变量：范围，资源和时间，如图1所示。调整任何一个变量都会对其他变量产生直接影响。

图1.项目尺寸

传统的交付方法试图分配额外的资源或延长项目时间，以交付商定的范围，这被视为一个不可动摇的维度。但是，敏捷开发过程的全部目的是能够适应范围的变化，或者提供解决方案，而不必首先对范围进行详细的了解。使用敏捷方法，范围不再是一个不变的因素。项目可以避免长时间的分析，并可以以最少的初始投资就可以为企业带来增值。

敏捷实践

以下一系列创新工作实践通常与敏捷开发过程相关：

结对编程 ：开发人员是成对工作，通常一种是打字，另一种是“按需”设计思想。
测试 驱动的开发 ：在编写代码模块之前，开发人员首先编写测试并将其嵌入到代码库中。
每晚自动生成 ：整个源代码每晚编译一次，并且自动执行回归测试以验证代码的完整性。
用户故事 ：通过采访分析师和主要用户来捕获需求，并记录在轻量级故事中。
“ Post-It”星球 ：团队会议室的墙壁上贴满了Post-It便笺，定义了按周和阶段完成的故事。这些注释会根据其相对重要性和复杂性定期重新排列。
每日“站立” ：开发人员和建筑师在每日站立会议中进行“即时”设计会议。

重构

敏捷方法的一个副产品是重构。在实现每个后续用户故事时，它可能会影响现有代码库，从而导致模块被重写以适应新功能。这种重构源自避免扩展分析和设计阶段并开始快速交付代码以提供加速业务价值的愿望。

以这种方式进行重构不应被否定地看待。从编程的角度看，它似乎效率不高，但付出的灵活性却是一个合理的代价，它使项目能够吸收不断变化的需求。

冲刺

冲刺是在敏捷方法（包括Scrum方法）中发现的开发周期。基于Scrum的Sprint是固定时间（通常在2到4周之间）的有时间限制的开发周期，在此期间，Scrum团队致力于提供特定的用户故事。 Sprint旨在提供完整的功能范围，称为潜在可交付的增量（有时称为PSI），如果需要，可以将其发布给企业。

诸如看板团队之类的替代开发方法为实施故事提供了更加灵活和需求驱动的方法，可以构成持续交付周期的一部分。

无论采用哪种方法，创建可以逐步发布的生产质量代码都是一个主要目标。

流程驱动的方法

通常与IBM BPM开发相关的方法已成功采用以下敏捷实践：

迭代实现
业务与最终用户的一致
减少前期分析和设计
用户故事驱动的需求捕获

但是，IBM BPM流程和敏捷应用程序的交付方式存在许多细微的差异和变化。

严格的要求

就其本质而言，IBM BPM几乎始终专注于定义良好的规范：即流程本身。需求通常为企业所熟知，通常是对低效和次优运营的回应。

流程所有者通常负责端到端流程，并且通常由许多了解其操作细节的业务主题专家提供支持。最重要的是，根据定义，流程不会经常更改。他们可能会使用规则来引入动态行为，但从结构上讲，它们通常是稳定的。因此，尽管回放被用来包含业务反馈，但是不要指望开发过程中整个过程都会发生变化。

业务期望

在讨论IBM BPM中的敏捷性时，主要不是要对不断变化或未知的需求做出React。当然，每个项目都试图吸收迭代之间的反馈。但是，这种反馈几乎永远不会引入批量更改。它通常会完善或阐明现有要求。从IBM BPM衍生的敏捷性应该是业务敏捷性 ; 提供灵活的，面向未来的流程，该流程会不断增长，以提供更高水平的运营响应能力。

流程或应用

业务流程管理与构建“应用程序”无关，它是IBM与客户互动中观察到的最常见的反模式之一。流程通常是单向且基于任务的。他们开始，做某事，通常涉及各种角色，然后完成。应用程序也可以基于任务，但是它们通常具有交互模式，其中一个用户角色反复返回到中央屏幕以执行类似的工作活动。客户关系管理（CRM）系统是一个应用程序，航班预订系统是一个应用程序，而现金定单是一个过程。 IBM BPM的一个很好的用例是它协调多个应用程序并涉及多个角色的用例。

是的，IBM BPM可以用于构建应用程序-但它并非设计为快速应用程序开发（RAD）平台或第四代编程语言（4GL）。以这种方式使用IBM BPM时应格外小心，因为此类项目通常属于20/80规则的范围：最后20％的需求需要80％的精力。

解决方案设计

由于IBM BPM中的IBM Process Designer非常直观，因此通常有一种规避所有设计活动并直接进入键盘并在第一天开始进行流程实施的诱惑。经验告诉我们，您不能跳过设计活动。仍然需要进行不同的过程分析，建模和解决方案设计活动。在项目的初始阶段（称为“蓝图”或“迭代0””），进行了以下活动：

流程分析和建模：交付团队和业务部门需要协作以了解项目的需求并以图形方式对流程进行建模。理想情况下，此活动应由项目团队的专门业务分析师领导，他们应该熟悉流程建模和优化技术，并且可以使用诸如Blueworks Live之类的工具。
定义用户故事：仅流程模型无法全面捕获所有需求。必须编写一系列用户案例来定义各种角色如何与流程交互。
构造线框UI：可以使用简单的用户界面模型来增强播放效果，并使业务发起人沉浸在新流程中。
业务指标 ：我们将如何验证IBM BPM实施是否确实交付了业务价值？必须与业务发起人一起捕获关键绩效指标（KPI），以提供对未来运营的洞察力。
业务对象 ：尽管在此阶段无需对解决方案中包含的业务数据的各个方面进行建模，但是您必须确保已识别出关键对象，并且它们可以支持所需的业务指标。以后重构业务对象，尤其是那些用于复杂服务接口的业务对象，可能会很耗时。
解决方案概述：解决方案体系结构通常被忽略，但是需要一定程度的宏设计来捕获解决方案的技术方面，包括非功能性要求，并确定和验证与支持的操作系统的集成点。
播放0 ：范围，过程，设计和计划均已通过关键业务赞助商验证。

故事点

在大型项目中，项目管理团队与一群不熟悉的开发资源一起工作并不罕见，每个开发资源的技能和经验水平均会显着影响其交付代码的能力。在这种情况下，设计团队在估计工作包的复杂性时使用任意度量单位可能是有益的。在将工作分配给已命名的资源之后，可以将与资源无关的评估转换为特定于开发人员的数据。

大多数敏捷项目都使用一些故事点来评估用户故事的复杂性。故事点是抽象的数值，用于定义故事与其他正在开发的故事相比的复杂性，但它们并不能直接反映交付故事所需的天数。开发人员也有自己的速度，一个数值反映了他们交付代码的能力。

要计算特定开发人员交付特定故事所需的时间（天），只需将故事点数除以开发人员自己的速度即可。因此，如果您的故事已分配了8分，并以2的速度分配给初级开发人员，那么开发人员可能需要8÷2 = 4天的时间来交付该故事。速度为4的高级开发人员会在一半时间内编写相同的故事。

如果您有一个专门的设计团队来负责估计所有故事并且还不了解开发资源的功能，那么故事点可以很好地工作。但是，故事要点确实带来了以下挑战：

会期：商业赞助商喜欢考虑实际情况。如果企业发起人问“项目何时交付”？他们想要一个日历日期，而不是故事点的价值。
估算：使用故事点可为项目规划带来更高的估算水平。您不仅要估算每个故事，还必须估算每个开发人员的技能水平。因此，最重要的指标（即交付工作包的天数）是两个估计值的乘积，每个估计值都会有一些不确定性因素，可能导致总体估计中更大程度的不准确性。

就其性质而言，IBM BPM项目应与相关业务线建立紧密的工作关系。项目旨在尽早并经常交付业务价值，这有助于推销IBM BPM愿景并建立团队对整个企业交付能力的信心。这种方法对典型的IBM BPM项目的结构有以下影响：

以流程为中心的项目：通过实施核心流程，您隐式地交付了很大一部分解决方案，这意味着您通常没有数百个用户案例可以在整个迭代中进行管理，估算和开发。
解决方案加速 ：IBM BPM产品的模型驱动方法有助于加速解决方案交付。讲讲短的开发周期和增量部署，发布通常发生在10到16周之间。因此，工作包较小，更易于准确估算。
团队组成 ：IBM BPM项目通常具有规模较小，联系紧密的团队，其技术能力具有很高的可视性。开发人员经常与项目经理和解决方案架构师合作进行故事评估，并且应该对交付能力具有高度的信心。

由于这些原因，我对IBM BPM项目中故事点的价值有所保留。引入额外的估计水平无疑会增加出现误差的机会，同时也不会给商业赞助商带来任何价值。考虑到团队中的技能水平，通常在“平均开发人员日”中估算起来要简单得多。

项目计划

在IBM BPM计划中，通常明确需要为业务发起人提供准确的交付时间表，并伴随对流程演变的明确期望。但是，您不能以100％的确定性来估算项目的工期，也不能这样做，因为您仍然希望能够在实施过程中对不断变化的需求做出React。项目经理和解决方案架构师应该对交付时间尺度和资源分配有80％的信心。因此，计划不应被定义为^第 n ^个学位，但它应该提供的业务的信心，该解决方案将如期交付广泛。

在“蓝图”阶段之后，您还必须计划迭代以有效分配资源。通常，IBM BPM团队的成员会根据需要移入和移出，并且不需要专职人员就业务规则和用户体验等主题进行专职培训。此类资源需要准确计划，因为它们经常在多个项目之间共享，这可能是通过卓越中心交付的IBM BPM计划的一部分。

站起来的会议

关键的敏捷功能是每日站立会议或Scrum会议。由于以下主要原因，这次会议非常宝贵：

重构敏捷性成本：就其本质而言，敏捷性方法会引入不同程度的返工，因此，重要的是，在团队中公布代码重构的任何影响，并在所有相关方面公开讨论其后果。
设计会议：敏捷方法通常会放弃详细的设计阶段，而是倾向于在日常会议中“按需”设计，以便小组可以就如何最好地处理特定故事交换技术思想。

在IBM BPM项目上，您仍然希望在适当的地方适应业务变化，但是应该通过初始的“蓝图”设计和规划工作来最小化重构和动态设计。结果，您经常会看到站立会议变成了“圆桌会议”，每个参与者都只是站起来并陈述他们正在做什么。这次会议确实可以确保每个人都知道其他人在做什么–但是这段时间每天都花得很好吗？

这些会议的费用不应该被低估，尤其是在试图加快进度的情况下。例如，如果您设想一个典型的，为期12周的小型项目，团队由8个资源组成，则每日会议的累计成本可能是：8人*每天0.5小时* 5天* 12周= 240小时

沟通至关重要，但是在小型项目中，通常整个团队都位于一个房间内，因此通常会隐式地传播项目知识。团队成员知道彼此的成功和挑战，解决方案架构师负责根据需要将特定资源整合在一起以解决技术问题。无论何时加入，每种资源都应该了解全局，并应使用Playback 0资料，以便他们充分了解自己的工作如何为整体解决方案做出贡献。

因此，在投入大量的项目时间之前，请仔细评估日常会议的需求，并考虑团队中的经验，位置和社交因素。每周会议通常可以提供最佳的权衡。在几周没有回放的情况下，短暂地召集整个团队讨论整个项目的状态并播报任何问题可能是有益的。

播放效果不错，但实际上并不是什么新鲜事

软件项目几乎总是向客户展示进度，尽管可能没有采用这种计划的方法。从客户的角度来看，新功能是，他们只需要将按钮移动3个像素就不必提出项目变更请求（PCR）！

但是，播放不是用户接受测试，因此您不应该为此做准备。应该演练回放，并且应确保可以证明整个解决方案的增长。但是，它们是收集重要业务反馈的机会，并且（通常）不代表正式的签字或合同里程碑。当然，最终的回放可能是例外，它可能构成用户接受程度，因此应加倍努力。

在某些情况下，整个项目团队会下载工具，并花费数天的时间为每次回放做无限精确的准备。在这种情况下，业务发起人几乎被吓到了，被视为恐惧的敌人，而不是扩展团队中受欢迎的合作伙伴。尽管这种准备水平是值得称赞的，但通常是负担不起的。根据前面的示例，数学又很简单：8个人* 8小时* 3天的准备时间* 4次回放= 864小时

这个例子意味着大约109天将专门用于准备和演示（而不是开发！），这种奢侈通常是不可能的。播放效果很棒：拥抱它们，最大程度地受益，但不要害怕。

IBM BPM迭代不是敏捷的sprint

两者都是短暂的开发周期，通常持续2至3周，其中整个解决方案是通过实施用户案例逐步构建的。但是，在迭代结束时，解决方案不一定设计为处于可以发布给业务的状态。

相比之下，敏捷的sprint旨在持续交付可发布的工件，这使业务发起人能够说出他们是否愿意继续使用到目前为止所拥有的功能，以防特定的有价值功能已经交付。这适用于某些应用程序交付，但是IBM BPM以流程为中心，因此将IBM BPM迭代视为敏捷sprint可能会导致以下问题：

释放半成品流程： IBM BPM项目尝试尽快交付每个端到端流程，以使企业能够设想最终的解决方案。预想解决方案可能最初需要使用无法实际发布的存根和模拟服务。
加大测试工作量：更多版本需要更多测试，特别是组织的业务发起人，主要用户或分析师进行的正式用户验收测试。
永久变更管理 ：如果您在每2或3周冲刺结束时向企业发布整个企业范围的流程，则企业发起人很容易发现自己陷入了变更循环中，对可能实际上阻碍了运营的增强做出持续React他们履行职能的能力。

在流程级别进行太多更改只会使业务发起人感到沮丧。因此，您需要建立一个健康的平衡点，以支持对运营改进的渴望，而又不会对业务造成不必要的影响。

这种平衡通常可以在持续的过程改进计划中找到，该计划可以促进长期的增量增长。

Craft.io优化

IBM BPM是精益或六西格玛流程改进计划的自然实施合作伙伴。精益分析通常在一系列过程中进行，试图提供改进的过程控制和测量，性能可视性和运营效率。尽管精益和IBM BPM通常作为单独的练习进行，但可以将其合并到一个迭代的交付生命周期中。有关更多详细信息，请参见参考资料部分。

持续改进流程

首先，应该将IBM BPM开发视为持续改进流程的程序，而不是一个单一的交付工具。应用程序通常是交付的并且通常是打补丁的，但是它们可以存在很长时间，而无需升级或增强。借助IBM BPM，您希望快速实施，通过业务监控收集业务见解，提供改进的流程并重复执行。

监控是这里的关键方面：必须给业务发起人一些时间来评估新发布的流程，通常在分析几个月的业务指标和运营统计数据之前，可能会发现进一步的改进。

流程实施路线图

随着IBM BPM技术的成熟和采用变得更加主流，越来越多的客户开始使用IBM BPM程序。这些计划通常涉及少量团队并行交付多个流程，通常采用工厂方法，并在全年进行定期部署。分析和设计始终在内部进行，并且尽可能靠近企业，但是开发团队可以位于离岸，可以使用外包资源或业务合作伙伴提供经济高效的方法来加速IBM BPM交付。

随着交付和支出规模的增加，选择正确的流程以在短时间内创造业务价值和投资回报变得更加重要。通过一系列过程评估研讨会来实现这些目标，这些研讨会统称为过程清单，变异分析和路线图（PIVAR），其中将多个候选过程与一组商定的标准进行比较，以确定可以带来最高收益的标准。有关更多信息，请参阅《使用IBM Business Process Manager IBM红皮书的业务流程管理设计指南》。这些研讨会的输出可以绘制在影响力图上，以帮助创建IBM BPM流程实施路线图，如图2所示。

图2.流程优先级

理想情况下，寻求优先处理那些适合该图左上方“魔力象限”的流程，以最少的努力带来高影响。因此，IBM BPM计划提供了一种实现连续流程改进的理想工具，使企业能够计划流程中的增量改进，并提前确保运营准备好在全年的预定时间点接受这些增强。流程优先级与传统的IT交付模型完全不同，但是比典型的敏捷方法更严格，因此流程优先级在灵活性和可预测性之间找到了一个满意的中介。

结论

尽管IBM BPM交付方法大量借鉴了敏捷方法，但突出了以下差异：

明确定义的需求：该流程提供了一个易于理解且不易改变的核心业务需求。
解决方案设计：一定程度的前期解决方案设计对于提供准确的范围和计划，最小化重构很重要。
持续的流程改进：流程开发和优化是一项持续的活动，它使用业务监控来确定进一步的提炼机会。
IBM BPM计划：一种可扩展的交付方法侧重于计划的，与业务保持一致的IBM BPM解决方案部署。

在您着手执行IBM BPM项目或程序之前，必须定义，记录和宣传合适的交付方法。一种方法很少适合所有情况，因此您可能需要自定义现有的敏捷方法，或与IBM或IBM业务合作伙伴合作进行方法采用研讨会（MAW）或卓越中心（CoE）参与，以定义适合于以下情况的方法：您组织的需求。无论采用哪种方式，都应解决本文中讨论的因素，以最大程度地提高IBM BPM旅程的效率。

致谢

作者要感谢Paul de Wildt的评论和评论。

翻译自: https://www.ibm.com/developerworks/bpm/library/techarticles/1602_glen-trs/1602_glen.html

ibm bpm开发 手册_IBM BPM =敏捷开发吗？