Wenn ein Programmierer schnell ist, sind 3 Programmierer zehn mal so schnell, wie dieser eine Programmierer. Diese Rechenregel gilt für Gruppen bis 6 Leute, danach gehts wieder bergab.
Leider sind die Entscheidungsträger, meistens kaufmännisch orientierte Menschen, immer noch der Überzeugung, dass die Anwendungsentwicklung das Ende ist. Dabei ist ein Programmierer nur ein GESELLE und nicht mehr. Bevor hier das große Geschrei beginnt, eine kleine Begriffserklärung.
Programmierer. Kommen zur Arbeit und tippen Regeln in eine gewisse Sprache ab, für die es einen Compiler gibt. Sie entwickeln fehlende Strategien im Programm und sorgen damit für einen sauberen Ablauf.
Softwareentwickler. Kommen zur Arbeit und denken sich Regeln aus. Diese Regeln werden in ein Model eingearbeitet und schließlich abprogrammiert. Das Model wird in ein Basismodel gewandelt (Framework, Library). Die Programmierung basiert nicht mehr auf die ursprüngliche Sprache, sondern auf vorher entwickelten Modellen, die sich bewählt haben. So garantieren die Softwareentwickler Updates für alle Projekte, die die Modelle nutzen.
Die Entwickler nennen sich meistens nur Programmierer, weil die Entscheidungsträger mit die Unterschiede nicht kennen. Jetzt sollte es allen klar sein: Programmierer sind nichts weiter, als GESELLEN. Die MEISTER sind die Entwickler, weil die mehr tun, als die Regeln abzuarbeiten, die von irgendwoher kommen.
Leider kommen die Regeln oft von fachfremden Personen (aus der Sicht des Technikers ist ein kaufmännischer Vorgesetzter eine fachfremde Person). Und da habe ich ein großes Problem mit. Ein Beispiel: Prozesse werden in der Informatik als ein Ablauf technischer Arbeitsschritte gesehen. Der Optimierungsbedarf ist dort zu finden, wo viel menschliche Arbeit zu finden ist (kommt damit endlich klar) und wo Datenstrukturen direkt von Menschen geliefert werden (Excel Listen, von Hand geschriebenes XML oder Textdateien, bäh).
Mit dieser Regel im Kopf kann man Prozesslücken beim ersten Gespräch herausfinden und eine grundsätzliche Lösung entwickeln. Kaufmänner wollen auch die politischen Prozesse verstehen, aber die Informatik interessiert sich nicht für die politischen Prozesse. Für uns gilt EVA.
Wer es nicht glaubt, sollte mal einen Softwareentwickler fragen- wenn man einen findet. Dass ist ein Problem, weil, gerade in Deutschland, ein echt krankes Bild von der Informatik existiert, ein Bild aus dem 18. und 19. Jahrhundert, wo ein Kaufmann seine Gesellen scheucht und die Hand auf ihnen hat. Ein Kaufmann hat natürlich auch seine Prozessicht, seine Erfahrungen und seine berufsmäßigen Werkzeuge, aber die kann man nicht so wirklich auf Informatik anwenden.
Ein Beispiel ist die objektorientierte Analyse (die kaum jemand richtig beherrscht). Die Analyse ist der erste Schritt zur Modellentwicklung für den Softwareentwickler. Dabei wird man merken, dass der Benutzer berücksichtigt wird, aber erst mal total unwichtig ist.
Der Kaufmann kann es vielleicht anders sehen, aber uns ist der Benutzer bei der Modelentwicklung egal. Wir wollen wissen, wie das EVA (Eingabe, Verarbeitung, Ausgabe) – Prinzip im Prozess aussieht und nicht, was der Mensch gerne für Knöpfe auf dem Feld haben will.
Die Entwicklung von der UI her ist falsch. Die UI ist das RESULTAT, nicht der Grundstein. Der Grundstein eines qualitativen Softwareprojektes ist die OOA, das Softwaremodell und die darauf aufbauenden Klassen. Dass hat nicht nur rein technische Gründe, sondern auch organisatorische:
Der Programmieraufwand soll minimal gehalten werden. Das Ziel ist ein sinnnvolles Modell zu entwickeln (70% der Projektzeit) und dieses in ein Programm zu gießen (30% der Projektzeit).
Dass ist unser Ziel. Wir wollen ein sinnvolles Modell haben. Die Programmierung ist uns egal (die ist nicht wichtig, geben wir irgendwem, der das abprogrammiert). Damit sind wir schnell unterwegs.
Wir reden, schreiben und planen viel und am Ende plöppt ein Produkt und ein Modell, dass wir wiederverwenden können.
Wir können aber schneller. Die Kaufmänner sind für uns gut, weil sie die Personen im Blick halten, was wir nicht tun. Aber dass zwingt uns, schneller zu werden. Man nehme eine Pizzaria als Beispiel. Der Kunde kommt in den Laden, bestellt eine Pizza und in den meisten Fällen kann er dem Bäcker beim Arbeiten zuschauen. Er sieht den Teig, das Produkt und kann sehen wie das Produkt erstellt wird. Jeden Arbeitsschritt kann der Kunde sehen. Bei der Softwareentwicklung ist das nicht der Fall. (dieses Beispiel kann man mit Autos, Uhren, Häusern, Bäckern usw…machen)
Und in vielen Fällen misstraut man uns, gibt uns Kernarbeitszeiten und denkt, dass es sinnvoll sei, einen Menschen 8 Stunden an den PC zu ketten.
Wir müssen auf dieses Problem reagieren. Dass können wir, indem wir die Phasen der Modellierung und Programmierung zerhacken. Jede Woche entwickeln wir ein kleines Modell und lassen es durchprogrammieren. Das Ergebnis geben wir dem Kunden. Somit muss der Kunde keine 6 Monate warten, sondern kriegt jede Woche ein Ergebnis präsentiert. Das geht aber nicht, wenn man nur ein Programmierer hat. Man braucht schon mindestens drei Leute, ein Programmierer, ein Entwickler und einen, der die Übersicht hat, das Team ordnet und von beiden Welten (Technik, BWL). Die drei Leute werden garantiert schneller sein, als jeder solo Programmierer, weil sie ein Fließbandbetrieb einrichten können.
Jetzt noch einige Begriffe, die nicht jedem klar sein können.
Schnelligkeit. “Ich habe heute eine Software ausgeliefert. Dabei habe ich nur 4 Mal 15 Stunden Tage schieben müssen. Okay, die Software ist langsam und stürzt ab, wenn man gewisse negativeingaben in zwei Felder schreibt, aber sie ist fertig. Ihr habt 100 Stunden geschätzt. Total lächerliche Zeit” War der Programmierer schnell? Nein. Er hat seine Gesundheit aufs Spiel gesetzt und die QUALITÄT der Software war miserabel. Das Team schätzte mehr Aufwand, hatte aber Phasen drin, die der einzelne Programmierer nicht hatte, darunter z.B. eine ausgedehnte Analysphase, eine testgestützte Entwicklung und die Programmierer sollten keine Überstunden machen.
Fließband. Als in der Industrie die Fließbandarbeit eingeführt wurde, hatte dass den Sinn Stationen aufzubauen, die dann viele Dinge parallel machen konnten. Man stelle sich ein Projekt als ein Fließband vor. Die Arbeiter an dem Fließband haben die die Aufträge PLANUNG, TEST, IMPLEMENTIERUNG, AUSLIEFERUNG. Die Teamarbeit sieht so aus :
Projekt A kommt rein. Die Planungsphase beginnt. Projekt B kommt rein und kommt in die Planungsphase. Projekt A wandert in die Testphase (das Modell wird geprüft und automatisierte Tests werden entwickelt). Projekt C ist in der Planungsphase angekommen. B steckt auch noch drin. Projekt A wird implementiert. Projekt B kommt in Testphase, Projekt C ist fast fertig und wandet mit B in den TEST.
Man sieht: Es ist nicht EIN Fließband, sondern mehrere und das Team beackert alles.
Kaufmänner arbeiten nicht so. Dass muss allen klar sein. Ist es aber nicht. Wir haben ein ernsthaftes Problem. Es ist schon ein Indiz dafür, dass was schief läuft, wenn die meisten tollen Softwareenwicklungen in ausländischen Unternehmen stattfindet. Deutschland wird niemals führend in der IT sein, wenn die Kaufmänner ihre Hand auf alles legen – und uns ITler die Luft zum Atmen nehmen.
