用看板做敏捷开发

编者注:对于需要在不同地点、时间协同的团队,可以用电子看板,比如 Leangoo

正文
今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。

对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。

对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

那么 Kanban 到底是什么呢?我们先来看看这张表格吧:

leangoo

下面我们来理解一下这个表格吧!

这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)

其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)

包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!

leangoo
产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。

leangoo

现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。

leangoo

有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。

leangoo

部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。

leangoo

此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。

leangoo

完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。

leangoo
所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。
leangoo

部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。

leangoo

整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。

leangoo

看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!

leangoo
几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!

leangoo

文章来源:http://my.oschina.net/huangyong/blog/196883

### 看板方法在敏捷开发中的应用 看板方法作为一种源自精益制造体系的思想,在知识型工作中得到了广泛应用,尤其是在敏捷开发环境中。尽管看板方法不像某些敏捷方法那样严格规范,但它具有较低的侵入性和较高的灵活性,能够帮助团队逐步改进工作方式并最终过渡到更成熟的敏捷实践[^1]。 #### 看板方法的核心原则 看板方法强调可视化、限制在制品(WIP)、管理流动和持续改进。这些原则使得团队能够在现有流程的基础上引入增量式的改变,而无需彻底颠覆现有的工作模式。通过这种方式,看板方法降低了实施新方法的风险,并允许团队根据实际情况调整节奏。 #### 在敏捷开发中的角色 看板方法与敏捷开发的理念高度契合,特别是在以下几个方面: - **交付价值**:无论是看板还是敏捷,都注重快速交付有价值的成果给客户。这可以通过优化任务流来实现,从而缩短周期时间并提高效率。 - **适应变更**:看板方法支持频繁的小规模迭代,使团队更容易应对不断变化的需求环境。这一特性正好满足了敏捷开发对于灵活应变的要求。 - **持续改善(Kaizen)**:基于精益思想的基础,看板鼓励定期回顾会议以识别瓶颈并制定改进行动计划。这种方法促进了长期的学习文化形成,这也是敏捷实践中不可或缺的一部分[^3]。 #### 实施建议 当考虑将看板方法融入敏捷开发时,可以采取以下策略: 1. 使用物理或数字化白板创建可视化的任务列表,清晰展示每项工作的状态; 2. 设定合理的 WIP 上限,防止资源过度分配而导致延迟完成; 3. 定期审查整个过程的表现数据指标(如吞吐量),以便及时发现问题所在; 4. 鼓励跨职能合作精神,打破部门壁垒促进沟通交流[^2]。 ```python class KanbanBoard: def __init__(self, columns=['To Do', 'In Progress', 'Done']): self.columns = {col: [] for col in columns} def add_task(self, column_name, task_description): if column_name not in self.columns: raise ValueError(f"Column '{column_name}' does not exist.") self.columns[column_name].append(task_description) def move_task(self, from_column, to_column, task_index=0): try: moved_task = self.columns[from_column].pop(task_index) self.add_task(to_column, moved_task) except IndexError: print("No tasks available at the specified index.") # Example Usage board = KanbanBoard() board.add_task('To Do', 'Implement feature X') print(board.columns) ``` 上述代码片段展示了如何构建一个简单的看板类 `KanbanBoard` 来跟踪不同阶段的任务进展状况。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值