So entwickeln wir Software

So entwickeln wir Software


Egal, wie ausführlich man Lastenhefte für komplexe Softwareprojekte gestaltet, in den meisten Fällen ist es nicht realistisch, alle Projektanforderungen vor Entwicklungsbeginn vollständig, exakt und endgültig zu definieren.

Dazu kommt, dass die Schnelllebigkeit im Geschäftsalltag mit ständig neuen Anforderungen an Projekte einher geht.

Wenn Änderungen "normal" werden und Kommunikation essentieller Bestandteil ist, müssen Softwareprojekte sowohl methodisch als auch architekturell darauf ausgerichtet werden.

Das wirft viele Fragen auf. Diese haben wir zum Anlass genommen, Ihnen nachfolgend unseren Ansatz und die Methodik, wie wir Software entwickeln, näher zu bringen.


Was muss ich vor Entwicklungsstart an Vorleistungen erbringen?

Die Last mit dem Lastenheft

Der Klassiker:
Vor Entwicklungsbeginn wird vom Auftraggeber ein detailliertes Lastenheft erstellt. Das kostet erst mal viel Zeit. Das Risiko, dass etwas vergessen oder nicht ausreichend genau formuliert wird, ist hoch. Alle Anforderungen vor Entwicklungsstart genau zu definieren, erfordert enorme Aufwände bei allen Beteiligten. Trotz aller Bemühungen ändern sich gerade bei komplexen Projekten die Anforderungen und Randbedingungen bereits während der Entwicklungszeit. Das zieht große Aufwände für die Anpassung des Lastenhefts nach sich und kann dann im Projekt-Alltagsstress und festen Deadlines gerne mal unter den Tisch fallen.

Wir beobachten in großen komplexen Projekten auch häufig die Situation, dass Mitarbeiter mit der Erstellung von Lastenheften betraut sind, die ganzheitliches prozess- und abteilungsübergreifendes Wissen haben, jedoch nicht alle technischen Details kennen. Die spezifischen Anforderungen aus der Anwender- und Betriebssicht werden dann oft nur rudimentär oder sehr spät mit einbezogen.


Ergebnis:
Wenn das Projekt "blind" entsprechend dem initialen Lastenheft (in Time und Budget) durchgeführt wird, bekommen die Anwender am Ende des Projekts eine Software, die den dann gültigen Anforderungen nicht mehr entspricht. Wird stattdessen das Lastenheft regelmäßig aktualisiert und die Entwicklung entsprechend angepasst, entsteht ein erheblicher Mehraufwand.

 

Unser leichtgewichtiger Ansatz: 

Wir entwickeln Software agil.
Dabei ist die Arbeitsannahme, dass sich Anforderungen während der Projektlaufzeit ändern.

Bei agiler Softwareentwicklung werden die Anforderungen zunächst "nur" grob aus Anwendersicht und in verständlicher Sprache erfasst (sogenannte User-Stories). Obwohl der Detailgrad der User-Stories zu Beginn gering ist, werden dennoch alle wesentlichen Anforderungen erfasst und erlauben eine kommerzielle Bewertung des Projekts. Die Verfeinerung der User-Stories erfolgt dann "just-in-time", das heißt Anforderungen für ein Feature werden jeweils erst kurz vor dessen Umsetzung detailliert erfasst.

Dadurch ergeben sich zwei Vorteile:

  1. Die Wahrscheinlichkeit, dass sich die Anforderungen für ein Feature vor dessen Implementierung noch einmal ändern, sinkt.
  2. Das aktuelle Projekt-Wissen kann in die Erstellung der detaillierten Anforderungen einfließen.

Insgesamt sinken dadurch die Aufwände für Änderungen der Anforderungen und das Projekt kann schneller und günstiger realisiert werden.

 


