无迭代的增量式软件开发

作者 Amr Elssamadisy译者 乔梁 发布于 2007年6月11日 上午3时30分

社区

Agile

主题

协作,

方法论,

企业级敏捷

标签

看板,

计划,

精益,

管理,

丰田生产系统

David Anderson描述了他的团队在运维工程（维护与Bug修复）活动中如何使用看板系统。尽管没有使用迭代，但软件仍旧保持每两星期发布一次。他们通过“看板”和每日站立会议来布置任务，并对其进行监控。

看板（Kanban）来自于丰田生产系统（Toyota Production System）和精益制造（Lean Manufacturing），它是一个信息指示牌，作为生产全过程中团队协作的指示。尽管它并非起源于敏捷社区，但也不是一个新概念。Anderson和他的团队所做的工作就是一个应用精益生产原则来消除在先前曾经有用的浪费的典型案例。对于维护版本的发布，我们真的需要为了迭代而进行像计划、估算及其它额外工作吗？

它用一个看板系统来追踪变更请求（Change Request，CRs）。 当完成一个CR时，它就被置为发布就绪状态，这个状态一直保持到每两个星期中的第二个星期三。此时正是计划的发布日期。

该方法也抛弃了迭代开发中的一个常见约束，即所有的问题都必须被分解到足够小，以便将其放在某个迭代中：

同样，看板系统使我们可以不受固定迭代周期的限制。尽管我们每两个星期发布一次，但看板系统中的每一项任务都可以花上60天的时间，这取决于任务大小和复杂度。那些超过两星期的任务仍可以放在这个看板系统中而管理层无需投入特别的关注。

以上是该方法积极的一面。然而，这真的是一种可以及时响应变化的技术吗？事实上，该方法没有提供像演示、回顾这样用于对过程本身进行信息反馈的同步时点。也就是说，Anderson团队在远程协同工作的过程中，已经发现了一个问题：

实践证明，在保持工作同步方面是有问题的，尤其是当团队成员在家或异地工作时。Darren Davis已经制定了一个“亲密伙伴”方案，即那些在家工作（Work From Home，WFH）的人必须指派一个在办公室的人为其更新白板，并使其与电子跟踪系统保持同步。

这么看来，该团队似乎是通过每日站立会议的方式得到反馈的。但这样会一直保持足够吗？

查看英文原文：Incremental Software Development without Iterations

• 更早的 >