拆分与解耦是敏捷与精益的核心

最新推荐文章于 2022-08-27 23:59:28 发布

kenneth_h_liu

最新推荐文章于 2022-08-27 23:59:28 发布

阅读量607

点赞数 1

本文链接：https://blog.csdn.net/kenneth_h_liu/article/details/98861707

版权

预计阅读时间：8分钟

“今年是在新部门的第二年，在敏捷与精益的理解和应用上有了新的突破。我非常认同拆分与解耦是敏捷与精益的核心的观点。以下是我围绕着这两点的一些实践与心得。”

—

今年的实践与小结

挑战

我们最重要的大型项目依然采用瀑布式开发的计划模式，交付周期以年计，交付风险非常高。部分的业务代表也缺乏采纳敏捷的意愿或者不知道从何下手。

人员的分配以项目为单位，大部分人员被分配到最重要的项目中，但由于需求不明确，项目成员很难进行持续的高价值交付。而另一边厢，系统维护、审计需求、业务流程优化等方面的需求很多，却缺乏人员应付，造成整体人员工作分配不合理和不均衡。

解决方案

新交付方式

我们暂时无法在上面提到的大型项目采纳敏捷，但我们从小处出发，在业务流程优化需求上搞试验田，尝试以下的“新交付方式”（我们没有宣称这是在搞敏捷与精益，但思路是一致的）。

0?wx_fmt=png

拥抱变化——适应任何需求变化以满足业务的最终需求。拆分原始请求并快速交付其中最重要的需求获取反馈并及时修改。
拆分——把大的需求拆分成最小可交付工件来缩短交付时间和实现持续交付。
简化流程——最终用户与程序员直接沟通，减少交接与签署。不再依赖繁文缛节的文档。业务可通过我们管理软件（JIRA）直接提交需求。
透明可视化——需求与细节都记录在JIRA。通过看板可视化进度与阻碍。定期汇报。
改进服务——上线后为每个交付收集业务反馈。建立交付排行榜激励人们参与交付及拆分需求。

在过去，如果我们收到一个请求，里面含有5份报表的开发，我们会一次性对这5份报表进行需求分析，为整个请求写设计文档并要求业务确认和签署，然后一次性开发这5份报表并发布到测试环境让业务验收。整个过程需要差不多3个月，过程重，反馈慢。如果验收过程出现需求变化，由于变更成本高，我们通常都会回绝或要求业务提起新的请求。

现在的做法是，我们会把这个请求拆分成5个独立的交付，并让业务对它们进行排序，然后我们会立马把最重要的那份报表进行开发并交付到测试环境让业务体验和反馈。我们相信，用户要看到实物才能知道自己的真实需求，因此我们不再依赖文档，而是选择更快地让成品呈现给用户体验。如果有任何反馈意见我们会及时修改，直到满足最终需求，达到可上线状态，交付时间缩短到两到三周。接下来再依次进行其他报表的开发。由于同一个请求的报表有相似性，我们从第一份完成的报表所获取的信息可以借用给其他报表，从而加快对它们的交付。

成果：

最终用户（请求提出者）与开发人员可以直接沟通，沟通效率大大提高，反馈周期大大缩短。
大的请求被拆分成若干个更小的独立交付，可以更快地交付其中最重要的需求并获取用户反馈，完全满足他们的反馈及相应的需求变更（变更代价也因拆分而变小）。

产品小分队

为了解决人员分配问题，我们建立了以主要产品为单位的小分队。每个小分队负责其产品的端到端交付，包括系统维护、审计需求、业务流程优化、大型项目等各方面的需求。主要人员全部分配到新的小分队中，不再归属于任何项目。项目只有项目经理与一两个项目BA，负责向每个产品小分队提交需求。

我们考虑的原则有：

能否减少对外依赖。
能否提高沟通与交付效率，减少等待与交接。
能否自主决策。
能否可视化需求与依赖，并根据业务价值进行需求排序。

0?wx_fmt=png

成果：

人员方面——每个人都有机会参与不同的项目，不再有人长期参与重要项目，有人只能负责系统维护，提升了工作热情与士气。
DevOps方面——从项目视角转化为产品视角，是DevOps进程的开端。每个小分队关注自己的产品，更易于进行持续的产品改进。
交付方面——更有效地安排人员满足不同项目的需求。
敏捷方面——每个小分队可以管理自己的Backlog和迭代计划。
运维方面——每个人都有机会对生产环境进行贡献，参与运维与小交付，并实现“谁开发、谁维护”的原则。
职责方面——每个小分队的职责清晰，负责端到端交付，减少交接与中间人角色。
技术方面——更利于进行架构重审与重构。

—

带来的启示

今年我的最大收获是在多年敏捷的基础上学习了精益与看板。它帮助我从另一个视角看敏捷，强化了我们手中的武器。

早前曾看过一篇文章，很认同里面的观点，DevOps实施落地的2大法宝——粒度与解耦。其实以上的实践恰好是从这两个方面着手。