Wie wir Softwareprojekte vorbereiten:

  • Vor Projektstart werden mit dem Auftraggeber und den entsprechenden Mitarbeitern gemeinsam die Projektziele und Rahmenbedingungen definiert.
  • Unsere Entwickler schauen sich die Abläufe vor Ort genau an und lernen die Prozesse des Kunden in der Praxis kennen.
  • Unsere Kunden lernen uns ebenfalls kennen, und erfahren wie wir arbeiten und "ticken".
  • Kunden und deren Mitarbeiter/Anwender beschreiben die gewünschten Features aus ihrer Sicht und mit ihren Worten.
  • Gemeinsam mit unseren Projektleitern werden daraus User Stories erstellt.
  • Wir erstellen GUI-Mockups. Damit können sich die Anwender frühzeitig ein Bild von der Software machen.
  • Auf Basis der User Stories schätzen unsere Entwickler den Aufwand zur Umsetzung des Projekts und wir erstellen ein Angebot. Die Umsetzung kann dabei klassisch als Festpreisprojekt, als agiles Festpreisprojekt oder nach Aufwand erfolgen.
  • Während des gesamten Prozesses findet eine durchgängige und offene Kommunikation statt.

Was bekomme ich für mein Geld?

Damit Angebote nicht zu Makulatur werden.


"Es wird doch immer teurer, als gedacht, dann bekomme ich nicht, was ich mir vorgestellt habe und wenn in der Spezifikation eine Kleinigkeit vergessen wurde, kostet mich das gleich Unsummen." - das oder so etwas in der Art hören wir nicht selten in Gesprächen mit potentiellen Kunden.

Intransparenz und komplexe, unverständliche Angebotstexte sowie ungenaue oder lückenhafte Formulierungen von Anforderungen im Lastenheft sind einige Gründe, die Wunsch und Wirklichkeit bei Projekten voneinander trennen können. 

In Softwareentwicklungsprojekten mit klassischem Projektmanagement konzentriert sich die Kommunikation zudem häufig auf die Anfangs- (Lastenhefterstellung) und Endphase (Auslieferung). Wenn das Projekt zudem nicht kundenorientiert gemanaged wird, ist zwischen diesen beiden Phasen kommunikative Diaspora.

 

Wie wir Angebote für Softwareprojekte erstellen:

  • Wir beschreiben Features bzw. Anforderungen als sogenannte User Stories, d. h. aus Sicht der Anwender und in "klardeutsch". User Stories werden entweder direkt von den Anwendern, je nach Erfahrung mit Softwareentwicklung oder von unseren Projektleitern in Zusammenarbeit mit den Anwendern formuliert. Die User Stories sind für die Anwender immer gut zu verstehen und können dadurch überprüft werden. Klare Akzeptanzkriterien fassen für die Entwickler die wesentlichen Anforderungen zusammen.
  • In den Schätzrunden werden Aufwandsschätzungen für alle User-Stories erstellt. Die Aufwände  werden vom Entwicklungsteam geschätzt, nicht durch Manager oder Projektleiter.
  • Unsere Teams sind cross-funktional besetzt: hier sitzen Entwickler, Tester, Administratoren, Designer und Support-Mitarbeiter. Dadurch werden spätere Installations- und Pflegeaufwände frühzeitig berücksichtigt und z. B. eine gute Testbarkeit schon durch die Architektur der Software vorbereitet.
  • Wir bewerten jedes Feature mit einem Risiko-Wert und planen entsprechend dem Risiko und des Feature-Umfangs einen angemessenen Risikopuffer ein, um zu realistischen Lieferterminen zu gelangen.
  • Wir kommunizieren durchgängig mit unseren Kunden. Während des Projektverlaufs gibt es regelmäßige Feedbackrunden (sog. Sprint Reviews), Demonstrationen des aktuellen Projektstands und natürlich direktes Feedback, wenn Probleme auftauchen. So weiß der Kunde immer, wo sein Projekt gerade steht und dass er das bekommt, was er bestellt hat.

Schaffen Sie es, mein Projekt in Time und Budget umzusetzen?

You can have it good, cheap or fast. Which two of them do you want?

