Montag, 23. November 2015

Software-Entwicklung: Ist Chaos eine positive Eigenschaft bei der Entwicklung?

Chaos aus Kundensicht

Zunächst ist es wichtig zu betonen, dass ein "Kunde" für sein "gutes Geld" eine ordentliche Ware oder DL (Dienstleistung) erhalten will, die eine Qualität aufweist, wie der Kunde sie erwartet.
  1. Eine Ware, die ordentlich produziert worden ist, dürfte in den meisten Fällen die Erwartungen des Kunden entsprechen.
  2. Eine Ware oder DL jedoch, die in einer chaotischen Produktionsumgebung entwickelt worden ist, dürfte in einer beträchtlichen Anzahl der Fälle nicht die Erwartungen des Kunden erfüllen, ganz einfach, weil in einer chaotische Umgebung Details ignoriert, vernachlässigt oder gar vergessen werden.

Hand aufs Herz: Würden Sie eine Buchhaltungs-Software kaufen, die eine Gruppe von Chaoten zusammen geschrieben haben mit wenigen bekannten Software-Fehler - oder doch lieber die Software von einem Entwicklungs-Team bei dem ganz genau geplant wurde, was zu tun ist, haben aber jedoch mehr Software-Fehler entdeckt, doch keine bekannten gravierenden Fehler enthalten sind?

Chaos als Ausrede

Es gibt Menschen, die stets versuchen auf dem "Schreibtisch" Ordnung zu haben; kämpfen gegen das Chaos.
Wiederum gibt es andere Menschen, welche die Meinung vertreten, sie seien "kreative Chaoten". M.a.W. bedeutet das, dass sie nur aus einer chaotische Umgebung heraus eine kreative Arbeit erledigen können.

Organisieren

Organisieren ist doch der Versuch, Ordnung in einer ungeordneten Umgebung zu schaffen, um zu einem kontrollierten Ergebnis zu erlangen.
Das Organisieren tut man nicht aus Spaß oder Langeweile, sondern weil man dadurch einen geplanten und durchdachten Ergebnis erzielt und somit die Kundenwünsche besser abdeckt.

Anmerkung

Ich möchte hier noch betonen, dass meine heutige Ausführungen sich nicht gegen die sogenannten "agilen Methoden" im Allgemeinen richtet; vielmehr beziehe ich mich auf alle Entwicklungs-Umgebungen die mehr chaotisch als geordnet arbeiten.
Sowohl unter Anwendung von XP, Scrum, Kanban (ist das Agil?) usw kann eine stabile, organisierte Arbeitsweise statt finden.
Alles kann man organisieren.
Nur die sogenannten "agilen Methoden" lassen nicht nur mehr Freiraum (mehr Freiraum ist nicht schlecht, man muss ein bisschen mehr organisieren) -wo Chaos entstehen kann (nicht muss)- nein, das Problem ist, dass manchmal postuliert wird, das Chaos kreativ macht, produktiv ist.
Das mag für einzelnen Menschen vielleicht zutreffen, -obgleich nur unter sehr begrenzten Bedingungen- in den meisten Fällen jedoch (meiner Meinung nach) ist das eine Ausrede, um Schlampigkeit gut zu heißen.
Bei Teams dürfte die "Produktivität" unter chaotischen Umgebungen sehr, sehr rar sein... wenn sie überhaupt vorkommt, und wenn sie vorkommt, nur für eine ganz kurze Zeit.

Lösung

An der Lösung wird gearbeitet.

Ich wollte heute nur einige Gedanken zur Dekonstruktion des Mythos des "Kreativen Chaos" beitragen.

Und wie gefährlich diesen Mythos für die Qualität ist, die ein Kunde erhält.




Leser: Habt Ihr Kommentare?

Freitag, 30. Oktober 2015

Was ist ( eigentlich ) "Agil"?

