Die Nase voll... (Teil II)

Bist Du auch überdrüssig von vielen der sogenannten "agilen" Praktiken (und anderen Monstrositäten) ??

• vom täglichen Rumstehen in infantilen "Daily Stand-Ups"?
• von albernen Karten-Spielchen AKA Pokern-Schätzen?
• von kindlichen Retros, wo ein "Scrum Master" mit Spielchen die Entwickler zu unterhalten versucht?
• von Unmengen an Tickets die man für jede Bagatelle anlegt - mehr Verwaltung kann man sich gar nicht vorstellen (nicht "agil" sondern das Gegenteil) ?
• von Sprints, die nichts anderes sind als kleine "Wasserfälle" die man aber in 2 oder 3 Wochen Rhythmus durchführt?
• von "Groomings" bzw Schätz-Orgien, wo jeder mit noch so wenig Ahnung eine Zahl ausspucken darf... und musst! ?
• Von "Scrum Master" oder anderen sogenannten "Enabler", die nicht mal eine Zeile Code programmieren dürfen! - Was zum Kuckuck "enablen" die denn, ... etwa die unzähligen Meetings?

Dann... Komm zu TST!

(TST: Tsubame Software Tools)

Die Nase voll... (Teil I)

Bist Du auch überdrüssig von vielen der sogenannten "agilen" Praktiken (und anderen Monstrositäten) ??

• von endlosen Meetings, die ohne klares Ziel starten, ohne sinnvolle Beiträge stattfinden und ohne Ergebnisse enden
• von dogmatischen Vorgesetzten, die gebetsmühlenartig "agile Prinzipien" rezitieren, ohne sich den geringsten Gedanke darüber gemacht zu haben
• von dem "Kultur"-Geschwafel durch unfähigen, nichts bringenden sogenannten agilen Manager o.ä.
• von Großraumbüros, wo der Entwickler jede Privatsphäre verliert und sich wie in einer Legebatterie für Hühner fühlt
• vom entstandenen Chaos und die "agilen" Evangelisten, die das nicht sehen oder wahrnehmen wollen

Dann... Komm zu TST!

(TST: Tsubame Software Tools)

Warum FlePA

FlePA erlaubt die Arbeit flexibel zu organisieren; bei einem Ansatz, wie ich es mit TST verfolge, würde eine andere (von den bekannten) Möglichkeit nicht funktionieren.

Klassisch:
Bei klassischen Modellen ist die Anwesenheit eines Managers viel zu unentbehrlich, dass macht eine Entwicklung aus der Ferne beinahe unmöglich bzw mit so viel Überarbeit, dass es schlichtweg irre wäre, eine klassische Methode zu verwenden.

Agil:
Agil ist zu überladen mit Prozessen aller Art, Pair Programming geht gar nicht, denn die Entwickler sollen alleine aus der Ferne arbeiten können.
Meetings bringen nichts, wenn man weiß, was man tut, und das soll man schon wissen.
Das sich ein Team selbst organisiert ist schön in der Theorie, doch in der harten Praxis der Entwicklung von neuer SW bedarf auch wieder viel zu viel Organisations- und Abstimmungsarbeit mitten in der Entwicklung. Das können wir uns nicht leisten; wir wollen doch unser Einkommen maximieren :-)

Dagegen sind die Vorteile von FlePA für eine solche Entwicklung nicht zu unterschätzen:

• Verantwortungsprinzip: Unentbehrlich bei einer Entwicklung aus der Ferne (im Gegenzug zu der Verantwortungslosigkeit bei dem Gedanken des "Team-Ownerships")
• Anwendbar auf Teams jeglicher Größe, damit flexibler und benutzbar für verschiedene Projekte ohne in Schwierigkeiten zu laufen (nicht begrenzt auf Teams von 5..9 Personen). Dazu: der Administrationsaufwand wird hiermit auch minimiert
• Einfachheit und Verzicht auf fixe Prozesse und Zeremonien (Das Modell ist so einfach wie möglich und schreibt keine zwingenden Maßnahmen vor)
• Optimieren als Ziel (Lean Entwicklung Ansätze: keine Verschwendung -u.a.-)
• Umfang und Qualität des Ergebnisses sind nicht "verhandelbar" (Projektmäßig halt; wie es sein soll, m.E.n.)
• Betonung der Sicherheit bei den Entwicklung und bei der fertigen SW (eine der wunden Punkte sowohl bei den klassischen als auch bei den agilen Methoden)

Ohne FlePA waere einen solchen Ansatz nicht möglich...

Was so alles mangelhaft ist bei unserer täglichen (SW-Entwicklungs-) Arbeit

Meiner Meinung nach gibt es einige Punkte, die zu kritisieren sind.

Zunächst einmal ist die SW-Entwicklung mit erheblichen Schwierigkeiten behaftet, in erster Linie denke ich, dass die Tatsache, welche die meisten Probleme verursacht, die ist, dass man die SW so schnell und einfach umschreiben (Stichwort Refactoring) kann; das ist die Ursache für einen Chaos-Wachstum, den man nicht mehr Herr werden kann.