oder

Unmögliches wird sofort erledigt. Wunder dauern etwas länger.

 

Agile Softwareentwicklung und agiles Management beruhen auf mehreren Säulen. Eine davon ist Transparenz. Insofern sprechen wir das "Dilemma der vier Variablen" bei unseren Kunden offen an. Es beschreibt das Spannungsfeld jeden Projekts. 

Das "Teufelsquadrat" nach Sneed

 

Im "Teufelsquadrat" nach Seed ist das Dilemma der vier Variablen anschaulich dargestellt. Die konstante Fläche des Quadrats entspricht in der Abbildung der Produktivität des Entwicklerteams. Die an den Ecken notierten Ziele (Kosten, Entwicklungsdauer, Qualität und Funktionsumfang) konkurrieren um die verfügbare Produktivität. Möchte man beispielsweise den Funktionsumfang erweitern und die Entwicklungsdauer soll gleich bleiben, so führt dies zwangsweise zu höheren Kosten. 

Können oder dürfen die Kosten nicht steigen, so bleibt als "Kompensation" nur noch eine Absenkung der Qualität, die sowohl für den Auftraggeber als auch den Auftragnehmer schlecht ist.

Neben der äußeren Qualität der Software, die für Kunden noch ganz gut zu beurteilen ist, gibt es auch die sogenannte innere Qualität der Software. Diese ist für Kunden im Allgemeinen erst einmal nicht erkennbar. Sie ist aber für die Stabilität des Produkts, die Wartbarkeit, die kostengünstige Erweiterbarkeit und für die Investitionssicherheit von enormer Bedeutung.

 

Wie wir Softwareprojekte  und Kundenerwartungen managen:

  • Wir entwickeln mit der agilen Methode Scrum: Durch das iterative (schrittweise) Vorgehen können Kunden schon sehr früh und in kurzen Abständen (typischerweise zwei Wochen) den aktuellen Stand der Software ausprobieren und  testen, wie sich die geplante Umsetzung "in der Praxis" anfühlt. So wird rechtzeitig klar, ob die Entwickler die Features richtig verstanden haben. Bei Bedarf können Änderungen in diesen kurzen Phasen kostengünstiger umgesetzt werden.

    Vor Beginn der Entwicklungsphase werden die zu implementierenden Features gemeinsam mit dem Kunden, anhand des Kundennutzens und ggfls. anhand äußerer Restriktionen priorisiert. Diese Priorisierung kann im Sinne einer agilen Vorgehensweise während der Entwicklungsphase entsprechend dem Projektstand und des dann zur Verfügung stehenden Wissens angepasst werden. Dies erfordert neben dem agilen Projektmanagement eine entsprechende Softwarearchitektur und eine agile Entwicklungsmethodik, die die zeitlichen Änderungen bzgl. der Implementierung einzelner Features unterstützt.

    Somit ist es möglich Projekte in Time und Budget bei variabel gehaltenem Funktionsumfang fertig zu stellen. Essentiell dabei ist, dass die Features entsprechend ihrer Wichtigkeit (Kundennutzen und äußere Randbedingungen) implementiert werden.

    Bei dieser Art zu Entwickeln legen wir ein sehr hohes Maß an Transparenz an den Tag. Bei klassisch durchgeführten Festpreisprojekten existiert diese Transparenz nicht. Zudem muss der Auftragnehmer mit ausreichend Sicherheitspuffern agieren, wenn die innere und äußere Qualität der Software bei eintretenden Unwägbarkeiten und Mehraufwand durch unterschiedliche Interpretationen des Lastenhefts nicht reduziert werden sollen.  
  • Wir entwickeln testgestützt. Von Anfang an werden automatisierte Tests eingeführt. Dadurch steigt nicht nur die Gesamtqualität der entwickelten Software (zu vergleichbaren oder sogar niedrigeren Entwicklungskosten), sondern es steigt auch die Wartbarkeit. Aufwände für Erweiterungen fallen deutlich geringer aus.

    Automatisierte Tests werden dabei auf verschiedenen Abstraktionsebenen durchgeführt: von Unit-Tests, die die korrekte Funktion kleiner Software-Module (Units) sicherstellen, über Integrationstests, die das Zusammenspiel verschiedener Komponenten überprüfen, bis hin zu Akzeptanztests, die die Korrektheit der Anwendung aus Nutzersicht überprüfen. Akzeptanztests werden dabei so formuliert (z. B. als Excel-Tabelle oder HTML-Seite), dass auch Anwender ohne tiefgehende Informatikkenntnisse prüfen können, ob die Tests dem erwarteten Verhalten entsprechen.
  • Wir implementieren Kontinuierliche Integration: bei uns werden alle Projekte rund um die Uhr mit einem sogenannten Continuous Integration Server (Jenkins) überwacht. Dieser kompiliert den Quellcode nach jeder Änderung, stellt sicher, dass der Code allen Qualitätsanforderungen entspricht und führt die automatisierten Tests durch. Zusätzlich ist dadurch die vollautomatische Erstellung von Software-Releases möglich. Manuelle Fehler beim Erstellen der Installationspakete werden dadurch ausgeschlossen.