Zunächst einmal bin ich der Meinung, dass Software-Entwicklung IMMER agil ist, weil man die Software, die "weiche Ware" auch sehr schnell ändern kann.

Das ist ein Vorteil (man kann schnell anpassen) gleichzeitig aber ein Nachteil (man kann die Software "ad infinitum" ändern ("Änderitis"). Doch auf keinem Fall ist Software-Entwicklung nicht agil, egal welche Methode man anwendet.

Solche ständige Änderungen sind wohl auch Verschwendung im Sinne der "Lean"-Prinzipien (also gegen die "Lean" Prinzipien, die grundsätzlich gegen Verschwendung sind: also müsste eine Lean-Entwicklung grundsätzlich gegen Änderungen sein, somit aber auch gegen das, was eine SW-Entwicklung ausmacht...).

Und es sind aber auch solche Änderungen, die diese "agilen" Methoden befürworten, die dann auch zu aller Überfluss von vielen Menschen, Gruppen von Menschen und "Berater" sogar aller Couleur, gerne "Verkauft" werden; und dabei schießen sie sich, meiner Meinung nach, selbst ins Knie. Oder verdienen sich eine goldene Nase, je nachdem.


Scrum: agil oder nicht agil?
Es gibt außerdem auch Menschen, die behaupten, dass "Scrum" nicht agil sei.
Wieso?
Weil, zum Beispiel, täglich ein "Stand up" abgehalten wird. Sehr Starr. Nicht agil.
Dazu sehr feste Riten, wie zum Beispiel Retrospektiven, Planungsmeetings, usw.
Man kann eigentlich ohne weiteres postulieren, dass Scrum eine Art "Wasserfall" ist (wenn tatsächlich eine solche Konstruktion existieren würde), bei dem anstatt nach Funktionen nach "Timeboxing" entwickelt wird.
Schlicht und ergreifend "das Gleiche in Grün".

Und... sind andere "agile" Methoden auch "das Gleiche in Grün" ?

Mal sehen...


Nun stellt sich die Frage: Was ist "Agil"?
Zunächst gilt es, Abstand von dem unnützlichen "Manifesto" zu nehmen.

Nach der Definition von "Agilität":
- Gelenkigkeit {1}
- Aufgewecktheit {2}
- Gewandtheit {1}
- Lebendigkeit {2}
- Mobilität {1}
- Regsamkeit {2}
- Wendigkeit {1}
- Agilität {1}
- Flinkheit {1}

Es ist klar somit, dass jegliche Software-Entwicklung "agil" per se ist.
Vielleicht sollte eher das Ziel darin bestehen, zu versuchen, die Software-Entwicklung in Wirklichkeit "unagiler" zu machen, um nicht in des Teufels Änderungsküche zu geraten... (und bedanken wir uns hier bei den Lean Prinzipien ;-)


Was spricht eigentlich gegen die "Agilität" der "agilen" Methoden
Es handelt sich offensichtlich um ein Paradoxon:
Durch die "agilen" Methoden wird die Software-Entwicklung (welche natürlicherweise die weiter oben mit {1} aufgelisteten Eigenschaften inne haben) in einem Korsett von Richtlinien und Prinzipien eingepresst, und gleichzeitig wird behauptet, das sei "agil".
Pustekuchen ist das "agil" :-)
Es ist Verschwendung auf höchster Ebene, ganz im Gegenteil zu den Lean Prinzipien.


XP: Praktisch, ja, einige Wochen; wenn ein Anfänger hinter einem "Senior" sitzt. Sonst liegt die Produktivität bei ca 10 bis 20 % mehr von dem, was ein Entwickler alleine schafft: Also ein Wirkungsgrad von... 60% ?.

Nach meinem Wissen sind es gar nicht so viele "agile" Methoden im Umlauf (wenn man die -vielen- Variationen von "Scrum" außer Acht lässt: ein "Scrum" wo jedes Team irgend einer Abart von Scrum einsetzt, als "Scrum-But" bekannt, was schon zeigt, was man davon halten soll), doch wirklich funktionieren tut keine aus inhärenten Eigenschaften; Es sind immer die Teams, die etwas zum Laufen bringen.

