nicht angemeldet
Ueberlegungen zur Software-Entwicklung
Hi,
ich werde gleich fuer mich vier charakteristische Typen der Software-Entwicklung (leicht karikierend) vorstellen und bitte Euch um Ergaenzungen und Stellungnahmen:
I. Der "Bottom up - Typ":
Nachdem die Anforderung (typischerweise) im Groben aufgenommen worden ist, legt das Entwicklungsteam auch schon los. Man schnappt sich vielleicht irgendein Template, das beispielsweise als Prototyp eines aelteren Projekt liegengeblieben ist, hat somit schon Ansaetze einer Praesentationsschicht und setzt unmittelbar fort Funktionalitaeten beizufuegen sowie fast permanent mit dem Abnehmer zu kommunizieren.
Es stellen sich im Laufe des Entwicklungsprozesses dann schon mal Fragen wie "Ist der reale Sachverhalt in der Datenhaltung und im Datenzugriff korrekt nachgebildet worden?" oder "Welche Technologie setzen wir denn nun dafuer (fuer eine angeforderte Funktionalitaet) ein?". In der Regel werden diese Fragen erst recht spaet gestellt und beantwortet. "Kruecken" und schlimmstenfalls sogar "Tuerken" kommen dann moeglicherweise zum Einsatz. Das System kann dann schon mal wartungsunfreundlich, schlecht skalierbar und kaum weiterentwickelbar an den Abnehmer ausgeliefert werden.
Wenn das Team Glueck hat, ist der Abnehmer zufrieden und erfaehrt eine langjaehrige Betreuung.
II. Der "Top down - Typ":
Die Planungszeit endet hier erst, wenn die Anforderung feinspezifiziert ist, die einzusetzenden Technologien ermittelt sind und die personelle Verteilung der anstehenden Arbeiten geklaert ist. Das kann schon mal etwas laenger dauern, der Abnehmer ist auch schon ein klein wenig genervt; hat er doch sehr praezise spezifizieren muessen, was er denn nun eigentlich will. Er hat Angst, dass auf seiner Seite dabei Fehler gemacht worden sind.
Dem Entwicklungs-Teamleiter ist bei Beginn der Programmierung alles klar; er ueberschaut den entstehenden Aufwand und die einzusetzenden Technologien sind "im Griff", auch weil einige Mitarbeiter noch zu Schulungen geschickt worden sind. Der Teamleiter nennt auch gerne Termine fuer die voraussichtliche Fertigstellung, was dem Kunden gefaellt.
Erste Probleme treten auf, als ein Mitarbeiter fuer einige Wochen krank wird. Sein KnowHow kann nur schwer ersetzt werden und mehrere Meilensteine koennen ohne ihn nicht erreicht werden, da andere Teams seine Leistungsabnehmer sind. Zudem scheint die Anforderungslage gar nicht so stabil zu sein, wie angenommen. Der Abnehmer aeussert mit zunehmernder Dynamik noch einige (auch "kleinere") Aenderungswuensche.
Der Teamchef arbeitet weiter mit konsequenter Spock-Logik und es entsteht erst Terminstress, dann richtiger Stress.
In Sondersitzungen wird der dritte zugesagte Termin eingehalten. Das uebergebene System ist allerdings nicht schwaechenfrei.
III. Der Mischtyp:
Auf eine naehere Beschreibung moechte ich verzichten, da die Mischung aus "Top down" und "Bottom up" aussagekraeftig zu sein scheint. Es entstehen mal die einen (Typ I), mal die Probleme (Typ II). Das uebergebene System ist nicht schwaechenfrei.
IV. Der "philosophische" Typ:
Der Teamchef fuehlt sich gut, seine langjaehrigen Erfahrungen sagen ihm, dass Softwareentwicklung a la Typ II nicht geht. Er ist auch oberflaechlich betrachtet recht ideologiefrei und kann allzu gradlinigen, rechtwinkligen (orthogonalen) Argumentationen und Denkweisen wenig abgewinnen, weiss er doch um die Grenzen der Leistungsfaehigkeit seines Teams und der Leistungsfaehigkeit der Anforderungsspezifikation, die ja immerhin einen Sachverhalt aus der Realitaet mit Bits und Bytes nachzubilden beabsichtigt.
Das Team ist gut ausgebildet und man arbeitet nah an der Anforderungslage. Gelegentlich gibt es einen Engpass, weil beispielsweise eine Einheit des Teams in Verzug geraet oder auch weil eine laengere Diskussion ueber die bestmoegliche und einfachste Bearbeitung einer Teilanforderung anstand. Der Teamchef umschifft dank seiner sozialen Kompetenz aber die wichtigsten Hindernisse und die ausgelieferte Loesung haette hohe Akzeptanz finden koennen, wenn der Kontakt zum Abnehmer optimal gepflegt worden waere. So aber ist der Abnehmer trotz Qualitaetsarbeit nicht ganz zufrieden, aber das stoert den Teamchef nicht.
Gruss,
Lude
---
"Wir brauchen einen Mann auf dem Mars."
-
Hm,
schöne Lehrbuchabschriften aber: Was bitte möchtest Du?
Gruß Jan Huss
-
Hi,
Hm,
schöne Lehrbuchabschriften aber: Was bitte möchtest Du?
Gruß Jan Huss
'Ergaenzungen und Stellungnahmen'.
Gruss,
Lude---
"Bis Weihnachten brauchen wir Klarheit bei der Maut."
-
-
Hi Lude,
wenn Du eine gute Ausbildung genossen hast, hat man Dich die Essays aus "The mythical man-month" von Fred Brooks lesen lassen. Wenn Du gut bist (im Sinne der Ingenieur-Wissenschaften), hat diese Lektüre Deine Haltung zu Konzepten des Software-Engineerings so grundlegend beeinflußt, daß Du diesen Thread nicht eröffnet haben würdest [1]. Denn dann wäre Dir deutlich geworden, daß einige Visionäre sich bereits Mitte der 70er Jahre des vergangenen Jahrhunderts keiner Illusion mehr hinsichtlich des garantierten Scheiterns Deiner Typen I,II und III hingaben (IV scheint mir kein spezifischer Typ zu sein, sondern eine Selbstverständlichkeit für jeden Entwickler).
Aus Deinen Fragestellungen zu diesem Thema hallt die winselnde Hilflosigkeit der Auftraggeber und Manager von Softwareentwicklern unserer Zeit; diese lähmende und permanent Fehlentscheidungen erzeugende Unfähigkeit, die angesichts der unüberwindbar komplexen und weitgespannten Anforderungen der Softwareentwicklung nach einem Strohhalm in Form eines approbierten, genormten Verfahrens zu greifen sucht. Im Grunde ein spezialisierte Form von Lebensunfähigkeit, die ihre Ursache in der Pest der unserer Zeit hat: die BWL (Himmel - es wird emotional, tu einfach so, als hättest Du den letzten Satz nicht gelesen; dieses Thema läßt sich nur an langen Abenden mit Wein vor dem Kaminfeuer diskutieren, niemals online...).
Aktuell läßt sich diese Schauspiel am Beispiel "Extreme Programming" beobachten: jeder spricht davon, daß soll was tolles sein, weniger Entwicklungszeit, wesentlich höhere Erfolgsquote, blah blah blah. Aber es setzt sich nur quälend langsam durch; denn die Entscheider blicken nicht durch, ihre Phantasie versagt völlig bei der Vorstellung, zwei Entwickler gemeinsam an einem Terminal arbeiten zu lassen und auch sonst alle approbierten und zertifizierten Methoden über Bord zu werfen (und was noch viel bedeutender ist: sie haben keine persönliche Erfahrung mit dieser Methode gemacht und werden sie nie machen, denn sie sind BWLer und keine Ingenieure; was bedeutet, daß sie es niemals richtig beurteilen können werden).
Aus meiner eigenen Erfahrung würde ich die Sache so sehen, wie ich es bei Stephen Black gelernt habe: "Surgical Team im chaotischen Raum".
1. Ein oder mehrere Teams sind aufgebaut wie ein chirurgisches Team im OP: _ein_ Entwickler (vielleicht nach Extreme-Programming-Manier zwei, die wie einer arbeiten, die Erfahrung habe ich nur einmal gemacht und das ist schon so lange her), der über eine Gruppe von Leuten verfügt, die ihm zuarbeiten (Tester, Werkzeugmacher, Dokumentierer, Rechercheur, Kommunikator, ...)
2. Zerhacken der unklaren und wechselnden Anforderungen in nach Prioritäten geordnete Häppchen, die drängendsten werden zuerst abgearbeitet, die unbedeutenden verschwinden über die Laufzeit von selbst, permanentes Briefing hält das Moving Target im Fadenkreuz
Ergo muß Softwareentwicklung meiner Meinung nach im Rambo-Stil ablaufen: Entwickler wird nachts im Sturm über unbekanntem Dschungelgebiet mit dem Fallschirm abgeworfen und muß sich taktisch lavierend mit viel Erfahrung und Agilität durchkämpfen. Das bedeutet für den Auftraggeber und das Management, auf solche Rambos Zugriff haben zu müssen - und die gibt es so häufig wie schwarze Perlen im Ozean; das bedeutet, solchen Rambos vertrauen zu müssen, ohne genau zu wissen, wo es hingeht; das bedeutet, nur sehr schwer solche Projekte pauschal kalkulieren zu können; das bedeutet, das große Projekte (von denen wir hier sprechen) keine singulären Ereignisse sind, sondern einen permanenten, nie endenden Strom darstellen. Wir haben es also vorwiegend mit Problemen zu tun, die gegen die Natur des BWLers sprechen und somit heutzutage kaum lösbar sind...
hth Robert
[1] Da ich diesen Disclaimer in Diskursen mit Dir wohl immer wieder anbringen muß: ich möchte Dich nicht offensiv oder aggressiv angehen; meine Aussagen ergeben sich ganz natürlich und emotionslos aus den gegebenen Umständen.
-
Hi,
Denn dann wäre Dir deutlich geworden, daß einige Visionäre sich bereits Mitte der 70er Jahre des vergangenen Jahrhunderts keiner Illusion mehr hinsichtlich des garantierten Scheiterns Deiner Typen I,II und III hingaben (IV scheint mir kein spezifischer Typ zu sein, sondern eine Selbstverständlichkeit für jeden Entwickler).
ja, interessant dass das schon lange bekannt ist.
Im Grunde ein spezialisierte Form von Lebensunfähigkeit, die ihre Ursache in der Pest der unserer Zeit hat: die BWL (Himmel - es wird emotional, tu einfach so, als hättest Du den letzten Satz nicht gelesen; dieses Thema läßt sich nur an langen Abenden mit Wein vor dem Kaminfeuer diskutieren, niemals online...).
Auch das koennte "stimmen".
Aktuell läßt sich diese Schauspiel am Beispiel "Extreme Programming" beobachten: [...] sie haben keine persönliche Erfahrung mit dieser Methode gemacht und werden sie nie machen, denn sie sind BWLer und keine Ingenieure; was bedeutet, daß sie es niemals richtig beurteilen können werden).
Interessante Theorie, der ich fast geneigt bin zuzustimmen.
Aus meiner eigenen Erfahrung würde ich die Sache so sehen, wie ich es bei Stephen Black gelernt habe: "Surgical Team im chaotischen Raum".
-
Ein oder mehrere Teams sind aufgebaut wie ein chirurgisches Team im OP: _ein_ Entwickler (vielleicht nach Extreme-Programming-Manier zwei, die wie einer arbeiten, die Erfahrung habe ich nur einmal gemacht und das ist schon so lange her), der über eine Gruppe von Leuten verfügt, die ihm zuarbeiten (Tester, Werkzeugmacher, Dokumentierer, Rechercheur, Kommunikator, ...)
-
Zerhacken der unklaren und wechselnden Anforderungen in nach Prioritäten geordnete Häppchen, die drängendsten werden zuerst abgearbeitet, die unbedeutenden verschwinden über die Laufzeit von selbst, permanentes Briefing hält das Moving Target im Fadenkreuz
Danke fuer diesen interessanten Hinweis.
Ergo muß Softwareentwicklung meiner Meinung nach im Rambo-Stil [...] Wir haben es also vorwiegend mit Problemen zu tun, die gegen die Natur des BWLers sprechen und somit heutzutage kaum lösbar sind...
Ich hatte bisher statt 'Rambo' immer von 'Spielstaerke' gesprochen. Hoert sich fuer mich besser an und bringt ebenso mit sich, dass es spielschwache Entwickler gibt, denen man genausowenig trauen kann wie einem impotenten 'Rambo'. - Zum Glueck bin ich kein "BWLer". ;-)
[1] Da ich diesen Disclaimer in Diskursen mit Dir wohl immer wieder anbringen muß: ich möchte Dich nicht offensiv oder aggressiv angehen; meine Aussagen ergeben sich ganz natürlich und emotionslos aus den gegebenen Umständen.
Man kann beruhigt zwei Dinge ueber Dich behaupten: 1.) Du bist intelligent. 2.) Du bist unangenehm in der Kommunikation hier.
Darauf, dass Du hier emotionslos Deine Buchstaben eintippst, wuerde ich allerdings nicht wetten wollen.Gruss,
Lude-
Hi,
Ergo muß Softwareentwicklung meiner Meinung nach im Rambo-Stil [...] Wir haben es also vorwiegend mit Problemen zu tun, die gegen die Natur des BWLers sprechen und somit heutzutage kaum lösbar sind...
Ich hatte bisher statt 'Rambo' immer von 'Spielstaerke' gesprochen. Hoert sich fuer mich besser an und bringt ebenso mit sich, dass es spielschwache Entwickler gibt, denen man genausowenig trauen kann wie einem impotenten 'Rambo'. - Zum Glueck bin ich kein "BWLer". ;-)
ACK
1.) Du bist intelligent.
Das ist ein in Milch eingelegtes Brötchen auch (mit einem IQ von 0), vielen Dank!-)
2.) Du bist unangenehm in der Kommunikation hier.
?
Darauf, dass Du hier emotionslos Deine Buchstaben eintippst, wuerde ich allerdings nicht wetten wollen.
Emotionslos war der Part, zu dem die Fußnote gehörte. Ansonsten würde ich auch nicht darauf wetten...
hth Robert
-
-