Guru4 pro lean_software_development_v1.0
•Descargar como PPT, PDF•
1 recomendación•482 vistas
Dutch presentation given on a Guru4Pro (Logica Event) in November 2010.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Similar a Guru4 pro lean_software_development_v1.0
Similar a Guru4 pro lean_software_development_v1.0 (20)
Guru4 pro lean_software_development_v1.0
- 2. Guru4Pro Lean Software Development Edward Crain 29 November 2010
- 3. AGENDA INTRODUCTIE Introductie van Lean WAAROM LEAN SD? Redenen om Lean principes toe te passen in software dev. LEAN SD Uitleg wat Lean SD is TOEPASSING LEAN SD Uitleg hoe je de principes kan toepassen PUNTEN OM MEE TE NEMEN Ideëen om na afloop mee te nemen
- 4. Introductie De Lean filosofie is een 'continuous improvement' Lean filosofie. De kern draait om: Maximaliseren klantwaarde Minimaliseren verspilling
- 5. Waarom Lean SD? Hou het groter In softwareontwikkeling ligt de focus vaak op geheel in subproces optimalisatie “We moeten de requirements SMART maken.” het oog Stel elk subproces in SD leidt tot 90% first pass though? 90% x 90% x 90% x 90% x 90% x 90% x 90% = <50%
- 6. Waarom Lean SD? Scheduled loss (overhead) Hidden Unscheduled “Fix it” loss Process rate (equipment failure ) Factory Hidden loss Fabriek (naast Total Factory Quality/Yield hoofdfabriek) die al loss Time (rework) de fouten en Transition loss (product A B, vb vertragingen oplost. ReqDesign) Verspillingen bij Valuable software Operating Time development Rework No Demand Overdracht
- 7. Waarom Lean SD? People • Who is doing the job? oriented “If I could only get the right person in this job, everything companies would be peachy…” Process • Vertrouw op mistake-proof process, voor een oriented levering die op tijd is en zonder fouten business “Watch your product not your people.” Local Hero Mistake-proof process
- 8. Mary and Tom Lean Poppendieck Software Development Vertaling van Lean Manufacturing. Uiteindelijk gaat het om goed werkende software. Al het overige levert geen waarde (value) op voor de klant. Grootste verspilling Extra Features
- 10. Toepassing Lean SD Piloting Wie is je klant? Wat willen ze? Lean Analyseer de huidige status van je proces (non-value add vs value add) Ontwikkel een toekomstig proces • Eliminate waste • Build quality in • Create Knowledge • Defer Commitment • Deliver Fast • Respect People • Improve the System Implementeer de verandering Monitor en behoud de verbetering Blijf continu verbeteren
- 11. Toepassing – Analyseer huidige status Value Een tool om de grootste verspilling (of mogelijkheid Stream tot verbetering) in een proces te vinden. Map Wat zijn de stappen?, Waar zit wachttijd?, Waar zit de value?, Waar zit de waste? VSM of small, high-priority feature change request
- 12. Toepassing – Analyseer huidige status Eliminate Vaak veel verspilling in communicatie via email waste Niets werkt beter dan 1 op 1 interactie! Hou een daily stand-up meeting met iedereen binnen het team. Voorkom volle email inboxen!
- 13. Toepassing – Ontwikkel toekomstig proces Voordelen One-piece-flow t.o.v. Batch Deliver Verhoogt productiviteit Fast Creëert flexibiliteit Verhoogt moraal Verlaagt voorraad
- 14. Toepassing – Ontwikkel toekomstig proces Improve KanBan (Make the Invisible Visible ) the Visuele transparantie naar Management – System Verlaagt de effort om een update te geven aan het management Visuele transparantie naar Business – Geeft direct feedback op voortgang/vertraging van features en biedt de mogelijkheid om vroeg in te grijpen
- 15. Toepassing – Ontwikkel toekomstig proces Improve Creëer visuele transparantie met KanBan: Per release the Per iteration/sprint System Per task *http://www.infoq.com/articles/agile-kanban-boards
- 16. Toepassing – Ontwikkel toekomstig proces Improve the Een voorbeeld met KanBan. System *Kanban and Scrum – Henrik Kniberg (http://www.amazon.com/Kanban-Scrum-making-most-both/dp/0557138329
- 17. Toepassing – Ontwikkel toekomstige proces Improve Group by Product using cross-functional teams the System REQ DEV Product A Product B TEST DBA Product D Product C *Kanban and Scrum – Henrik Kniberg (http://www.amazon.com/Kanban-Scrum-making-most-both/dp/0557138329
- 18. Toepassing – Improve Continuously Evalueer continu: Retrospectives Na elke iteratie Na elke release Gebruik “Snake on the wall”
- 19. Punten Om Mee te Nemen Thoughts Kijk naar je eigen proces vanuit de optiek to Ponder van de klant (outside-in-thinking) Wat levert waarde op? En vooral wat niet? Toon moed en durf te veranderen! Identificeer en bestrijd verspilling Doe retrospectives en blijf continu verbeteren
- 21. Bijlage – Optimize the Whole
- 22. Bijlage – Prescriptive vs Adaptive *ScrumBan by Corey Ladas http://www.amazon.com/Scrumban-Essays-Systems-Software-Development/dp/0578002140
- 23. Bijlage – Long Running Tasks *ScrumBan by Corey Ladas http://www.amazon.com/Scrumban-Essays-Systems-Software-Development/dp/0578002140
- 25. <Vervallen sheet> Waarom Lean SD? Ik sjouwhelp een muur Ik stenen Wat ben je teWe helpen de bouwen welvaart van ons aan het land te doen? verdedigen! Binnen Software ontwikkeling denkt met nog Lean steeds heel erg in hokjes: Thinking “Ik bouw aan deze module.” “Ik schrijf Use Case 01” “Ik test de performance” Etc.
Notas del editor
- http://www.lean.org/whatslean/principles.cfm 1. Centraal staat altijd de klant. Waar wil hij voor betalen? Ofwel, welke activiteiten zijn voor hem van waarde? Lean zegt: Doe alleen dat wat van waarde is voor je klant. Dat lijkt logisch, maar hoe vaak doen we niet dingen om onze baas te plezieren in plaats van onze klant? Ik denk maar eens aan rapportages, het tellen van voorraden, of het aanvragen van subsidies. 2. Om de waarde voor de klant te onderscheiden van verspillingen is het goed een waardestroom op te stellen. Hierin worden alle activiteiten binnen een bedrijf in kaart gebracht, van klantvraag tot levering, en wordt voor elke activiteit bepaald of ze waarde toevoegt voor de klant. Verbeteren wordt nu simpel: minimaliseer alle niet waarde toevoegende stappen! En het maakt niet uit of ik nu vliegwielen, vliegtuigen of vliegreizen verkoop. 3. Beleg verantwoordelijkheden laag in de organisatie; Laat de mensen die het werk doen ook zelf de beslissingen nemen. 4. Maak beslissingen op basis van gegevens. Objectiveer je beslissingen. Neem beslissingen op basis van de maximale hoeveelheid beschikbare informatie. Houd het grotere geheel in het oog. Pas op voor suboptimalisatie. Continue verbeteringen. Aaneenschakeling van kleine successen. Zelfs Toyota, dat al meer dan 50 jaar op deze manier zijn bedrijfsprocessen (en dat is dus veel meer dan alleen hun productie) probeert te verbeteren, zegt nog maar op 70% te zitten van wat ze haalbaar achten. Maar ze gaan door in hun streven naar perfectie. Net als dat kinderdagverblijf, dat probeert haar dienstverlening uit te breiden naar 24 uur, er naar streeft vragen om plaatsing binnen twee weken te honoreren, zijn medewerkers continu bijschoolt en daarbij vrolijke kinderen in een veilige omgeving voor een betaalbare prijs als belangrijkste uitgangspunt neemt
- Scheduled losses: Geplande onderhoud, inspecties, testen, project werk Unscheduled losses: Willekeurige ongeplande gebeurtenissen. Netwerk down etc. Process rate loss: Processen die niet goed op elkaar aansluiten, vb. Dat je project in verschillende fases zit. Deel Startup deel initiation. Quality/Yield loss: Off-spec product made, rework, contamination, not first pass/first quality Transition loss: All losses associated with transitioning from 1 product to another Valuable operation time: First quality production
- The biggest Wastes are extra features, churn and crossing boundaries Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community. Lean development could be summarized by seven principles, very close in concept to lean manufacturing principles. The term Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck. Lean Software Development
- Eliminate Waste: Waste is anything that does not add value to a product, value as perceived by the customer. In lean thinking, the concept of waste is a high hurdle. The Biggest wastes in software development are extra features, churn and crossing boundaries. Built Quality In: If you routinely find defects in your verification process, your process is defective. Write executable specifications instead of requirements. Stop Building Legacy Code; Legacy code is code that lacks automated unit and acceptance tests. Create Knowledge: The best approach to improving a software development environment is to amplify learning. Planning is useful. Learning is essential. Als iets moeilijk is dan moet je het gewoon vaker doen;-) Defer Commitment: In an evolving market, keeping design options open is more valuable than committing early. A key strategy for delaying commitments when developing a complex system is to build a capacity for change into the system. Abolish the idea that it is a good idea to start development with a complete specification. Deliver Fast: In development the discovery cycle is critical for learning: Design, implement, feedback, improve. The shorter these cycles are, the more can be learned. Speed assures that customers get what they need now, not what they needed yesterday Respect People: R espect for and sensitivity to morale, not making people do wasteful work, real teamwork, mentoring to develop skillful people, humanizing the works and environment, safe and clean environment and philosophical integrity among the management team Improve the System: Integrity in complex systems requires a deep expertise in many diverse areas. One of the most intractable problems with product development is that experts in any area (e.g., database or GUI) have a tendency to maximize the performance of the part of the product representing their own specialty rather than focusing on overall system performance
- Vb. vliegritten, wie is je klant? Niet management, maar passagiers Measure performance (lead time, #defects, % on time delivery)
- Example 2 ( Figure 4.4) is a value stream map for a request of about the same size as the request in Example 1 ; a simple feature change that takes about two hours to code and test. However, it takes more than six weeks to complete the work. From the customers' viewpoint, it takes an extra 15 minutes to write up a request because a standard form must be used that requires a lot more information. Since requests are reviewed once a week, the request waits an average of a half week before approval. Then the request waits an average of two weeks for one of the scarce architects, and after a technical review, it waits an average of two more weeks for developers to become available. After two hours of coding and testing, the request waits for an average of a week, because releases are scheduled for once every two weeks. Just before release there is a final verification. Even though the code was thoroughly tested when it was written, some code added to the release package in the last week has introduced a defect into the feature which went undetected until final verification. So it takes four hours to fix and retest the release, which, you will notice, is twice the time it took to write and test the code in the first place. Since verification only took 15 minutes in the previous example, the other three hours and forty five minutes are waste introduced by the process. Finally everything is ready to deploy, but it takes an average of another half week for the original requestor to get around to using the new feature in production
- Bij geen continuous flow, soms hard rennen, soms rustig. Ritme proces moet overeenkomen met ritme van de klant. Bij SD is dat niet het geval. Cultuur “never pass a defect”, controleer je eigen werk en dat van anderen. Kosten nemen toe naarmate je later in het proces je fouten ontdekt.
- Snake on the wall: What does this accomplish? • it validates real issues • it kills false beliefs and misdirected complaints • it quantifies the impact of impediments • it creates transparency for managers who don't believe what you say • it empowers the team • it is immediate • it self-prioritizes • it uncovers surprises