Also das Dogmatismus um die "agilen" Methoden setzt auf den falschen Prinzipien. Offensichtlich.

Freitag, 25. September 2015

Mögliche Gründe für den (unerklärlichen) Siegeszug der "agilen" Methoden

Ich habe mir ein Paar Gedanken gemacht über die Akzeptanz der agilen Entwicklungsmethoden.

Wieso werden diese eingesetzt, blind, ohne den Versuch zu unternehmen, daraus etwas vernünftiges, ordentliches, funktionierendes zu gestalten?

Hier einige Ideen:
  • Das Management ist sich über die Nachteile nicht im KlarenJunge Entwickler scheinen wohl stark indoktriniert worden zu sein
  • Die Entwickler lassen es sich gut ergehen, genießen wohlgemerkt die Wonne der Verantwortungslosigkeit, die Ruhe sich nur zu dem zu "commiten", was man bequem schaffen kann
  • Das Management genießt auch die Verantwortungslosigkeit: laxe, unbekümmerte Vorgehensweise, sich in "Rollen" wiederfinden, die leicht von der Arbeit und einfach zu handhaben sind

In meinen Augen sieht es eher so, dass einer ohne wirklich nachzudenken sich für die agilen Methoden geäußert hat, und dann haben viele andere das einfach, weiterhin ohne richtig nachzudenken, wenn überhaupt, sich auch für diese Ideen geäußert.

Keine gute Voraussetzung, um das Problem mit der Software-Entwicklung zu lösen.

Ich glaube, man hat sich leichtsinnigerweise an den Symptomen ausgetobt, anstatt die Wurzel des Problems zu analysieren, und vernünftigerweise hier anzusetzen.

Doch solange die Geldgeber überzeugt sind, dass Software-Entwicklung eine ganz besondere Sache ist, die "agil" zu erfolgen hat und viel Geld verschlingen muss, wird eine Vielzahl von "agilen" Entwickler gemütlich absahnen können.

Sonntag, 13. September 2015

Agile Entwicklungsmethoden => Dogmatischer Glaube und kein bisschen Nachdenken


Ich erlebe, verstärkt in den letzten Zeiten, dass die sogenannten "agilen" Methoden nicht nur vom Management (das Management hat eigentlich keine Ahnung von Entwicklung und soll diese auch nicht haben, da das Management durchaus andere Aufgaben zu erledigen hat) "gepuscht" werden (was man noch u.U. vermeiden könnte als erfahrener Entwickler), sondern auch, dass viele "Entwickler", also tatsächlich Menschen die SW Code schreiben, (Im Allgemeinen junge Leute, die wahrscheinlich noch mit einem Bein an der Uni stehen) sich diese Methoden dogmatisch hingeben.

Dass das Management oft und gerne auf "Hypes" reitet ist hinlänglich bekannt. Aber dass auch Entwickler so etwas anscheinend machen, versetzt mich im Erstaunen.

Eine rhetorische Frage von den eher unerfahrenen Entwicklern: "Sollen wir etwa Wasserfall anwenden?" - Betonung auf das Wörtchen "etwa". Tertium non datur. Schwarz-Weiß Auffassung der Welt...

Lernen sie so etwas an der Uni? Lehren die Profs, dass die sogenannten "agilen" Methoden das non-plus-ultra der Entwicklung ist? Die jungen Entwickler scheinen tatsächlich zu glauben, dass agile Methoden "agil" und besser seien, und Wasserfall "abscheulich" ist. Und das glauben sie mit religiösem Eifer... Schwarz-Weiß-Denken.