Die einzige Lösung zu diesem (wichtigsten) Punkt ist nun mal, dass man einen sauberen Design hat... und man sich daran hält. Einfach gesagt. Beinahe unmöglich zu halten, wenn wir ehrlich sind.
Dennoch! Trotz allem, das ist die einzige Möglichkeit, der einzige Weg, so wie ich es sehe.

Das (unheilvolles) Entstehen und Gedeihen der sogenannten "Agilen" ist, in meinen Augen, dazu zurückzuführen, dass man versucht, die Probleme der SW-Entwicklung Herr zu werden, leider in diesem Falle ohne sich mit dem Kern der Problematik auseinander zu setzen.

Es ist wirklich an einem klassischen oder agilen Ansatz nichts anzusetzen... denn jegliche Methode wird scheitern, wenn nicht die wirkliche harte Arbeit verrichtet wird, die richtig und notwendig ist.

Die Crux mit den klassischen Entwicklungsmodelle:
Die klassischen Modellen sind von einem Kontroll-Freak-Management bevorzugt, eines das glaubt, mit vielen Zahlen und Wände voll von Diagrammen kann man des Chaos Herr werden.
Falsch gedacht, würde ich sagen.

Die Crux mit den "Agilen":
Bei den Agilen läuft auch einiges Schief, sie sind voll von Aberglaube und Mythen, aber hierüber kann man viel mehr im Blog: ruynk.blogspot.de lesen...
Auf jeden Fall auch ziemlich falsch gedacht, möchte ich meinen :-)

Noch eins bezüglich das (heutige SW-) Management:
Vielleicht legen die Manager so viel Wert auf "weiche Sachen" wie Werte (Values), Kultur, etc, weil sie sowieso Nichts beitragen, also müssen sie etwas erfinden, womit sie eine Daseinsberechtigung bekommen, wie z.B. bei Werten und sonstige "weichen" Begriffe.
Dieses "Nichts-Beitragen" ist offensichtlich eine Folge der (unverstandenen) SW-Entwicklungsarbeit. Also ist neuerdings der Beitrag des Management das Einführen von den (in Mode geraten) agilen Methoden.

Ich würde mich freuen, etwas Feedback zu diesem Blogeintrag zu bekommen!

Besondere Merkmale der TST - SW - Entwicklung

Wie angekündigt, wird das Unternehmen von Grund aus restrukturiert.

Ziel: Gutes Geld verdienen, das wir unter allen Beteiligten rechtmäßig verteilen (siehe Punkt 4 der Auflistung weiter unten).

Folgende Merkmale sollen die Projekt-Tätigkeiten aufweisen:

1. Ein "Pool" an Projekten wird erstellt und kontinuierlich aktualisiert. Projektliste folgt!
2. Projektsprache ist (stets) Deutsch: Das Zielmarkt ist in erster Linie DACH. (WELT folgt ;-)
    
3. Mehrere Projekte können gleichzeitig gestartet werden, je nach Verfügbarkeit der Projektmitarbeiter: Ein Projekt startet so bald es voll besetzt ist.
    
4. Die Organisation ist "sui generis". Die Idee zu konkretisieren hat mir einige Arbeit abverlangt. Beschreibung folgt!

 


Ja... einiges soll noch kommen, man darf wirklich gespannt sein, denn so etwas... gab es, meines Wissens nach, nicht wirklich!




Also dann!!

Bis bald:-)

Restrukturierung

Nach langer Pause und viel Gehirnschmalz, welches in einem tragbaren Geschäftsmodel eingeflossen ist, steht "Tsubame Software Tools" (TST) vor einer Restrukturierung. Und zwar eine brachiale und radikale Restrukturierung.

Zunächst plane ich, die Entwicklungsarbeiten wieder auf zu nehmen.

Das Ziel: Software zu erstellen, für welche gute Unternehmen gut bezahlen.

Folgende Merkmale soll das Unternehmen TST aufweisen:

- Entwickelt wird nach dem FlePA Rahmen
- Verwaltungskosten zu minimieren um die Einnahmen der Projektteilnehmer zu maximieren
- Nach FlePA Prinzip, es gibt keinen Chef/Manager/Geschäftsführer


Die gegenwärtigen Seiten (HomePage) von TST werden demnächst vom Netz genommen werden und neue Seiten kommen an deren Stelle (Zum Ende des Jahres geplant).

Vielen Dank!

Kein Neustart... sondern die Folge von tstnews.blogspot.de

Da ich mich in dem alten Blog (http://tstnews.blogspot.de/) nicht mehr einloggen konnte
habe ich diesen neuen Blog gestartet.

Grund: Die alte Telefonnummer und die alte Email funktionierten nicht mehr, damit, und weil der Google sonst keine Moeglichkeit anbietet, einen Bolg zu retten, musste ich diesen Weg gehen.

Also... die alten Eintraegen sind noch auf dem Blog: http://tstnews.blogspot.de
zu finden. Allerdings kann ich nicht sagen für wie lange.

In diesem Sinne,

Tsubame