Entwicklungsprozess bei codemacher

Vielleicht haben Sie als Kunde mit Software-Projekten bisher nur gute Erfahrungen gemacht. Das spräche für Sie und für die beauftragte Firma und ist durchaus nicht selbstverständlich. Ein wenig Glück kann natürlich auch nicht schaden, allerdings muss man nicht ausschließlich darauf vertrauen.

Eine individuelle Software-Entwicklung ist eine Einzelanfertigung. Also keine fertige Schrankwand aus dem Möbelgeschäft, sondern die Anfertigung vom Tischler, speziell für Ihr Zimmer mit Dachschräge, mit speziellen Maßen und Materialien, mit zugelieferter Beleuchtung für die Vitrine, mit ein paar Änderungswünschen für die Schubläden während des Einbaus.

Dass derartige Anfertigungen schwieriger zu planen sind als Standardinstallationen, liegt auf der Hand. Bei Software kommt noch hinzu, dass die Problemstellungen häufig abstrakt sind. Um im Bild zu bleiben: wir reden also nicht nur von greifbaren Dingen wie Türen, Beschlägen oder Griffen, sondern auch von Benutzerkonten, Zugriffsrechten oder Geschäftsabläufen, also mit Begriffen, die mehr Interpretationsspielraum lassen und damit erstklassige Vorlagen für Missverständnisse darstellen.

Theoretisch können entsprechende Fehlentwicklungen natürlich beseitigt werden. Praktisch ist diese Möglichkeit durch den Preis und durch die verbleibende Zeit begrenzt – niemand möchte die Mehrkosten tragen, Termine können nicht beliebig verschoben werden. Manchmal können Fehlentwicklungen nicht einmal rechtzeitig erkannt werden - als Kunde können Sie bei Fertigstellung Ihrer Web-Lagerverwaltung kaum beurteilen, wie diese Software dann funktionieren wird, wenn wirklich einmal hundert Leute damit arbeiten und nicht nur Sie allein bei der Probe.

Die agilen Vorgehensmodelle (z.B. Scrum) versuchen, den Entwicklungsprozess sowohl für Kunden als auch Entwickler praxistauglich zu gestalten. Scrum will Änderungswünsche berücksichtigen können, Fehlentwicklungen vermeiden, Termine und finanzielle Grenzen einhalten, Qualität sichern. Wir bei codemacher interpretieren Scrum in einer für uns passenden Weise. Die gesamte Entwicklungszeit wird von uns in Phasen von zweiwöchentlicher Länge unterteilt. Alle zwei Wochen wird eine Zwischenbilanz gezogen. Was ist fertig? Was fehlt? Was liefern wir dem Kunden zur Ansicht? Welche Prioritäten sind für die nächste Phase zu setzen?

Im Folgenden finden Sie ein paar Aspekte unserer Arbeitsweise näher beleuchtet.

Missverständnisse? Zwischen dem Kunden und uns, zwischen uns Entwicklern, Testern, einfach zwischen Menschen. Und das ist keineswegs nur das Ergebnis von Nachlässigkeit. Jeder Mensch interpretiert eine Aussage eben vor dem Hintergrund seiner eigenen Erfahrung. Die Abstraktheit von Software macht die Sache noch schwieriger.

Unsere Gegenmittel:

1. Häufige (meist zweiwöchentliche) Zwischenergebnisse in Form von lauffähiger Software. Dazu brauchen wir dann die Reaktion des Kunden – mit einiger Wahrscheinlichkeit fällt so ein eventuelles Missverständnis sehr zeitig auf, so dass wir die Entwicklungsrichtung noch ändern können.
2. Bedarfsweise: Prototypen. Ein Prototyp besteht z.B. aus einer Folge von Bildschirmansichten, die einen ganz speziellen Ablauf im Programm darstellen (“Klick-Dummy”). Er kann mit wesentlich geringerem Aufwand erstellt werden als die entsprechende Software, das Interaktionserlebnis ist für den Kunden aber ähnlich.

Keine Software ist perfekt. Aber wir geben uns Mühe (auch wenn das im Beurteilungsjargon ein niederschmetterndes Urteil ist). Für kleine Programmteile schreiben wir automatische Tests (UnitTests), wo sie angemessen und machbar sind. Und wir testen die Software manuell. Das heißt, es drückt nicht nur der Entwickler selbst einmal auf den Knopf, sondern bei uns wird eine Funktionalität von einer anderen Person getestet, mit verschiedenen Daten, mit verschiedenen Browsern entsprechend den Anforderungen. Eine Funktionalität ist also nicht “fast fertig” oder “fertig bis auf den Test”, sondern fertig. Zumindest nach bestem Wissen.

werden von uns eher vorsichtig geschätzt - inklusive Herbsterkältung, Spontanurlaub und den Realitätszuschlagsfaktor X. Wir messen unsere Geschwindigkeit. Durch die Zerlegung des Projektverlaufes in zweiwöchentliche Phasen können wir dann hochrechnen und beurteilen, wann wir insgesamt fertig sein werden. Durch die Erfahrung über die Jahre konnten wir damit unsere Schätzungen verbessern. Es gibt Fehleinschätzungen, aber sie werden seltener.

Wieviel kostet was? Hier die wichtigsten Herangehensweisen:

1. Sie als Kunde fixieren die Funktionalität und wir sagen, wieviel das kostet.
2. Sie als Kunde fixieren den Preis und wir schauen dann, welche Funktionalität dafür machbar ist.
3. Wenn Sie nur eine Größenordnung statt eines detaillierten Angebots haben möchten, dann nennen wir Ihnen einen Preisrahmen. Der kann allerdings relativ ungenau sein, je nachdem, wie genau Ihre Vorstellungen schon sind. Beispiel: 10 Tausend bis 20 Tausend statt 16.400

Häufig können wir nicht ohne Weiteres ein detailliertes Angebot aus der Tasche ziehen. Ihre individuelle Software kann nicht durch ein Pauschalangebot beschrieben werden. Manchmal bietet sich dazu eine...

an. Wir besprechen mit Ihnen die Anforderungen. Welche Nutzer gibt es, welche Rollen, welche Randbedingungen müssen beachtet werden? Das kostet natürlich ein paar Tage Zeit und damit kostet es Geld. Aber es lohnt sich. Nicht selten ist ein verbindliches Angebot für die eigentliche Entwicklung erst nach dieser Konzeption möglich.

Wir schreiben Ihnen hier kein Fazit vor. Sie dürfen selbst entscheiden, welche Erkenntnisse Sie aus diesem Artikel entnehmen. (und welcher Firma Sie Ihr Vertrauen schenken ;-)