Für Akademiker sollte klar sein, dass ALLES Vor- und Nachteile hat. Und echte Profis sollten auf der Arbeit (eigentlich) auch bemüht sein, die Arbeit, Arbeitsmethoden usw zu verbessern, optimieren, Probleme zu entdecken und verschwinden zu lassen. Das geht aber nicht wenn man dogmatisch an bestimmten "Prinzipien" oder gar "Manifestos" fest hält.

Ich arbeite daran :-)

Sonntag, 26. Juli 2015

Neue Home Page

Hier:
www.amtrs.de
Viel Spaß und Erfolg, wie immer !


Dienstag, 23. Juni 2015

Das Toyota-System: Lean und Kaizen. Einige Begrifflichkeiten.

Die Grundlagen von Lean sind weder irgendwelche Werkzeuge noch eine Vermeidung von Verschwendung.

Wakamatsu und Kondo, beide Experten bei Toyota, brachten es auf den Punkt:
Das Wesen des Toyota-Systems ist einfach; dass jeder einzelne Mitarbeiter die Gelegenheit hat, in seinen eigenen Arbeitsumfeld Probleme zu finden, diese zu lösen und Verbesserungen zu machen.

So "einfach" wie es auch klingt, so schwierig ist doch die Umsetzung.

Das Toyota-System kann man durch 2 Grundlagen kurz beschreiben:
  1. Kontinuierlich Verbessern, und
  2. Menschen respektieren.

Ständige Verbesserungen, -oft als Kaizen benannt- ist Toyotas Ansatz, das tägliche Geschäft zu führen. Nach dem Prinzip: "Alles in Frage stellen". Mit anderen Worten: "Stets denken".

Wichtiger aber als die tatsächlichen Verbesserungen, die die Mitarbeiter umsetzen (dürfen), ist der wahre Mehrwert das Schaffen einer Umgebung in der man ständig lernen kann; eine Umgebung, die nicht nur Änderungen akzeptiert, sondern sie geradezu fördert.
Eine solche Umgebung kann nur dort entstehen, wo man die Menschen ohne wenn und aber respektiert - daher ist dieser der 2. Grundsatz des Toyota-Systems.

Und an diesem 2. Grundsatz scheitert grundsätzlich die Mehrzahl von unserem "westlichen" Management.

Kaizen wird (oft) schlicht als "kontinuierliche Verbesserung" übersetzt. Das aber verwechselt die Bedeutung von "kontinuierlichen Verbesserung" und ist nicht mit dem wahren "Kaizen" deckungsgleich.
Es wird empfohlen, das japanische Wort Kaizen zu gebrauchen und sich dabei der wahren Bedeutung bewusst werden: Kaizen ist gleichzeitig gelebte Praxis und eine (persönliche) Einstellung.
Nicht einfach "stets verbessern"...


Cargo Cult (Cargo-Kultur)


Eine Cargo-Kultur sind Rituale, von einer (primitiven) Gesellschaft durchgeführt, die das Verhalten von nicht-native Besucher (oft aus Europa) nachahmt.

Analog dazu nennt man Cargo-Kultur-Prozesse solche, wo Rituale und Oberflächlichkeiten, ohne eingehendes Verständnis für die Hintergründe, praktiziert werden. (Oft vorzufinden bei vielen Organisationen, die "Agile Methoden" praktizieren, ohne sich mit der "agilen" Denkweise auseinander zu setzen -siehe "Scrum"-.)

Eine "Lean Cargo-Kultur" führt "lean" Werkzeuge (durch das Management) ein, ohne dass sich wirklich weder die Denkweise noch das Verhalten von Management oder gar der Mitarbeiter ändert.

Natürlich können sich beide nicht von heute auf morgen ändern, das braucht:
1. (eine lange) Zeit.
2. Maßnahmen, um die Mitarbeiter dahin zu führen (vom Management getragen).
Und sicher auch noch der Wille dazu und die Bereitschaft, Mitarbeiter gewähren zu lassen.

