Lean Managing
精益开发,用看板(Kanban)管理项目
Why Chapter Ⅰ
Origin
Why A dream business model
...make an idea possible with the lowest amount of work
Why Unfortunately, reality is a little bit different...
...you have to invest some money,
you'll have to do some work as well
Building software is very expensive, so we need a
methodology which makes it less expensive
Flow
Why Flow analysis
10
Why
Waste in Operations
Why
Waste in Operations
Why
Waste in Operations
Why 软件开发中的8大浪费
不必要的功能部分完成工作 再学习/返工
不同的任务间切换
交接 延期 缺陷
Why This is the 10th slide and no Lean so far,
you are talking about waste...
WHERE IS
IT…
Why
My apologies... it is there... at the X
Between 1940 and 1950, Japan and Toyota
weren't in the best economical condition
1、Maximize customer value while minimizing waste
2、Improve the production process continuously
3、Bring out the best from the people
But Toyota had a plan to survive
What
What Lean Production
JITJust in time
旨在需要的时候,按需要的量,生产所需的产品
Pull
Continuous Flow
Customer Value
Waste Elimination
Continuous Improvement
Kanban is…
Kanban is translated as:
“Visual Card”or “Signal Card”
What
Kanban is…
Kanban is a transparent work-
limited, pull system
Pull value through the Value Stream
Limit work in progress
Mike it visible
What
Why Chapter Ⅱ
Principles
First principle: visualize the flow
This is the flow, your
actual process!
Your flow could be something like:
Request → Dev → Verify → Release
What
We can visualize value flow in a more transparent way
...because "arrows" and non-visible process states won't
help you find waste and improvement areas
What
What do you see on this picture?
I see a huge inventory (11 items), but no customer
value
What
How Block your flow so that items will push each other out...
regular approach single piece flow
What
How Second Principle: Limit the actual work in progress(WIP)What
It's easy to get friction between different teams,
especially when one is more performant...
What
How … and pushes more work than another one can actually handle.
How A solution to this is a pull system,
where next team pulls work only when ready for it.
What
Start by putting limits on columns in which work is being performed
Don’t try to
work more than
three things
at a time
What
Why Chapter Ⅲ
The rabbit's hole
Cumulative Flow Chart
This will produce a mountain-like looking chart, which gives insight into the
process, shows past performance and allows to predict future results
What
You can implement pull system by adding a limited capacity buffer
between teams.
What
Why Chapter Ⅳ
Implement
ScrumbanHow
Sprint planningHow
Kanban does not require all tasks
must be completed within an iteration
User storyHow
Every increment is able to
bring value for user
independently
SprintHow
PULL
Review MeetingHow
Demo
Done – by delivery criterion
Problems and improvement will be accumulated
to the backlog
Release
Retrospective MeetingHow
Reflect on what is working well and what isn’t,
and decide what to change.
‘fist of five’ for vote
Continuous iterationHow
每个发布版本都是了解真相的最佳时刻——我们这时才能了解产品是否与用户的需求契合!
两次发布的间隔时间越长,我们在代码中嵌入的缺陷和错误假设就会越多。
如果发布频率高一些,补丁小一些,每个版本的问题和风险也就相应降低了许多。
How
Don't work on a feature that nobody wants
Don't write a document that nobody will read
Don't write code that nobody can/will test
Don't test a feature that cannot be deployed
Closing words
HowThank you very much for your attention!

Lean managing of software development

