朝向基于原则的过程

敏捷人员经常告诉我们，我们应该基于首要原则来设计自己的流程，而不是采用一个已发布的框架作为一组固定的规则。当他们这么说的时候，我们又回到了豪华的皮革香烟，用熟练的皱纹皱起眉头，旋转着干邑白兰地，抚摩着车把上的小胡子，尽可能像英国人一样吟唱:“啊，是的。”的原则。快乐的好,知道吗?”

然后，我们继续采用已发布的框架作为一组固定的规则。

因为，你知道，什么原则?

它们与软艺术的早期实践者在20世纪60年代发现的原则是相同的，随后在20世纪70年代早期的“大官僚审判”中被驱除了，它建立了主宰世界直到千年结束的瀑布圣堂(赞美DoD-STD-2167A和其他圣人及其附属段落)。

到20世纪80年代中期，民间有传言说瀑布教堂可能是在纪念假神。毕竟，什么样的神会允许客户需求和软件解决方案之间的这种错位，就像那个时代常见的那样，如此严重的代码库腐败，或知识工作者的系统退化到仅仅是“资源”的状态?亚傅体育app一种改革运动在20世纪90年代获得了势头。根据敏捷的智慧之珠博客:

所谓的轻量级敏捷软件开发方法是在20世纪90年代中期发展起来的，作为对重量级的面向瀑布的方法的一种反应，重量级的面向瀑布的方法被他们的批评者认为是严格规范、严格管理、微管理和过度增量的开发方法。

当他们建议我们将流程建立在原则的基础上时，敏捷人员可能考虑的是敏捷宣言：

• 个人和交互高于过程和工具
• 工作软件优于全面的文档
• 客户协作高于合同谈判
• 响应变化而不是遵循计划

然后是12个原则为了说明这些价值(这里不重复)。

但2001年的这份文件不是第一份，也不是唯一一份表达类似价值观和原则的文件。动态系统开发方法(DSDM)于1994年发布，基于以下“构建块”:

• 终端用户积极参与
• 授权团队
• 高度重视团队协作和合作
• 频繁发布和更新
• 开发驱动以满足业务需求亚博vip9通道
• 增量开发是关键
• 开放的态度面对改变
• 保持高水平的需求
• 开发和测试之间的有效集成

类似价值的另一种表述，关注过程而不是技术实践，指出了看板方法背后的指导原则。正如大卫·安德森列出了他们：

• 可视化工作流
• 限制在制品的数量
• 管理流
• 明确流程策略
• 协同改进(使用模型和科学方法)

流行的Scrum框架定义了一组三个“支柱”以及一些明确的值。它们非常强调协作工作的人的方面，并且更加注重过程而不是技术实践。根据Scrum指南，支柱是:

• 透明度
• 检查
• 适应

Scrum的价值是:

• 承诺
• 勇气
• 焦点
• 开放
• 尊重

“承诺”这个词经常被误解为“履行承诺”。它真正指的是团队承诺交付客户定义的价值，并将他们所知道的最佳专业实践应用到他们的工作中;作为团队成员对彼此的承诺。

最近的一种表述，被称为精益-敏捷原则，已经被许多组织，甚至一些已发布的框架所采用。以下列表来自scale Agile Framework (SAFe)的网站，该网站不加修改地采纳了这些原则:

• 从经济角度来看
• 运用系统思考
• 假设变化;保存选项
• 以快速、集成的学习周期增量地构建
• 以工作系统的客观评价为基础建立里程碑
• 可视化和限制在制品，减少批大小，并管理队列长度
• 应用节奏，与跨域规划同步
• 解锁知识型员工的内在动机
• 分散决策

当有如此多的原则四处游荡时，尝试并根据原则为您的组织设计定制流程可能会令人畏缩。幸运的是，在这些列表中有一些共同的元素。让我们看看能不能把它分解，让它变得更有意义。

类别

各种原则的表述似乎涉及不同的领域:

• 所有的开发都是由业务需求驱动的(从经济角度看，终端用户积极亚博vip9通道参与，客户协作高于合同协商，以及类似的短语)
• 软件的消费者(客户、用户、涉众和类似的术语)和软件的生产者(开发人员、团队、“发布培训”和类似的术语)之间的对齐/连接。
• 清晰准确的沟通(透明度、开放性和类似的术语)和正在进行的工作状态的可见性(可视化管理、信息辐射器和类似的术语)的重要性
• 人与人之间互动的质量(协作、合作、透明度、勇气等)
• 反馈循环指导解决方案设计并与客户需求保持一致的重要性(迭代开发、增量交付、快速集成的学习周期，以及类似的术语)
• 强调经验主义而不是抽象的计划和文档(工作系统的客观评价、检查、适应、工作软件)
• 跨团队工作的有效协调(与跨域计划同步，限制在制品，管理流程，以及类似的术语)
• 保持选择权;接受变化(假设可变性，保留选项，检查和适应，响应变化而不是遵循计划，以及类似的短语)

您可能会得到一个与我不同的类别列表，但您可能会同意确定这些不同原则列表的关键元素的一般方法。当我们把它分解成几个关键点时，它看起来就不那么复杂了。除此之外，所有的变化都是词汇的选择。

对我来说，这些常见的原则分类可以浓缩成一个简短的关键元素列表，如果轻量级过程想要帮助交付价值，特别是在一个包含多个交付团队的环境中:

• 直接让关键的涉众参与进来，他们对需求有清晰的理解，并且可以就中期交付的方向、速度和内容(无需征得许可)做出战术决策。
• 经常调整增量交付，从关键涉众那里获得反馈，以通知学习周期。
• 为所有相关方可视化整个过程和正在进行的工作的时间点状态。
• 在团队成员之间和更大的组织内的团队之间采用有效的协作方法。
• 量化计划工作的期望值和预期成本，包括机会成本和延迟成本。
• 协调跨多个团队或具有其他组织依赖性的工作项的计划和执行。
• 将决策推迟到最后一个负责任的时刻，但也要提前足够远地处理已知风险，以防止它们成为代价高昂的问题。
• 尽早使用度量标准来检测潜在的交付问题，以便处理它们。
• 充分利用别人多年来在管理流程和最大化增值时间方面学到的知识;避免重复别人已经犯过的错误。
• 更多地依靠基于经验业绩数据的预测，而不是对短期规划的估计

你可能还有其他我没有想到的因素。在任何情况下，你使用的准确术语和你遵循的准确程序来完成这些事情并不重要，重要的是它们的实质。尽量不要被发布框架中的“规则”和区分市场的流行词所纠缠。

最后，我认为有必要记住，你不必在第一次尝试时就把所有事情都做对。您可以一次又一次地更改您的定制流程，直到您满意为止。使用这种方法中固有的反馈循环或学习循环来增量地改进您自己的过程。

LeadingAgile可以帮助

LeadingAgile有一个经过验证的、实用的方法来帮助组织朝着拥抱这些原则的方向前进。我们不有一个僵化的，固定的方法，或者一大堆让你盲目遵循的规则。如果你不确定如何将相对抽象的原则转化为实际的现实，我们可以帮助你。我们可以从各种方法中提取在您的上下文中有用的元素，并将它们组合在一起，使它们不会相互抵消。所以，不要害怕按照敏捷人士所说的去做:根据第一原则来设计你自己的流程。