架构需求的看板实现

一个精益的、基于流的过程模型在支持从系统架构到系统实现中,必须实现四个目标:

使架构在制品(Architecture Work In Process,AWIP)可见:精益思想要求我们确保所有工件可见。正如Reinertsen[2009]指出的,不可见的开发在制品仍是在制品[]。糟糕的是,由于它们不可见,而且没有“自然的天敌”,对于从事这种工作的人员会有自然的过载倾向(我们不能看到或量化它们,它们似乎也是一些必须的重要内容,为什么不多做些呢?)。
我们的看板制度必须使AWIP可见,使它们可以被负责和管理。架构待办事项、队列和分析在制品都必须是可见的,形成对当前和未来工作负载的共同理解;

建立AWIP限制,以便控制队列尺寸并帮助确保产品开发流机制:限制WIP可以帮助我们避免由大队列尺寸、大延迟、过载资源的辗转成本和低效率造成的经济损失。
首先,我们把局部AWIP限制在架构团队能够实际从事的工作,确保架构师们不在过宽的工作负载中辗转。即:启动很多项目但最后完成得很少。这样可以提高架构团队的效率、生产力和质量输出。
其次,通过这样做也可以有意识的限制全局WIP,包括上游的投资组合WIP(驱动新架构的项目)和下游的开发WIP(构建新架构的项目)。以这种方式,将可以在企业范围内使输入目标与实现约束匹配。

推动与开发团队的有效协作:在架构和开发部门之间的紧张关系是明显的,毕竟是由开发团队实现架构篇章,让他们对一些新东西感到惊讶没有帮助(“如果我们早知道那些,我们就不会把那么多时间花在…”)。或者,要求他们负责一些他们认为不能真正工作的实现计划也是如此。F-Secure的James Cooper指出:
倾听开发人员的观点,如果他们说那个设计有问题,那可能就有。
如果我们的模型可以促进在不同团队之间的有效交流,则过程就可以更顺畅地自然流动。

为作出经济决策提供量化基础:如此,我们就可以知道正以正确的次序完成正确的事项。

在这一看板制度中,对所有篇章(Epics)的处理都要经过连续的四个队列,这些队列以对架构不同部分和开发团队开展的活动为特征,而且投资水平相应提高。这些队列包括:

1. 漏斗:识别问题/解决方案需要
漏斗队列是一种“采集”队列,在这个队列中欢迎所有新的“大思路”。它们可以来自任何来源,对它们不要求商业案例或估算。使用的工具也很简单,文档、电子表格或墙壁上的简单列表就足够了。
鉴于对漏斗队列中条目的工作量投入较小,该队列不是WIP限制的,所有思路都被采集供进一步考量。针对漏斗中篇章的讨论,是按照架构团队所确立的周期节拍,那些满足决策准则的篇章将被提升到待办事项队列。

2. 待办事项
对到达待办事项队列的篇章有必要进一步时间投入。在这个队列中,对篇章大致估计大小,有些价值估值被确认。在时间方面的投入将控制在讨论的水平,而且可能进行一些初步调查。篇章可以细化成一到两个段落。
由于投入的增加,此队列是WIP限制的,以便限制过程中活动的条目数量。对待办事项篇章的讨论是定期的,并且为这些篇章指定延迟成本(CoD)。对于上升到队列顶部的篇章,将在分析队列中有空间时尽快拉取。

3. 分析
对到达此队列的篇章,有必要经过更严谨的分析并要求进一步的投资。通常指派一名架构师作为一个篇章的负责人,并启动与开发部门的积极协作。还要探索有关的设计替代方式,考虑内部开发和/或外包的选项。最后,要开发一个轻量的商业案例,带有通过或不通过的建议。
在这个队列中的条目要使用稀缺资源,因此它是限制WIP的。这种限制是基于架构团队和开发团队的能力,以及针对分析队列中的条目所需的吞吐量。从分析提升到实现,对于企业来说是一个重要的经济决策,只能由适当主管基于已开发的商业案例作出这一决策。符合通过准则的篇章被提升到实现队列。

4. 实现
在此队列中,针对篇章的主要职责被传递到开发团队。架构师资源保持以“拉”方式的可用性:实现的职责是由开发团队承担,但是架构师要辅助团队并且共享责任,直到团队具有完成相关工作所需的充分理解。
实现队列是WIP限制的,在这里受到的限制主要是开发团队的生产力和所需的架构投入量。