Wie kann ich sehen, wie es in meinem Projekt steht?

Was mein Softwareprojekt gerade macht? - keine Ahnung!

In Softwareentwicklungsprojekten mit klassischem Projektmanagement konzentriert sich die Kommunikation häufig auf die Anfangs- (Lastenhefterstellung) und Endphase (Auslieferung). Wenn das Projekt nicht kundenorientiert  gemanagt wird, herrscht zudem zwischen diesen beiden Phasen kommunikative Diaspora.

Wie wir Projekte für unsere Kunden transparent machen:

  • Sie haben auf Wunsch direkten Zugriff auf unser Projektplanungs- und Issue-Tracking System Jira. Dort können Sie live und im Detail sehen, wie die Entwickler Aufgaben angehen und abschließen, offene Punkte diskutieren sowie Fehler aufnehmen und beheben. Außerdem können Sie beobachten wie der Gesamtfortschritt des Projekts gegenüber dem Plan ist und wie viel Zeit/Aufwand in die einzelnen Features investiert wurde.
  • Sie erhalten einen Wochenbericht als Zusammenfassung der wöchentlichen Arbeit des Entwicklungsteams: erledigte Aufgaben, Projektfortschritt, aufgetretene Schwierigkeiten, benötigte Zeit im Vergleich zur ursprünglichen Schätzung, ...
  • Wir führen Ihnen regelmäßig den aktuellen Entwicklungsstand in den Sprint-Reviews (typischerweise alle zwei oder drei Wochen) vor.
  • Die agile Vorgehensweise erlaubt die Anpassung von Priorität und Inhalt von Entwicklungspaketen bei jedem Sprintwechsel.
  • Auf Wunsch (auch remote) können Sie an den täglichen Projekt-Meetings (Daily-Standups; Dauer: ca. 10 Minuten) teilnehmen.


In unseren Projekten setzen wir folgende Kollaboration-Tools ein:

  • Jira
  • Confluence
  • Git
  • Instant Messenger
  • E-Mail / Telefon / Video-Konferenzen
  • Remote-Desktop Zugriff

 

Wie sieht mein Projektteam aus?

Zeige dein Gesicht, wenn du Geschäfte machen willst
chin. Sprichwort

 

Häufig kennen Kunden nur 2-3 Gesichter des Auftragnehmers. Die Leute dahinter, die die eigentliche Arbeit machen, kennt der Kunde nicht. Auftraggeber wollen mit echten Menschen kommunizieren, nicht mit anonymen Abteilungen. 

 