Editor's Notes

  • #4 最理想的商业模式就是把想法直接转化为金钱(Money),脑子动一动钱就来了谁不愿意 但是不可能,能量守恒定律不允许 所以,企业家和管理者想通过尽可能节约成本来获得最大利润
  • #5 现实是残酷的,想要获得可观的产出,除了想法之外,必须投入一定的成本,金钱、人力、工作量,并且要经过一个转换过程,才能最终得到我们想要价值,也就是既得利益 同样,软件的构建也是把想法和成本转换成可用的产品,不管是当前盛行的服务类软件还是打包出售的工具类软件,最终都会转换为金钱 所以,制作一款软件是非常昂贵的,我们需要一个方法让他不那么昂贵 再看一下这个经典的转换过程,想法和成本通过一定的过程转化为金钱,这个过程被称为价值流,我们可不可以从这个价值流入手来节约我们的成本,获取尽可能多的利益 已经有人这么做了
  • #6 普惠公司,世界最大的飞机喷气式发动机制造商,为它的三选喷气式发动机做了价值流分析。分析中发现,他们的下游原料供应商原料制造采用的方式使成本大大的提高了。 比如钛镍的原始铸件比成品要重10被,这就意味着有90%的昂贵材料成为了废品,设想一下,如果这类活动可以立即去除,我们就可以极大地节约成本
  • #7 生产了无需求的产品 由于上道工序发送传递不及时,使做下一道工序的人只能等待 货物从一个地方到另一个地方的盲目搬运
  • #8 不必要的工序 由过产造成的不必要的库存和积压
  • #9 员工的盲目走动 需要纠正的错误 未充分利用的员工才能
  • #12 他在这里,它起源于汽车制造业 汽车制造业有两种经典的生产模式,一种是福特模式,一种是丰田制造模式 他们都是将批量生产转化成连续流生产的方式 什么事批量生产和连续流生产呢?我们以包饺子为例。(统筹效应)福特模式适用于大产量的生产,因为它是固定的装配线,必须批量化生产完全相同的零件 而丰田模式由于其多变性,适用于适当规模的小型化生产
  • #13 通过使浪费最小化达到用户价值最大化 不断改进生产过程 最大程度激发员工能力 在丰田眼里,没有消极的员工。只要方法正确,员工都能焕发活力。
  • #15 将任务通过卡片可视化
  • #16 看板还是一个透明的工作量限制的拉动式系统 通过价值流拉动价值 限制工序中的工作总量 价值流必须可见
  • #18 想法转变成价值中的黑箭头就是流 软件生产中的流就是需求、开发、测试和发布
  • #19 通过冗长的黑箭头我们没有办法看到价值流的转换过程 而kanban就是那个价值流可视化的工具,通过它我们可以找到浪费和改善的空间
  • #21 我们所需要的不是像左边那样,各个工序工作量明显不平衡 理想的方式应该是像右边一样实现平稳增长,不会造成不必要的积压 怎样实现平稳增长呢
  • #22 由此引出第二个原则,限制在制品数量 堵车任何人都很讨厌,为什么会堵车呢,是因为一个路口已经达到了他最大的承受容量,如果我们驶出一个拥堵的路口,会发现后续的一大段道路其实是一马平川的 上一道工序传递的不及时,造成下一道工序不必要的等待
  • #23 软件开发过程中不同team之间产生摩擦是屡见不鲜的,多数是因为产能的不平衡造成的, 比如开发和测试team,常常可以看到测试团队没有足够的人力为开发者测试,而开发者还在源源不断的递送测试申请 记得是在周报中就听到这样的问题,大师那组总是抱怨sitesurvy v5早就开发完成,但是QA由于测试项目的过多而没有时间为sitesurvy进行测试,这样造成的结果就是延期交付
  • #24 上游的工作推送就是拥堵的始作俑者,推送的速度大于下游工序的产能就会造成拥堵,拥堵则会造成浪费
  • #25 一个有效的解决方式就是采用拉动系统,工作量由下游team决定,当有足够的裕量来处理问题时就从上游拿新的任务,这样就可以保证任务的平滑流动
  • #26 Kanban就是这种拉动式系统,
  • #28 我们可以通过积累流图来实现KPI统计 横轴是时间,纵轴为任务数量
  • #32 迭代计划会的任务有两点,首先是挑选出待开发的功能 然后将功能拆分为面向工程师的细碎的任务
  • #33 以便于从用户的角度考虑问题,这就是减少不必要功能的一种手段
  • #38 不做没人想要的功能 不写没人会读的文件 不写没人会测试的代码 不为不能发布的功能测试 其实就是一点,不要浪费