Spezialisierung bei der Softwareentwicklung – was fehlt uns?


28.03.2017 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Phasen und Aktivitäten in der Software​entwicklung…

Eigentlich wäre die Welt per­fekt, wenn jeder alle Auf­gaben in glei­cher Weise gut aus­führen könnte – ins­beson­dere in der Welt der Soft­ware​ent­wick­lung. Leider sind die Uni­ver­sal­genies nur spärlich ver­treten. Die meisten Be­teilig­ten haben ihre Stärken, aber auch ihre Schwächen.

Aus diesem Grunde hat es sich schon lange Zeit heraus­ge­bildet, dass bei der Soft­ware​ent­wick­lung eine Spezi­ali­sie­rung der Be­teilig­ten hilf­reich ist. Damit müssen dann nicht mehr alle alles machen. Der Ein­zel­ne kann sich auf seine Stärken stützen.

Sehr populär ist diese Spezi­a­li­sie­rung mit den Phasen­model­len einer Soft­ware​ent­wick­lung ge­worden. Egal, ob streng nach Wasser­fall be­trach­tet oder itera­tiv: Immer sind die Ak­ti­vi­tä­ten „Ana­lyse“, „Ent­wurf“, „Imple­men­tie­rung“, „Test“ und „Be­trieb“ im Spiel – mach­mal mehr und manch­mal weniger ausgeprägt.

…führen zur Spezialisierung

Aus diesen Akti­vi­tä­ten hat sich schon seit Langem eine Spezi­ali­sie­rung ab­ge­leitet. In der Regel werden nicht alle Akti­vi­tä­ten von den gleichen Per­sonen erledigt:

  • In der „Analyse“ gibt es An­for­de­rungen auf­zu­nehmen. Das wird in der Regeln von Busi­ness-​Ana­lys­ten erledigt.
  • In der Phase „Ent­wurf“ wird das Sys­tem ent­worfen. Das wird land­läufig von Archi­tek­ten übernommen.
  • In der Phase „Imple­men­tie­rung“ wird das Sys­tem pro­gram­miert. Das machen die Entwickler.
  • Fertige Features oder ganze Appli­ka­tio­nen werden in der Phase „Test“ einer Quali­täts­siche­rung unter­zogen. Das ist die Auf­gabe der Tester.
  • Und schließlich wird das System an den Be­trieb zur Be­treuung über­geben. Hier sind dann die Ope­ra­teu­re an der Reihe.

In der Soft­ware​ent­wick­lung haben sich alle diese Auf­gaben schon etabliert und die ent­sprechen­den Spezi­alis­ten sind iden­ti­fi­ziert und täg­lich an der Arbeit.

Es hat sich ge­zeigt, dass das Spezi­alis­ten­tum der Effizienz zu­träg­lich ist. Den Effekt ken­nen wir nicht nur aus der IT, sondern aus vielen anderen In­dustrie­be­rei­chen. Eigent­lich reden viele in der IT auch über Indus­tri­ali­sie­rung – aber das ist eine andere Geschichte.

Malen der Oberfläche und Beglückung der Anwender

Natürlich ist damit das Bild noch nicht fertig. Im Projekt­all­tag gibt es weitere Rollen, die von Spezia­lis­ten aus­ge­füllt werden. Hier will ich nicht eine voll­stän­di­ge Liste der Rollen auf­führen, die in Soft­ware​ent­wicklungs­pro­jek­ten vor­kommen. Viel­mehr möchte ich auf Rollen zu sprechen kommen, die oft­mals ver­nach­lässigt werden.

In den Anfängen waren die Com­pu­ter sehr mit sich selbst be­schäf­tigt. Pro­gram­me liefen – manch­mal ein­zeln oder als Batches ge­bün­delt oder nach­einan­der – ab. Zu­nehmend sind die Systeme näher an den An­wender heran­ge­kom­men. Da­mit spielt dann auch die Nutzungs­schnitt­stelle (= User Inter­face = UI) eine immer wich­ti­gere Rolle. Hier mussten wir lernen, dass je­mand, der gut spezi­fi­ziert oder pro­gram­miert noch lange kein Ex­perte für UI-​Design sein muss.

Ein Fehler, der immer wieder be­gangen wurde, be­steht darin, das UI-​Design zu ver­nach­lässigen. Das kann am Ende dann ein Akzep­tanz­prob­lem der fertigen Appli­ka­tion zur Folge haben. Und damit droht ein Pro­jekt im Ex­trem­fall sogar daran zu scheitern.

Daraus lernen wir, dass der Ge­stal­tung der Nutzungs­ober­fläche die ge­bühr­ende Be­ach­tung ge­schenkt werden muss. Am besten ge­schieht das, indem je­mand mit den ent­sprechen­den Vor­lieben und Fertig­keiten in dem Ent­wick­lungs­pro­jekt mit­arbei­tet. Diese Lücke haben schon viele ent­deckt und man findet eine pas­sende Be­setzung in zu­nehmen­dem Maße in den Projekten. Dieser Themen­kom­plex läuft neuer­dings unter dem Stich­wort User-Ex­pe­rien­ce oder kurz UX.

Dokumentieren ist etwas anderes als Programmieren

Eine andere Fertig­keit wird immer noch gerne den Pro­gram­mie­rern zu­ge­schrie­ben. Das ist die Er­stel­lung von Doku­men­ta­tion. Die Argu­men­ta­tion ist da­bei, dass die Ent­wick­ler am besten wissen, was ein Pro­gramm macht und es des­halb am besten auf­schrei­ben können. Leider sind Uni­ver­sal­genies selten. Des­halb tun sich auch Pro­gram­mierer mit solchen Auf­gaben manch­mal etwas schwer.