Nein... einfach ist das nicht.

Samstag, 13. Juni 2015

(Nicht so sehr) Lean Untersuchung der Lean-Prinzipien

Zunaechst sei angemerkt, dass die "Lean-Prinzipien" schon eine etwas längere Geschichte haben als die sogenannten "agilen".

Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".

"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."

Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)

Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.

Nun zu den Prinzipien.

Die sieben Prinzipien der Lean-Entwicklung:
  1. Verschwendung vermeiden (siehe weiter unten)
  2. Feedback einfordern (alle Teilnehmer einbeziehen - Kommunikation intensivieren)
  3. Spät entscheiden (sich so viel Zeit wie möglich nehmen: zum Denken und zum Planen)
  4. Schnell ausliefern (so schnell wie möglich die Entwicklung durchziehen, nachdem "entschieden" wurde)
  5. Team trägt Verantwortung (impliziert Selbst-Organisation...)
  6. "Integrität einbauen" ("stets" standardisieren, so wie ich es verstanden habe)
  7. Die Gesamtheit optimieren (Den gesamten Prozess verbessern)

Andere "Übersetzungen" postulieren:
  • Die Arbeiten gleich beim 1. Mal richtig machen (inhaltlich zum 1. Punkt: keine Verschwendung)
  • Den Arbeitern erlauben, Entscheidungen zu treffen (nicht nur "ganze Teams" sondern auch auf persönlicher Ebene)
  • Stets verbessern (inhaltlich zum 7. Punkt)
  • Lernen unterstützen (entfernt verwand mit dem 2. Punkt...)


Und hier die 7 Verschwendungen der SW-Entwicklung:

  • Überproduktion (Zusätzliche Funktionalität)
  • Inventur (Administration / Anforderungen)
  • Zusätzliche Produktionsschritte (Komplexität / Überfluss)
  • Bewegungen (Suche von Informationen)
  • Fehler (Bugs / Fehler in der SW / Tools mit )
  • Wartezeiten (Warten auf Entscheidungen / Warten auf Kunden-Feedback)
  • Transport (Schnittstellen / Workflow der Arbeit)


Hier die japanischen Begriffe für Verschwendung:

- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.


Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.

Samstag, 23. Mai 2015

Warum Scrum abbrennen soll (eine Übersetzung)


Why Scrum Should Basically Just Die In A Fire (hier nur ein Abzug)

Von: http://gilesbowkett.blogspot.de/2014/09/why-scrum-should-basically-just-die-in.html

(Ich empfehle das Original zu lesen!)


The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense.

Well-written text very often trumps face-to-face communication. You can refer to well-written text later, instead of relying on your memory. You can't produce well-written text unless you think carefully. Also, technically speaking, you can literally never produce good code in the first place unless you produce well-written text. [...]

In fact, GitHub itself was built without face-to-face communication. Basecamp was built without face-to-face communication as well. I'm not saying these people never met each other, but most of the work was done remote.  [...]. And face-to-face communication plays a minimal role in the majority of open source projects, which usually outperform commercial projects in terms of software quality.

In addition to defying logic and available evidence, both these Agile Manifesto principles (1) encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points.


Übersetzung (des Abzuges)

Das Agile Manifesto widerspricht auch die Standup des Scrum . Es besagt, dass "die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch". Um fair zu den Autoren zu sein muss man hier bemerken, dass dieses wurde im Jahr 2001 geschrieben, und zu dieser Zeit gab es noch kein git log. Bei den heutigen Tools, die für die verteilte Zusammenarbeit existieren, es diese Behauptung recht unglaubwürdig, und eben auch im Jahr 2001; musste man doch annehmen, die Autoren haben nie etwas von Linux gehört, wenn Sie wirklich richtig liegen sollten.

