Von der Idee zum fertigen Produkt
Starten Sie ihr Projekt noch heute und erhalten Sie in kurzer Zeit ein Angebot, das die Entwicklung aller nötigen Anwendungsfälle abdeckt und trotzdem flexibel genug ist, agile Entwicklungsmethoden zu verwenden. Wie das geht, erklären wir Ihnen kurz an dieser Stelle.
Die Beauftragung einer Entwicklung für Individualsoftware ist kein leichtes Unterfangen. Oft existiert nur eine grobe Vorstellung von dem, was die Software einmal können soll, und Zeit für die Ausarbeitung einer detaillierten Spezifikation fehlt. Trotzdem möchten Sie gerne loslegen, die Entwicklung vorantreiben und zudem die Kosten im Auge behalten. Wir empfehlen das Projekt mindestens in 3 Phasen aufzuteilen.
Projektphase 1
Erfassen und Sammeln der Anforderungen
Um eine qualifiziertes Angebot abgeben zu können müssen wir zunächst einmal erfassen, was zu tun ist und welchen Funktionsumfang das Produkt haben soll. Wir nutzen dafür gerne Anforderungsworkshops, analysieren die aktuelle Situation, lassen uns bestehende Prozesse erklären und versuchen zu verstehen wo aktuell die Probleme liegen. Idealerweise haben Sie auch schon eine eigene Vorstellung, oder sogar ein grobes Konzept darüber, wie die Anwendung aussehen soll. Aus der Summe dieser Informationen entwickeln wir ein grobes Bild über Aufbau und Funktionsumfang der Applikation.
Projektphase 2
Angebot und Vertrag
Auf Basis der erarbeiteten Anforderungen führen wir eine Grobschätzung durch und erstellen Ihnen ein Angebot.
Sagt Ihnen das Angebot zu, machen wir uns gemeinsam an die Ausarbeitung des Vertrags. Im Idealfall haben Sie mittlerweile so viel Vertrauen in unsere Arbeitsweise, dass wir uns auf einen einfachen Dienstleistungsvertrag im Umfang des Angebots einigen könnnen, aber auch ein Werksvertrag auf Basis des Grobkonzepts ist denkbar. Wir versprechen Ihnen in jedem Fall, dass die Software am Ende den Umfang haben wird, den Sie festgelegt haben.
Projektphase 3
Umsetzung
Jetzt, da wir uns einigen konnten und es zum Vertragsschluss kam, können wir endlich loslegen. Dazu nehmen wir uns das erste Arbeitspaket vor, teilen dies ggf. noch in weitere kleinere Arbeitspakete auf und verteilen die veranschlagte Zeit auf diese kleineren Pakete.
Dann geht es daran, die Spezifikation in Form eines Backlogs mit Tickets (User-Stories/Anforderungen) für das zu bearbeitende Arbeitspaket zu befüllen. Dabei wird jetzt möglichst genau spezifiziert, welche Funktionen die Software an dieser Stelle zur Verfügung stellen muss. Herrscht Einverständnis zwischen Ihnen als Product Owner und uns als Product Manager, dass alle Anforderungen erfasst sind, bewertet unser Entwicklungsteam jedes einzelne Ticket und gibt eine Schätzung ab, wie lange die Bearbeitung der Tickets dauern wird. Idealerweise liegt die Summe aller Zeiten aller Tickets des Arbeitspakets unter der verfügbaren Zeit, so dass noch Luft bleibt für sich ändernde Anforderungen. Liegt die neue Schätzung über dem Budget, so müssen Aufwandstreiber identifiziert werden.
Oft reicht es nun, das ein oder andere Feature ein klein wenig anders zu gestalten, um den Entwicklungsaufwand zu senken, oder es gibt Tickets, deren Umsetzung zwar schön wäre, die die Funktionaltät der Software aber nicht wesentlich verbessern. Diese Tickets können in einem ersten Schritt wegpriorisiert werden. Sie wandern in einen Pool mit "Nice-To-Have-Features", welche umgesetzt werden, falls am Ende Zeit übrig bleibt. Sobald der geschätzte Aufwand für die umzusetzenden Tickets unter der Budgetgrenze liegt, wird dieses Arbeitspaket implementiert.
Während der Implementierung können Sie durch unser ausgefeiltes Projektmonitoring jederzeit sehen, wo wir uns befinden, ob Termine gehalten werden können und somit auch das Budget ausreichen wird. Sie erhalten ca. alle zwei bis vier Wochen eine lauffähige Version Ihrer Software, damit Sie sich die neuesten Features ansehen können und Änderungswünsche früh einsteuern können. Führen Änderungswünsche zu einer Überschreitung des Budgets, so muss eine weitere Priorisierung stattfinden. Dadurch wird gewährleistet, dass der Rahmen niemals gesprengt wird.
Mit diesem Vorgehen werden nach und nach alle Arbeitspakete abgearbeitet, bis Sie am Ende das fertige Softwareprodukt in den Händen halten.
Projektphase 4 (optional)
Wartung
Wir stehen Ihnen auch nach Abschluß der Entwicklung weiterhin zur Verfügung. Oft treten im Produktivbetrieb noch Wünsche auf, die eine Erweiterung der Software erforderlich machen. Diese Erweiterungen können im Rahmen eines Wartungsvertrags bequem und vor allem schnell durchgeführt werden. Die Gestaltung des Wartungsvertrags ist von Projekt zu Projekt verschieden. Wir bieten hier sehr flexible Vertragsmodelle, die für beide Parteien die ideale Lösung darstellen.
Kommunikation als Basis für eine erfolgreiche Zusammenarbeit
Gleich zu Beginn eines Software-Projekts zu wissen, was genau das Produkt, wie und in welchem Umfang, am Ende leisten soll - Mission Impossible.
Deshalb ist es für uns umso wichtiger, für Sie geeignete Kanäle und eine optimale Plattform für die Kommunikation Ihrer Belange herzustellen. Unser Ticket-System (Jira) erlaubt es Ihnen möglichst einfach Änderungswünsche, Bugs (sofern sie auftreten) oder neue Anforderungen anzulegen und den Fortschritt des Projekts zu beobachten.
Im Gegenzug informieren wir Sie regelmäßig über den Fortschritt des Projekts. Auch wenn etwas schneller fertig ist oder einmal länger dauert als geplant, können Sie rechtzeitig eingreifen und beispielsweise den Funktionsumfang einer Anforderung erweitern oder schmälern.
Immer in Ihrer Nähe
Meeting? Und zwar alle am gleichen Platz?
Möglich, aber nicht unbedingt notwendig.
Auch wenn wir persönliche Treffen ausgesprochen schätzen, sind wir dazu übergegangen, die meisten unserer Reviews, Präsentationen, Feedback-Runden usw. virtuell abzuhalten. Online-Meeting-Tools wie Microsoft Teams ermöglichen es uns, Treffen mit Video, Ton und Bildschirmübertragung an (fast) jedem Ort der Welt abzuhalten. Das schont Ressourcen!
Rock Solid Development
Agilität, Kommunikation, Transparenz, ... das klingt alles schön und gut, aber am Ende des Tages zählt doch nur eins: Ihre Software muss einwandfrei funktionieren. Was hilft Ihnen ein hochmodernes Vorgehensmodell, das Änderungen willkommen heißt und Kundenorientierung in den Vordergrund stellt, wenn jedes neu implementierte Feature nur halbwegs richtig implementiert ist und zu Fehlern in bereits implementierten Funktionen führt?
Deswegen stellen wir bei der iXTS GmbH unseren Entwicklungsprozess auf drei starke Säulen:
- Clean Code Development
Die Regeln des CCD umfassen alle wichtigen Prinzipien und alle "Lessons Learned" der vergangenen Jahrzehnte in elf "Tugenden". Diese transportieren z.B. Werte wie Evolvierbarkeit, kontinuierliche Verbesserung, Produktionseffizienz, Korrektheit usw.
- Test Driven Development und Test Automation
Wird heutzutage ein neues Auto entworfen, werden Crash-Tests am Computer simuliert, noch bevor der erste Prototyp eines Chassis gebaut wurde. Auf diese Weise werden die Risiken einer Fehlentwicklung minimiert.Ähnlich sorgfältig schreiben wir den Code für Ihre Software. Wir implementieren automatisierbare White-Box-Tests, schon bevor wir eine einzige Zeile des Produktiv-Codes schreiben. So können wir zu jeder Zeit sicherstellen, dass Änderungen an egal welcher Stelle im Code die Korrektheit des Gesamtsystems nicht verletzen.
- Continuous Deployment
White-Box- bzw. Unit-Tests sind schön und gut, aber komplexe Systeme bestehen meist aus vielen, oft sogar verteilten Komponenten, Diensten etc. Um diese vernünftig und automatisiert testen zu können, müssen sie sich in einer Staging-Umgebung befinden.
Deshalb wird bei jeder von uns vorgenommen Änderung die Software automatisch neu kompiliert und nachdem alle automatisierten Tests erfolgreich waren auf die Staging-Umgebung veröffentlicht. Dort können Sie sich dann auch selbst ein Bild vom aktuellen Fortschritt Ihres Projekts machen.
Die iXTS Toolchain
In unserem Entwicklungsprozess führt jede Änderung (Commit) eines Programmierers zum Anstoß des Kompilierungsprozesses im Build-Server. Dieser führt alle automatisierten Unit-Tests aus und meldet dem Team eventuelle Fehler.
Die Fortschritte in der Implementierung werden von den Entwicklern im Issue-Tracking System Jira dokumentiert und vom Projektmanager überwacht. Dieser sorgt auch für die Pflege der nicht automatisierten Zephyr-Tests im Testkatalog.
In bestimmten Intervallen - in der Regel jede Nacht - liefert der Build-Server den aktuellen Stand der Software automatisch auf die Staging Umgebung aus (Nightly-Build).
Maßgeschneiderte Transparenz
In die Entwicklung Ihres Produkts möchten wir Sie, so gut es geht, einbeziehen - natürlich nicht ganz ohne Eigennutz. Durch regelmäßige Präsentationen und Feedback-Runden sind wir bestrebt das Risiko einer Fehlentwicklungen zu eliminieren, schon bevor es entsteht.
Dennoch kann Transparenz ein sehr individuelles Kriterium sein und liegt meist im Auge des Betrachters. Wo sich die einen tägliche Statusupdates und kurze Kommunikationswege wünschen, bevorzugen andere seltenere, aber dafür sehr prägnante Reports. Wie Sie sich auch entscheiden, wir bieten Ihnen volle Transparenz, ganz nach Ihrem Maß.
Probieren geht über Studieren
Mit dem Abschluss einer jeden Version stellen wir Ihnen einen funktionsfähigen Prototyp Ihres Produkts zur Verfügung. So können Sie am besten einschätzen, ob wir uns auf dem richtigen Weg befinden, ob das Look & Feel Ihren Vorstellungen entspricht, oder ob gewisse Funktionen noch fehlen oder gar nicht gebraucht werden.
Bilder sagen mehr als tausend Worte
Wie verläuft die Implementierung der aktuellen Version? Gibt es Schwierigkeiten?
Ist Funktion X schon implementiert?
Wie liegen wir in der Zeit / im Budget?
Für solche Fragen geben wir Ihnen eine Reihe von Diagrammen an die Hand, die prägnanter sind als jeder Report.
Leichtgewichtig, aber nicht leichtsinnig
Agilität. Ein Wort, das heutzutage schon fast inflationär gebraucht, aber leider viel zu selten ernst genommen wird.
Als Softwarehersteller agil zu sein bedeutet für uns, die Natur der Software-Entwicklung zu respektieren, denn Softwareprojekte verlangen eine kontinuierliche Planung und Retrospektive, sowie eine enge partnerschaftliche Zusammenarbeit mit dem Kunden.
Wo andere Unternehmen versuchen, möglichst mit dem Strom zu schwimmen und sich Methoden wie Scrum oder Extreme Programming aufzwängen, respektieren wir die Grundsätze agiler Software-Entwicklung:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Wir stellen...
...Individuen und Interaktionen über Prozesse und Tools
...funktionierende Software über großangelegte Dokumentationen
...Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
...Reagieren auf Veränderungen über das Befolgen eines Plans
Trotz aller Agilität lassen wir eine wichtige Komponente nicht außer Acht: Wirtschaftlichkeit.
Als erfahrene Projektmanager und Software-Ingenieure kennen wir beide Seiten des Softwaregeschäfts und wissen, dass es mit Agilität alleine noch nicht getan ist. Deshalb legen wir viel Wert auf ein sauberes Controlling und liefern nicht nur Ergebnisse, sondern messen sie auch an Größen wie Kosten- und Zeiteffizienz.
Agilität konkret
Um Ihnen einen Eindruck zu vermitteln, was Agilität für uns bedeutet, möchten wir Ihnen einen kleinen Einblick in unseren Software-Entwicklungsprozess geben:
Produktvision
In unserem Wiki hauchen wir Ihren Spezifikationen Leben ein. Living Documents sind genau wie Softwarespezifikationen stets im Wandel. Darum nutzen wir diese Technologie damit Ihr "Big Picture" nicht zur eingestaubten Antiquität wird.
Wishlist / Backlog
Ihre Spezifikationen formulieren wir als Software-Inkremente und arbeiten diese nach Ihrer Priorisierung Version um Version ab.
Versionen
Für eine Version setzen wir uns zeitliche Limits von ca. 30 Tagen. Am Ende jeder Version wird ein neuer Prototyp ausgeliefert, unser Testkatalog, unser "Big Picture" sowie die Dokumentation werden erweitert.
Zyklen
In festen Abständen finden bei der iXTS GmbH projektübergreifende Meetings statt. Das tägliche Stand-Up-Meeting nutzen wir für einen kurzen Statusupdate untereinander und für die Beseitigung von Hindernissen. Alle zwei Wochen finden im Wechsel Reviews und der Office Friday statt. In den Reviews stimmen wir uns über die Modellierung, Struktur und Umsetzung der Software ab und besprechen neue Features anhand Ihrer Architektur. Der Office Friday bietet uns ein Forum für Vorschläge, Problemlösungen und regelmäßige, von den Mitarbeitern vorbereitete Fachvorträge.
Kommunikation als Basis für eine erfolgreiche Zusammenarbeit
Gleich zu Beginn eines Software-Projekts zu wissen, was genau das Produkt, wie und in welchem Umfang, am Ende leisten soll - Mission Impossible.
Deshalb ist es für uns umso wichtiger, für Sie geeignete Kanäle und eine optimale Plattform für die Kommunikation Ihrer Belange herzustellen. Unser Ticket-System (Jira) erlaubt es Ihnen möglichst einfach Änderungswünsche, Bugs (sofern sie auftreten) oder neue Anforderungen anzulegen und den Fortschritt des Projekts zu beobachten.
Im Gegenzug informieren wir Sie regelmäßig über den Fortschritt des Projekts. Auch wenn etwas schneller fertig ist oder einmal länger dauert als geplant, können Sie rechtzeitig eingreifen und beispielsweise den Funktionsumfang einer Anforderung erweitern oder schmälern.
Immer in Ihrer Nähe
Meeting? Und zwar alle am gleichen Platz?
Möglich, aber nicht unbedingt notwendig.
Auch wenn wir persönliche Treffen ausgesprochen schätzen, sind wir dazu übergegangen, die meisten unserer Reviews, Präsentationen, Feedback-Runden usw. virtuell abzuhalten. Online-Meeting-Tools wie Microsoft Teams ermöglichen es uns, Treffen mit Video, Ton und Bildschirmübertragung an (fast) jedem Ort der Welt abzuhalten. Das schont Ressourcen!
Rock Solid Development
Agilität, Kommunikation, Transparenz, ... das klingt alles schön und gut, aber am Ende des Tages zählt doch nur eins: Ihre Software muss einwandfrei funktionieren. Was hilft Ihnen ein hochmodernes Vorgehensmodell, das Änderungen willkommen heißt und Kundenorientierung in den Vordergrund stellt, wenn jedes neu implementierte Feature nur halbwegs richtig implementiert ist und zu Fehlern in bereits implementierten Funktionen führt?
Deswegen stellen wir bei der iXTS GmbH unseren Entwicklungsprozess auf drei starke Säulen:
- Clean Code Development
Die Regeln des CCD umfassen alle wichtigen Prinzipien und alle "Lessons Learned" der vergangenen Jahrzehnte in elf "Tugenden". Diese transportieren z.B. Werte wie Evolvierbarkeit, kontinuierliche Verbesserung, Produktionseffizienz, Korrektheit usw.
- Test Driven Development und Test Automation
Wird heutzutage ein neues Auto entworfen, werden Crash-Tests am Computer simuliert, noch bevor der erste Prototyp eines Chassis gebaut wurde. Auf diese Weise werden die Risiken einer Fehlentwicklung minimiert.Ähnlich sorgfältig schreiben wir den Code für Ihre Software. Wir implementieren automatisierbare White-Box-Tests, schon bevor wir eine einzige Zeile des Produktiv-Codes schreiben. So können wir zu jeder Zeit sicherstellen, dass Änderungen an egal welcher Stelle im Code die Korrektheit des Gesamtsystems nicht verletzen.
- Continuous Deployment
White-Box- bzw. Unit-Tests sind schön und gut, aber komplexe Systeme bestehen meist aus vielen, oft sogar verteilten Komponenten, Diensten etc. Um diese vernünftig und automatisiert testen zu können, müssen sie sich in einer Staging-Umgebung befinden.
Deshalb wird bei jeder von uns vorgenommen Änderung die Software automatisch neu kompiliert und nachdem alle automatisierten Tests erfolgreich waren auf die Staging-Umgebung veröffentlicht. Dort können Sie sich dann auch selbst ein Bild vom aktuellen Fortschritt Ihres Projekts machen.
Die iXTS Toolchain
In unserem Entwicklungsprozess führt jede Änderung (Commit) eines Programmierers zum Anstoß des Kompilierungsprozesses im Build-Server. Dieser führt alle automatisierten Unit-Tests aus und meldet dem Team eventuelle Fehler.
Die Fortschritte in der Implementierung werden von den Entwicklern im Issue-Tracking System Jira dokumentiert und vom Projektmanager überwacht. Dieser sorgt auch für die Pflege der nicht automatisierten Zephyr-Tests im Testkatalog.
In bestimmten Intervallen - in der Regel jede Nacht - liefert der Build-Server den aktuellen Stand der Software automatisch auf die Staging Umgebung aus (Nightly-Build).
Maßgeschneiderte Transparenz
In die Entwicklung Ihres Produkts möchten wir Sie, so gut es geht, einbeziehen - natürlich nicht ganz ohne Eigennutz. Durch regelmäßige Präsentationen und Feedback-Runden sind wir bestrebt das Risiko einer Fehlentwicklungen zu eliminieren, schon bevor es entsteht.
Dennoch kann Transparenz ein sehr individuelles Kriterium sein und liegt meist im Auge des Betrachters. Wo sich die einen tägliche Statusupdates und kurze Kommunikationswege wünschen, bevorzugen andere seltenere, aber dafür sehr prägnante Reports. Wie Sie sich auch entscheiden, wir bieten Ihnen volle Transparenz, ganz nach Ihrem Maß.
Probieren geht über Studieren
Mit dem Abschluss einer jeden Version stellen wir Ihnen einen funktionsfähigen Prototyp Ihres Produkts zur Verfügung. So können Sie am besten einschätzen, ob wir uns auf dem richtigen Weg befinden, ob das Look & Feel Ihren Vorstellungen entspricht, oder ob gewisse Funktionen noch fehlen oder gar nicht gebraucht werden.
Bilder sagen mehr als tausend Worte
Wie verläuft die Implementierung der aktuellen Version? Gibt es Schwierigkeiten?
Ist Funktion X schon implementiert?
Wie liegen wir in der Zeit / im Budget?
Für solche Fragen geben wir Ihnen eine Reihe von Diagrammen an die Hand, die prägnanter sind als jeder Report.
Leichtgewichtig, aber nicht leichtsinnig
Agilität. Ein Wort, das heutzutage schon fast inflationär gebraucht, aber leider viel zu selten ernst genommen wird.
Als Softwarehersteller agil zu sein bedeutet für uns, die Natur der Software-Entwicklung zu respektieren, denn Softwareprojekte verlangen eine kontinuierliche Planung und Retrospektive, sowie eine enge partnerschaftliche Zusammenarbeit mit dem Kunden.
Wo andere Unternehmen versuchen, möglichst mit dem Strom zu schwimmen und sich Methoden wie Scrum oder Extreme Programming aufzwängen, respektieren wir die Grundsätze agiler Software-Entwicklung:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Wir stellen...
...Individuen und Interaktionen über Prozesse und Tools
...funktionierende Software über großangelegte Dokumentationen
...Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
...Reagieren auf Veränderungen über das Befolgen eines Plans
Trotz aller Agilität lassen wir eine wichtige Komponente nicht außer Acht: Wirtschaftlichkeit.
Als erfahrene Projektmanager und Software-Ingenieure kennen wir beide Seiten des Softwaregeschäfts und wissen, dass es mit Agilität alleine noch nicht getan ist. Deshalb legen wir viel Wert auf ein sauberes Controlling und liefern nicht nur Ergebnisse, sondern messen sie auch an Größen wie Kosten- und Zeiteffizienz.
Agilität konkret
Um Ihnen einen Eindruck zu vermitteln, was Agilität für uns bedeutet, möchten wir Ihnen einen kleinen Einblick in unseren Software-Entwicklungsprozess geben:
Produktvision
In unserem Wiki hauchen wir Ihren Spezifikationen Leben ein. Living Documents sind genau wie Softwarespezifikationen stets im Wandel. Darum nutzen wir diese Technologie damit Ihr "Big Picture" nicht zur eingestaubten Antiquität wird.
Wishlist / Backlog
Ihre Spezifikationen formulieren wir als Software-Inkremente und arbeiten diese nach Ihrer Priorisierung Version um Version ab.
Versionen
Für eine Version setzen wir uns zeitliche Limits von ca. 30 Tagen. Am Ende jeder Version wird ein neuer Prototyp ausgeliefert, unser Testkatalog, unser "Big Picture" sowie die Dokumentation werden erweitert.
Zyklen
In festen Abständen finden bei der iXTS GmbH projektübergreifende Meetings statt. Das tägliche Stand-Up-Meeting nutzen wir für einen kurzen Statusupdate untereinander und für die Beseitigung von Hindernissen. Alle zwei Wochen finden im Wechsel Reviews und der Office Friday statt. In den Reviews stimmen wir uns über die Modellierung, Struktur und Umsetzung der Software ab und besprechen neue Features anhand Ihrer Architektur. Der Office Friday bietet uns ein Forum für Vorschläge, Problemlösungen und regelmäßige, von den Mitarbeitern vorbereitete Fachvorträge.