Kontinuierliche verbesserung in php projekten
•Télécharger en tant que KEY, PDF•
1 j'aime•776 vues
Recommandé
Recommandé
Contenu connexe
Similaire à Kontinuierliche verbesserung in php projekten
Similaire à Kontinuierliche verbesserung in php projekten (10)
Plus de Johann-Peter Hartmann
Plus de Johann-Peter Hartmann (20)
Kontinuierliche verbesserung in php projekten
- 1. Kontinuierliche Verbesserung in PHP-Projekten Thorsten Rinne ist in Australien, statt dessen dann ich. © 2011 Mayflower GmbH
- 2. Continuous Integration? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 2
- 3. Continuous Inspection? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 3
- 4. Continuous Delivery? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 4
- 5. http://www.flickr.com/photos/nataliaromay/3217596831/ Warum brauchen wir kontinuierliche Verbesserung? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 5
- 6. Wir sind Entwickler Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I
- 7. Wir sind Entwickler Wir sind nicht der Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I
- 8. Wir sind Entwickler Wir sind nicht der Wir sind nicht perfekt, aber wir wissen das immerhin. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I
- 9. „Continuous Improvement is better than delayed perfection.“ Mark Twain Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 7
- 10. Aber was genau ist kontinuierliche Verbesserung? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 8
- 11. „A continuous improvement process is an ongoing effort to improve products, services or processes. These efforts seek incremental improvement over time or breakthrough improvement all at once.“ Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 9
- 12. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 10
- 13. Continuous Improvement ~ Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 11
- 14. KAI ZEN = = Wandel Gut Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 12
- 15. Attention! Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 13
- 16. Das komplette Unternehmen muss den Wandel wollen! Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 14
- 17. In 3 Schritten zur kontinuierlichen Verbesserung Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 15
- 18. 1 Was wollen wir erreichen? Welche Probleme und Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 16
- 19. 2 Was machen wir konkret? Welche Maßnahmen machen Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 17
- 20. 3 Wir entscheiden, welche Maßnahmen in Verbesserungen Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 18
- 21. Plan Do Act Check Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 19
- 22. PLAN: Was wollen wir Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 20
- 23. Plan Do Act Check Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 21
- 24. DO: Durchführen der Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 22
- 25. Plan Do Act Check Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 23
- 26. CHECK: What did we achieve? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 24
- 27. Plan Do Act Check Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 25
- 28. ACT: Es zum Standard Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 26
- 29. Plan Do Act Check Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 27
- 30. Ok, Theorie ist klar, was macht die Praxis? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 28
- 31. SCRUM Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 29
- 32. SCRUM Retrospektiv e Return Gift wrap Cancel Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 33. SCRUM Retrospektiv Sprint e 2 weeks Return Gift wrap Cancel Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 34. SCRUM Retrospektiv Sprint e 2 weeks Sprint goal Return Gift wrap Cancel Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 35. SCRUM Retrospektiv Sprint e 2 weeks Sprint goal Return Sprint backlog Gift wrap Cancel Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 36. SCRUM Retrospektiv Sprint e 2 weeks Sprint goal Return Sprint Potentially backlog shippable Gift wrap product increment Cancel Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 37. SCRUM Retrospektiv Sprint e 2 weeks Sprint goal Return Sprint Potentially backlog shippable Gift wrap product increment Cancel CS fixes Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 38. SCRUM Retrospektiv Sprint e 2 weeks Sprint goal Return Sprint Potentially backlog Cancel shippable CS fixes product increment Gift wrap Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 39. SCRUM 24 hours Retrospektiv Sprint e 2 weeks Sprint goal Return Sprint Potentially backlog Cancel shippable CS fixes product increment Gift wrap Product backlog Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 30
- 40. SCRUM: Velocity als transparente Effizienz Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 31
- 41. Plan Do Act Check Typische Fehler: - Retrospektiven ohne C&A - Shippable - SCM ignoriert das Produkt selbst - Velocity wird ignoriert Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 32
- 42. Extreme Programming Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 33
- 43. Extreme Programming: Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 34
- 44. Extreme Programming: Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 35
- 45. Extreme Programming: Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 36
- 46. Fazit: Agile Methoden sind für kontinuierliche Verbesserung gemacht! Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 37
- 47. Scrum + XP + Continuous EPIC WIN Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 38
- 48. Technische Kontinuierliche Verbesserung Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 39
- 49. Mit einer alten Code- Basis arbeiten Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 40
- 50. Code Aging Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 41
- 51. Technical Debt Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 42
- 52. „We can do things quick and dirty. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 43
- 53. „We can do things quick and dirty. The dirty way leads to technical debt. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 43
- 54. „We can do things quick and dirty. The dirty way leads to technical debt. This can kill a software.“ Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 43
- 55. Warum auch das Management keinen Technical Debt will: Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 44
- 56. Kosten pro Feature / Bug fehlendes Refactoring maximaler Businessvalue DEAD END! Zeit Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 45
- 57. Ohne Rückzahlung der technischen Schulden stirbt die Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 46
- 58. Kontinuierliches Refaktorieren der Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 47
- 59. PHP Tool Support Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 48
- 60. Ein CI-Server muss da sein. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 49
- 61. Ein CI-Server muss da sein. Selbst wenn man keine Unittests Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 49
- 62. (Bitte nicht Sebastian Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 50
- 63. Jenkins CI Server Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 51
- 64. Netterweise gibts schon eine schöne PHP- Integration: http://jenkins- php.org Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 52
- 65. $ pear channel-discover pear.pdepend.org $ pear channel-discover pear.phpmd.org $ pear channel-discover pear.phpunit.de $ pear channel-discover components.ez.no $ pear channel-discover pear.symfony-project.com $ pear install pdepend/PHP_Depend $ pear install phpmd/PHP_PMD $ pear install phpunit/phpcpd $ pear install phpunit/phploc $ pear install PHPDocumentor $ pear install PHP_CodeSniffer $ pear install --alldeps phpunit/PHP_CodeBrowser $ pear install --alldeps phpunit/PHPUnit Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 53
- 66. PHP_CodeSniffer Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 54
- 67. Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 55
- 68. PHP_CodeBrowser Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 56
- 69. Cinder Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 57
- 70. Todolist 1. Commitment von _jeder_ Seite schaffen 2. Organisatorische Infrastruktur schaffen 3. Technische Infrastruktur schaffen 4. Nachvollziehbare Verbesserung produzieren Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 58
- 71. Questions? Continuous Improvement in PHP Projects I Mayflower GmbH I 25th February I 59
Notes de l'éditeur
- \n
- Wer benutzt continuous integration?\nJenkins? Bamboo? phpUnderControl?\nPHPUnit? Unittests?\n
- PHP_CodeSniffer? phpcpd?\nWer benutzt diese Tools??\n
- Wer macht die Releases? Können jederzeit welche passieren? \n
- \n
- \n
- \n
- \n
- Aber was steht genau dahinter? \n
- Dahinter steht die Einsicht, dass eine konsequente Verbesserung überall in kleine Schritten mehr Früchte trägt als die Hoffnung auf ein Silver Bullet, das einen magischen Durchbruch erlaubt.\n
- Die Idee stammt nicht von uns Software-Jungs, sonder bildet die Grundlage des Erfolges der japanischen Automobilhersteller in der Nachkriegszeit. \n\n
- Die Idee hat sich einen Weg durch alle Branchen gefressen, und findet sich als KaiZen, als TQM, als Kontinuierlicher Verbesserungsprozess und ähnliches in fast jedem mittlerem und grossen Unternehmen. \n\n
- KAIZEN sind zwei Worte, \nKAI steht für Wandel | ZEN steht für das Gute\nder Wandel zu etwas Besserem ist also die Motivation.\n
- Und da beginnen auch die Probleme - Wandel bringt Probleme\n\n
- Wenn das Management, die Projektleiter, die Gamedesigner, die Entwickler oder die Admins den Wandel nicht wollen - weil sie ihm etwa nicht trauen - funktioniert es nicht. Auch nicht der Wandel zum Guten.\n
- \n
- Dieser Schritt wird vom ganzen Team in einem Workshop gemacht. Im Gegensatz zur klassischen Unternehmensführung geht es hier nicht um Vorgaben des Managements, sondern um eine gemeinsame Einschätzung der Leute, die es betrifft. In Scrum nennt man diesen Workshop Retrospektive. Probleme und Chancen werden durch die Betroffenen priorisiert.\n
- Aus den Problemen und Chancen entwickeln wir Maßnahmen - aber nicht jede Maßnahme taugt, denn das Ziel sind kontinuierliche, kleine Verbesserungen und keine Revolutionen. \n
- Weiss jemand, wie das geschieht? Woran erkennt man, dass ein Maßnahme eine Verbesserung sein wird? \n
- Die Antwort ist einfach: man kann es nicht vorher entscheiden, man muss es probieren. \nEiner der Leute, die damals von MacArthur nach Japan geholt wurden war William Edwards Deming, und hier sehen wir den Deming-Circle, der genau mit der Tatsache umgeht, dass man erst hinterher weiß, obs gut war.\n
- Zunächst Planen, das ist der oben genannte Workshop bzw. die Scrum-Retrospektive.\n\n
- Second part is DO.\n
- Dann wird die Änderung durchgeführt - das muss btw. nicht überall sein, und es muss sich auch nicht um eine grundlegende Änderung handeln. Hiermit kann auch ein kleiner Probelauf, zum Beispiel ein Architectural Spike als Test im nächsten Sprint gemeint sein.\n\n
- Der dritte Schritt ist CHECK\n
- Die Resultate werden geprüft, und es wird beurteilt, ob es so überall eingeführt werden kann, ob es angepasst und nicht mal probiert werden muss oder ob es einfach nur eine Schnappsidee war. \n\n
- Last step: ACT\n
- Wenn man festgestellt hat das es taugt, wird es auf breiter Front eingeführt. Bis es aufhört zu taugen und wieder als Problem auftaucht.\n
- Einer dieser Cycles bezieht sich also nur auf eine Veränderung, auf nur eine Maßnahme, von der man erst nach dem Durchlauf weiss, ob sie was getaugt hat. \n
- \n
- \n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- In Scrum nimmt die Retrospektive die Rolle der kontinuierlichen Verbesserung ein. Auch das konsequente Liefern von potenziell lieferbaren Produkten fokussiert auf kleine statt grundlegende Änderungen.\n
- Testgetriebene Entwicklung ist klassische Kontinuierliche Verbesserung: Es wird das Soll definiert, und dann das Ist so geändert, dass das Soll messbar erfüllt wird.\n
- Jetzt machen wir - wie auch hier - schon eine Weile Scrum, und da gibts auch schon Erfahrungen, warum das nicht immer klappt. \n
- Auch Extreme Programming bringt einige Ideen aus der kontinuierlichen Verbesserung mit.\n
- Testgetriebene Entwicklung ist klassische Kontinuierliche Verbesserung: Es wird das Soll definiert, und dann das Ist so geändert, dass das Soll messbar erfüllt wird.\n
- Kontinuierliche Integration sichert das Vorgehen in kleinen Schritten, und die permanente Prüfung dieser kleinen Schritte. Wenn sie das Gesamtsystem stören, wird es unmittelbar behoben.\n
- Refactoring beruht auf der Prüfung des bestehenden und passt dieses gegebenenfalls an.\n
- \n
- Wir haben also ohnehin schon die Plattform, die uns kontinuierliche Verbesserung bringt.\n
- Ein paar praktische Beispiele für kontinuierliche Verbesserung in PHP-Projekten.\n
- Bei PHP gab es ja nicht umsonst die Dark Ages. Erinnert sich noch jemand an PHP-Code, den er 2001 programmiert hat? Angeblich soll es sogar sehr erfolgreiche Browsergames auf einer solchen Basis geben. \n
- Aber auch bei neuem Code haben wir in PHP solche Probleme, schliesslich wollen die Leute schnelle Featureänderungen und viel Evolution. Das ist massgeblich für die Plattformentscheidung zu PHP:\n
- Das, was wir dann unsichtbar in der Software mitschleppen ist technical debt.\n
- Erfunden hat das Ward Cunningham 1992\n
- Erfunden hat das Ward Cunningham 1992\n
- Und damit will es btw genau Test Driven Development, Refactoring, etc. \n
- Wenn ich die Lebenszeit der Software auf eine Zeitachse lege, dann gibt es eine natürliches Ende des Lebens der Software - wenn der Aufwand zur Änderung höher ist als der Businessvalue der Änderung. Häufige Änderungen beschleunigen dieses Leben, Refactoring verlängert es.\n
- Ich kann also mit dem Einsatz von Refactoring nicht nur die laufenden Kosten der Software mittelfristig senken, sondern auch die Gesamtlebenszeit - und damit den Gesamt-ROI - vergrössern.\n
- Und da wir alle das Pech haben, dass unsere Lösungen erfolgreich sind und sich tatsächlich weiterentwickeln, müssen wir auch alle Refactorn.\n
- Netterweise hilft einem die PHP-Welt dabei, und versucht uns den Weg zu billig und schmerzfrei wie möglich zu machen.\n
- \n
- \n
- State-Of-The-Art tool ist Jenkins.\n
- Installation for PHPUnit, PHP_Depend, PHPMD, phpcpd, phploc,\nPHP_Documentator, PHP_CodeSniffer and PHP_CodeBrowser\n
- \n
- Der Codesniffer hilft mir bei einigen Varianten von Technical Debt - zB fehlender Inline-Dokumentation, schlechter Struktur und unlesbarem Code. Er verbilligt mir, in Deming-Circle gesprochen, den Plan-Anteil\n
- PHPMD ist der PHP Mess Detector, der ähnliches tut - allerdings tiefer in den Syntax und die Struktur eingesteigt, und auch Aussagen über Vererbungstiefe und ähnliches geben kann. Wie man an diesem Feature sehen kann kommt er aus der Java-Welt.\n
- Der Codebrowser kommt von Mayflower und ist ein einfaches Tool, dass die Ausgaben aller oben genannter Tools direkt im Sourcecode anzeigt. Das verbilligt den Do-Teil aus dem Deming-Circle, weil ich die Verbesserungen on the fly machen kann, wenn ich den Code ohnehin gerade verstehe.\n\n
- Cinder macht das gleiche - nur innerhalb von Eclipse. Die Ergebnisse aus meiner Jenkins-CI werden direkt auf meinen Code in der IDE abgebildet - und auf die Weise kann ich dort unmittelbar an meinem Code Verbesserungen vornehmen.\n\n
- \n
- \n