Ein gut geschriebener Text ist oft einfach besser als ein persönliches Gespräch. Ein Text kann jederzeit nachgelesen werden, anstatt dass man sich auf das eigene Gedächtnis verlässt. Man kann auch ein Text nicht schreiben ohne (genau) zu wissen, was man wirklich äußern will. Technisch gesehen, man kann auch nicht gut programmieren wenn man nicht richtig schreiben kann. [...]

Richtig ist es, dass GitHub selbst ohne persönliche Gespräche entwickelt wurde. Das Gleiche gilt für Basecamp. Ich behaupte nicht, das die Entwickler sich nie getroffen haben, doch die meiste Arbeit wurde aus der "Ferne" getan. [...]. Ebenfalls spielen persönliche Gespräche in den meisten Open-Source-Projekte eine untergeordnete Rolle. Und Open-Source-Projekte übertreffen in der Regel, in Bezug auf die Qualität der SW, kommerzielle Projekte.

Nich nur dass diese beide "agilen" Prinzipien (1) vorhandene Beweise und einfache Logik trotzen, sondern dass sie auch eine Art Kindergarten-Mentalität fördern. Ich habe noch nie gesehen, dass man Scrum bei Design, Buchhaltung oder Ein- und Verkauf benutzt: oberflächliche, Bilderbuch-ähnliche Vereinfachungen, wie die Sache mit den "Story Points" (Bewertung der 'Geschichten').


(1)
Als 2. Prinzip ist gemeint:
"business people and developers must work together."
Zu deutsch:
'Geschäftsleute und Entwickler müssen zusammenarbeiten.'

Die 1. angesprochene Prinzip war:
'die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch'.

Mittwoch, 13. Mai 2015

Agile Prinzipien: Schwammig. Schwach. Lahm.

From: http://www.agilemanifesto.org/principles.html
Principles behind the Agile Manifesto

We follow these principles:


1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -the art of maximizing the amount of work not done- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Mein Senf dazu:

Zu 1. Gut und wichtig ist es, den Kunden stets glauben zu lassen, man will sie zufriedenstellen. Ansonsten ist der Punkt eher schwammiges Wunschdenken.

Zu 2. Mehrarbeit zu begruessen zeugt eher von schwacher Denkweise. Es soll gelten: Aenderungen zu minimieren. Das soll auch der Kunde beherzigen. Je eher die Anforderungsaenderungen erscheinen desto besser, man soll diese ergo verlangen, ASAP, doch nicht "auch spaet im Projekt diese willkommen heiszen".

Zu 3. Schwacher Punkt. Es ist wichtig, dass das Ergebnis funktioniert, und zwar so gut wie moeglich. Das die SW lange vor Ende des Projekts "arbeitet", und auch diese (so) oft (wie moeglich) zu liefern... das kann kein wirkliches Ziel sein. Ziel ist das Endergebnis. Und darauf sollte man fokusieren.

Zu 4. Die Entwickler taeglich mit Meetings (oder was auch immer eine Zusammenarbeit bedeutet) mit "Business People" wuerde den Entwickler eher zu sehr ablenken, belasten. Eine enge Zusammenarbeit ist erwuenscht, doch "taeglich" ist uebertrieben. Die "Business People" sollen dem Entwickler jederzeit zur Verfuegung stehen. Nicht mehr und nicht weniger. "Taeglich" etwas zu erzwingen ist irgendwie besonders unflexibel.

Zu 5. Gute Idee. Ist das aber eine exklusive Eigenschaft des "Agilen" Entwickelns, oder eher eine allgemeine gute Idee ...?

Zu 6. Aber auch nicht immer. Ausnahmen existieren. Ich halte solche allgemenine generalisierneden Aussagen, fuerwahr, fuer eher unflexibel. Die Punkte 5 bis 7 sind eher allgemeine gute Praktiken, wurden aber sicher nicht von den Autoren des "agilen Manifests" "erfunden".

