Lean and Kanban Principles for Software Developers
•
2 recomendaciones•2,402 vistas
This was a presentation given for the South Florida Code Camp in March, 2010 covering the basics of Lean and Kanban principles for Software Developers
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (17)
Destacado
Destacado (20)
Similar a Lean and Kanban Principles for Software Developers
Similar a Lean and Kanban Principles for Software Developers (20)
Más de Cory Foy
Más de Cory Foy (20)
Último
Último (20)
Lean and Kanban Principles for Software Developers
- 1. LEAN, KANBAN, AGILE @cory_foy | Cory Foy | http://coryfoy.com
- 2. Hi
- 3. Lean
- 4. Kanban
- 5. Waterfall
- 7. Waterfall Requirements Design
- 8. Waterfall Requirements Design Development
- 9. Waterfall Requirements Design Development Test
- 10. Waterfall Requirements Design Development Test Credit: http://www.flickr.com/photos/tonymangan/611780383
- 11. Agile
- 12. Agile Waterfall Agile 70 52.5 35 17.5 0 Q1 Q2 Q3 Q4 Q5 Q6
- 13. Scrum
- 14. Scrum
- 15. Scrum Ideal Actual 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10
- 16. Scrum Ideal Actual 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10
- 17. Scrum Ideal Actual 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10
- 19. Productivity
- 21. Developer
- 22. Lines of Code Developer
- 23. More Lines of Code Developer
- 24. Goodness More Lines of Code Developer
- 25. Goodness More Lines of Code Great Developer
- 26. Tester
- 27. Bugs Found Tester
- 28. More Bugs Found Tester
- 29. More Bugs Found More Goodness Tester
- 30. More Bugs Found More Goodness Awesome Tester
- 31. Company
- 32. Sales Company
- 33. More Lines of Code Sales Company
- 34. More Bugs Sales Company
- 35. More Sales Company
- 36. More Sales More Money Company
- 37. More Sales More Money Happy Customers Company
- 38. More Sales More Money Happy Customers Happy Company
- 39. More Sales More Money Happy Customers Happy Company Happy Developers
- 40. Waiting Development Test Feature 1 64-Bit Priority Bug 2 Testing Bug 17 Feature 11 Priority Bug 7 Feature 18 Bug 4 Feature 42
- 41. Waiting Development Test Feature 1 64-Bit Priority Bug 2 Testing Bug 17 Feature 11 Priority Bug 7 Feature 18 Bug 4 Feature 42
- 42. Waiting Development Test 64-Bit Testing Feature 1 Priority Bug 7 Priority Bug 2 Feature 18 Bug 17 Feature 11 Bug 4 Feature 42
- 43. Waiting Development Test Priority Bug 7 64-Bit Feature 18 Testing Bug 4 Feature 42 Feature 1 Priority Bug 2 Bug 17 Feature 11
- 44. Capacity
- 45. Waiting [8] Dev [4] Test [2] Feature 1 64-Bit Priority Bug 2 Testing Bug 17 Feature 11 Priority Bug 7 Feature 18 Bug 4 Feature 42
- 46. Waiting [8] Dev [4] Test [2] Feature 1 64-Bit Priority Bug 2 Testing Bug 17 Feature 11 Priority Bug 7 Feature 18 Bug 4 Feature 42
- 47. Waiting [8] Dev [4] Test [2] 64-Bit Priority Bug 2 Testing Bug 17 Feature 1 Feature 11 Priority Bug 7 Feature 18 Bug 4 Feature 42
- 48. Waiting [8] Dev [4] Test [2] Priority Bug 7 64-Bit Priority Bug 2 Testing Bug 17 Feature 1 Feature 11 Feature 18 Bug 4 Feature 42
- 49. Lean
- 52. Seven Principles Decide as late as possible
- 53. Seven Principles Deliver as fast as possible
- 54. Seven Principles Empower the team
- 56. Seven Principles See the Whole
- 57. Theory
- 58. Implementation
- 59. Four Steps
- 61. Understand Your Existing Process Value Stream Map
- 63. Customer Enters Bug to Emails Rep Tracker
- 64. Customer Enters Bug to Executive Emails Rep Tracker Review
- 65. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix in Version
- 66. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to in Version Dev Team
- 67. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team
- 68. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Test Team
- 69. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Tested Test Team
- 70. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Release Tested Test Team Planning
- 71. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Release Tested Test Team Planning Deploy to Beta Site
- 72. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Release Tested Test Team Planning Deploy to Tested Beta Site
- 73. Customer Enters Bug to Executive Emails Rep Tracker Review Assigned Fix Assigned to Coded in Version Dev Team Assigned to Release Tested Test Team Planning Deploy to Deploy to Tested Beta Site Production
- 74. Customer 1 Enters Bug to 1-2 Executive Months Emails Rep Week Tracker Review 1 Day Assigned Fix 3 Assigned to 2 Weeks Weeks Coded in Version Dev Team 1 Day Assigned to 1 4 Release Week Tested Weeks Test Team Planning 2 Days Deploy to 1 1 Deploy to Week Tested Week Beta Site Production
- 75. Customer 1 Enters Bug to 1-2 Executive Months Emails Rep Week Tracker Review 1 Day Assigned Fix 3 Assigned to 2 Weeks Weeks Coded in Version Dev Team 1 Day Assigned to 1 4 Release Week Tested Weeks Test Team Planning 2 Days Deploy to 1 1 Deploy to Week Tested Week Beta Site Production
- 76. Reduce Waste
- 78. Reduce Waste -> Seven Wastes Partially Done Work
- 79. Reduce Waste -> Seven Wastes Extra Features
- 80. Reduce Waste -> Seven Wastes Lost Knowledge
- 81. Reduce Waste -> Seven Wastes Handoffs
- 82. Reduce Waste -> Seven Wastes Task Switching
- 83. Reduce Waste -> Seven Wastes Delays
- 84. Reduce Waste -> Seven Wastes Defects
- 85. Reduce Waste Write Less Code
- 87. Reduce Waste Single Responsibility Principle SOLID
- 88. Reduce Waste Single Responsibility Principle SOLID Open-Closed Principle
- 89. Reduce Waste Single Responsibility Principle SOLID Open-Closed Principle Liskov Substitution Principle
- 90. Reduce Waste Single Responsibility Principle Interface Segregation Principle SOLID Open-Closed Principle Liskov Substitution Principle
- 91. Reduce Waste Single Responsibility Principle Interface Segregation Principle SOLID Dependency Inversion Principle Open-Closed Principle Liskov Substitution Principle
- 92. Reduce Waste TDD
- 93. Reduce Waste TDD Test-Driven Development
- 94. Reduce Waste Behavior-Driven Development TDD Test-Driven Development
- 95. Reduce Waste Behavior-Driven Development TDD Test-Driven Development Acceptance-Test Driven Development
- 96. Reduce Waste Minimal Useful Feature
- 97. Reduce Waste Justify Every Feature
- 98. Reduce Waste Don’t Automate Complexity
- 99. Deliver Fast
- 103. Make it Visible
- 104. Make it Visible Big Visible Wall
- 105. Make it Visible Big Visible Wall
- 106. Make it Visible Big Visible Wall
- 107. Make it Visible Kanban Board
- 108. Make it Visible Kanban Board
- 109. Make it Visible Kanban Board
- 112. Make it Visible Build Lamp
- 113. Make it Visible Build Lamp
- 114. Be Lean
- 115. Be Mean
- 116. •Cory Foy •Slides at: http://coryfoy.com •Email: foyc at cory foy dot com •Twitter: @cory_foy
Notas del editor
- I’m Cory Foy. Agile Coach, consultant and developer. You can find me at http://www.coryfoy.com, or on Twitter as @cory_foy.
- We’re going to cover two main concepts. Lean
- and Kanban, all within the context of delivering software faster. But to talk about Lean and Kanban, we need to first talk about some Models of Software Development.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- True waterfall, everything flows downwards. If you are going back up, you are either doing it wrong. Or Salmon. Possibly salmon.
- Goal behind agile methods is a collaborative environment that gets us to market faster, so we can make money faster
- Goal behind agile methods is a collaborative environment that gets us to market faster, so we can make money faster
- Goal behind agile methods is a collaborative environment that gets us to market faster, so we can make money faster
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- Scrum is best known methodology. But when you look at the burndown chart, you can see a pattern suspiciously similar to what we saw in waterfall. But worse - we have a gap. And it’s caused by something interesting
- You might ask yourself how productivity would cause us to *not* deliver. Ask audience to define productivity.
- Productivity is defined by how we are paid
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- And then you end up with Happy Developers
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- 64-Bit Testing occupying QA. Devs keep working. Push completed work to QA queue. So they can be “productive”. But, is this productive? Heck, no! We’re not shipping anything. Unverified Expectations
- One def of Kanban: A team has a capacity and is willing to set limits
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- When the Dev and Test queues are full, the dev team could go home, or work to clear the queues. Not pull from the waiting queue for the sake of “productivity”
- This concept of looking at the whole is one of the fundamental tenants of Lean Software. Lean Software Development: An Agile Toolkit
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- 10% Efficiency Rate
- If you have 5 half-done novels, you ain’t got nothin’ to sell.
- Clearing a bottleneck reveals the next bottleneck in the stream
- 100% Utilization is not ideal
- The amount of time it takes for a work item from entering the system to exiting the system