Jugaad，一种印度的交付方法

Jugaad是一种对待分娩的态度，起源于印度，由三个简单的原则组成：

Jugaad将敏捷性发挥到极致，最适合具有高度变化性、风险性和不确定性的项目。没有什么比印度制造的同名临时车辆更能体现Jugaad的精髓了。所有重要的机械部件都是敞开的，很容易拿到，而不是封闭在外壳里。车辆可以由常见的、用途不同的部件组装而成。它可以进行定制和扩展，以满足各种个人和专业需求、工作负载和环境。零部件的选择可以使Jugaad车辆适应不同类型的地形、用途、燃料和零部件的可用性。

这篇帖子不是研究文学的结果，其中大部分似乎都是围绕着2010年朱加德炒作的巅峰写成的。它相当于提炼了在印度与交付团队合作十年的经验，我从他们的交付方法和沉浸在印度企业文化中学到了什么。通过这篇文章的大部分内容，我似乎主张采用jugaad并废除其他敏捷方法；恰恰相反，我将尝试指出，jugaad对解决方案设计的整体方法应该与敏捷或XP等框架的战术纪律相匹配。

这三个原则(谦逊、开放、节俭)以一种美丽的方式相辅相成，又相互矛盾：谦逊产生解决方案的选择，开放引导并结合这些选择，节俭则消除这些选择。只有遵循所有这三个原则的解决方案才能建立在朱加德精神中。

像瀑布、Scrum和XP这样的交付方法引发了关于定义的宗教战争(例如，正确的冲刺长度是多少？)，流程(例如，前期规划的程度)、技能(例如。我们应该使用哪种框架)和工具(例如，Maven或Gradle)，所有这些或多或少都是对一种方法的坚持衍生出来的。Jugaad用一个中心指导取代了这些定义、流程、技能和工具：意识到与其他两个原则相关的捷径。Jugaad经常带有高度的“开箱即用”思维，需要谦逊地放弃关于什么是“合适的”方式的技术和方法论上的先入为主的观念，只关注结果，才能让它发挥作用。

谦逊是Jugaad的起点，因为使用“一切可行”会产生过多的选择。那么，我们如何在这些选项中进行选择呢？这就是开放发挥作用的地方。

Jugaad对待交付的表面上的粗心大意是建立在开放的坚实基础上的。无论我们构建什么，都应该很容易扩展、更改或反转。开放往往缺乏优雅和简洁，事物的内部运作被暴露出来，没有太多的润色，人们可以看到解决方案的组成部分-更不用说由这种解决方案引起的安全问题了。如果你需要一幅脑海中的画面，只要想想我们之前谈到的Jugaad车辆就行了。但这些权衡使得解决方案很容易修改，而且恰恰就是这样：有意识的权衡，而不是缺点。开放更改的解决方案是坚实的项目或产品基础，因为它可以适应不可预见的更改，并且不需要太多的前期设计。开放是谦逊的选择，并引导它们进入连贯的模式。并不是所有的选择都会形成一个好的解决方案，也不是所有的选择组合都会奏效；开放性告诉我们，在发现的过程中，哪些选项可能会奏效，而不会失去一只胳膊和一条腿。

节俭与风险管理有关：现在降低前期成本允许现在探索更多的价值主张和解决方案方法，同时稍后将资源花费在改进解决方案上。早期产生的低成本对项目的危害比同时产生的大成本要小，特别是如果我们买到的任何成本最终都是错误的。节俭是对开放性指导的模式的整体视图-它考虑了选项之间的协同效应，并最大化了价值，这既包括为解决方案创建的业务价值(以何种努力实现了多少需求)，也包括为项目交付增加的价值(改进了多少交付和质量，学到了什么等)。

Jugaad用几个例子进行了最好的说明，这些例子将传统的、“适当的”设计与即兴的Jugaad设计进行了对比。

设计一个生成、存储收据并通过电子邮件发送给客户的系统。客户支持应该能够检索收据。

