Shu Ha Ri

Technische Unfähigkeit bei Konzernen, Folge n+1 (Flinkster und Deutsch Bahn)

2011-02-06T19:56:00.009+01:00

Disclaimer: Ich weiss, dass es kindisch ist, diesen Eintrag zu schreiben, aber da ich schon gerade dabei war, mich aufzuregen...

Schon mal versucht einen Flinkster Vertrag online abzuschließen?
Wenn ja, dann hoffentlich mit einem Windows-Rechner mit der richtigen Version von Microsoft™ Word.

Hier die Mail, die ich (ohne viel Hoffnung auf sinnvolle Reaktionen) gerade an Flinkster geschickt habe:

====8<----- snip ----

Sehr geehrter Damen und Herren,

der zur Vervollständigung des Anmeldeprozesses auszudruckende
Vertrag liegt leider in einem Format vor, welches von meinen
Systemen nicht verarbeitet werden kann.
(Es scheint sich hier um ein Mircrosoft-Word Derivat des 
Formates RTF zu handeln)

Bitte lassen sie mir den Vertrag in einer nicht 
herstellerspezifischen Form zukommen.

Beispiele für solche übergreifend nutzbaren Formate sind: 
 * Rich Text Format (rtf) [Standardkonform]
 * Portable Document Format (pdf)
 * Postscript (ps)
 * Hypertext Markup Language (html) 
 * Tagged Image File Format (TIFF)
 * Portable Network Grafics (png) 

In der Anlage erhalten sie in Form einer png Datei ein 
Beispiel dafür, wie der Vertrag aussieht, der durch das
für die Flinkster Website derzeit eingesetzte System
erstellt wird, wenn er /ohne/ Microsoft Word 
ausgedruckt wird.

Mit freundlichen Grüßen
   Michael Mahlberg
-- 
TCG The Consulting Guild AG * Friesenwall 126 * 50672 Köln
Mobil: +49 160 97856224 * Büro: +49 221 677742111 * Fax: +49 221 677742119
HRB (Köln): 63476, Vorstand: Michael Mahlberg (V)
Vorsitzender des Aufsichtsrates: Daniel Speicher

(Nein, die schwärzungen stammen nicht von mir, sondern sind das ergebnis des heruntergeladenen Vertrags)
====8<----- snip ----

Mittlerweile habe ich mich auf ein paar anderen Rechnern ausgetobt: Mit Microsoft Word auf dem Mac sieht es halbwegs vernünftig aus - Zeichensatzprobleme nicht mitgerechnet.

Scrum? Das ist doch das mit den Kreisen!

2010-10-20T19:15:00.005+02:00

Na Super!
Vielen Dank auch an die Marketing-Spezialisten...

(Die Titelzeile "Scrum? Das ist doch das mit den Kreisen!" ist ein reales Zitat von einem Networking-Treffen im Herbst 2010...)

Das einfache Bild (dass ja bekanntlich sogar auf einen Bierdeckel passt ist) hat sicherlich viel dazu beigetragen, Scrum und auch dem Gedanken agiler Prozesse ganz allgemein zu der heutigen Akzeptanz zu verhelfen.

Als "hilfreiche Vereinfachung um die Grundgedanken von Scrum zu transportieren" kann ich mit diesem Bild leben. Zur Einführung eines Scrum-basierten agilen Prozesses werden aber meiner Erfahrung nach doch einige Aspekte mehr benötigt.

("Standard"-Bild zu Scrum)

Die andere Seite - das Produkt ist nicht das einzige, was durch einen Scrum-basierten Prozess verbessert wird - wird zunehmend auch wahrgenommen, wie David Harvey in seinem Beitrag deutlich macht.

(David Harveys Bild zu Scrum )

Was David Harvey hier herausstellt ist die Tatsache, dass neben dem eigentlichen Produkt durch den Prozess selber auch noch ein Team und ein im Team gelebter, konkreter Prozess erzeugt werden, die sich auch mit jedem Inkrement verbessern.

Was man darüber hinaus aber nicht vergessen darf ist, ...

[Vorsicht, Analogie für Softwareentwickler, die Objektorientierung kennen]

dass Scrum so etwas ist wie eine abstrakte Klasse - man kann es nicht instantiieren ohne die spezifizierten Methoden zu implementieren - und wenn man die Implementierung nur in Form von leeren Stubs durchführt kann man auch kaum erwarten, dass die Instanz sinnvolle Arbeit leistet.