Wie unsere Projektteams aussehen und arbeiten:

  • Unsere Teams sind cross-funktional besetzt: Hier arbeiten Entwickler, Architekten, Tester, Administratoren, Designer und Support-Mitarbeiter zusammen.
  • Im Rahmen unserer agilen Arbeitsweise besteht für unsere Kunden die Möglichkeit, das Team, das für sie arbeitet, kennenzulernen: Vertreter des  Kunden können an allen Scrum-Meetings (außer der Retrospektive) teilnehmen (dies geht auch remote) und somit einen sehr direkten Einblick in die Arbeitsweise des Teams werfen. Unsere Entwickler kommen auch gerne zum Kunden ins Unternehmen, um Abläufe, Hintergründe und Randbedingungen besser verstehen zu können.
  • Der Kunde wird bei einer agilen Softwareentwicklung ins Team eingebunden: Als sogenannter Product-Owner repräsentiert ein Mitarbeiter / Projektleiter des Kunden die Kundenwünsche gegenüber dem Entwicklungsteam und ist Ansprechpartner des Teams für alle fachlichen Fragen. Alternativ wird die Rolle des Product-Owner durch einen Projektleiter in unserem Haus wahrgenommen und bildet dann die Schnittstelle zum Projektleiter auf der Kundenseite.

Kann ich sicher sein, dass State of the Art Technologien eingesetzt werden?

Nichts ist so alt, wie die Software von gestern.

 

Wenn ich als Kunde Geld in die Hand nehme, um Software entwickeln zu lassen, möchte ich natürlich auch sicher sein, dass diese „State of the Art“ ist. Zudem möchte ich als Kunde, dass mein Geld effizient eingesetzt wird, dass also bei der Entwicklung strukturiert vorgegangen wird, dass Qualität von Anfang an im Fokus ist und dass keine unnötigen Aufwände entstehen. Dies kann durch den Einsatz von geeigneten und aktuellen Tools, die die Entwicklung erleichtern und Qualität verbessern und somit Zeit und Geld sparen, gewährleistet werden. 

 

Wir führen regelmäßig sogenannte Innovation Days durch. An diesen Tagen werden unsere Entwickler von der Projektarbeit und dem Tagesgeschäft freigestellt und können die Zeit nutzen, um sich mit neuartigen Technologien, Tools, Bibliotheken, Open Source-Produkten etc. zu beschäftigen und deren Tauglichkeit zu prüfen. Dadurch ist sichergestellt, dass wir immer vorne mit schwimmen. 

 

Zur Zeit nutzen wir zur Entwicklung unter anderem folgende Sprachen und Frameworks:

 

Im Java-Bereich:

  • JavaEE
  • Spring
  • JSF
  • PrimeFaces
  • GWT
  • Maven

 

Im C/C++-Umfeld:

  • C++11
  • STL
  • Boost
  • OpenCL
  • CMake

 

Zusätzlich setzen wir folgende Lösungen zur Optimierung des Projektablaufs und zur Qualitätssicherung ein:

  • Git: Verteilte Versionsverwaltung und Konfigurationsmanagement
  • Liquibase: Versionierung von Datenbankschemas und Verwaltung von Testdaten
  • Automatisierte Tests: Unit Tests, Integration Tests, Akzeptanztests
  • Statische Analyse: Sonar, cppcheck
  • Laufzeitanalyse (Profiling und Memory-Leaks): Valgrind
  • Interne Projektdokumentation: Confluence



Wie kann ich mein Projekt kontrollieren

Nichts ist so alt, wie der Projektstand von gestern.

 

