Kanban and Iterationless Working
•Descargar como PPT, PDF•
1 recomendación•747 vistas
From the BT Developer Day held at Osmosoft on 20 Jan 2010.
![Kanban & iterationless working ,[object Object]](https://image.slidesharecdn.com/kanban-100122030238-phpapp02/85/Kanban-and-Iterationless-Working-1-320.jpg)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (7)
Similar a Kanban and Iterationless Working
Similar a Kanban and Iterationless Working (20)
Más de Kerry Buckley
Más de Kerry Buckley (20)
Último
Último (20)
Kanban and Iterationless Working
- 2. Iteration
- 3. In the beginning was the waterfall
- 4. Plan Design Impl Test Deliver Plan Design Impl Test Deliver Plan Design Impl Test Deliver Plan Design Impl Test Deliver
- 13. Kanban 看板 看板
- 14. Push A B
- 15. Pull A B
- 17. Prio Plan Impl Impl Impl Accept Deliver Implement Impl Impl Impl Impl (oops)
- 18. WTSTTCPW?
- 19. Pick Impl Accept Deliver Pick Impl Accept Deliver Pick Impl Accept Deliver Accept Rework Accept Deliver Pick Impl
- 23. Iteration two!
- 27. Advantages
- 28. Disadvantages
- 29. end
Notas del editor
- Waterfall
- Most agile methodologies use fixed iterations. Preferable to traditional approaches because the customer gets to see working code at the end of each iteration, and the project can frequently correct its course based on feedback. Moving to a fixed iteration forces you to take smaller steps, otherwise nothing will fit into an iteration.
- How XP defines the iteration…
- … and how Scrum defines the sprint. Because most people associate Agile with XP and/or Scrum, it’s easy to assume that the fixed-length iteration or sprint is a precondition of agility. But…
- This is the closest the Agile Manifesto principles come to talking about iteration length. “Frequent and Continuous”. Despite what many people think, there’s nothing inherently un-agile about not using a fixed iteration.
- This is the closest the Agile Manifesto principles come to talking about iteration length. “Frequent and Continuous”. Despite what many people think, there’s nothing inherently un-agile about not using a fixed iteration.
- A quick detour into Lean Manufacturing (Toyota Production System). I am not an expert! One of the key aspects of Lean is the elimination of waste.
- I don’t speak Japanese, but apparently that says ‘muda’. These are the seven main types of waste identified by Toyota.
- Some of these can be applied to software development. Iterative development removes a lot of waste, but fixed iterations can still cause unnecessary waiting (for a feature to be planned into an iteration, and for an iteration to be deployed), and any completed features not deployed are unnecessary inventory.
- Literally ‘visual card’. Used as a token for a downstream process to pull materials from an upstream process.
- An assembly line where process B depends on the output of process A. A keeps churning out parts as fast as it can, which leads to a build up of work in progress. This is managed by up-front process design and by observing the amount of inventory of part A.
- The amount of inventory of part A is fixed (in this case two batches of three), and process B requests more as required. This is managed using kanbans – there are only two in the system, one per batch. If process A has a kanban, it produces a batch of part A, and attaches the kanban. When process B uses up a batch, it returns the kanban to process A, which triggers production of more parts. The amount of WIP is controlled by reducing the number of kanbans at different points in the production process. This exposes the bottlenecks in the system (the processes that are still running at full capacity when others are idle), allowing them to be addressed.
- Need to prioritise the backlog first, to be able to pick the appropriate number of stories to commit to the iteration. Planning involves some analysis, to try and estimate whether stories will fit in the timebox. Fixed time causes some problems. Might finish a story without enough time to start another (waiting), or not finish a story before the end of the iteration, and need to replan. Stories completed early wait for acceptance (unnecessary inventory). Any rework required feeds into, and complicates, the planning for the next iteration.
- What’s the simplest thing that could possibly work?
- No iterations. No estimation. Stories just move through from the backlog to delivery as fast as possible. Customer decides which story to pull in from backlog when capacity becomes available. Analysis done just in time.
- Short of whiteboard space, so our ‘swim lanes’ are drawers. We have backlog, live, ready for acceptance and done. Different projects will have different sets of lanes (eg if they have separate analysis and QA sign-off stages). Don’t confuse it with waterfall – stories move through independently (and as quickly as possible). Think of cards as kanbans requesting features. The customer pulls features from the ‘done’ end, but because the feature needs to pass through each stage the kanban gets passed all the way back to the backlog. Obviously in practice it just starts in the backlog like a normal story card. WIP limit of three in live (one per pair). Also have ‘blocked’ drawer off to the side, and yellow non-story cards for technical debt repayment etc. When a pair is available to work on a new story, agree with customer which one, and clarify acceptance criteria. Photos stuck on to show who ‘owns’ development of a story. Bugs found after delivery are added to live stories on red cards, and addressed ASAP.
- Backlog sorted into themes. Queue for top few backlog items (chosen by customer). Now have queue, analysis, development, acceptance and done. Explicit criteria for moving between stages. WIP limit for each stage. Buffers for features which have met transition criteria but don’t fit in next stage because of WIP limits. Done means accepted by customer and deployed on live system. Expedite lane for emergency stories (not subject to WIP limit). We don’t often use it.
- We currently aren’t estimating stories, but were previously using points. An alternative is to split stories until they’re all approximately the same estimated size, then just count stories in stead of points. By recording when a story moved into ‘live’ and then into ‘done’, we can calculate a rough cycle time figure. This allows us to provide an ‘estimated queuing time’ (like Alton Towers). The same could be done for the beginning of the backlog. Lean seems to focus more on cycle time than throughput, but we can also use the same numbers to estimate how far through the backlog we expect to get in a particular period of time. In practice we’ve found that the backlog stories and their priorities change too fast to make this a useful figure.
- This was something we tried for a while, but it didn’t seem to provide much value and I was fed up with being the only person to ever update it. Basically a chart of the size of each lane over time. Provides some visual indication of progress (or lack of it) and bottlenecks.
- Simpler! Less time spent analysing stories in backlog. Less exposure to customer changing his mind. Acceptance/demo/deployment can happen at any time. No faffing around figuring out what to do with stories that cross the iteration boundary. Stories can be larger if necessary. Exposes bottlenecks and imbalances.
- Less explicit visibility of progress. Miss satisfaction and celebration from completing an iteration.