Wie geht moderne Softwareentwicklung?

Felix: Moderne Soft­wa­re­ent­wick­lung ist die Anwen­dung der Erfah­run­gen aus den letz­ten zwan­zig Jahren. Ganz klas­sisch gab es früher das Pflich­ten- und Lasten­heft. Der Kunde hat seine Anfor­de­run­gen in einem Riesen­buch zusam­men­ge­schrie­ben. Dann wurde zwei Jahre entwi­ckelt. Anschlie­ßend kriegte der Kunde eine Lösung – und die war gar nicht das, was er haben wollte.

Das Lear­ning daraus ist der agile Ansatz: Wir fangen mit etwas an und schauen in regel­mä­ßi­gen Abstän­den mit dem Kunden drauf. So kann er recht früh Einfluss auf die Entwick­lung nehmen. Das ist meis­tens deut­lich güns­ti­ger, als wenn es nach zwei Jahren eine grund­le­gende Anpas­sung geben soll.

Björn: Man könnte das auf einen Satz herun­ter­bre­chen: Früh­zei­tigs­tes Feed­back einho­len. Sowohl was die Metho­dik angeht, dass wir Scrum-Termine – Reviews, Plan­nings, Refi­ne­ments – machen, bei denen der Kunde dabei sein kann. Aber auch was wir tech­no­lo­gisch machen. Conti­nuous Deploy­ment zielt darauf ab, dem Kunden möglichst früh­zei­tig zu zeigen, was man gemacht hat. Damit ermög­li­chen wir dem Kunden neu entwi­ckelte Featu­res sehr zeit­nah zur Entwick­lung zu testen, zu reviewen und ggf. gegen­zu­steu­ern, wenn er – aus welchen Grün­den auch immer - merkt, dass etwas noch nicht so ist, wie er es braucht.

Felix: Was ich an diesen kurzen Zyklen auch super wert­voll finde, ist, dass die Entwick­ler und Entwick­le­rin­nen ein viel besse­res Verständ­nis dafür krie­gen, warum der Kunde bestimmte Entschei­dun­gen trifft.

Felix: Früher hast du vom Kunden sehr grobe Anfor­de­run­gen bekom­men, für die dann ein Entwick­lungs­team Lösun­gen geschus­tert hat. Heute defi­niert er die Anfor­de­run­gen, dann guckt das Entwick­lungs­team drüber, stellt seine Rück­fra­gen und fina­li­siert sie direkt mit dem Kunden.

Björn: Da haben am Ende in den meis­ten Fällen alle Team­mit­glie­der das glei­che Verständ­nis, was als Ergeb­nis heraus­kom­men soll. Aber nicht nur die Entwick­le­rin­nen und Entwick­ler erhal­ten ein besse­res Bild von den tatsäch­li­chen Anfor­de­run­gen, sondern auch für unsere Kunden bietet das heutige agile Vorge­hen den großen Vorteil, dass sie selbst mit jeder Itera­tion besser heraus­fin­den können, was sie eigent­lich wirk­lich brau­chen.

Björn: Das ist je nach Projekt unter­schied­lich: In den größe­ren Projek­ten stellt der Kunde meis­tens eine Person, mit der wir die Anfor­de­run­gen heraus­a­r­bei­ten und der das Produkt letzt­lich gegen­über seinen Stake­hol­dern verant­wor­tet – da kommt der Name Product Owner ja auch her. Es kann aber auch durch­aus mehr als eine Person dabei sein. So war es bei einem Kunden die Regel, dass vier bis fünf Leute bei den Scrum-Termi­nen waren: IT-Leiter, QS, Projekt­lei­ter und weitere Leitungs­funk­ti­o­nen.

Felix: Ich habe gerade einen klei­ne­ren Start-up-Kunden, der ist bei jedem Meeting bis hin zum Daily dabei. Das sorgt bei ihm für ein größe­res Verständ­nis, wenn wir mal mit irgen­d­et­was strug­geln. Er ist bei der Entste­hung des Problems dabei und kann auch den Fort­s­chritt bis hin zur Lösung des Problems verfol­gen.

Björn: Wir haben 2008 bei einem größe­ren Kunden den agilen Ansatz einge­führt. Unser Kollege Frank Düster­beck hat mit Daily-Stand-ups ange­fan­gen. Das hat erst­mal für Verwun­de­rung gesorgt, warum jetzt so viele Menschen, sechs bis sieben Leute, auf einmal jeden Morgen in der Bespre­chungs­ecke stehen und mitein­an­der quat­schen. Das war schon unge­wöhn­lich. Da musste man für werben. Es gab aber auch damals schon Leute auf der Kunden­seite, für die das zumin­dest theo­re­tisch nicht neu war und die das gerne auspro­bie­ren woll­ten.