拆分

拆分就是减小管理粒度。

精益和看板里最重要的原则就是减小批量大小，限制在制品，加快价值交付（一个工件只有完成了其价值才得以实现，长时间处于在制品的状态没有意义）。把一个大项目或大需求拆分成最小的可交付工件，或者敏捷里说的用户故事，就是要以工件或用户故事作为管理粒度。项目和大的需求都很复杂，管理难度非常大，内部有大量依赖和不可控的因素，其推进过程也并非线性，传统的以完成百分比作为量度的方法其实完全不能反映其进度。所以要对它们进行拆分，直到不可再拆分为止。比如支付是一个大需求，可以拆分成现金支付、银行卡支付、微信支付、支付宝支付等，每个都可以单独交付，实现相应的业务价值。这个过程就是把管理粒度缩小。拆分后依赖关系更加清晰，每个单位更容易完成，价值交付变得更快并可视。要注意，拆分的结果一定要是最小可交付的，也就是单独交付都能实现一定的业务价值的，而不是堆积半成品的过程（半成品指的是一个有价值的交付仅完成了部分阶段，比如一个特性完成了前端开发但后端开发没有做，或者一个特性代码写好了但没有测试等，都处于部分任务完成但不可交付的状态）。

解耦

解耦就是减少依赖，加快决策与交付。

前面提到的拆分也是解耦的过程，一个大的需求里面会有很多的依赖，拆分过程就是把其中的所有依赖拆分出来，使依赖关系可见，并可逐个攻破，加快价值交付。

把团队结构变成特性交付团队或前面提到产品小分队也是一个解耦的过程，目的是让新的团队能够实现自行决策、自我管理和独立完成端到端的交付，减少对外依赖，不需要接收其他团队的半成品或把半成品转移到其他团队，产生不必要的“库存”与交接，造成浪费。

整个软件技术的发展——模块化、面向对象编程以及近年流行的微服务架构，也是一个不断解耦的过程。

所谓的管理，说到底就是在分分合合之间找平衡。

—

未来计划

把“新交付方式”扩展到所有项目

前面提到，我们的大型重要项目依然采用瀑布计划方式，我们需要把“新交付方式”扩展到所有项目。

建立产品小分队已经把大部分人员从项目脱离出来，让项目管理与人员管理分离，这是第一步。然后我们希望能把项目的需求全部条目化，然后每月与所有业务决策人进行定期排序会议，确定下一个月应该交付的需求条目，不再以项目为单位进行计划。这样可以保证我们一直为业务的整体最高价值进行交付，不管这个需求来自哪个项目。所有业务人员也可清晰地看到我们在做什么、进度如何和有什么障碍。

无论如何，资源与时间都是有限的，目前的情况是，不同项目的请求在无序地竞争着我们有限的人员。我们要和业务一起确保有限的资源和时间用在最有价值的事情上，杜绝浪费。

0?wx_fmt=png

用户故事驱动开发

要实现上面的目标，必须对项目的大需求进行拆分，将其变成最小可交付工件或用户故事。我们一直希望业务能为大型项目定义最小可用产品（MVP），以确定优先级，更早地实现交付和开展业务，减低交付风险，但是大家都没有头绪，因为业务太复杂，业务干系人太多。也许做好了需求拆分后，大家可以再来分析哪些应该是MVP的部分，这样也许更容易一些。

目前前期需求分析依然以需求文档的形式进行，由业务代表提供。我们的计划是接收到需求文档后，第一件事情就是对其进行拆分，我们不相信需求文档内的所有需求都是MVP的组成部分，每个需求的优先级应该被独立审核。拆分后，对于每个可交付工件或用户故事，为了确保对需求的正确理解，需要与业务确定以下几点：

确认理解——我们会复述对需求的理解并要求业务方确认我们的理解。由于一般需求的表述都是抽象的，同一件事情不同人的理解可以有天渊之别，复述与确认确保我们的理解是正确的。
问为什么——解答为什么需要这个需求，为什么现在就需要。这里需要技巧，直接问这个问题可能无法得到有效答案，应该详细询问在什么场景下需要这个需求，包括谁用、什么时候和条件、要解决什么问题、什么频次、怎么发生，以甄别伪需求。有些需求其实是解决方案，需要挖掘其背后的真实用意（这里介绍一篇关于需求分析不错的文章——产品经理：需求做与不做,一念之间）。
确定验收条件——这也是我们常说的实例化需求，也是为了避免误读，让抽象的需求变成具体的实例。这一步很难，但非常重要。没有明确的验收条件，我们便不知道如何测试，业务也不知道如何验收。做一件事情，以终为始，在一开始明确要做成什么样子，行成闭环，才能指导行动并确保结果正确。以下是一个例子。

比如，我的需求是开发一个股价监控手机app，用户故事是作为一个投资者，我需要实时的股价提醒，以帮助我在目标股价范围内及时买卖股票。

其中一个验收条件是当股价低于目标价时，发出提醒：