Bei uns haben Sie jederzeit den aktuellen (tatsächlichen!) Projektstand im Blick:

  • Jira
    Sie haben auf Wunsch direkten Zugriff auf unser Projektplanungs- und Issue-Tracking System Jira. Dort können Sie live im Detail sehen, wie die Entwickler Aufgaben angehen und abschließen, Offene Punkte diskutieren sowie Fehler aufnehmen und beheben. Außerdem können Sie beobachten wie der Gesamtfortschritt den Projekts gegenüber dem Plan ist und wie viel Zeit / Aufwand in die einzelnen Features investiert wurde.
  • Teilnahme an den Entwicklungsmeetings 
    Im Sinne der agilen Softwareentwicklungsmethode Scrum können Kunden an allen Scrum-Meetings (außer der Retrospektive) teilnehmen und so einen sehr direkten Einblick in die Fortschritte haben. Wir empfehlen und begrüßen die Teilnahme (in persona oder auch remote) an den sogenannten Sprint-Reviews, an denen neue Funktionalität vorgeführt wird, die dann auch vom Kunden unmittelbar beurteilt werden kann. Gleichzeitig bietet sich den Entwicklern die Möglichkeit, bei Verständnisfragen schnellstmöglich kompetente Antworten aus erster Hand zu erhalten.

  • Remote-Desktop Zugriff
    Sollten Sie nicht in der Lage sein, vor Ort an den Sprint-Reviews teilnehmen zu können, bieten wir Ihnen auch gerne die Möglichkeit, remote teilzunehmen. Den aktuellen Stand der Implementierung führen Ihnen unsere Entwickler in diesem Fall gerne über das Internet vor.

 

 

Arbeiten Sie mit Near- oder Offshore-Partnern?

Kurz und bündig:

Offshore: nein.

Nearshore: Bei Bedarf - ja.

Lang und breit:

Ein Hauptproblem in der Zusammenarbeit mit Offshore-Partnern ist aus unserer Sicht der Umstand, dass es häufig in anderen Kulturen dem Höflichkeitsempfinden widerspricht, Probleme direkt und unverblümt anzusprechen. Damit einher geht, dass sich Offshore Partner oft schwer tun, Probleme im Projekt proaktiv zu melden. Ein weiteres Problem besteht unserer Meinung nach darin, dass unterschiedliches Hierarchiedenken eine große Rolle spielt, wodurch häufig Projektleiter auf Offshore-Partner Seite eine zu dominante Rolle spielen und die Spezialisten ihr technisches und fachliches Know-how nur unzureichend in die Projektarbeit einbringen können. 

Wir sehen daher die Zusammenarbeit mit Offshore-Partnern eher kritisch.

 

Wenn wir unsere Teams verstärken wollen oder müssen, dann brauchen wir Partner, die agil und testgestützt auf hohem Niveau entwickeln können und es gewohnt sind, ein hohes Maß an Transparenz zu leben. Denn nur so ist es uns möglich, für den Projekterfolg und die von uns gemachten Zusagen gegenüber unseren Kunden gerade zu stehen. Derartige Partner  - Nearshore Partner - haben wir in den letzten Jahren gefunden: In Polen, in Portugal und in der Ukraine.

Warum testgestützte Softwareentwicklung?

Die Qualität und Wartbarkeit von Software steht und fällt mit einer guten Testabdeckung.

Automatisierte Tests

Ohne automatisierte Tests besteht - insbesondere bei gewachsenen Projekten - die Gefahr, mit Änderungen an einer Stelle Fehler an anderen Stellen zu bewirken, die auf den ersten Blick nichts mehr mit der Änderung zu tun haben. Ohne Codepflege durch sogenannte Refactorings nimmt die innere Qualität  des Codes mit der Zeit immer mehr ab und damit wird die Gefahr des Einschleichens neuer Fehler ständig größer. Dies geht soweit, dass die Implementierung neuer Features oder das Beheben von bekannten Fehlern gar nicht mehr mit vertretbaren Aufwand möglich sind, da niemand mehr den komplexen, über die Zeit verwucherten Code vollständig versteht.

Ein "Sicherheitsnetz" von automatisierten Tests erlaubt es den Entwicklern hingegen, die innere Qualität des Codes durch Refactorings ständig auf einem hohen Niveau zu halten. Erfolgreich durchlaufene Tests nach einer Änderung geben den Entwicklern positives Feedback und ermutigen sie damit zur Erhaltung einer guten Qualität: die Entwickler sind stolz auf ihre Ergebnisse. Falls durch eine Änderung Fehler eingeführt werden, werden diese in der Regel durch die automatischen Tests schnell entdeckt und können kann zeitnah und ohne große Suchaufwände behoben werden.