Felix: Ich glaube, viele Unter­neh­men haben verstan­den, dass gerade in der IT agiles Vorge­hen abso­lut sinn­voll ist. Und es wird ja jetzt auch in ande­ren Berei­chen adap­tiert. Nach wie vor ist es aber ein schwie­ri­ger Prozess, wenn Kunden das nicht gewohnt sind. Sie müssen sich umstel­len und sich wirk­lich aktiv einbrin­gen, damit wir die Lösung bauen können, die sie wirk­lich haben wollen. Das ist ein Prozess, bei dem der Kunde im Vorfeld abge­holt werden muss.

Felix: Was wir häufig machen ist, dass wir ihnen Leute an die Hand geben, die sie in diesem Prozess unter­stüt­zen. Einen Proxy-PO zum Beispiel.

Björn: Und auch einen oder eine Agile Maste­rin, die es zu ihrer Aufgabe macht, dem Kunden die agilen Prozesse näher zu brin­gen und dabei hilft, Schwie­rig­kei­ten zu besei­ti­gen.

Felix: Beim agilen Vorge­hen sollte man auch als Entwick­ler selbst in der Lage sein, mit dem Kunden zu kommu­ni­zie­ren und die tech­ni­sche Entschei­dung vor ihm vertre­ten zu können. Früher hat das häufig der jewei­lige Projekt­lei­ter über­nom­men. Aber dem fehlt im Zwei­fel das tech­ni­sche Know-how.

Felix: Am Ende des Tages auf ein Produkt, das die Bedürf­nisse des Kunden erfüllt. Die Entwick­lung soll schnell sein. Time-to-Market ist heute wich­tig, gerade wenn du nicht der einzige Player im Markt bist und das Produkt deshalb möglichst schnell veröf­fent­licht krie­gen willst.

Björn: Kunden­zu­frie­den­heit, das sowieso. Aber auch die Abwä­gung der Quali­täts­ziele, die so ein System haben sollte. Das kann von Projekt zu Projekt komplett unter­schied­lich sein. Viel­leicht ist Time-to-Market bei einem ande­ren Projekt gar nicht so wich­tig. Dafür musst du dann even­tu­ell einen größe­ren Fokus auf Daten­si­cher­heit haben, oder das System muss möglichst ausfall­s­i­cher sein.

Das sind viel­leicht Dinge, die – wie Felix sagt – bei einem Start-up erst­mal nicht so wich­tig sind. Hier muss man manch­mal den tech­no­lo­gisch nicht so super perfek­ten Ansatz wählen, damit man nicht Gefahr läuft, in Schön­heit zu ster­ben. Es hat schließ­lich niemand was davon, wenn nach fünf Sprints ein super sauber struk­tu­rier­tes System steht, das aber nichts von dem kann, was das Start-up drin­gend braucht und auf einmal das Geld alle ist.

Felix: Ausnah­men bestä­ti­gen die Regel. Aber ich würde sagen, ja. Ich könnte mir nicht mehr vorstel­len, ein Projekt nicht agil anzu­ge­hen.

Björn: Es hat auf jeden Fall immer agile Kompo­nen­ten. Es kann natür­lich sein, dass du bei Soft­ware, die kritisch für Leib und Leben ist, Flug­zeugs­oft­ware oder so, wahr­schein­lich deut­lich forma­ler vorge­hen musst. Aber unsere Projekte machen wir agil.

Felix: In der Vergan­gen­heit haben wir manch­mal agile Projekte zum festen Betrag ange­bo­ten. Das wider­spricht sich. Das sind keine Fest­preispro­jekte, sondern Aufwand­s­pro­jekte. Häufig wird verges­sen, dass die Schät­zung, die man im Vorfeld macht, eben eine Schät­zung ist. Auch da muss man den Kunden abho­len.

Felix: Jedes Projekt hat ein gewis­ses Maß an Unsi­cher­heit. Man kann aber versu­chen, diese Unsi­cher­hei­ten früh­zei­tig zu elimi­nie­ren. Beim Kunden Safeboxen zum Beispiel war der Scope des Projektes von vorneherein klar: Ein Container mit Schließfach-Boxen und einem Portal, über das dann irgendwie die Schlösser aufgehen. Ein Portal bauen, das können wir. Das haben wir schon x-mal gemacht. Aber bevor wir mit dem Team das Portal entwickeln, wollten wir im Vorfeld testen, wie sich die Bluetooth Controller in diese Schlösser integrieren lassen. Wenn das nicht funktioniert, dann brauchen wir den Rest gar nicht bauen.

