领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
文章：借助看板从敏捷到精益
作者 苑永凯 发布于 2008年2月19日
Kenji Hiranabe紧接前一篇关于敏捷项目中看板应用的文章，引用多个实例，独到地思考和阐述了如何更深入地借助精益思想中的看板跟踪系统优化整个软件开发价值流，以使整个流程可视化、拉动式生产，进而消除浪费。
首先Kenji Hiranabe借助简单的例子给我们图文并茂地讲解了制造业中的看板是如何在TPS（丰田生产方式）中使用的。并借势总结出了TPS中看板的特性和作用：
实体的：看板是实体的卡片。可以拿在手中，可以移动，可以放在某些东西上面或者里面。 限制在制品数量：看板限制在制品的数量，也就是防止生产过剩。 连续流通：它会在仓库耗尽库存之前通知生产的需求。 拉动式：下游工序从上游工序中抽取零部件。 自导向（Self-Directing）：它有要完成的工作的所有信息，能以一种非集中的方式实行生产自治，并且不需要微管理（micro-management）。 可视化：堆放或者张贴着的看板直观地展示了当前的状态和进度。 信号：看板的可视化状态为下一步的领取操作或者生产操作作出指示。 改善（Kaizen）：可视化的流程触发并刺激改善。 附着的（Attached）：看板附在所供给的零部件之上并随其一同移动。
紧接Kenji Hiranabe回到软件开发领域，列举了两种应用于软件开发的不同看板系统：敏捷看板（Agile Kanban）和持续看板（Sustaining Kanban）。这两种看板系统各有各的关注点，Kenji Hiranabe借此阐述了自己的观点——将两者结合使用（这正是中庸之道）：
“敏捷看板”用来在团队中分享信息并使工作自导向，但它不支持流程。“持续看板”是另一种类型的看板，能够让小批量的维护工作在几个状态之间流转。这种结合便是“精益+敏捷看板”，使用“持续看板”贯穿价值流，同时在子流（sub-stream）中使用“敏捷看板”。他提出的“精益+敏捷看板”由里到外地覆盖了整个软件开发的价值流。而后，Kenji Hiranabe描述了当敏捷与精益结合之后，看板应该代表些什么：
一个卡片是一个从“用户故事”中分解出来的“任务”。[……]作为工作的一个基本单元执行，因为团队中每个人都能明白它的意思。但是，在看板系统中它贯穿了价值流中的多个工序（多个团队），在其中流转之物应该带有客户认可的价值。既然这样，看板卡片就不是对应于“工作（work）”而是对应于“功能（feature）”，并且它不是WBS（任务分解结构，work breakdown structure）的组成部分，而是FBS（功能分解结构，feature breakdown structure）的组成部分。因此团队中的每个人，甚至是客户，都能够理解看板的含义和流转之物的价值。
如果你对Kenji Hiranabe的创新实践方式感兴趣，或者想了解如何使你的软件开发过程更加具有精益思想，那请阅读全文：将看板应用于软件开发：从敏捷到精益。
开眼界
发表人
dapeng li
发表于
Re: 开眼界
发表人
刘 显珂
发表于
第一次了解精益，一些想法~~~
发表人
liu xin
发表于
-
看过2篇Kenji关于Kanban在软件开发中的应用，感觉受益颇丰。但诧异此文章怎么之前没有人回复，希望大家踊跃回复说说对Kanban的看法
-
本文关于看板的讨论，特别是“敏捷看板”和“持续看板”的比较很是精彩。“持续”看板在过程控制方面的优势正好补充了“敏捷看板”的不足。值得推广。
-
第一次看到有关精益的理论，有些困惑
精益理论是为了解决“仅在需要的时候生产和交付所需要的东西，并且仅完成需要的数量”这样的问题的。
而在敏捷的开发中，这样的问题基本不存在，原因是：
1.敏捷开发中，每一个spint中的story，都是经过开发人员、产品人员以及客户仔细筛选，而确定的必须交付的功能，所以不存在不需要和生产过剩的问题。
本文中的“由下而上”的理论是值得借鉴的，用真正的商品价值去驱动上游的开发与测试，当然，纯粹的下游驱动还是不太可行的（开发和测试的工作在某些阶段是并行的）。
看完本文后产生的新想法：
在产品生产中，我们习惯于将scrum应用于某一个过程，比如开发或测试，于是，我们使用了本文中“图5 敏捷看板”这样的面板，但是软件产品不只局限于某一个过程，所以应该在我们的敏捷看板中，加入过程的可视化，以便可以清楚的看到story目前在整个过程中的状况
3 条回复
关注此讨论 回复