[Nach einer guten Analogie für BWL oder PMI Spezialisten suche ich noch, hier die schlechte]

dass Scrum nur den groben Bauplan vorgibt - wie bei einem "Standardhaus", welches man so auch nicht bauen kann ohne sich nicht zu entscheiden, wie man bei diesem konkreten Exemplar die Wände zieht, was für Treppen man einsetzt und wo welche Anschlüsse nun wirklich liegen sollen.

Das reale Bild - und auch hier sind noch nicht alle relevanten Details aufgeführt - sieht dann eher so aus wie diese konkrete Instanz eines Scrum-basierten Entwicklungsprozesses:

(um Missverständnisse zu vermeiden: Dies war eine konkrete Ausgestaltung für ein konkretes Team - bitte nicht verallgemeinern!

Was ich damit deutlich machen will ist folgendes:
Ja, auf einer abstrakten Ebene ist Scrum ganz einfach - genau so, wie beispielsweise ein Auto auf einer abstrakten Ebene ganz einfach ist: drei bis vier Räder, Motor, Getriebe, Bremsanlage, ein paar Schaltelemente und eine selbsttragende Karosserie, fertig ist das Auto. Aber der Unterschied zwischen einem Benz Patent-Motorwagen Nummer 1 und einem Tesla Model S (oder irgend einem anderen aktuellen Fahrzeug) liegt sicher nicht nur im unterschiedlichen Zeitgeschmack, was die Gestaltung der Speichen anbelangt.
Nein, es reicht nicht, wenn man sich den Bierdeckel nur lange genug anguckt. Wenn man eine auch nur halbwegs konkurrenzfähige Umsetzung des einfachen Konzeptes haben will, dann muss sich sich intensiv mit den Details auseinander setzen und auch bereit sein, diese von Generation zu Generation (oder in unserem Fall von Iteration zu Iteration) zu überdenken.

Kreation statt Konsum! (diesmal per Mail)

2010-06-19T10:28:00.002+02:00

Um nun auch meinen Blogs mal wieder ein wenig mehr Leben einzuhauchen Teste ich gerade verschiedene Möglichkeiten, Blogposts vom iPad aus zu erzeugen und zu verschicken.

Mail scheint schon eine erheblich bessere Variante zu sein um die Posts zu erzeugen, aber leider fehlt auch hier die Möglichkeit, eine vernünftige semantische Formatierung vorzunehmen.

- Listen
- Überschriften
- Hervorhebungen
- Zitate

Formatierungen wie fett, kursiv und Unterstrichen funktionieren nicht mal, wenn man die Inhalte aus einem Programm kopiert, dass diese Formatierung kann. (Wie dieser Absatz beweist)

Kreation oder Konsum?

2010-06-19T10:16:00.002+02:00

Die allgemeine Meinung zum iPad scheint zu sein, dass es vor allem ein Werkzeug zum mobilen konsumieren digitaler Informationen sei. Ich selber kann mich dieser Sicht kaum anschließen und nutze es vor allem zum kreieren von Sachen (vor allem von Texten, die ich unterwegs schreibe).

Um nun auch meinen Blogs mal wieder ein wenig mehr Leben einzuhauchen Teste ich gerade verschiedene Möglichkeiten, Blogposts vom iPad aus zu erzeugen und zu verschicken.

Dieser hier stamm aus einem Programm, dessen Namen ich schon wieder verdrängt habe, da die Benutzerführung 'eher unglücklich' ist...
nicht gerade eine iPad Experience

Gerade Nachgeguckt: BlogPress heißt das Programm...

Permanentes Code-Review (Aka pair programming howto)

2009-11-03T09:47:00.007+01:00

Was unterscheidet Pair-Programming davon, zu zweit vor einem Rechner zu sitzen?

Aus meiner Sicht 3 Dinge:

Klare Rollendefinition
Ein festes Prozedere
Eine (mentale) Checkliste

Die Rollen

Die beiden Rollen, die wahrgenommen werden müssen sind die des Fahrers und die des Navigators. Dabei ist die Aufteilung ähnlich wie im Motorsport - der Fahrer ist dafür zuständig, bis zur nächsten Kurve zu kommen und der Navigator dafür, dass das Team auch nach der Kurve noch weiss, wie es weiter geht.

Übertragen auf die Programmierung bedeutet das, dass der Fahrer sich sowohl um Maus und Tastatur (entsprechend Gas und Kupplung) als auch um die konkreten Details der näheren Umgebung wie Klassen, Syntax, Struktur des aktuellen Codeblocks (entsprechend Geschwindigkeit, Drehzahl Straßenzustand etc.) kümmert. Der Navigator kümmert sich so lange um die weiter entfernten Zielen wie Design, Schnittstellen, Frameworks und Architektur (entsprechend Strassenkarte, Himmelsrichtung, Entfernungen etc.).

In dieser Rolle ist es auch Aufgabe des Navigators sich um so etwas wie das Roadbook – im Falle der Programmierung um den GoalStack – zu kümmern sowohl um die Erstellung, als auch um die Abarbeitung!

Das feste Prozedere

Das Prozedere zum Pair-Programming umfasst einen Bildschirm, eine Tastatur und eine Maus sowie eine Stoppuhr (welcher Art auch immer). Die Maßgabe lautet nun, dass beide Entwickler zugleich vor der Maschine sitzen, sich vor Beginn der Arbeit über das Ziel und den Zeitrahmen absprechen und in festen Intervallen von 10 bis 15 Minuten die Rollen wechseln. Beim Rollenwechsel sollten dabei tatsächlich nur Maus und Tastatur verschoben werden und weder die Sitzpositionen, noch die Monitorposition angepasst werden. Letzteres soll sicher stellen, dass der Navigator tatsächlich den gleichen Zugang zum Code hat wie der Fahrer. (Anm: Tools wie Key Jedi helfen zusätzlich, falls der Fahrer ein Mausgegner sein sollte...)

Die Checkliste

Die Checkliste für den Navigator kann entweder sogar physisch vorliegen, sollte aber auf jeden Fall zumindest mental bei jeder Zeile durchgegangen werden, die der Fahrer programmiert.

Kommt es zu "Verstößen" gegen die Checkliste ist es Aufgabe des Navigators, zu entscheiden, ob dieser "Verstoß" sofort aufgelöst werden muss (was zum Beispiel im Falle von Rechtschreibfehlern sicherlich sinnvoll ist) oder ob diese Verstöße eher in den GoalStack gehören – also auf eine kurze, völlig informelle Liste von Dingen, die man "noch in dieser Session" bereinigen muss. In diese letzte Kategorie fallen insbesondere notwendige Refactorings und Verstöße gegen das DRY oder YAGNI Prinzip.

Ein guter Startpunkt für eine solche Checkliste ist aus meiner Sicht die folgende:

[Nur bei TDD und BDD] Haben wir einen (fehlschlagenden) Test für den Code, den wir gerade schreiben wollen?
Wird die gleiche Absicht an andere Stelle im Code bereits ausgedrückt? (Verstoß gegen das Don't Repeat Yourself Prinzip, DRY)
Benötigen wir diesen Code zu diesem Zeitpunkt? (Verstoß gegen das You Aren#t gonna Need It Prinzip, YAGNI)
Kommuniziert der Code klar die Absicht, die mit ihm verfolgt wird? (Gegenbeispiel für C-Programmierer: {while(*p++=*q++)} )
Entspricht der Code dem vereinbarten Coding-Style?
Entspricht der Code den vereinbarten Naming Conventions?
Entspricht der Code der vorgesehenen Nutzung des Frameworks?
Ist der Code ausreichend dokumentiert?
Bietet der Code Optionen für Refactorings? (Enthält er Code-Smells?)

Anm.:

Vor langer Zeit gab es mal einen guten aber kurzen Artikel darüber, was Pair-Programming davon unterscheidet einfach zu zweit vor einem Rechner zu sitzen.

Leider hat selbst extensive Google und Twitter-Recherche keine greifbaren Hinweise auf diesen Artikel geliefert, was bei mir die Befürchtung aufkommen lässt, dass es sich bei diesem Artikel und einen echten gedruckten Artikel handelt - daher diese Zusammenfassung aus meiner Sicht.

Einige der Quellen, auf die ich mich dabei beziehe sind:

http://c2.com/cgi/wiki?PairProgrammingPattern

http://c2.com/cgi/wiki?GoalStack

http://c2.com/cgi/wiki?LetTheJuniorDrive

http://webpages.cs.luc.edu/~anh/170/Kindergarten.html

http://softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/

Continuous Integration / Permanente Integration

2009-07-29T15:45:00.004+02:00

In letzter Zeit erzähle ich immer wieder etwas über meine Sicht auf das Thema "Continuous Integration" – es wird Zeit, das mal von Flipcharts und Whiteboards in Bits und Bytes zu transponieren.

Permanente Integration ist aus meiner Sicht etwas ganz anderes als der reine Tooleinsatz. Auch wenn mittlerweile selbst im Wikipedia-Artikel über “Kontinuierliche Integration” das Hauptaugenmerk auf der Automatisierung von Build, Test und Deployment liegt, gibt es noch eine andere Art, sich dem Thema zu nähern.

Da ich in absehbarer Zeit wohl kein Schriftsteller werde, würde ich mich um eine intensive Diskussion (z.B. hier in den Kommentaren) des Drafts unter
http://www.cg-ag.de/files/ContinuousIntegration-MindsetVersusTooling_draft1.pdf freuen.

(Auf einem Whiteboard ist es viel leichter darzustellen...)
Meine eigenen Hauptkritikpunkte:

Zu lang

Die Story fehlt noch (ist als nächster Schritt geplant)

Edit: Mittlerweile ist aus dem Draft ein Artikel geworden,der im RailswayMagazin veröffentlicht wurde. Ich muss "bei Gelegenheit" mal die von @jcfischer beigetragenen git-Spezifika wieder ausbauen und den Artikel als reinen "Was ist CI" Artikel veröffentlichen. Am besten auch gleich auf Englisch.

Politisch inkorrekt? (Zensur in Deutschland)

2009-06-19T14:36:00.006+02:00

Gestern ist also das (nach meiner Kenntnis) erste offizielle Gesetz in der BRD "durchgewunken" worden, dass Zensur in Deutschland für legal erklärt. Derzeit zwar nur für einen Bereich, in dem Zensur oberflächlich betrachtet "gut" zu sein scheint, aber schon gibt es ja die ersten Stimmen, die nach "mehr" rufen.

Schade, dass so wenig Leute z.B.: http://www.jensscholz.com/2009/04/warum-es-um-zensur-geht.htm (besonders den Teil "Verwaltung") gelesen haben (oder einfach das Gesetz selbst).

So bleibt wohl nur die Hoffnung auf eine Verfassungsbeschwerde oder -klage. Ob Aktionen wie z.B. die unter anderem von der Piratenpartei organisierte Demonstration etwas ausrichten können bleibt abzuwarten.

Zumindest war die Öffentlichkeit wohl nicht informiert genug um die Petition gegen das Gesetz durchzubringen.

Wobei ich mich jetzt schon frage, ob dieser Beitrag in ein paar Jahren gegen mich verwendet werden kann...

(P.S.: Wow, das Interview in dem Wiefelspütz die Ausweitung der Sperren fordert ist - zumindest unter dem alten Link http://www.berlinonline.de/berliner-zeitung/archiv/.bin/dump.fcgi/2009/0606/politik/0081/index.html nicht mehr verfügbar... die Interpretation sei dem geneigten Leser überlassen...

Der Wert von Software

2009-04-07T15:04:00.003+02:00

Auch wenn sich das Buch mit dem Ansatz, eine neue Methodologie zu präsentieren erheblich zu weit aus dem Fenster lehnt, lohnt Software by Numbers doch auf jeden Fall die Lektüre.

Nicht so sehr, weil es neues zeigt, sondern weil es bekanntes zusammenfasst und den Zusammenhang von betriebswirtschaftlichen und softwarearchitektonischen bzw. prozesspezifischen Entscheidungen nachvollziehbar darstellt.

Cheerio
_MM_

Mal was ganz anderes...

2009-04-02T17:17:00.002+02:00

Auch bei der Aufstellung von Plakaten sollte man sich ein paar Gedanken machen... Aber vielleicht ist das auch nur ein Spiegel unserer Welt.

Cheerio
_MM_

Meine heutigen 2 Cent zum Thema Maven...

2009-03-02T12:16:00.001+01:00

Moin!

nachdem letzte Woche an vier von fünf Tagen das Thema "Maven und die Sinnhaftigkeit des Einsatzes" hochkam, dachte ich mir, ich mache noch ein bisschen Lobby-Arbeit und weise auf den folgenden Artikel hin:

http://blog.labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-maven-blues/

Ohne natürlich zu verschweigen, dass zumindest im zweiten der dort zitierten Artikeln http://fishbowl.pastiche.org/2007/04/03/an_open_letter_to_maven_2/ und http://www.javalobby.org/java/forums/t92965.html#92139914 Maven gar nicht unbedingt Hauptthema war und es auch durchaus andere Stimmen gibt.

Erfolgreiche Woche!
_MM_

P.S.:
Ach ja: Buildr ist zu finden unter: http://buildr.apache.org/
Und richtig schnell soll es auch noch sein: http://blog.labnotes.org/2007/05/03/buildr-or-when-ruby-is-faster-than-java/

Anyway: Das sind natürlich nur meine 2 Cent und YMMV.

Karaoke für Berater (oder nicht?) (aka Powerpoint Karaoke)

2008-06-04T20:29:00.004+02:00

Seit gestern Abend kenne ich dank Peter eine neue Form von Karaoke - Powerpoint Karaoke!

Ursprünglich im Umfeld von Sascha Lobo - der schon Mitverantwortlich für den Begriff "Digitale Bohéme" zeichnet - als Projekt der ZIA initiiert geht es hierbei schlicht und einfach darum, vor einem fachfremden (aber präsentationerfahrenen) Publikum eine (mehr oder weniger) zufällig aus dem Internet herunter geladene Powerpoint-Präsentation zu halten.

Die Rahmenbedingungen:

5 Minuten
10 Slides
0 (zero) Vorbereitungszeit! (Genau: Der Präsentator sieht die Folien erst, wenn das Publikum sie auch sieht! Und er hat - wie das Publikum - keine Ahnung, worum es bei der Präsentation geht!)

Nette Idee - wie man die Umsetzungen einschätzt mag der geneigte Leser nach einer kurzen Suche bei YouTube oder GoogleVideo selber beurteilen.

Ich find's auf jeden Fall witzig und lehrreich.

_MM_

Chaos und starke Typisierung

2007-08-22T07:53:00.000+02:00

Phillip schrieb vor kurzem in seinem Blog über die Angst des Menschen an sich (und des Menschen in der Softwareentwicklung im besonderen) vor dem Chaos.

Besonders die von ihm erwähnten Mottos verdienen einen Kommentar

Mottos der letzten Jahre wie “Alles ist ein Dokument!”, “Alles ist ein CORBA-Objekt”, “Jede Ressource kann direkt über HTTP abgerufen werden” oder “Alle Systeme werden über EJB integriert” lassen erahnen, wie stark der Wunsch nach Ordnung ist.
Interessanterweise nannte mein Physiklehrer den Zustand, in dem alles gleich ist, Chaos. Er sagte, in diesem kann man nichts auseinander halten.

Spontan musste ich dabei an die verbreitete Abneigung gegenüber Sprachen mit Laufzeittypisiserung denken, die heute bei vielen Entwicklern und Entscheidern in der Softwareentwicklung verbreitet ist.

Irgendwie ist mein Kommentar dann doch etwas länger geworden...

Der - nur allzu verbreitete - Wunsch danach, keine falsche Entscheidung zu treffen, führt gerade in unserer Branche (also der Informmationsverarbeitung) zu den erstaunlichsten Auswüchsen. Ein Beispiel dafür sind die Typsysteme. Damit der Entwickler möglichst wenig falsch machen kann, soll möglichst früh durch den Rechner erkannt werden, ob er "alles richtig" gemacht hat. Also entwerfen wir (oder zumindest ein Teil von uns) munter Entwicklungsumgebungen, die möglichst restriktiv in dem sind, was der Entwickler machen kann. Und mit schöner Regelmäßigkeit sind die erfolgreichsten Erweiterungen für diese Systeme, solche, die darauf basieren, diese Beschränkung zu umgehen. (* Konkretes Beispiele: siehe Fußnote).

Zudem neigen viele der Entwickler, die ich kenne dazu, "erstmal eine allgemeine Lösung zu erstellen" damit "der normale Entwickler" auch mit "der Komplexität Umgehen kann" - erstaunlicher weise kenne ich kaum einen "normalen Entwickler", der froh ist die "allgemeinen Lösungen" zu haben - im Gegenteil: je größer die Entfernung zwischen Entscheider (oder demjenigen, der die "allgemeine Lösung" entworfen hat) und Realisierer ist, umso mehr wird nach Wegen gesucht, trotz der starren Vorgabe erfolgreich zu sein - und meistens funktioniert das auch.

Fazit meines kurzen Kommentars:
Klare Vorgaben sind nicht per se schlecht - ganz im Gegenteil. Aber:

Alle Vorgaben in der Softwareentwicklung, die mit Alle beginnen neigen dazu, kontraproduktiv zu sein.

Cheerio
_MM_

*) Hier ein kleines Beispiel aus dem Java-Umfeld:
Für diese stark typisierte Sprache ist der Kern einiger der erfolgreicheren Frameworks zum großen Teil mit der Umgehung der Typisierung befasst: JUnit, Hibernate, Spring, Struts

SOA für Manager - Was passiert mit mir?

2007-07-22T15:37:00.000+02:00

Bin ich zum SOA-Evangelisten geworden?
Nachdem ich bereits im letzten Jahr einen SOA Beitrag für "SOA-Expertenwissen" geschrieben habe, bin ich nun schon wieder dabei, etwas über serviceorientierte Architekturen zu schreiben.
Für den Management-Lehrgang "Service-orientierte Architekturen" des Euroforums arbeite ich derzeit an der Lektion 4 (Genaueres ist im Flyer zu finden).
Ich hoffe, meine Beiträge machen deutlich, dass für den Aufbau einer SOA (und dieser Begriff scheint wirklich derzeit in Großunternehmen nicht mehr zu umgehen zu sein) methodisches Vorgehen und teilweise jahrzehnte alte Techniken durchaus noch ihre Daseinsberechtigung haben. Nur ihr Kontext hat sich gewandelt und muss im Rahmen von serviceorientierten Vorhaben besonders berücksichtigt werden.
Meine Antwort auf die Frage "Bin ich zum SOA-Evangelisten geworden?" lautet also: "Nein, aber wenn es schon einen neuen, mächtigen Ansatz gibt, grundlegende Konzepte wie lose Kopplung und hohe Kohesion zu etablieren, dann sollte man ihn auch unterstützen."
_MM_

iPod neu definiert: Der iPott

2007-07-18T21:32:00.000+02:00

Endlich gibt es in Köln den stilechten Kaffe für den Multimediafreund von Heute. Das Holtmanns in Köln bietet jetzt den iPott an.

Test der Fußzeile

2007-07-18T12:01:00.000+02:00

... Da blogger leider keine komfortable Möglichkeit bietet, Feed-Reader oder Abrufe zu zählen, versuche ich es mal mit einer Grafik in der Fußzeile - schliesslich machen macupdate und co das ebenso ...

Und es scheint zu funktionieren ...

Noch ein Blog?

2007-07-16T23:08:00.001+02:00

Wozu brauche ich eigentlich noch ein Blog, wo ich doch schon in meinem englischen Blog kaum zum regelmäßigen posten komme?
Ganz einfach: viele der Sachen, die ich eigentlich unter agile-aspects posten würde sind einfach nur von lokalem Interesse und international überhaupt nicht relevant - deshalb schreibe ich dort weniger, als ich es tun könnte - mal sehen, ob ich hier mehr dazu komme auch mal Kleinigkeiten zu posten.
_MM_

Warum Shu-Ha-Ri?

2007-07-16T22:14:00.000+02:00

Obwohl ich selber aktiv Aikido betreibe (und dort wird das Shu-Ha-Ri besonders oft zitiert) hat mich nicht diese Kampfkunst zu dem Namen des Blogs verleitet, sondern ein Buch von Alistair Cockburn, in dem er dieses Prinzip auf Softwareentwicklung erweitert.
Was steckt aber hinter diesem Prinzip?
Nichts weiter, als der "Weg" zum Erlernen. Zum Erlernen von was? Eigentlich zum Erlernen der (japanischen) Kampfkünste, aber ebenso zum Erlernen aller "Fertigkeiten" - das wird auch dadurch deutlich, dass einer der Ursprünge des Shu-Ha-Ri Konzeptes bei der Tee-Zeremonie zu finden ist.
Eine englische Erläuterung ist bei Wikipedia zu finden, kurz skizziert geht es um folgendes:
Das Lernen wird in drei Phasen betrachtet. In der ersten Phase (Shu, 守, grob übersetzt: beschützen aber auch gehorchen) werden die Techniken "nach dem Buch" ausgeführt und im eigentlichen Sinne erlernt. In der zweiten Phase (Ha, 破, grob übersetzt: abschweifen, mit etwas brechen) werden die Techniken und ihre Grenzen erprobt um dann in der dritten Phase (Ri, 離, grob übersetzt: [etwas] verlassen, sich trennen) neu kombiniert und vom früheren Schüler selber erweitert zu werden.

_MM_