Die einfache, automatische Ausführung auch umfangreicher Testsuiten erleichtert - insbesondere im Zusammenhang mit agilen Entwicklungsmethoden - regelmäßige und auch sehr kurzfristige Releases an den Kunden, ohne dass die gelieferte Qualität darunter leiden würde.


Testgestriebene Softwareentwicklung (TDD)

Die Methode der testgetriebenen Entwicklung geht soweit, den gewohnten Entwicklungsprozess auf den Kopf zu stellen. Hier geht man in äußerst kurzen Zyklen - überlicherweise nur wenige Minuten - vor:

  • Zunächst wird ein Test für die zu entwickelnde Funktionalität geschrieben. Dieser schlägt natürlich erst einmal fehl, da noch gar keine Implementierung vorliegt.
  • Erst im zweiten Schritt wird so lange programmiert, bis der Test erfolgreich durchläuft.
  • Danach wird die Qualität des gerade geschriebenen Codes durch ein Refactoring auf das geforderte Niveau gehoben, ohne die Funktionalität zu verändern.


Diese iterative Vorgehensweise führt gleichermaßen zu einer extrem hohen Testabdeckung (es wird kein Code geschrieben, der nicht durch Tests abgedeckt wäre) als auch durch die ständigen Refactorings zu einer gleichbleibend guten Code-Qualität und Wartbarkeit.

In leicht abgewandelter Form lässt sich testgetriebene Entwicklung sogar in existierenden Projekten mit geringer Testabdeckung einsetzen, um bei Änderungen Schritt für Schritt die Testabdeckung zu erhöhen ohne die Umsetzung neuer Features zu stark auszubremsen.
 

Im praktischen Einsatz

Die Softwareentwicklung bei consistec setzt in einem testzentrierten Entwicklungsprozess auf allen Ebenen durchgehend auf eine hohe Testabdeckung.
Dies beginnt auf der Ebene von Unit-Tests für die verschiedenen Programmiersprachen (JUnit für Java, Google Test für C / C++, DbUnit für Datenbankanwendungen, ...), über automatische Werkzeuge zur Überwachung der Code-Qualität (Sonar, cppcheck, Valgrind, ...) bis hin zu automatisierten Ende-zu-Ende Tests (Selenium für Web-Anwendungen, Dogtail oder LDTP für C++ GUI-Anwendungen, ...).
Die Test-Suiten werden dabei automatisch nach jeder Source-Code Änderung auf einem sogenannten Continuous Integration Server ausgeführt, um sicher zu stellen, dass die Testfälle ebenso wie die Anforderungen an die Code-Qualität ständig erfüllt sind.
Und zwar auf allen unterstützten Plattformen, nicht nur auf dem Rechner des jeweiligen Entwicklers.

Was bedeutet agile Softwareentwicklung?

Agile Softwareentwicklung

Agile Entwicklungsmethoden sind die perfekte Lösung für ein häufig bei der Entwicklung von (Software-)Projekten auftretendes Problem: Die Tatsache, dass sich die Anforderungen zukünftiger Nutzer an eine neue Software nur sehr schwer im Voraus detailliert erfassen lassen und sich deren Wünsche und Prioritäten demzufolge oftmals während des Projekts stark ändern.

Klassische Entwicklungsmethoden, bei denen alle Details zu Beginn verbindlich festgelegt werden, stoßen angesichts dieser Dynamik schnell an ihre Grenzen. Das Ergebnis: Projektmanager versuchen häufig, die Realität an ihre Planung anzupassen; eine nicht ganz triviale Aufgabe ...