Björn: Du musst sehen, dass du das Wich­tigste, den MVP (Mini­mum Viable Product, etwa: kleins­tes funk­ti­ons­fä­hi­ges Produkt), heraus­schälst und den Fokus darauf legst, diesen umzu­set­zen. Damit hast du das größte Risiko mini­miert. Dann kann der Kunde entschei­den, ob es weiter­geht oder nicht. Eine Option ist eben auch, dass der Kunde abbre­chen kann, wenn sich nach drei, vier Sprints nichts Zufrie­den­stel­len­des ergibt. Diese wird zum Glück nicht allzu oft gezo­gen.

Felix: Ich glaube das ist, wieviel Eigen­ver­ant­wor­tung in den Teams liegt. Sie sind nach dem Projekt­start voll­stän­dig verant­wort­lich für das Projekt mit allem, was dazu­ge­hört. Die Teams haben jeder­zeit Einsicht in das Budget. Sie wissen, wo das Projekt steht. Sie müssen tech­ni­sche Entschei­dun­gen tref­fen. Um die Anfor­de­run­gen umzu­set­zen, müssen sie Verant­wor­tung über­neh­men. Bei den meis­ten Leuten führt diese hohe Eigen­ver­ant­wor­tung zu einer hohen Moti­va­tion. Es moti­viert, wenn du Dinge entschei­den kannst.

Björn: Das hat sich mit den Jahren auch gewan­delt. Früher hatten wir in Projek­ten oft die klas­si­schen Rollen: eine macht Archi­tek­tur, einer kümmert sich um QS, der nächste um die Projekt­lei­tung und dann noch ein paar Entwick­ler:innen. Das wird heute meist durch Team­a­r­beit erle­digt. Und hier­durch fühlt sich jedes Team­mit­glied für die jewei­li­gen Themen­ge­biete verant­wort­lich.

Genau hier kommt auch das Thema DevOps ins Spiel: In den meis­ten Projek­ten betreibt das Team das, was es entwi­ckelt hat, hinter­her auch. Da habe ich ein deut­lich gestei­ger­tes Inter­esse, die Prozesse möglichst hand­hab­bar zu machen.

Björn: ChatGPT. Reicht doch!

Felix: Das ist auf jeden Fall ein Punkt. Ich glaube, dass wir lernen, sowas wie ChatGPT zu bedie­nen. Klar brauchst du noch Leute, die das verste­hen, was da am Ende an Code heraus­kommt. Wir werden aber davon wegkom­men, dass man alles per Hand tippen muss. Wir verpro­ben bei uns gerade den GitHub Copi­lot. Das ist schon beein­dru­ckend, was der uns an Boiler­plate-Code abneh­men kann, also Code, der nur Fleiß­ar­beit ist.

Björn: Das wird in Zukunft aber noch deut­lich mehr Seman­tik haben. Ich kann dem Tool eine Aufgabe stel­len und es kommt ein biss­chen mehr heraus als dieser 0815-Code.

Felix: Eine Heraus­for­de­rung im Vergleich zu vor zehn Jahren ist, dass es nicht mehr reicht, Java und das eine oder andere Frame­work zu können. Heute muss ich mich mit viel mehr Sachen ausken­nen, nicht bis in die Tiefe, aber so weit, dass ich sie benut­zen kann. Ich muss ein biss­chen Ahnung von Docker haben, von Deploy­ment, Daten­ban­ken, dann die eigent­li­che Entwick­lung im Backend und Fron­t­end. Du musst neben deiner Projekt­a­r­beit gleich­zei­tig immer gucken, was rechts und links in dieser IT-Welt passiert. Das ist eine schwie­rige Balance.

Björn: Und du musst am Ball blei­ben. Gerade bei Themen wie KI / AI, da passiert so viel! Das ganze Thema rund um ChatGPT oder GitHub Copi­lot hat ja erst in den letz­ten zwölf Mona­ten so rich­tig Fahrt aufge­nom­men und gefühlt kommen jede Woche Neue­run­gen hinzu. Nichts­des­to­trotz müssen wir auch in der Zukunft unsere Basis-Tech­no­lo­gien im Blick haben, um hier keine Neue­run­gen zu verschla­fen.

Felix: Das auf jeden Fall. Ich denke aber, jenseits aller tech­ni­schen Neue­run­gen müssen wir in Zukunft noch viel mehr unse­ren Fokus darauf legen, unsere Kunden bei der Analyse ihrer Anfor­de­run­gen von der tech­ni­schen Seite zu unter­stüt­zen, damit wir ihnen Lösun­gen bauen können, die sie auch wirk­lich brau­chen. Das wird zeit­nah kein AI-Tool über­neh­men können und wird schließ­lich immer mehr zu unse­rer Kern­kom­pe­tenz werden.