Das Thema Dokumen­ta­tion ist aber auch ein um­fas­sen­des. Das kann auf der einen Seite mit einer End­an­wender­doku­men­ta­tion an­fangen und auf der anderen Seite bis in die Tiefe der Quell­code­doku­men­ta­tion ab­tauchen. Wenn wir heute schon ge­legent­lich Spezia­lis­ten für End­an­wender­doku­men­ta­tion finden, so werden die Ent­wick­ler doch immer noch regel­mäßig dazu ge­drängt, ihren Quell­code selbst zu dokumentieren.

Was passiert aber, wenn ein Ent­wickler nicht gut schreiben kann und des­halb auch keinen Spaß daran hat? Ein Ausweg hat sich mit der „Clean-​Code-​Philo­so­phie“ [1] ergeben. Die Logik ist ja zu einem ge­wissen Grade auch be­stechend: „Der Code doku­men­tiert sich selbst. Da braucht es sonst nichts mehr.“ Für einen Ent­wick­ler er­gibt sich da­mit ein ein­facher Aus­weg aus dem Doku­men­ta­tions­prob­lem: „Ich sage jedem, dass ich Clean-​Code mache. Damit ver­meide ich doku­men­tie­ren zu müssen, ohne dass je­mand merkt, dass ich das nicht gut kann.“

Um aus diesem Dilemma heraus­zu­kommen, sehe ich zwei Wege: Man kann die Pro­gram­mierer zu Schrei­bern er­ziehen oder man kann Spezia­lis­ten ins Boot holen, die das Schreiben über­nehmen. Diese Spezi­alis­ten würde ich dann „Techni­cal Writer“ nennen. Den Be­griff gibt es zwar schon. Da­run­ter wird aber meistens nur je­mand ver­stan­den, der tech­nische Doku­men­te er­stellt, was sich aber nicht bis hin zur Code-​Doku­men­ta­tion erstreckt.

Ich habe es in der vollen Aus­prä­gung noch nicht prak­tisch er­lebt, aber wenn man den Ge­dan­ken an Spezi­alis­ten­tum kon­se­quent zu Ende denkt, dann stellt sich die Frage, warum man den Ent­wick­lern eine un­ge­liebte Auf­gabe auf­drängt, an­statt die In­dus­tri­ali­sie­rung auch in dieser Ecke der Soft­ware​ent­wick­lung voran­zu­treiben und „Techni­cal Writern“ die Auf­gabe der Quell­code-​Doku­men­ta­tion und Er­stel­lung anderer technischer Doku­men­te zu über­lassen.

Im Sinne eines wasser­fall­artigen Pro­jekt­vor­gehens wäre das eine Phase, die man paral­lel zu Ent­wick­lung und Test an­siedeln könnte. Hier werden die „Techni­cal Writer“ parallel zu den Pro­gram­mierern und Testern aktiv.

Bei einem agilen Vor­gehen könnte diese Spezi­ali­sie­rung bei­spiels­weise mit Pair-​Pro­gram­ming kom­bi­niert werden. Ein ver­sier­ter Pro­gram­mierer und ein ver­sier­ter Schreiber bilden ein Paar. Zu­sam­men arbei­ten sie an dem gleichen Code, wobei der eine die Pro­gram­mierung und der andere die Doku­men­ta­tion im Fokus hat. Durch eine ge­mein­same Ar­beit wird das Wissen trans­por­tiert und die Arbeit an den je­wei­ligen Er­geb­nis­sen gleich aus einer an­de­ren Per­spek­ti­ve her­aus quali­täts­ge­sichert.

Mehr Fähigkeiten für den Einzelnen oder mehr Spezialisten für die Projekte!

Aus den voran­ge­gangenen Über­legungen er­geben sich für ver­schiedene Personen­kreise unter­schied­liche Konsequenzen.

Wir haben ge­sehen, dass eine weitere Spezia­li­sie­rung in IT-​Pro­jek­ten durch die Be­setzung mit bis­her ver­nach­lässig­ten Fähig­keiten er­fol­gen kann. Das ist eine Auf­gabe, die bei der Zu­sam­men­stel­lung eines Teams be­rück­sichtigt werden sollte – vielleicht mehr als dies aktuell der Fall ist. Das be­trifft die mit dem Staf­fing be­trau­ten Personen.

Eine weitere Gruppe sind die Wächter der Vor­gehens­model­len in Unter­nehmen oder Pro­jek­ten. Sie sollten über­prüfen, ob die hier an­ge­sproch­enen As­pek­te bei ihnen in an­ge­mes­sener Weise be­rück­sich­tigt sind.

Schließlich kommen die Per­sonen, die in einem Soft­wareent­wick­lungs­pro­jekt aktiv mit­wirken – und zwar ins­be­son­dere die Ent­wick­ler. Ein Ent­wick­ler sollte sich fragen, ob es nicht an­ge­raten wäre, die eigenen „Writing Skills“ auf den Prüf­stand zu stellen und ge­gebenen­falls zu ver­bessern. Wir müssen ja nicht gleich alle Uni­versal­genies werden, aber sich ein bisschen in diese Rich­tung zu be­mühen, ist sicher nicht schlecht.

Referenzen

[1] Robert C. Martin: Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code. mitp-Verlag, ISBN 978-0-13-235088-4.

Dieser Blog-Artikel steht under der Lizenz CC-BY-SA 4.0.
Die in den Blog-Beitrag eingebundenen Bilder stammen zum Teil von Pixabay und stehen alle unter der Lizenz CC-0.