David Anderson 描述了他的团队在运维工程（维护与 Bug 修复）活动中如何使用看板系统。尽管没有使用迭代，但软件仍旧保持每两星期发布一次。他们通过“看板”和每日站立会议来布置任务，并对其进行监控。
看板（Kanban）来自于丰田生产系统（Toyota Production System）和精益制造（Lean Manufacturing），它是一个信息指示牌，作为生产全过程中团队协作的指示。尽管它并非起源于敏捷社区，但也不是一个新概念。Anderson 和他的团队所做的工作就是一个应用精益生产原则来消除在先前曾经有用的浪费的典型案例。对于维护版本的发布，我们真的需要为了迭代而进行像计划、估算及其它额外工作吗？
它用一个看板系统来追踪变更请求（Change Request，CRs）。 当完成一个 CR 时，它就被置为发布就绪状态，这个状态一直保持到每两个星期中的第二个星期三。此时正是计划的发布日期。
该方法也抛弃了迭代开发中的一个常见约束，即所有的问题都必须被分解到足够小，以便将其放在某个迭代中：
同样，看板系统使我们可以不受固定迭代周期的限制。尽管我们每两个星期发布一次，但看板系统中的每一项任务都可以花上 60 天的时间，这取决于任务大小和复杂度。那些超过两星期的任务仍可以放在这个看板系统中而管理层无需投入特别的关注。
以上是该方法积极的一面。然而，这真的是一种可以及时响应变化的技术吗？事实上，该方法没有提供像演示、回顾这样用于对过程本身进行信息反馈的同步时点。也就是说，Anderson 团队在远程协同工作的过程中，已经发现了一个问题：
实践证明，在保持工作同步方面是有问题的，尤其是当团队成员在家或异地工作时。Darren Davis 已经制定了一个“亲密伙伴”方案，即那些在家工作（Work From Home，WFH）的人必须指派一个在办公室的人为其更新白板，并使其与电子跟踪系统保持同步。
这么看来，该团队似乎是通过每日站立会议的方式得到反馈的。但这样会一直保持足够吗？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论