Felix: Weil sie sonst ein Soft­wa­re­pro­dukt hätten, für das sie wahr­schein­lich keinen Dienst­leis­ter mehr finden, der das weiter­pfle­gen möchte. Wenn ein Projekt in Betrieb geht und du fasst es drei Jahre nicht an, dann hast du eine unglaub­li­che Arbeit, bis du die ganzen neuen Versi­o­nen aktu­a­li­siert hast. Darum stel­len viele Kunden bei uns über einen Support-Vertrag sicher, dass die Soft­ware up-to-date gehal­ten wird.

Björn: Was anders ist als früher, ist die Lang­le­big­keit von Projek­ten, die fast schon keine Projekte mehr sind, sondern eher Produkte der "Losgröße 1". Die meisten Projekte sind auf Langfristigkeit ausgelegt, also dass sie länger als fünf Jahre laufen. Deshalb wird Wartbarkeit und Erweiterbarkeit in diesen Umfeldern oft immer wichtiger.

Felix: Perfek­tes Stich­wort: Wart­bar­keit. Das hat sich auch geän­dert. Das ganze Thema Testing. Als ich ange­fan­gen habe, steckte das noch in den Kinder­schu­hen. Du willst auch nach fünf Jahren noch sicher­stel­len können, dass wenn du etwas anfasst, nicht etwas an ande­rer Stelle umfällt.

Björn: Ich will das schon nach zwei Tagen sicher­stel­len! Das hat auch etwas mit Eigen­schutz zu tun. Wenn du früher – in der Zeit als Unit-Testing noch nicht so verbrei­tet war - ein Refac­to­ring machen muss­test, wie konn­test du sicher­stel­len, dass das System hinter­her noch funk­tio­niert? Das war Stress pur! Genauso wenn man früher nur einmal im Quar­tal eine neue Version ausge­lie­fert hat. Da gab es dann Wochen­en­den, an denen alle gezit­tert haben, ob man sonn­tags nicht doch die alte Version zurück­spie­len muss. Daher hat alles, was wir heute an Conti­nuous Inte­gra­tion und Conti­nuous Deploy­ment machen, auch den Hinter­grund, dass das eine Art von Trai­ning ist und du sicher sein kannst, dass dir ein Fehler sofort auf die Füße fällt und eben nicht erst ein Vier­tel­jahr später, wenn du keinen Schim­mer mehr hast, warum.

Felix: Ich finde, wir sind gerade schon in einer super­span­nen­den Zeit. Klar, das KI-Thema ist noch­mal ein Schlag oben­drauf. Wenn ich mir ansehe, was sich da getan hat, kann ich mir nicht vorstel­len, was in den nächs­ten zehn Jahren noch passie­ren soll. Das ist schon total krass.

Björn: Prozesse, die wir heute noch manu­ell machen, werden wahr­schein­lich weiter auto­ma­ti­siert werden. Ich kann mir gut vorstel­len, dass das noch deut­lich komfor­t­a­bler und für die Entwick­ler:in einfa­cher wird. Tools und Systeme wie bspw. Kuber­ne­tes haben eine hohe Komple­xi­tät und steile Lern­kurve. Da wird sich mit Sicher­heit noch eini­ges tun, damit der Einstieg und die Bedie­nung künf­tig einfa­cher sind.

Felix: Worauf ich mich auf jeden Fall freue, das ist auch eine coole Geschichte bei der HEC, sind regel­mä­ßig wech­selnde Projekte und Kunden. Es werden früher oder später alle Berei­che zur Digi­ta­li­sie­rung gezwun­gen sein. Man beglei­tet viele Leute beim Weg in die Digi­ta­li­sie­rung. Das ist super­span­nend. Und irgend­wie schon cool, wenn du siehst, was die vorher für abge­fah­rene Prozesse hatten. Mit Excel ausdru­cken, eins­can­nen, abtip­pen, wieder Excel, faxen... Und jetzt krie­gen sie eine Lösung, mit der das alles auf Knopf­druck funk­tio­niert!

Björn: Beim Hand­werks­zeug gibt es span­nende Entwick­lun­gen. Früher waren Code-Reviews, Pair Program­ming und Mob Program­ming nicht so gang und gäbe. Durch Corona hat das einen Push gege­ben. Aller­dings leidet durch das Home­of­fice das sozi­ale Umfeld im Team. Wenn das Team nicht funk­tio­niert, funk­tio­niert das Projekt nicht. Deshalb denke ich immer mehr, ein zwei Tage vor Ort fände ich schon schön. Das ist viel­leicht das, worauf ich mich freue: Dass es in Zukunft wieder ein biss­chen mehr persön­li­che Tref­fen geben wird.