Bei agilen Entwicklungsmethoden hingegen steht die ständige Abgleichung der Entwicklung mit den Kundenwünschen im Mittelpunkt. Beim sogenannten "Inspect and adapt" wird in kurzen Abständen überprüft, ob Optimierungsmöglichkeiten im Vorgehen, bei der Priorisierung oder Ausgestaltung von Features bestehen (inspect) und bei Bedarf wird das Vorgehen angepasst (adapt).

Die starke Integration automatisierter Tests und eine gleichbleibend hohe innere Code-Qualität sind dabei Voraussetzung und Garant für die flexible Anpassung des Codes an sich ändernde Anforderungen.


Scrum

consistec setzt zur agilen Entwicklung die Scrum-Methode ein. Sie gibt Entwicklern und Kunden einen flexiblen Rahmen zur Umsetzung der agilen Ideen an die Hand.

Es existieren drei Rollen:

  • Das Entwicklungs-Team: in der Regel etwa fünf bis sieben Entwickler, die sich selbst organisieren. Durch die Selbstorganisation entsteht im Team ein hohes Verantwortungsbewusstsein für die Qualität der entwickelten Software.
  • Product Owner: ein Vertreter des Kunden, der dem Entwicklungsteam gegenüber Fragen zu den gewünschten Features beantwortet und diese priorisiert.
  • Scrum Master: Der Scrum Master moderiert die Abläufe im Scrum-Prozess und entlastet das Entwicklungsteam von entwicklungsfremden Aufgaben (Beschaffung von Infrastruktur, ...)


Die Entwicklung erfolgt in sogenannten Sprints. Dabei handelt es sich um feste, relativ kurze Zeitintervalle (in der Regel zwei bis drei Wochen). Zu Beginn des Sprints plant das Team, wie viele Features es im nächsten Sprint umsetzen kann (die Priorisierung gibt der Product Owner vor) und verpflichtet sich dann zur vollständigen Lieferung dieser Features in einer vorgegebenen Qualität pünktlich zum Sprintende. Qualität ist bei Scrum nicht verhandelbar und wird in der sogenannten Definition of Done festgelegt.

Der fixe zeitliche Rahmen bietet dem Entwicklungsteam eine stabile Basis für die Entwicklung der abgesprochenen Features, ohne ständige Richtungswechsel, und erlaubt gleichzeitig nach jedem Sprint eine flexible Anpassung des weiteren Vorgehens.

Einer der großen Vorteile für den Kunden besteht darin, dass die Software nach jedem Sprint in einem auslieferbaren Zustand ist.

Dadurch können die wichtigsten Features - diese werden ja nach ihrer Priorisierung zuerst umgesetzt - bereits in einem sehr frühen Stadium des Projekts produktiv eingesetzt werden. Ein extrem früher Return on Investment ist damit garantiert. Zusätzlich kann die Software im realen Einsatz evaluiert und so die wirklich wichtigen Features frühzeitig identifiziert werden.

Intern realisieren wir alle Software-Entwicklungsprojekte mit testgestützten agilen Methoden, unabhängig davon, ob Sie uns auf Festpreisbasis oder auf Basis eines agilen Ansatzes beauftragen wollen.

Lassen auch Sie sich von den Vorteilen agiler Software-Entwicklung überzeugen.

Icon Partner im Software-Cluster

„Wenn man Scrum nach Lehrbuch im Unternehmen einführt, stößt man auf viele offene Fragen und Probleme, die auch in den gängigen Scrum-Schulungen nicht abschließend behandelt werden. In consistec haben wir einen Partner gefunden, der uns unterstützt hat, die notwendigen handwerklichen und organisatorischen Aufgaben zu lösen, die entsprechenden fachlichen und technischen Rahmenbedingungen zu schaffen und durch aktive und moderierende Begleitung des Change-Managements möglichst viele Unternehmensebenen erfolgreich einzubinden. Mit Hilfe von consistec haben wir einen Weg gefunden, unsere eigene agile Vorgehensweise in der Softwareentwicklung erfolgreich etablieren zu können.“

Ralph Dornis,
Leiter Projektmanagement,
e.Consult AG

Logos