tag:blogger.com,1999:blog-83319908858683234732024-03-14T01:16:39.332+01:00Ruynk<a href="http://www.ruynk.com">
www.ruynk.com
</a>Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.comBlogger75125tag:blogger.com,1999:blog-8331990885868323473.post-22526286146386475432022-04-08T08:13:00.002+02:002022-04-27T14:43:30.210+02:00Analyse von Agil: Eine PDF<p> Zur Info: <a href="http://www.ruynk.com/downl/RuyNKSys_Analyse_von_Agil.pdf" rel="nofollow">"Analyse von Agil"</a></p><p>Eine PDF zum lernen.</p><p><br /></p>Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-83402757383205113992022-03-29T11:22:00.006+02:002022-03-29T11:22:57.545+02:00Nicht nur auf einfache Projekte anwendbar<p> <span style="font-size: medium;">Aus aktuellem Anlass:</span></p><p><br /></p><p><b><b><big>Es muss ein Mechanismus existieren, dass die Schweigsamen auch ihre
Meinung äußern dürfen: Es kann und soll nicht sein, dass nur weil
die intelligentesten den Mund nicht auf machen ein Projekt
schief läuft</big> (Buch "Adrenalin Junkies und Formular Zombies", Tom
Demarco, Kap. 25). </b></b></p><p><b><b> </b></b></p><p><b><b>Hier zu lesen: <a href="http://www.ruynk.com/flepa.htm" rel="nofollow">FlePA</a></b></b></p><p><b><b><br /></b></b></p><p><b><b><br /></b></b></p>Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-56024555168967700562018-07-20T18:25:00.000+02:002018-07-20T18:25:04.488+02:00Über Management und Effektivitätsteigerung - im Zeitalter der Informatik<br />
<br />
Wie immer sind die Bücher von DeMarco und Konsorten ein großes Lesevergnügen.<br />
<br />
<br />Vom Buch: <b>Wien wartet auf Dich!</b><br />
Tom DeMarco, Timothy Lister, Peter Hruschka<br />
<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">"Trotz all dem Gerede über "smarteres Arbeiten" ist die Meinung weit verbreitet, dass richtiges Management nur damit zu tun hat, wie man seine Leute dazu bewegt, härter und länger zu arbeiten, meistens auf Kosten ihres Privatlebens. Manager geben immer damit an, wie viele Überstunden ihre Mitarbeiter leisten und welche Tricks man anwenden kann, um noch mehr aus ihnen herauszuholen."</span><br />
<br />
<br />
Die Ideen in diesem Text sind nicht neu, doch schön auf dem Punkt gebracht.<br />
Auffallend, auf jeden Fall, ist die dadurch zum Vorschein kommenden Einstellung (Arbeitsverständnis) des Managements: es wird nicht "geführt" oder "geleitet" ('gemanaged') sondern lediglich mit allen Mitteln versucht, das maximale Möglich von den Mitarbeitern herauszupressen. Dies, natürlich, ist nicht die richtige Vorgehensweise.<br />
<br />
Eine Folge aus dieser Vorstellung bezüglich der Führung von Unternehmen (und auch Projekten) ist die, dass die Arbeiten, die Management-Inhärent sind, schlicht nicht durchgeführt bzw. an die Belegschaft weitergeleitet werden (manchmal ist das gut, manchmal aber auch nicht... nur: Was für eine Rolle soll eigentlich das Management dann spielen?).<br />
<br />
Nun kann ich diese Gedanken weiter auf die "agilen" Methoden übertragen: Sind diese "Methoden" (insbesondere das "Gedraenge", Scrum, weil sehr stark Prozess-orientiert) doch nicht lediglich noch ein Versuch, nicht "managen" zu müssen, sondern mit Hilfe sogenannter "agilen" Vorgehensweisen sich noch weiter von den Management-Aufgaben (planen, schätzen, koordinieren/organisieren) zu entfernen?<br />
<br />
<br />
<br />
Wenn Sie ein besseres agiles Arbeiten wünschen: <a href="http://amtrs.de/savap.htm">http://amtrs.de/savap.htm</a><br />
<br />
<br />
Doch wenn Sie überhaupt besser arbeiten wollen: <a href="http://amtrs.de/flepa.htm">http://amtrs.de/flepa.htm</a><br />
<div>
<br /></div>
<div>
<br /></div>
Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-35936354801045021222018-07-16T19:30:00.000+02:002018-07-16T19:32:34.181+02:00Produktivitätsteigerung als Folge von "Investitionen", nicht als Folge von dem Einsatz irgendwelchen (agilen) Methoden<br />
Aus dem Buch: Der Termin<br />
Tom DeMarco (1997)<br />
<br />
»Im Prinzip ist Prozessverbesserung eine gute Sache. Sie bedeutet, dass Sie Ihren Job immer besser machen. Aber ich bin wenig begeistert von Programmen wie dem CMM-Ansatz, die sich Prozessverbesserung auf ihre Fahne schreiben. Sie werden leicht zum Selbstzweck.«<br />
<br />
»So etwas wie eine schnelle Lösung gibt es in unserer Branche nicht. Es gibt keine Möglichkeit, die Produktivität kurzfristig zu steigern. Die Produktivität, die Sie heute erreichen, ist das direkte Ergebnis der langfristigen Investitionen, die vor Ihrer Zeit getätigt wurden. Und auch Sie können die Produktivität nur beeinflussen, wenn Sie Ihrerseits eine langfristige Investition tätigen, die Ihren Nachfolgern zugute kommt.«<br />
<br />
Soll man glauben (dürfen), dass man Produktivitätssteigerungen durch Einsatz von "agilen" Methoden erzielen kann?<br />
<br />
Ich finde den Text im Buch ganz gut, denn einerseits halte ich auch sehr wenig von CMM und andererseits scheint mir die Erklärung mit der Investition sehr "bodenständig". So etwas fehlt heute in der IT-Industrie.<br />
<br />
Auf jeden Fall finde ich die Aussage im Buch sehr interessant.<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-82440990938957731882018-07-05T19:33:00.002+02:002018-07-05T19:37:06.996+02:00Kann man Produktivität schätzen? - Und, wichtiger eigentlich: Bringt das was?<br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;">Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevergnügen 1. Klasse für alle Projektbeteiligten :-)</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><br /></span>
Vom Buch: Wien wartet auf Dich!<br />
Tom DeMarco, Timothy Lister, Peter Hruschka<br />
Seite 27ff:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">Lawrence und Jeffery wollten die Produktivitätseffekte verschiedener Schätzverfahren ermitteln. Ihr Ziel war es, den alten Glauben zu bestätigen oder zu widerlegen, wonach Entwickler (in diesem Fall Programmierer) härter arbeiten, wenn sie ihre eigenen Schätzungen einhalten wollen. Für jedes der 103 Projekte entwickelten Lawrence und Jeffery eine gewichtete Metrik für die Produktivität. Dann teilten sie ihre gesammelten Daten in Gruppen ein, gegliedert nach der Art, wie die ursprünglichen Schätzungen zustande kamen.</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">[...]</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Systemanalytiker sind die besseren Schätzexperten; besser als die Programmierer und besser als die Manager. Sie verstehen typischerweise die Arbeit bis ins Detail, sind aber nicht von dem natürlichen Optimismus der Personen befallen, die die Arbeit durchführen müssen, und auch nicht von den politischen oder budgetären Randbedingungen des Chefs beeinflusst.</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">[...]</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">Schlechte Schätzungen und hoffnungslos enge Terminpläne schwächen die Energie von Entwicklern. Capers Jones, der für seine Metrikstudien über Entwicklungsmodelle bekannt ist, hat es folgendermaßen ausgedrückt: "Wenn der Terminplan eines Projekts von Grund auf unrealistisch und unvernünftig ist, so dass selbst mit einer Menge von Überstunden nichts erreicht werden kann, wird das Projektteam zornig und frustriert... und die Moral sinkt auf den Nullpunkt." (Capers Jones, Programming Productivity (New York, McGrawHill, 1986), S. 213)</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;"><b>Dabei spielt es fast keine Rolle, ob die von Grund auf unrealistischen und unvernünftigen Termine vom Chef oder von den Entwicklern stammen.</b></span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
<span style="font-family: "courier new" , "courier" , monospace;">Das überraschendste Ergebnis der Studie von Lawrence und Jeffery aus dem Jahre 1985 stand ganz am Schluss, als sie die Produktivität der 24 Projekte untersuchten, für die es überhaupt keine Schätzungen gab. Diese Projekte wiesen eine viel höhere Produktivität auf.</span><br />
<br />
[Siehe Tabelle im o.g. Buch. Inhalt: Produktivität ohne Schätzung = 50% mehr als die Schätzung der Programmierer.]<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">Die Projekte, bei denen der Chef keinerlei Druck bezüglich des Fertigstellungstermins ausübte ("Weckt mich auf, wenn ihr fertig seid!"), wiesen die höchste Produktivität auf</span>.<br />
<br />
Mein Fazit: Nun muss ich unbedingt als Systemanalytiker zwar schätzen, der PM muss die Entwickler aber sich selbst überlassen.<br />
<br />
Heute was gelernt!<br />
<br />
Wie auch immer, bei Projekten sind Schätzungen sehr wichtig, denn es wäre wirklich irrsinnig etwas anzufangen ohne klare Vorstellungen von Zeit und Kosten zu haben. Doch das Mikroschätzen der "agilen Methoden" ist, meiner Meinung nach, overkilled, demnach auch die Einteilung in starren, unflexiblen, "Time Boxen" ("Agilität" lässt gerade ganz lieb grüßen...). Viel besser natürlich: <a href="http://amtrs.de/flepa.htm" target="_blank">FlePA</a>.<br />
<br />
Aber <a href="http://ruynk.blogspot.com/2018/06/wenn-sie-es-schon-nicht-sein-lassen.html" target="_blank">wenn Sie es doch nicht sein lassen können, dann machen Sie es zumindest so richtig wie möglich</a>: <a href="http://amtrs.de/savap.htm" target="_blank">SAvAP</a>.<br />
<div>
<br /></div>
Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-27420574023489896612018-06-29T18:58:00.000+02:002018-06-29T18:58:43.171+02:00Agile: Das Laetrile für den Projekt Manager?Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevegnügen 1. Klasse für alle Projektbeteiligten :-)<br />
<br />
<br />
Vom Buch: <b>Wien wartet auf Dich!</b><br />
Tom DeMarco, Timothy Lister, Peter Hruschka<br />
- Seite 32 -<br />
<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><b>Laetrile ist eine farblose Flüssigkeit, die aus dem weichen Inneren von Aprikosenkernen herausgepresst wird. In Schweden kann man diese Flüssigkeit in Lebensmittelgeschäften ungefähr für denselben Preis wie Mandelaroma kaufen. Man benutzt sie beim Backen so wie andere Extrakte. In Mexiko wird diese Flüssigkeit für 50 Dollar pro Tropfen als "Heilmittel" für die tödliche Geißel Krebs verkauft. Natürlich heilt sie gar nichts. Alle Anzeichen deuten darauf hin, dass alles nur grausamer Betrug ist. Aber da sonst niemand den Todeskandidaten irgendetwas anbieten kann, werden die Versprechungen der Laetrile-Quacksalber ernst genommen, ganz egal wie schändlich diese sind.</b></span><br />
<span style="font-family: Courier New, Courier, monospace;"><b>Personen, die extrem verzweifelt sind, prüfen Behauptungen nicht allzu kritisch nach.</b></span><br />
<span style="font-family: Courier New, Courier, monospace;"><b>Manche Manager sind in einer ähnlich "extrem verzweifelten" Lage und diese Verzweiflung macht sie zu einfachen Opfern für vielerlei technische Laetrile, die vorgeben, die Produktivität zu steigern. Nur selten gibt es Belege für die Wirksamkeit der offerierten Versprechungen. Aber auch sie verzichten auf Belege, weil ihre Not so groß ist.</b></span><br />
<br />
<br />
Das ganze 6. Kapitel: "Laetrile" ist sehr lesenswert!!!<br />
<br />
Kommentare hierzu halte ich für überflüssig.<br />
<br />
Abhilfe "De Luxe": <a href="http://amtrs.de/flepa.htm" target="_blank">FlePA</a> .<br />
<br />
Abhilfe für den normalen, praktischen Fall: <a href="http://amtrs.de/savap.htm" target="_blank">SAvAP</a> .<br />
<br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-61953790383348376472018-06-21T19:39:00.000+02:002018-06-21T19:39:27.884+02:00Wenn Sie es schon nicht sein lassen können, so gestalten Sie es aber bitte so gut wie möglichSeit dem Jahr 2009 arbeite ich mit agilen Teams und schon davor hatte ich mich mit den Kerngedanken des "Agilismus" auseinander gesetzt.<br />
<br />
Die Theorie um die agilen Methoden ist wirklich hübsch, besagt etwas von Frieden, Freude, Eierkuchen...<br />
Grundlage der agilen Methoden ist ein "Manifesto" und ornamentiert wird sie (die Grundlage) durch die bekannten (und berüchtigten) "12 Prinzipien".<br />
<br />
Was ich davon halte habe ich schon früher dargelegt.<br />
<br />
Dennoch habe ich in der letzten Zeit die Gelegenheit gehabt und ausgenutzt noch mehr dazu zu lernen.<br />
<br />
<br />
<h3>
7 Jahre Arbeit im "agilen Umfeld"</h3>
<br />
Mit mehr als 7 Jahren Arbeit in agilen Teams bei verschiedenen Firmen muss ich doch zugestehen, dass ich mich teilweise geirrt habe.<br />
<br />
So z.B. sind die agilen Entwicklungsmethoden keine Totgeburt wie ich meinte: scheinbar wachsen sie und gedeihen wider besseres Wissen... sogar bei echt großen Firmen!<br />
<br />
Ungefähr die Hälfte der in agilen Teams involvierten Mitarbeiter scheinen agile Ansätze zu mögen, die andere Hälfte aber nicht. Geteilte Meinungen also. Sowohl die eine als auch die andere Methode hat Vor- und Nachteile, wie es eigentlich auch zu erwarten war.<br />
<br />
Aus den mir vorliegenden Studien bezüglich das Ergebnis (Aufwand/Leistung Verhältnis) der Agilen (ACHTUNG! Gemeint sind nicht die subjektiven Meinungen von Teilnehmer an Fragebogen oder von Internet-Quizzen, sondern erhobenen Zahlen), scheinen sie sich mit den planungslastigen Methoden (BDUF: Big Design Up Front) in der Waage zu halten: Weder die eine noch die andere Vorgehensweise kristallisiert sich eindeutig als Sieger heraus (1). Hier ist aber eine verlässliche Aussage eher unmöglich, denn ein Vergleich ist nicht unter wirklichkeitsnahen Bedingungen realisierbar.<br />
<br />
<b>Was folgere ich daraus?</b><br />
Nun:<br />
<br />
1. Die Agilen sind da und werden aller Anschein nach nicht so schnell wieder verschwinden (m.a.W. es wird eine -lange- Weile dauern, bevor man sie wieder ersetzt, unabhängig von guten oder schlechten Ergebnissen, unabhängig vom Vorhandensein besserer Methoden).<br />
<br />
2. Die Agilen sind nicht besser oder schlechter als die BDUF-Methoden, sondern ziemlich gleichwertig. Doch das Management möchte sicherlich die Agilen beibehalten, denn dadurch sind sie von einem (guten) Brocken Arbeit entlastet (dies, werter Leser, gilt zu berücksichtigen).<br />
<br />
3. Historisch gesehen hat sich das klassische Projekt Management (BDUF) über eine (sehr) lange Zeitspanne entwickelt; die agilen Methoden aber sind ein relativ neuer, noch sehr junger Ansatz (2). Als solches sind sie einerseits für Fehlentwicklungen und Missverständnissen recht anfällig (da noch unzureichend untersucht), andererseits sind sie aber aus eben denselben Gründen besonders verbesserungsbedürftig.<br />
<br />
<br />
<b>Als Analytiker bin ich an Zahlen, Analysen und Ergebnissen sehr interessiert.</b><br />
Aus Erfahrung, meiner kritischen Haltung gegenüber der Agilen und meinen Drang, Prozesse zu verbessern (siehe z.B. mein "Kaizen destilliert": <a href="http://amtrs.de/downl/Kaizen_Destilliert.pdf">http://amtrs.de/downl/Kaizen_Destilliert.pdf</a>), entstand folglich die:<br />
<br />
<br />
<h3>
Strukturierte Analyse von agilen Prozessen (SAvAP)</h3>
<br />
Ziel und Zweck von SAvAP (wie der Name schon sagt) ist es, die agilen Methoden vom Nimbus des Esoterischen, vom Dogmatischen aus dem Manifesto und den 12 Prinzipien zu befreien und sie zu verständlichen, produktiven und an einer (Ihrer) Umgebung (sei es Team, Abteilung oder Firma) angepassten Methoden zu entwickeln.<br />
<br />
Doch dem kurzen Sinn langer Rede ist hier zu lesen: <a href="http://amtrs.de/savap.htm">http://amtrs.de/savap.htm</a><br />
<br />
_______________________________________________________________<br />
<br />
Was für Erfahrungen haben Sie mit agilen Methoden?<br />
<br />
Halten Sie „agil“ oder „klassisch“ für besser?<br />
<br />
Hätten Sie vielleicht sogar Vergleichszahlen zwischen beiden Ansätze?<br />
<br />
Und was meinen Sie; sind die agilen Methoden wesentlich oder unwesentlich zu verbessern?<br />
<br />
_______________________________________________________________<br />
<br />
<br />
(1) "One of the greatest tragedies in life is the murder of a beautiful theory by a gang of brutal facts." Benjamin Franklin<br />
<br />
(2) FlePA (siehe <a href="http://amtrs.de/flepa.htm">http://amtrs.de/flepa.htm</a>) ist sicherlich die Zukunft, aber, wie weiter oben angemerkt (1. Punkt); es wird ziemlich lange dauern bis dieser Ansatz Einzug in der gegenwärtigen Projekt Management Disziplin findet. Bis dahin müssen wir alle wohl oder übel mit den Agilen Vorlieb nehmen.<br />
<br />
<br />
und...<br />
<br />
<h4>
Heute ist der längste Tag des Jahres !!!</h4>
<div>
<br /></div>
Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-67893307823257655402018-02-13T16:50:00.001+01:002018-02-13T16:50:17.353+01:00Vergleich "Agile" vs. "nicht Agile"Ich kann mir sehr schwer vorstellen, dass Scrum oder "Agile" (wirklich) besser als einer klassischen Methode funktioniert.<br />
<br /><b>Deswegen suche ich harte Vergleiche; Vergleiche die auf Fakten basieren.</b><br /><br />Folgende Punkte möchte ich vergleichen:<br /><br />1. <b>Produktivität</b><br /><br />2. <b>Zufriedenheit der Projekt-Teilnehmer</b><br />2.1. Anzahl der Projekt-Teilnehmer, die ein nicht-Agiles Projekt in einer gegebenen Zeit verlassen haben, und<br />2.2. Anzahl der Projekt-Teilnehmer, die ein Agiles Projekt in einer gegebenen Zeit verlassen haben.<br /><br />3. Last but not least, der Wunde Punkt der SW-Entwicklung; <b>Bugs!</b><br />3.1. Anzahl Bug pro Zeiteinheit (oder TLOC oder Funktionspunkte)<br />3.2. Kritikalität der Bugs pro Zeiteinheit (Anzahl Bug pro Zeiteinheit und Kritikalität)<br />3.3. Durchschnittliche Verweildauer eines Bugs (wie lange braucht man, es zu beheben)<br />3.4. Durchschnittliche Verweildauer der Bugs nach Kritikalität (wie lange braucht man, Bugs nach Kritikalität zu beheben)<br />
<br />
<br />
<br />
<br />
Es gibt leider leider noch mehrere wichtigen Punkte zu vergleichen...<br />
Stoff für mehrere Arbeiten!<br />
<br />Hier mein Schreiben zu diesem "Vergleich": <a href="http://www.ruynk.com/downl/Vergleich_zw_Agile_und_nicht_Agile.pdf" target="_blank">Bitte runterladen.</a><br />
<br />
Auf Kommentare und weiterführende Infos bin ich sehr gespannt ;-)<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-19818432800755897972017-10-27T09:08:00.000+02:002017-10-27T09:08:06.587+02:00Gedankenfehler im Ansatz bei den Agilen - Teil 3 von 3Von:<br />https://de.wikipedia.org/wiki/Agile_Softwareentwicklung<br /><br />Hier:<br />Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung<br /><br />Das ist noch ein Meeting.<br /><br />Die Idee dahinter ist wie immer eine gute Idee, stammt eigentlich von dem <b>Toyota Production System</b> und wird <b>"Hansei"</b> genannt. <b>Hansei </b>ist viel mehr als einfach eine Selbstreflexion; <b>Hansei </b>ist das Anstreben einer totalen Ehrlichkeit bezüglich der eigenen Schwächen; es geht darum, diese Schwächen auszumerzen.<br /><br />Das ist was ganz anders als das, was man bei den "Agilen" vorfindet.<br /><br />Bei den Retrospektiven, so wie sie normalerweise ausgeübt werden, werden Spielchen gespielt (so offensichtlich mit dem Ziel, die Leuten zu unterhalten, als wären sie im Kindergarten), bestenfalls werden hier ansatzweise wunde Punkte angesprochen, wobei meistens ohne jegliche Kommentare (Schweigen im Walde) oder gar Konsequenzen (wer sich bewegt hat verloren, m.a.W. wer zugibt, dass tatsächlich Probleme existieren - Postbote schlechter Nachrichten - wird [symbolisch] exekutiert); Keiner wagt "unangenehm" auf zu fallen oder mehr als nur dezent (leichte) Probleme anzusprechen.<br /><b>Somit ist der ganze Sinn und Zweck einer solchen Retrospektive für die Katz.</b><br /><br />Dazu kommt, dass diese Retrospektiven als fester Bestandteil eines Sprints betrachtet und handhabt werden, dergestalt, dass sie als notwendige Zeremonie angesehen werden, ...und die normalen Mitglieder eines Teams lassen das Ganze - geduldig - über sich ergehen. Sie wissen doch, dass es sich um (noch) eine Zeremonie ohne Folgen handelt.<br /><br />Der Leitgedanke hinter dieser Retrospektive ist, wie fast alles, was aus der Toyota kommt, richtig und wichtig.<br />Leider, wie bei so vielen positiven Ideen, bei den Agilen ins Gegenteil umgewandelt.<br /><br />
Man soll berücksichtigen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind und ein gewichtiges Teil dieser Problemen ist nun mal ein unfähiges Management (daher so viele Meetings, um das Management zu ersetzen), leider und aus Gründen die mir unbegreiflich sind,<b> werden alle gute Ideen, die die Agilisten anfassen, zu unnützlichen, hemmenden Brocken,</b> die am Halse der Projektmitarbeiter hängen und ihr Handeln zu lahmen drohen.<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-69853864942773525382017-10-23T17:46:00.001+02:002017-10-27T08:59:13.445+02:00Gedankenfehler im Ansatz bei den Agilen - Teil 2 von 3Hier:<br />
<br />
2. The team is authorised to take decisions (<i>Das Team hat die Befugnis, Entscheidungen zu treffen)</i>.<br />
<br />
Within a cycle, the project team must be authorised to do what they think is best. If<br />
the project team does not have this power, the cyclical model of project management will not work.<br />
(<i>Im Laufe eines Zyklus muss das Team die Befugnis haben, das zu tun, was sie als das Beste erachten.<br />Sollte das Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren</i>).<br />
<br />
Das ist noch so eine Idee, die in Teile richtig ist aber dadurch, das sie nicht zu Ende gedacht ist, nicht wirklich dienlich (zweckdienlich) ist.<br />
<b>Die Leute, die Ahnung haben, sollen Entscheidungen treffen können.</b><br />
Menschen müssen die Macht haben, Fehler anzusprechen und Probleme bekannt zu geben, doch nicht jeder muss sich die Freiheit nehmen, irgendetwas zu ändern nur weil es ihm so besser gefällt, ohne zu wissen was er genau macht.<br />
Das mündet doch in der Verantwortungslosigkeit, wenn alle Fehler machen dürfen und keiner muss für Fehler gerade stehen.<br />
<br />
<b>Darüber hinaus sind die Teams</b> - aus der Sicht der Agilisten gesehen - <b>überbewertet</b>. Die Agilisten scheinen zu glauben, dass alles durch die Selbststeuerungsfunktion eines Team geheilt und in die richtige Bahn gebracht werden kann. Das ist: Überbewertung.<br />
<br />
Die Aussage "[...] Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren" ist auch nicht richtig: ein zyklisches Modell ist unabhängig von 1. Teams und 2. von den Befugnissen des Teams.<br />
<br />
Man soll jedoch nicht vergessen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind, wo Teams eigentlich einzelne Mitarbeiter waren, mehr oder minder isoliert von dem Rest der Mitarbeiter gearbeitet und von dem Management als "Ressource" betrachtet wurden. Daher ist dieses (agile) Umdenken, wenn auch radikal, schon gewissermaßen gerechtfertigt.<br />
<br />
Das "Richtige" ist es aber noch nicht...Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-74169079621332000842017-10-18T18:40:00.001+02:002017-10-18T18:44:20.562+02:00Gedankenfehler im Ansatz bei den Agilen - Teil 1 von 3Hier: <br />
<br />
1. Users/customers are actively involved (Benutzer und Kunden nehmen aktiv im Entwicklungsprozess teil).<br />
<br />
Das bringt nicht wirklich viel und es macht für den Kunden überhaupt keinen Sinn, ständig bei dem Lieferanten antanzen zu müssen. Die Idee ist gut, die Implementierung ist mangelhaft (bisweilen eine Katastrophe).<br />
<br />
In der Praxis sieht das so aus, dass der "Kunde" einmal pro Sprint (oder so; nicht "täglich", das ist Nonsense) bei dem Auftragnehmer erscheint, ihm wird das vorgeführt, was funktioniert, der "Kunde" sagt; 'hübsch hübsch!' und geht wieder.<br />
Eigentlich ein Zeitverlust für alle, das Schlimmste aber ist es, dass es für den AG keine wirkliche Verpflichtung gibt, sich mit dem Entwicklungsstand auseinander zu setzen.<br />
Aussagen sind mündlich und somit nicht bindend.<br />
Die Einstellung des AG ist in Allgemeinen so, dass er sowieso vom AN erwartet, dass die SW erstellt wird; seine Anwesenheit ist eine zu "leichte" Sache; er testet nicht, lässt sich lediglich die SW vorführen.<br />
Es gibt natürlich Firmen, wo das etwas anders abläuft.<br />
<br />
Also...<br />
<b>Vorteile:</b><br />
<ul>
<li>Der Kunde gibt Rückmeldung (Wichtig).</li>
<li>Die Entwickler könnten einen Eindruck erhalten, wie der Benutzer mit der SW umgeht (Wichtig!) - wenn es einigermaßen gut durchgeführt wäre... eher seltener als die Ausnahme -.</li>
</ul>
<br />
<b>Nachteile:</b><br />
<ul>
<li>Zeitverlust für die Teilnehmer die an Meetings teil nehmen, die nichts zu melden haben</li>
<li>Zeitverlust für den Kunden, denn oft fahren mehrere Personen zum AN und verschenken die eigene Zeit, sowohl in Meetings als auch bei den Fahrten - ohne konkretes Ergebnis (nichts spezifiziert => kein Ergebnis) -.</li>
<li>Dass der Kunde vor Ort ist garantiert in keiner Weise, dass die SW fehlerfrei ist.</li>
<li>Kommunikationsschwierigkeiten können auftreten, die Möglichkeit und Einfluss von Missverständnissen erhöht sich durch die eher nicht strukturierte Vorgehensweise - im Gegensatz zu dem, was postuliert wird -.</li>
</ul>
<br />
Scheint mir so eine wischi-waschi Lösung zu sein für das Problem "Anforderungsmanagement" zu sein, welche mittels einer Art "Meeting" eine Pseudo-Lösung herbeizuführen wünscht.<br />
<br />
<br />
<br />
Und überhaupt; sieht ganz so aus, als würden die "Agilen" versuchen, alle Schwierigkeiten mittels Meetings zu lösen.<br />
<br />
Man soll immer bedenken, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind. Das heißt nicht, dass sie nicht ihre eigene Probleme herbeiführen und auch nicht, dass die Lösung auch eine ist.<br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-90614364974779321162017-09-30T18:08:00.000+02:002017-09-30T18:08:14.919+02:00Das "agile Manifesto": Ein Manifesto der Frust?"Agil" sollte eigentlich bedeuten, dass man die SW-Entwicklung an die Menschen anpasst (Manifesto!). Leider ist wieder mal das Gegenteil von dem geschehen, was man sich vollmundig versprochen hat: Die Menschen werden in Wirklichkeit an einem (nunmehr "agil" genannten) Prozess (stark bis sehr stark) angepasst.<br /><br />Eine Entwicklungsmethode muss mit den Menschen, die man hat, klar kommen.<br /><br />"Nehmen Sie die Menschen, wie sie sind, andere gibt es nicht", so hat ein Politiker, Konrad Adenauer, mal gesagt.<br /><br />Sowohl die klassischen Methoden als auch die sogenannten "agilen" (insbesondere Scrum - das Gedränge) wollen die Menschen an einem Prozess anpassen. Vielleicht soll man sich Gedanken machen, ob dieses "Wollen" nicht in Wirklichkeit ein "Sollen" sein soll: <b>Ist es nicht so, dass ein Prozess gegeben sein muss, um eine bestimmte Arbeitsleistung zu erbringen?</b><br /><br />Wenn dem so ist, so brauchen wir tatsächlich einen Rahmen (Methode), der uns ein Prozess definiert, wo aber die Mitarbeiter sich so weit entfalten können wie möglich. <b>Das ist weder mit den klassischen noch mit den sogenannten "agilen" der Fall.</b><br /><br />Auch "KanBan" [das "agile" KanBan, hat mit dem wirklichen (Toyota-) KanBan wenig zu tun] will die Menschen an einem bestimmten Prozess angepasst haben.<br /><br />Das kann funktionieren, muss aber nicht, und auf jeden Fall funktionieren solche Methoden dann "suboptimal":<br />Klassische Methoden haben den Manko, dass sie ziemlich starr sind und die Mitarbeiter die Freiheit nicht haben, seine Arbeit zu verbessern (Stichwort Kaizen).<br />
<br />Die sogenannten "agilen" Methoden auf der anderen Seite haben aber den Manko, dass sie eine falsche Freiheit versprechen. Dies hat wahrscheinlich seinen Ursprung in der Tatsache, dass normale (schlichte) Entwickler das "Manifesto" geschrieben haben.<br />
<br />
Siehe meine Homepage und die alten Blogeinträge:<br />- <a href="http://www.ruynk.com/ruynk_agilismus_analyse.htm">http://www.ruynk.com/ruynk_agilismus_analyse.htm</a><br />- <a href="http://ruynk.blogspot.de/2015/03/wie-agil-ist-eigentlich-agil-was-kann.html">http://ruynk.blogspot.de/2015/03/wie-agil-ist-eigentlich-agil-was-kann.html</a><br />- <a href="http://ruynk.blogspot.de/2015/05/agile-prinzipien-schwammig-schwach-lahm.htm">http://ruynk.blogspot.de/2015/05/agile-prinzipien-schwammig-schwach-lahm.htm</a>l<br /><b> </b><br />
<b>Das "Manifesto" wurde aller Anschein nach aus Frust geschrieben (die "klassische" SW-Entwicklung kann ser frustrierend sein!) und mangelt sowohl an wissenschaftlicher Stringenz als auch an der notwendigen Flexibilität um es an die wirklichen Gegebenheiten in den Firmen anzupassen.</b><br /><br />Zwar wird behauptet, dass die "agilen" Teams die "agilen" Methoden anpassen können und sollen, doch... das ist zu viel der Freiheit; der "falschen" Freiheit (Stichwörter: Chaos, Willkür, Unverantwortlichkeit, Dogmatismus u.a.).<br /><br />Eine echte Lösung muss versuchen, die Menschen (MA) jeder für sich optimal einzusetzen. <b>FlePA</b> verfolgt diesen Ansatz.<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-15072680122843230012017-06-20T19:57:00.001+02:002017-06-20T19:57:12.679+02:00Über die magische Entstehung von "Agilität" durch den Einsatz von ToolsIn der "agilen" Welt, so wie ich sie in den letzten Jahren bewundern durfte, ist einen lustigen Ansatz zu beobachten:<br />Erstens: Es existieren eine Serie an Tools, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "Jira"; <b>den Einsatz solchen Tools wird nun erzwungen.</b><br />Zweitens: Es existieren eine Serie an Praktiken, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "CI/CD" (Continuous Integration / Continuous Deployment); <b>den Einsatz solchen Praktiken wird nun erzwungen.</b><br /><br />Der Ansatz wird wohl in der Hoffnung oder dem Glaube verfolgt, dass lediglich eine geistlose Anwendung einer Mechanik ausreichend ist um ein Ergebnis herbeizuzaubern.<br /><br />Das ist ein Glaube an einer (einfachen) mechanischen Kausalität.<br /><br />Doch wir haben es eigentlich hier mit sehr komplexen Interaktionen in einem sozialen Gebilde (kein "System" sondern eher ein "Organismus") zu tun. Hieraus erklärt sich der Denkansatz der überwältigen Wichtigkeit des "Teams" als solches: Deshalb schwafelt man gerne von den sich selbst organisierenden Teams und dass das Ergebnis mehr sein soll als den Beitrag jeden einzelnen usw.<br /><br />Nun, es sieht so aus, als würden die sogenannten "agilen" Methoden erwarten, dass durch die mechanische Anwendung bestimmter Rituale (Praktiken) und Tools ein organisiertes (organisches) Team entstehen soll: Das kann (könnte) passieren, muss aber nicht. Und wenn Jemand erwartet dass etwas passiert, was passieren "könnte", pflegt diese Person eigentlich nichts anderes als "Wunschdenken".<br /><br />Nehmen wir z.B. CI/CD als Untersuchungsobjekt:<br /><br />CI/CD scheint eine Technik zu sein, die in Zusammenhang mit den sogenannten "agilen" Firmen mehr und mehr eingesetzt wird.<br /><br />Dazu möchte ich auf 2 Punkten aufmerksam machen, die mir bei der Arbeit in den letzten Jahren aufgefallen ist.<br /><br />1) CI/CD ist eine Technik die eigentlich für Projekte weniger bis gar nicht anwendbar ist: Viele 'Manager' wollen sie jedoch haben, weil sie scheinbar "agil" ist. Doch eigentlich sollte sie <span style="font-size: large;"><b>nur</b></span> für die Serienproduktion einzusetzen sein. Die Idee stammt doch von der Toyota Serienautoproduktion. Als solche erzeugt sie bei der Projektarbeit eine schwer zu beherrschenden Overhead-Verwaltung. Vor Allem im Zusammenhang mit den ach so wichtigen automatischen Tests (mehr dazu lesen Sie hier: http://www.ruynk.com/ruynk_irrlicht_agil.htm - unter "Negative Eigenschaften der agilen Methoden" den letzten Punkt, über automatische Tests).<br /><br />2) Bei vielen Firmen, die sich "agil" benennen wollen, werden Tools zur CI/CD eingeführt und eingesetzt, ohne wirklich verstanden zu haben, was CI/CD bedeutet. Und was bedeutet CI/CD? Die Idee hinter CI/CD ist wohl, das man ständig Änderungen und Verbesserungen (quasi in einem immerwährenden Prozess) im fertigen "Produkt" einfließen lassen kann.<br /><br />Ich denke, dass man als erstes das Prozess so anpassen und optimieren soll, dass eine CI bzw CD Sinn macht. Das wird selten gemacht: Das wäre doch eher die Arbeit von Analysten, doch Analysten werden von den Firmen nicht mehr nachgefragt.<br /><br />Davor jedoch sollte man sich Gedanken machen, was für einen Sinn CI/CD hat, sowohl für die Entwickler als auch für den Kunden. Solche Überlegungen werden auch (sehr) selten, manchmal gar nicht durchgeführt.<br /><br />Vielleicht hofft das 'Management', dass CI/CD sich beim bloßen Anwenden von Tools einstellt.<br /><br />Vielleicht hofft das 'Management', dass die "Agilität" sich beim bloßen Anwenden von Tools (und Praktiken) einstellt.<br /><br />Das wird selten vorkommen. Das ist Wunschdenken.<br /><br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-19245921377489604422017-06-20T19:47:00.001+02:002017-06-20T19:47:20.808+02:00Post-Agile... ein Begriff von Kritekern des "Agilismus"...Einige Seiten, die sich mit "Post-Agile" auseinandersetzen:<br /><br />Interessanter Vergleich klassisch-agile mit vielen Anmerkungen:<br />https://www.artefactgroup.com/articles/post-agile-a-design-thinking-approach-to-software-development/<br />
<br />Startseite des Blogs:<br />https://postagilist.wordpress.com/<br /><br />"Scrum" als magisches Werkzeug:<br />https://postagilist.wordpress.com/2011/04/05/the-flawed-rhetoric-about-scrum-and-organizational-dysfunction/<br />
<br />
<br />
<br />
<br />"Agile" als kommunistisches Regime:<br />https://postagilist.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/<br /><br />Interessant, viele Punkte, die ich selber schon bemängelt habe, hier:<br /><a href="http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf">http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf</a><br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-70877686299586052102017-06-20T19:44:00.001+02:002017-06-20T19:44:33.275+02:00Neue Homepage für "AMTRS"Neue Homepage für "AMTRS" (Analysieren - Modellieren - Trainieren - Reorganisieren - Systematisieren)<br />
<br />
Hier: <a href="http://www.amtrs.de/">http://www.amtrs.de</a><br />
<br />
Die Seite über "Systemanalyse" ist wert zu lesen, und<br />
Downloads sind interessant!<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-54124790245699715642017-06-20T19:41:00.003+02:002017-06-20T19:41:52.506+02:00Neue Homepage für "RyuSui"Neue Homepage für "RyuSui" (IT-Wissen; Kurse und Seminare)<br />
<br />
Hier: http://www.ryusui.de<br />
<br />
Einige der Downloads sind interessant, aber nicht nur!<br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-34050043003337958552017-05-25T21:50:00.004+02:002017-05-25T21:50:42.970+02:00Zwei Kommentare zu zwei bei den "Agilen" verwendeten BegriffenZunächst möchte ich auf einen Vergleich verweisen:<br />
<br />
<a href="http://www.ruynk.com/downl/Vergleich_zwischen_Agilen.pdf">http://www.ruynk.com/downl/Vergleich_zwischen_Agilen.pdf</a><br />
<br />
Hier geht es um eine Untersuchung über die verschiedenen agilen Methoden (es wurden 26 verschiedene Methoden bewertet und aufgrund dieser Bewertung habe ich den Vergleich durchgeführt). Wobei ich muss schon sagen; das Ergebnis fiel mehr oder minder wie erwartet. Dennoch interessant.<br />
<br />
Doch eigentlich wollte ich auf auf 2 Begriffe eingehen.<br />
<br />
<h4>
1. Kanban</h4>
Ich wundere mich immer wieder wenn Menschen (insbesondere Leute der IT Branche, die es eigentlich besser wissen sollten) meinen, Kanban wäre eine agile Entwicklungsmethode.<br />
Ich weiß leider nicht wie "lazy" die Kollegen mit den Wörter umgehen, aber Kanban ist keine Entwicklungsmethode:<br />
<b>KanBan ist ein Tool (Werkzeug) zum Visualisieren der Arbeitspaketen!</b><br />
Nicht mehr und nicht weniger.<br />
Oder sind Sie, werter Leser, über "Kanban" eine andere Auffassung?<br />
<br />
<br />
<h4>
2. Scrum</h4>
Mein Lieblings Punchingball: Das Gedränge :-)<br />
Scrum ist meiner Meinung nach ein Sammelsurium an Praktiken, keine Methode. Natürlich lässt sich schon streiten, in wie weit Scrum eine Methode ist.<br />
Wikipedia ("https://de.wikipedia.org/wiki/Methode_(Softwaretechnik)") liefert uns folgende Definition:<br />
"Als <b>Methode</b> – „wörtliche Bedeutung: Der Weg zu etwas“ (Duden) – bezeichnet man in der Informatik und der Softwaretechnik
eine „systematische zielgerichtete Vorgehensweise, sowie planmäßiges
Verfahren, welches für eine Vielzahl von Problemen zu einer sinnvollen
Lösung führt“ und/oder „eingeübte oder formalisierte Abläufe, die sich
als zweckmäßig und erfolgreich erwiesen haben<br />
Die 1. Definition trifft für Scrum nicht zu, denn Scrum ist nicht "planmäßig" (<b>Klar!</b> Scrum - und die "Agilen" im Allgemeinen - wollen keine Planung). Und ich halte Scrum auch nicht für "systematisch" - es ist dahinter kein System zu erkennen.<br />
Die 2. Definition könnte schon gelten, dies liegt daran, dass die Definition zu ungenau ist: "...
als zweckmäßig und erfolgreich erwiesen haben" - ja... wie weit zweckmäßig und wie genau erfolgreich?<br />
Aber jetzt will ich es kurz machen, abgesehen von allen Erklärungen, Methode ist "der Weg zu etwas" und das reicht mir und ist genau genug für mein Geschmack;<br />
<b>Scrum ist nicht der Weg zu etwas,</b> sondern lediglich ein loser Haufen an mehr oder minder brauchbaren Praktiken. Einen "Weg" stellen sie nicht dar.<br />
<br />
Auch hier bin ich an Kommentare über die Methode-Eigenschaften des Scrums gespannt: Meinungen...?<br />
<br />
Bis bald<br />
ruynk<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-51736770668549344192017-04-06T16:28:00.003+02:002017-04-06T16:28:59.469+02:00Der "SW-Entwickler als Fabrikarbeiter" vs. der "SW-Entwickler als Kreativitaetsmanager"In meiner Untersuchung ("Untersuchung bezüglich der SW-Entwicklungsmethoden im Unternehmen mit dem Schwerpunkt 'Agil' und ansatzweise Suche einer Lösung für die Unzulänglichkeiten der gegenwärtigen SW-Entwicklungsmodelle", hier können Sie sie downloaden: http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf) ist zu lesen, dass eine gute Möglichkleit, das Beste aus der SW-Entwicklung als Prozess heraus zu kriegen ist indem man den Entwickler erklärt, was man haben will, und sie dann gewähren lässt.<br /><br />Diese Vorgehensweise ist stark vereinfacht und hat sowohl einige Vorteile als auch gravierende Nachteile (Stichwörter: Vergoldung, falsch verstandene Anforderungen, Änderungen ausser jedwede Steuerung, usw usf).<br /><br />Dennoch hat die Vorgehensweise zweifelsohne wichtige Vorteile für das Ergebnis der SW-Entwicklung.<br /><br />Die Grundlage dieser Vorgehensweise ist die Auffassung der Entwickler selbst, sie sehen sich als seien sie kreative Experten und Wissenmitarbeiter in einem.<br /><br />Dagegen finden wir auf der anderen Ende der Skala Methoden wie Scrum, wo die SW-Entwickler wie Fabrikarbeiter behandelt werden und die zu bauenden SW als Mauer aus Steine, die die SW-Entwickler zusammen zu kleistern haben; mit Hilfe von schlauen Tools und unzähligen Meetings (Stichwort Mikromanagement) sollen diese Fabrikmitarbeiter nun in der Lage verstezt werden, die SW zu konstruieren.<br /><br />Es dürfte klar sein, dass diese "Scrum" (Gedränge) Vorgehensweise auch weit entfernt von einem Optimum ist.<br />Vorteile: Mikromanagement; das Management ist jederzeit in der Lage den aktuellen Stand zu wissen.<br />Nachteile: Die Entwickler arbeiten weit unter ihre eigentlichen Fähigkeiten.<br /><b>Ist nun ein SW-Entwickler ein Fabrikarbeiter oder ist er ein Kreativitätsmanager?</b> Beide Ansätze sind falsch!<br />Ein SW-Entwicler ist ein SW-Entwickler und kein Designer, Architekt, Tester, oder was auch immer ein Modell aus ihm machen will!<br /><br />Mit <b>FlePA</b> jedoch, als Nachfolge der sogenannten "Agilen", werden die SW-Entwickler wieder zu dem, was sie sind und somit die Entwicklung von SW selbst, als solche, optimiert.<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-26681610779824482082017-03-15T21:12:00.000+01:002017-03-15T21:12:40.310+01:00Kann "Planen" flexibel sein?Bei <b>FlePA</b> (Flexibles Planen und Arbeiten) kommt doch ein "flexibles Planen" vor.<br /><br />Nun, daraus ergibt sich eine durchaus berechtigte Frage:<br />Wie kann man das "flexible" Planen verstehen?<br /><br />Planen ist doch, sagen wir mal, sehr "rigide"... Man plant und daran soll man sich halten. Oder?<br /><br />Von einem "flexiblen Planen" zu sprechen klingt wirklich so, als würde ich von einer "lebendigen Leiche" oder von "trockenem Wasser" reden. Richtig?<br /><br />Nun; Planen ist nicht das Gleiche wie Planung.<br /><br />Dadurch, dass ich (mit flexiblem Denken) Planung und Planen auseinander definiert und das Planen durchexerziert habe, habe ich eine Lösung gefunden und diese in <b>FlePA</b> eingearbeitet.<br /><br /><br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-2549447625016791432017-03-11T22:16:00.001+01:002017-03-11T22:16:38.789+01:00Die "Agilen" (Methoden) als notwendiges Uebel<br /><br />Vielleicht haben Sie, werter Leser, aus meinen Blogeintraegen den Eindruck gewonnen, dass ich ganz und gar gegen die sogenannten "agilen" Methoden bin.<br /><br />So ganz stimmt das nicht.<br /><br />Ich halte die sogenannten "agilen" Methoden fuer einen ersten Schritt in der richtigen Richtung... leider hat man mit diesem 1. Schritt (nicht zuletzt wegen Missgeburten wie Scrum) richtig fett im Haeufchen getreten, dennoch haben wir, so wie ich es sehe, <b>mit einem Schritt in der richtigen Richtung zu tun.</b><br />
<br />Der Softwareexperte Erik Meijer bezeichnet agile Methoden als "Krebsgeschwuer":<br /><a href="http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/management/articles/471509/">http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/management/articles/471509/</a><br /><br />Ich habe einen grossen Respekt dem Kollegen Erik Meijer gegenueber, er sagt aus meiner Sicht eine Wahrheit aus: die "Agilen" seien ein Krebsgeschwuer, so wie sie zurzeit wuchern, ist die Aussage wohl zutreffend.<br /><br />In meiner Meinung sind sie, die "Agilen", giftig, ruhen auf falschen Praemissen, sind unkontrollierbar und, durch eine Aura an Esoterismus bedingt (wegen des Dogmatismus der verschiedenen "Methoden"), zersplittern sie in einer Vielzahl an "Sekten" (Methoden, Techniken oder wie man das Ganze, das uns blueht, nennen mag). <b>Die vielen "Sekten" zeigen deutlich, und das kann Niemand zweifeln, dass jegliche "agilen" Methode weit entfernt davon sind, eine Loesung oder gar ein Patentrezept zu sein.</b><br /><br />Aber... die "Agilen" sind nicht aus Jux und Tollerei entstanden, sondern als Antwort auf bestimmten und ganz konkreten Problemen, und diese sind unbedingt zu adressieren, wenn wir eine Loesung fuer die SW-Entwicklung wollen und suchen.<br /><br />
<b>Folglich halte ich die sogenannten "agilen" Methoden ein (zurzeit noch, aber nicht mehr lange) notwendiges Uebel in der SW-Industrie.</b><br /><br />Zum Glueck gibt es schon einen Nachfolger: <b>FlePA.</b><br /><br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-43225825795525916772017-03-08T20:59:00.000+01:002017-03-08T20:59:52.353+01:00Kommentare zum "Status-Quo-Agile-2016_17-Abschlussbericht_Studienteilnehmerversion_1.0.pdf"<br />Vor wenigen Tagen bekam ich diese Studie und las sie, da mir das Thema natürlich interessiert ;-)<br /><br />Folgende Punkte möchte ich gerne kommentieren<br /><br />Auf Seite 26:<br />Gründe für und gegen die Verwendung agiler Methoden<br />Gründe sich für agile Methoden zu entscheiden (1/2)<br /><br />"61% der Teilnehmer sagen, dass sie die Produkteinführungszeit optimieren möchten, 47% wollen die Qualität optimieren und 42% die Risiken im Projekt reduzieren."<br /><br /><b>Meiner Meinung nach haben sich die Herren, die sich das wünschen, sich nicht wirklich richtig mit der Thematik auseinandergesetzt: Ausgerechnet Produktivität und Risiken... Wunschdenken, anders kan nich es mir nicht erklären.</b><br /><br />"Während die meisten Teilnehmer eine bessere Betriebsleistung anstreben, gibt es nur einige, die es wegen sonstiger/ externer Gründe tun: 27% sind mit klassischem Projektmanagement frustriert und einige wenden agile Methoden an, weil es von Geschäftspartnern gefordert wird."<br /><br /><b>Das man mit dem klassischem Projektmanagement frustriert ist, kann ich gut verstehen. Da muss sich aber das 'Management' an die Nase fassen...<br />Und wenn Geschäftspartnern das nun fordern... na, da soll man sich sehr genau ausrechnen, in was man da reingezogen wird...</b><br /><br />Seite 98: Anwendungsformen - Nutzung agiler Tehniken: Lean Nutzer benutzen<br />"Daily Scrum: 87%<br />Sprint Planning 81%<br />User Stories: 80%<br />Sprint Review: 79% (also auch "Sprints")<br />... usw usf"<br /><b>Dabei ist mir aufgefallen, dass ausgerechnet "Lean", (das sich eigentlich bemühen sollte, "schlank" zu bleiben, mit wenig "Overhead" und überflüssigen Verwaltungsarbeiten), solchen Techniken mit starker ZeitVerlustCharakter wie "Daily Scrum", "Sprint Planning", "Sprint Review" usw anwenden... da haben sie sich die "Leans" (zumindest die, die an dieser Studie teil genommen haben), ins Knie geschossen.<br />Das ist, in meinen Augen, kein "Lean " mehr, sondern eine (giftige) Mischform.</b><br /><br />Und noch ein bisschen Nachdenken am Rande der Studie:<br /><br />Wenn ich mir die Anzahl an verschiedenen "Methoden" anschaue, so habe ich den Eindruck, dass ich mit Sekten zu tun habe.<br />Besonders augenfällig (für mich zunächst, wegen Mangel an Bodenständigkeit) sind Methoden wie: "Design Thinking", "Lean Startup", "Agile Modeling", "Adaptive Software Development", ...<br /><br />"Design Thinking": https://de.wikipedia.org/wiki/Design_Thinking<br />"Lean Startup": https://en.wikipedia.org/wiki/Lean_startup (englisch nur)<br />"Agile Modeling": https://en.wikipedia.org/wiki/Agile_modeling (englisch nur)<br />"Adaptive Software Development": https://de.wikipedia.org/wiki/Adaptive_Software_Development - Insbesondere auffällig: "Dabei wird alle vier Wochen geprüft, ob eine neu erstellte Programmversion einen Fortschritt zur Vorgängerversion darstellt. Dies geschieht gemeinsam mit dem Kunden. Zwischen jedem der Treffen werden die Phasen 'Spekulieren', 'Zusammenarbeiten' und 'Lernen' durchlaufen". Tja... man muss sich doch diesen Satz auf der Zunge zergehen lassen... ganz langsam, ganz genüsslich!<br /><br />Meinen Eindruck über die vielen mehr oder minder definierten agilen Methoden ist:<br /><b>Es handelt sich um ein wirrwarr an Sekten, die viel (viel zu viel) Text produzieren, jedoch nichts Konkretes: Die Produktion liegt auf einem sehr - sehr - niedrigen Niveau.<br />Ich persönlich lese die ganzen Artikel gar nicht mehr; ich überfliege sie, suche nach Ergebnissen, finde sie nicht, denke mir "schon wieder Überflüssiges...".</b><br /><br />Anmerken muss ich, dass ein grosses Teil der Studie "Status Quo..." auf "Einschätzugen" von Teilnehmern basiert; leider ist das einerseits nicht sehr wissenschaftlich und andererseits nicht wirklich aussagekräftig, in meinen Augen...<br /><br />Noch eine Anmerkung (die 2.): Wie ausagekräftig die Statiskiken aus einer mathematischen statistischen Betrachtungsweise sind, damit habe ich mich nicht auseinandergesetzt. Ich will die Studie doch nicht zerpflücken (nur kommentieren).<br /><br />3. Anmerkung: Es ist leider nicht möglich zu wissen wie viele der Teilnehmer an die Studie eigentlich z.B. (externe) Berater bzw Mitarbeiter sind, die allgemein von dem "agilen" Hype leben oder leben wollen, und dementsprechen fallen die Aussagen in dem Sinne: positiv für die "agilen" Methoden. Die ganze Studie ist folglich aus meiner Sicht mit sehr viel Vorsicht zu geniessen.<br /><br />Die Autoren der Studie sprechen diesen Punt auch auf Seite 188 an: "Ein Bias (eine Verzerrung) in der Stichprobe, der die Ergebnisse beeinflusst hat, kann somit nicht ausgeschlossen werden - ist sogar wahrscheinlich. Auch beruhen die Ergebnisse auf Eigeneinschätzungen der Teilnehmer. Es ist nicht auszuschließen, dass einige Angaben nicht der Realität entsprechen."<br /><br />Interessante, ergänzende Information auf Seite 169:<br />"27% der Teilnehmer, die eine Angabe zur Zertifizierung gemacht haben, haben eine Scrum Alliance oder Scrum.org Zertifizierung."<br /><br /><b>Also hatten 80% der Teilnehmer eine agile Zertifizierung:</b><br />Seite 170:<br />Scrum.org: 27%<br />Scrum Alliance: 27%<br />Sonstige Zertifizierung für agile Methoden: 13%<br />Kanban Zertifizierung: 7%<br />Andere Scrum-Zertifizierung: 6%<br /><br />Noch eine interessante, ergänzende Info: Die Teilnehmerstruktur. Hierauf will ich nicht mehr eingehen, wer Interesse hat, soll sich die Studie beschaffen und lesen.<br /><br />Eine zusätzliche, interessante und ergänzende Info zu berücksichtigen ist auf Seite 191 zu lesen; die Liste der bedankten Unterstützer der Studie. ...Einfach als Hintergrundinformation.<br /><br />Und die letzte interessante und ergänzende Info: Der Studieninitiator, Prof. Dr. A. Komus ist u.a. auch (Mit)Initiator der Praxiswerkstatt Agilität, Consultant und Coach in agilen Methoden, hat u.a. auch eine Studie "agiles PMO" (PMO: Projekt Management Office) geschrieben. Infos aus der Seite 189.<br />
<br />
Honi soit qui mal y pense. Interessant ist die Studie allemal.<br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-65741085132854271902017-03-06T22:28:00.002+01:002017-03-06T22:29:12.895+01:00Ein Paradies auf Erden: agiles WunschdenkenIch habe etwas interessantes gelesen!<br />
<br />
Aus<br />
https://deutscherarbeitgeberverband.de/aktuelles/2017/2017_01_23_dav_aktuelles_wissen-nicht.html<br />
folgenden Text:<br />
"Es ist oft gesagt, aber selten gehört worden, dass der abstrakte Wunsch, allen Menschen das Paradies zu bereiten, der beste Weg zur Erzeugung einer konkreten Hölle ist. Das hängt mit den "guten Absichten", die auch ohne jede Kompetenz zum Handeln antreiben, eng zusammen."<br />
Dörner untersuchte experimentell auch, ob die Gruppe, also die "Weisheit der Vielen", positiven Einfluss auf die Qualität der Entscheidungen hat. Dem war allerdings nicht so, vielmehr ergaben sich negative Gruppendynamiken, z.B. das sogenannten Gruppendenken, welche die Gruppe am Erfolg hinderten."<br />
<br />
Daraus lässt sich folgern, dass sowohl eine Arbeitsweise nach "Wasserfall" (also nach einem wie auch immer gestaltenen hierarchischen System) als auch nach den "agilen" Merthoden (das Team als Leistungsträger) nicht wirklich, in der Praxis, funktionieren können.<br />
Warum?<br />
Weil:<br />
<ol>
<li>Handeln ohne Kompetenz - Kompetenz im Wissen und Kompetenz im Treffen von Entscheidungen - (typisch fuer die "agilen" Methoden)</li>
<li>Eine "Weisheit der Vielen" gibt es nicht, nur das Durchsetzen der Lautesten</li>
<li>Aus einer fehlenden Ordnung ergeben sich "negative Gruppendynamiken".</li>
</ol>
Alle 3 Punkte entspringen dem Wunschdenken, Menschen (Mitarbeiter) ein Paradies auf Erden anbieten zu wollen. Auch das agile Manifesto postuliert klar ein Paradies, welches sich aus eben ähnlichem Wunschdenken ableiten soll.<br />
<br />
Die Lösung? <b>FlePA</b>.Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-59067389949165036802017-02-14T16:12:00.002+01:002017-02-14T16:12:22.378+01:00Warum "FlePA"Hier ein bisschen Information, zum Runterladen:<br />
<br />
<a href="http://www.ruynk.com/downl/Warum_FlePA.pdf">http://www.ruynk.com/downl/Warum_FlePA.pdf</a><br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-47586790174866625172017-01-25T22:51:00.002+01:002017-01-25T22:52:12.571+01:00"Agile" Methoden vergleichen: Anstoße zum NachdenkenHier:<br />
<br />
<a href="http://www.ruynk.com/downl/Vergleich_Agile_nichtAgile.pdf">Gedanken zu einem Vergleich zwischen "Agile" und "nicht Agile"</a> (Version vom 25.01.2017)<br />
<br />
und<br />
<br />
<a href="http://www.ruynk.com/downl/Vergleich_Agile_nichtAgile.pdf">Vergleich zwischen agilen Entwicklungsmethoden (Version vom 25.01.2017)</a><br />
<br />
Viel Spaß beim Lesen!<br />
<br />
ruynk<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com0tag:blogger.com,1999:blog-8331990885868323473.post-70757353733265489892017-01-06T19:33:00.000+01:002017-01-08T13:43:22.599+01:00'Copy und Paste' beim Buchschreiben - ein kurzer KommentarIrgendwie schaffen die "Agilen" von sich reden zu lassen, wenn auch der Autor eigentlich besser täte, sich nicht zu äussern... So entstehen falsche Eindrücke, Dogmatisches und 'Hören-Sagen', wenn man ungeprüft Text durch Kopieren entstehen lässt. Oder soll ich die Aussagen vom Autor im Buche einfach als "Modererscheinungen" gelten lassen?<br />
<br />
Im Buch "Projektmanagement" von Patzak und Rattay, 6. aktualisierte Auflage, Seite 703, kann man einen Vergleich zwischen Agilen und Klassischen Entwicklungsmethoden lesen. Hier meine Kommentare, nicht in Tabellenform sondern als Liste:<br />
<br />
1)<br />
Agiles Wert: Vertrauen<br />
Klassisches Wert: Misstrauen/Kontrolle<br />
Meine Meinung dazu: Man hat es sich hier viel zu einfach gemacht (m.a.W. einfach die "agile" Propaganda übernommen). Die Aussage stimmt nicht: Unter Scrum z.B. kommt es häufig zu einem unerträglichen Mikromanagement. In den "klassischen" andererseits spricht nichts dagegen, dass das Management in dem, was die Entwickler tun (entwickeln halt), Vertrauen hat.<br />
<br />
2)<br />
Agiles Wert: Verantwortung des Teams<br />
Klassisches Wert: Gesamtverantwortung Projektleiter<br />
Meine Meinung dazu: Das mit der Verantwortung des Teams ist Wunschdenken.<br />
<br />
3)<br />
Agiles Wert: Selbstorganisation im Team<br />
Klassisches Wert: Führung durch den PM<br />
Meine Meinung dazu: Das mit der Selbstorganisation des Teams ist Wunschdenken (kann funktionieren, muss aber nicht).<br />
<br />
4)<br />
Agiles Wert: Schätzungen/Entscheidungen im Team<br />
Klassisches Wert: Vorgaben/Entscheidungen durch Projektleiter/Auftraggeber<br />
Meine Meinung dazu: Mitarbeiter im Team sind dazu da, ihre Arbeit zu machen, nicht (r)um zu schätzen. Entscheidungen waren schon immer eine Domaene des Managements. So eine Vorgehensweise macht nicht immer Sinn (eher ausnahsweise, gebe ich zu - wenn das Management ein 'Management' ist, sie meine "Untersuchung...": Downloadseite bei www.ruynk.com)<br />
<br />
5)<br />
Agiles Wert: Auftraggeber-Koordination durch das Umsetzungsteam<br />
Klassisches Wert: Auftraggeber-Koordination durch Projektleiter<br />
Meine Meinung dazu: Das Team als solches ist dazu da, die Arbeit zu erledigen, nicht um Auftraggeber zu koordinieren.<br />
Der Gedankenfehler hier scheint mir der zu sein, dass die "Agilen" das Team als eine Person (Entität) betrachten, anstatt, wie es tatsächlich ist, als eine arbeitende Menge von Individuen.<br />
<br />
6)<br />
Agiles Wert: Prozessoptimierung durch das Team<br />
Klassisches Wert: Prozessoptimierung angestossen durch den Projektleiter<br />
Meine Meinung dazu: Um ein Prozess zu optimieren, soll man es gut kennen und die angrenzenden Prozesse sollen auch noch berücksichtigt werden; selten wird es der Fall sein, dass ein Team das notwendige Know-How hierzu hat.<br />
<br />
7)<br />
Agiles Wert: Teamprozessreflexion durch das Team selbst<br />
Klassisches Wert: Teamprozessreflexion auf Initiative des Projektmanagers<br />
Meine Meinung dazu: In der Wirklichkeit kann man aber deutlich beobachten, dass der "Prozess Master" (Name verwendet für die Rolle des 'Scrum Master' in dem o.g., Buch so fern ich das verstanden habe) die ominöse "Reflexion" anstosst, regelmässig, auch ohne Notwendigkeit, aus dem "Prozess" heraus, oft mit Null Zugewinn, also eher Zeitverlust (solange lustige Spielchen nicht als Zeitgewinn zu verbuchen sind).<br />
<br />
<br />Ruynkhttp://www.blogger.com/profile/06381372164994952460noreply@blogger.com3