Lean Concepts & Agile Software Methodologies
•Télécharger en tant que PPTX, PDF•
3 j'aime•4,505 vues
Presentation introducing the core concepts of Lean in manufacturing and an exploration of the various Agile software engineering approaches which apply these principles to increase the responsiveness of product development. Download and reference notes for full detail.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Lean Concepts & Agile Software Methodologies
Similaire à Lean Concepts & Agile Software Methodologies (20)
Dernier
Dernier (20)
Lean Concepts & Agile Software Methodologies
- 1. Lean Concepts & Agile Development
- 2. Lean Concept Recap Lean Manufacturing Tenets Specify Value Map the Value Stream Visualize Work Create Flow – Eliminate Waste Develop Customer Pull Continuous Improvement Toyota’s Taiichi Ohno
- 3. Why Implement Lean? Manufacturing Example & Result in Our Market
- 4. Lean in Our Market The Problem Sales at record levels Inventory too high Costs too high Unhappy Workers Long, costly change- overs The Lean Solution Shift to cellular manufacturing 200+ Kaizen Events Yearly Employee Cross-Training Strategic Insourcing Executed at all levels Value Stream Managers
- 5. Lean in Our Market The Results 220% Productivity Increase 400% Inventory Turns Increase 200% Sales Increase 10x Profit Improvement
- 7. Software Development Methodologies Software Development Methodology Framework used to structure, plan and control the process of developing software and information systems. Common Methodologies Waterfall - 1970’s to present, very old school Agile/Scrum - 2001 to present, modern & lean Kanban (“Scrumban”) - Now, continuous & lean
- 8. Lean Software Engineering Waterfall: The Traditional Approach Example Practitioners
- 9. Lean Software Engineering Waterfall: What it Looks Like in Practice Lots of artifacts and long development cycles Lots of WIP, rework, “inventory”
- 10. Lean Software Engineering Agile/Scrum: Software Engineering Gets Lean Example Practitioners
- 11. Lean Software Engineering Agile/Scrum: What it Looks Like in Practice
- 12. Lean Software Engineering Kanban: Software Engineering Gets Lean(er) Example Practitioners
- 13. Lean Software Engineering Kanban: What it Looks Like in Practice READY WIP READY TO SHIP
- 14. Lean Software Engineering Dual Track Scrum: Emerging Concept Discovery Track Quickly generating validated product backlog items in collaborative sessions with engineers & designers for Delivery Track. Delivery Track Engineering releasable software based on backlog items qualified and defined in Discovery Track.
- 15. Lean Software Engineering Additional Agile Reading & References Introduction to User Stories: http://www.agilemodeling.com/artifacts/userStory.htm#Introduction Scrumban Overview: http://leansoftwareengineering.com/ksse/scrum-ban/ Dual-Track Scrum: http://www.svpg.com/dual-track-scrum/
- 16. Ryhme and Reason Why Responsive Development Is Important
Notes de l'éditeur
- The term Kanban originated with physical cards that were placed in inventory bins that aided employees to visually identify when inventory was running low and it was time to “pull” more inventory.
- Billion,Wisconsin manufacturer of snowblowers and lawnmowers800+ employeesInventory was frequently returned from distributors and stacking upChangeover from lawn to snow took 2 weeks and $1 Million+ YearlyHOWNew leadership that distinguished itself, listened and communicated franklyExecutive commitment – spent days collaborating in lean eventsIssues made visible to allEmployee cross-training eliminated layoffsCellular manufacturing eliminated change-over costs and enabled additional units to be made on demandExtra capacity created allowed insourcing – smoother supply, higher quality
- Methodologies represent natural progression as tools and technology have improved – an demand more rapid changes.Kanban is used by many startups and is recommended by startup guru Eric Ries
- Been around since 1970Sequential phases from requirements (PRD) to dev to release. Very rigid and formally documentedFeedback loops exist between phases to support modifying plans based on observed infoPlanning & requirements do not include feedback from developers - assumes feasibilityLittle crossover and collaboration - siloed groups (Research, planning, dev, testing)Attempts to plan milestones and costs of entire project up-front. Very likely to be wrong.Attempts to develop whole, entire projects at once...no breaking up so feedback loops are too little too late. Massive WIP – very little “shippable” at one time.Underlying Assumptions:There exists a reasonably well-defined set of requirements if we only take the time to understand them.During the development process, changes to requirements will be small enough that we can manage them without substantially rethinking or revising our plans.Software innovation and the research and development that is required to create a significant new software application can be done on a predictable schedule.
- Tons of documentationRigidReally formalSlow to change
- More responsive - 2 weeks sprints & iterationsMore flexible backlog and planning - anything outside of sprint is open for modificationFrequent shipping of functional elements (roughly every 2 weeks)Decreased focus on documentation and increased focus on interactionFocused on collaborative planning and requirements definition - reduces amount of rework and unfeasible requirementsSupport iterative and continuous improvement, assumes things will continue to be refinedRecognizes and addresses long timeframes and large projects will inevitably be derailed by unforseenchallenges
- Basic visualizationStill a little hard to grasp at a glanceCompartmentalized into sprintsScope, effort, and capacity measured by story points via “planning poker” during Sprint planningSprints formally scheduled with associated work scheduled for completion and release at a specific date.
- Visualization of statuses and progressIncreased responsivenessStandardized, flexible backlogTrue Pull systemConstant smooth process, elimination of rigid plan/release cyclesFocus on cycle time and throughput in place of burndown
- Visualize status at a glanceHard limit on WIPStrengthen “Pull” ProcessBetter OrganizationMore IntelligibleCapacity and performance gauged by story throughputIn order to properly project performance and throughput, all stories must be broken down into approximately identical and consistent sizes.Very little/loose calendar association (no defined beginning and end of periods and bodies of work)
- Helps reduce drawn out Sprint planning sessions with undefined user storiesIncreases collaboration with Engineers and Designers when defining stories, easing transition to production and deliveryFurther eliminates mini-waterfall effect of each specialized group creating artifacts and passing onto the next group for execution without collaborative definition sessionHeavy focus on Lean UX and prototyping in place of artifacts