Zu 7. Es kommt darauf an, wie man "Fortschritt" definiert. Und was man genau messen will. Komplexitaet, z.B. -in Bezug auf Fortschritt-, sollte man anders messen. Diese Aussage ist in meinen Augen auch eher zu allgemen. Dieser Punkt auch eher unflexibel.

Zu 8. These ohne Beweis. Nur solange die Entwickler bezahlt werden, werden sie auch entwickeln. Ausserdem muessten die Entwickler auch die Taetigkeit als sinnvoll erachten. Diese Voraussetzungen basieren nicht auf "agilen Prinzipien".

Zu 9. Scheinbar waren die Schreiber des Manifests ab Punkt 8 schon etwas muede. Schoene Woerter, zusammenhaltslos aneinadergereiht. Nicht nur, dass die Folgerung, wie hier beschrieben, nicht ersichtlich ist; sondern vielmehr lassen sich zahlreiche Gegenbeispiele zu dieser Aussage finden.

Zu 10. Einfachheit ist schon (sehr) wichtig. Doch "essential" ? Na ja. Ausserdem ist "Einfachheit" ganz sicher nicht "die Kunst, die nicht verrichtete Arbeit zu maximieren". Im Gegenteil; oft muss man mehr Arbeit verrichten und ein System einfacher zu gestalten.

Zu 11. Ich halte dieses Prinzip auch wieder fuer schwach im Sinne des Denkens: Gute Architekturen werden von guten Architekten entwickelt. Gute Anforderungen werden von guten Requirement-Engineers geschrieben. Gutes Design wiederum von guten Designers erstellt. Diese Arbeiten haben mit einem Team eher wenig zu tun. Ziemlich egal wie sehr sich das Team "selbst organisiert".

Zu 12. Gutes Prinzip. Sehr gut sogar (richtung Kaizen). Doch... eine Exklusivitaet von agilen Teams...? Zweifle ich stark.

Mein Fazit zu dem Manifest:

Inhaltslos: Punkte 1, 5 und 9.
Unflexibel: Punkte 4, 6 und 7.
Folgerung unlogisch: Punkte 8 und 9.
Falsch: Punkte 2, 10 und 11.

Auch hier (wie bei http://www.agilemanifesto.org) sollte man stark (zum Besseren) ueberarbeiten.
Vom urspruenglichen Manifest wird wahrscheinlich kaum etwas uebrig bleiben.

To be done. Bei mir. Im Laufe dieses Jahres.
 :-)

Freitag, 3. April 2015

Agile heilige Kühe in Indien...


Frage: Warum sind die Inder so stark vertreten seit einigen Jahren (seit der Einführung der "agilen" Methoden) bei der Entwicklung von Software?

Antwort: Weil bei der Software-Entwicklung so viele heiligen Kühe gibt!

Freitag, 27. März 2015

Wie "Agil" ist eigentlich "Agil"? Was kann man damit anfangen?

From: http://www.agilemanifesto.org

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:
1- Individuals and interactions over processes and tools
2- Working software over comprehensive documentation
3- Customer collaboration over contract negotiation
4- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.



Meine Gedanken zu den "Werten" des Manifestes:

1- Also, "agil" sind Individuen ohne Tools die wilde Interaktionen ohne wesentliche Prozessorientierung zu tun pflegen.

2- Das Ergebnis wird dann nicht unoft: "Unmaintable SW and uncomprehensive documentation". Also für die Katz, die Entwicklung...

3- Echt super, die Kunden werden geradezu ermuntert, ständig Änderungen und neue Funktionalitäten zu fördern!

4- Alles Andere als zielorientiert...

Daraus folgt, aus meiner Sicht: Das "Manifesto" ist noch nicht richtig anwendbar, ca 80% müsste noch korrekt überarbeitet werden.

Dazu, zu lesen (wenngleich nicht besonders informativ, sondern eher Gelaber/Textguss ohne wertvollem Inhalt): http://ronjeffries.com/xprog/articles/beyond-agile-new-principles/