传统的“合适的”解决方案是：我们编写一个系统，将收据存储在关系数据库中，生成收据PDF，将这些PDF存储在数据库中，然后将PDF发送给客户。我们编写了一个供客户服务使用的Web界面，该界面可以查询数据库中的收据。

Jugaad设计的解决方案：我们编写了一个系统，生成HTML收据，将它们通过电子邮件发送给客户，并以相同的收据密件发送一个客户支持电子邮件账户。客户支持可以使用他们的电子邮件客户端检索收据。这些组件都是打包的，不需要开发工作(客户支持电子邮件客户端、电子邮件服务器)，只有几个组件，它们很容易实现。

让我们对照Jugaad的原则评估Jugaad设计的解决方案，并将其与“传统”解决方案进行比较。

谦虚：该设计依赖于可能已经存在的打包组件，并且它只对现有的IT环境进行了最小程度的入侵。它重复使用组织中可能已经存在的高质量套装解决方案(电子邮件服务器、电子邮件客户端)，并将实施任务减少到电子邮件服务器和电子邮件客户端配置。传统的交付方法对如何构建解决方案提出了几个要求：它要求正式的API，可能是特定的技术平台，以及根据其构建组件的预定义方法(例如。在项目投入生产之前很久，技术文档和全面的测试自动化就已经开始了，但是仍然增加了解决方案和交付过程的概念和实际复杂性，并要求项目参与者具备更高的技能。

开放性：应用程序、电子邮件服务器和电子邮件客户端之间的电子邮件协议易于理解和扩展。使用电子邮件客户端需要的培训很少，甚至不需要培训，而且IT部门可能已经对其进行了维护。这些成分本身可以被替代，而不会对溶液的其余部分产生太大影响。在不修改已出库入库的情况下，可以在将来入库中增加新字段。由于许多组件可以由人工代理(电子邮件服务器和电子邮件客户端)操作，因此许多新功能和变通方法可以在编码和自动化到软件中之前作为手动过程实现。由于在前期设计的初始阶段投入的精力不多，因此在需求更改和后续实现时不会浪费太多精力。

节俭：使用打包的组件，特别是在它们已经很熟悉的情况下，可以减少实现工作并加快交付速度，但代价是成品会显示出不同组件接口的不一致性。需要更大更改的新需求可以通过将现有组件替换为更适合需求的组件来实现，如果需要，甚至可以从头开始重写它们。在许多情况下，由于较低的初始工作而取得的早期进展应该足以弥补较高的后期成本。就努力而言，传统的解决方案与Jugaad形成了鲜明的对比。例如，它将强制使用特定的API设计，比如用于回执生成器和回执检索的rest API，甚至是回执生成器和电子邮件服务器之间的rest API，因为…。原则。技术文档将在项目上线之前很久就为组件编写，而不是考虑到在非增值功能上花费的任何努力都会危及上线。最后，在明确单元测试是否产生业务价值之前，单元测试将被编写来实现任意商定的测试复盖率。通过捕捉倒退。Jugaad设计的解决方案将产生正式的API、文档和测试自动化，当它们的附加值超过实现工作时。

Jugaad没有Scrum或XP这样的进程。它谈到了值得奋斗的价值观。它没有讨论速度或质量；即使是对低成本的关注也引入了实现开放性的原则，从而能够重新访问以前构建的解决方案。敏捷强调反应性，它的要点是对不可预见的更改做出反应的能力，但它使用预定义的过程，如Scrum或看板。该流程必须适应组织的变化或不断变化的技能集。Jugaad没有规定任何交付过程，因此在某种程度上它与现有的敏捷实践是正交的。通过添加正式的步骤，成熟的Jugaad实践可能会演变为Scrum或看板，如果这看起来有用的话。

但是Jugaad不是关于没有流程的敏捷-它的中心主题是谦逊-开放-节俭的结合，这与通常纯粹迭代的敏捷实践方法形成了巨大的对比。著名的[引用需要]引语“灯泡不是来自蜡烛的迭代改进”暗示产品开发需要远见和总体计划的指导。如果没有这一点，渐进式的功能改进必然会出现分歧，并产生一个没有人需要的产品。

例如，Scrum建立在增量应该很小的思想之上。这个想法在实践中产生了几个后果，比如用户故事(跟踪小增量)和测试自动化(减少回归的测试工作，因为小增量意味着频繁部署)。对Scrum经常发出的批评是，它没有提供关于远见的指导--保持小增量是好策略，但不是好策略。朱加德用开放取代了小增量主义-增量可以是巨大的(例如。通过用打包的应用程序替换自定义组件)，只要它易于扩展或可逆。

极限编程(Extreme Programming，XP)专注于交付工具和方法；其基本思想是，通过改进交付技能，产品质量将自动提高，因此技术熟练的团队将神奇地交付良好的业务价值。与Scrum相同的批评也适用于此：XP并不指导我们的愿景。对XP的主要批评是，XP对纪律和质量的关注，而不是对结果的关注，过早地在除了产品本身之外的所有与交付相关的事情上花费了太多的努力。

我想举一个例子来说明Jugaad应用的一种非常有用的技术，它在敏捷中被认为是异端的：mocks。功能通常由UI和后端逻辑组成。敏捷要求用户故事的实现需要已经实现UI、后端和测试自动化；然后用户拒绝UI或发现需求中的缺陷，大部分实现工作都白费了。像用户旅行和设计研讨会这样的现代技术通过首先交付UI的模拟或清除后端逻辑，以便在投入时间在适当的实现之前验证用户的接受程度，从而及早捕捉到这种潜在的错误。

一个应用了jugaad的项目从外部看起来与任何敏捷项目没有什么不同，但对于那些参与其中的人来说，它的感觉却有很大的不同。我自己在(无意识地)实践jugaad的团队中工作的经历经常让我感到不安，因为我把它误认为是应用不好的Scrum或XP，甚至是没有任何具体的交付方法。

人们注意到的第一个不同之处是，没有关于定义、过程、工具和框架的固执己见的辩论，这些辩论将谦逊从一种交付原则提升到一种生活方式。团队成员很少坚持以一种特定的方式做事，没有明显的不是这里发明的综合症，也没有工作场所的竞争和攻击性。

第二个不同之处是，决策的目标是易于实施、易于理解、在必要时易于逆转，并发挥协同作用-开放。团队考虑实施选项的后果，总是超前一步思考，这(至少对我而言)解决了我长期以来对Scrum的担忧，即它将团队变成传送带工人。决策从不声称遵循最明智、最僵硬的原则；实际上恰恰相反！练习Jugaad的团队意识到风险和缺点，这就是为什么他们选择容易扩展或可逆的设计。

第三个不同之处在于，指导决策的是努力，而不是规模。Scrum要求增量在功能上很小，而jugaad则要求增量在工作量上很小。Scrum中的小增量总是需要功能上的小增量，否则它将不适合用户情景。Jugaad中的一个小增量意味着花费的工作量很低，即使这意味着我们的产品刚刚添加了整个打包的应用程序套件，将功能增加了十倍。

第四个不同之处是，通常情况下，只练习Jugaad的球队一开始的发球技能往往很差。尽管对敏捷方法的批评不绝于耳，但还是要提到jugaad的负面影响：Scrum、看板、XP等培训技术技能，组织交付，并对如何做某事有固执己见的回答。Jugaad的整体解决方案设计方法和缺乏战术指导无助于构建技术项目交付所需的技能和纪律。

Jugaad的原则不是通过做出明智的前期选择，而是通过最小化此类选择的成本来指导项目做出最大限度地提高灵活性和最大限度地减少未来遗憾的选择。Jugaad带来了又好又便宜的选择，但需要Scrum或XP等交付方法来实现这些选择。