Neben dem Einsatz unflexibler Werkzeuge ist mangelndes Vertrauen ein weiterer maßgeblicher Grund für starre Systeme in Individual-Software-Enwicklungs-Projekten. Um spätere Streitigkeiten zu vermeiden, werden Projekte in hohem Detaillierungsgrad und mit immensem Aufwand spezifiziert. Aufgrund der hohen Dynamik des IT Umfeldes überholt die Realität diese Dokumente jedoch nicht selten noch in der Planungsphase, ganz sicher jedoch im weiteren Projektverlauf. Der investierte, hohe Aufwand war im besten Fall schlicht überflüssig, im Regelfall jedoch sorgen veraltete Spezifikationen und Dokumente eher zusätzlich für Verwirrung, d.h. sie nützen am Ende nicht nur nichts, sondern schaden sogar. Im Klartext haben Sie Geld dafür bezahlt, sich zusätzlich Steine in den Weg zu legen, denn eine Dokumentation, die nicht aktuell gehalten wird, ist schlechter als gar keine Dokumentation.
Daher werben wir hier bewusst für gegenseitiges Vertrauen. In einem Umfeld, in dem sich die Voraussetzungen extrem schnell ändern, können Sie sich fast im wahren Sinne des Wortes zu Tode spezifizieren! Daher ist es nicht nur sinnvoll, sondern geradezu notwendig, Vorgehensweisen zu wählen, die das klassische Projekt-Management als blauäugig bezeichnen würde. Da Software-Lieferant und Kunde gleichermaßen im Risiko stehen, ist es Sache einer intelligenten Vertragsgestaltung, das Risiko gerecht auf beide Schultern zu verteilen. Die gesparte Zeit ist besser in die Details ihres Software-Wunsches investiert, damit ein Streitfall gar nicht erst eintritt. Denn bei einem gescheiterten Software-Entwicklungs-Projekt gibt es am Ende nur Verlierer!
Alles was Sie brauchen, ist ein bisschen Mut, sich auf unseren neuartigen Ideen zur intelligenten Vertragsgestaltung einzulassen. Am Ende profitieren beide Seiten massiv davon!
Unsere Vorgehensmodell ist eng angelehnt an Scrum, da wir den Grundgedanken von Scrum (Wikipedia: "Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können.") geradezu für essenziell halten. Der aufmerksame Leser wird sicher auch noch andere der auf dieser Webseite geäußerten Gedanken in dem Artikel über Scrum auf Wikipedia wieder finden. Dabei halten wir uns jedoch nicht streng an die dort geforderten Rollen und Artefakte.
Kurz zusammengefasst besteht unser Ansatz aus folgenden Säulen, die wir im Folgenden dann etwas näher erläutern:
Die strenge Forderung nach einer einzelnen Person als Product-Owner ("Er ist eine Person, kein Komitee.") halten wir für wenig sinnvoll. Eine Person kann schwerlich über alle notwendigen Perspektiven verfügen, die bei einem komplexen Software-Entwicklungs-Projekt zu berücksichtigen sind. Daher plädieren wir eher für ein schlankes Komitee (max. 10 Personen, besser weniger), in dem am Ende ein Vorsitzender die endgültigen Entscheidungen trifft, nachdem er die Einwände aller Beteiligten sorgfältig gegeneinander abgewogen hat! Dieser Nachsatz ist das eigentlich Wichtige dabei, ebenso wie die Forderung, dass das Product Owner-Komitee vorwiegend aus interdisziplinäre Experten bestehen sollte. Wenn nicht Personen in der Überzahl sind, die sowohl über Business/Prozess-, als auch über technisches Know How verfügen, sind Missverständnisse vorprogrammiert. Auch ein Spezialist von jeder erforderlichen Seite schadet nicht, ist aber keinesfalls ausreichend!
Aus Budget-Sicht ist ein wichtiger Aspekt des Grundgedanken von Scrum , unproduktive Arbeitsaufwände möglichst zu vermeiden, in dem man z.B. keine Details spezifiziert, die sich wahrscheinlich erst im Laufe des Projektes ergeben oder die aufgrund von technologischem Wandel möglicherweise überholt werden. Ein weiterer, unseres Erachtens noch wichtigere Aspekt ist die gezielte Vermeidung von Streitfällen, die besonders dann auftreten, wenn sich ein Projekt der Abnahme nähert. Welcher Projektleiter kennt nicht die immerwährende Frage, ob im Falle eines nicht implementierten Anwendungsfalls nun eine neue Anforderung oder ein Fehler vorliegt!? Unterschiedliche Sichtweisen hierüber sind nicht immer zu verhindern, und so ist es sinnvoll, hierfür von vornherein einen Risikopuffer einzubauen, auf den in solchen Fällen zurückgegriffen wird. Dieser ist in etwa vergleichbar mit einem Risiko-Fond, in den alle Parteien vorab "einzahlen". Im Konfliktfall wird so vermieden, dass man sich in endlosen Debatten verliert, die beiden Parteien gleichermaßen schaden, anstatt das Problem, das sich ja nicht weg definieren lässt, schlicht zielorientiert einer Lösung zuzuführen.
Nun passiert es leider nicht selten, dass der Versuch zur Vermeidung von Planungs-Overhead in manchen Projekten ins totalen Chaos mündet, da die Zeitplänge so eng kalkuliert derden, dass auch Backlog-Dokumente schlampig geführt werden und sich am Ende kaum noch nachvollziehen lässt, was denn das Produkt am Ende eigentlich können soll. Das ist sicher nicht im Sinne von Scrum, da eine seiner Kernforderungenen "Transparenz" ist. Die bei Scrum üblichen Backlog-Dokumente sollten nicht vernachlässigt werden, wünschenswert ist aber auch eine ausführliche Protokollierung von Gesprächen und Meetings. Gerade bei Unklarheiten kann es sehr hilfreich sein, wenn auch der Prozess der Meinungsbildung zumindest ansatzweise nachvollziehbar ist. Nicht zuletzt sollten, sobald dies möglich ist, wöchentliche reviews des aktuellen Standes Software gemacht werden. Eine Implementierungsrichtung von der GUI zur Persistenz ist daher sinnvoll. Hier liegt eine weitere Stärke von WebTactics, da funtionierende Prototypen auch ohne Persistenz-Anbindung leicht zu erstellen sind.
Über den letzten Punkt, "Berücksichtigung von Verwaltungsaufwänden bei der Aufwands-/ und Preiskalkulation", mag der eine oder andere innerlich lächeln, da er beinahe wie eine Trivialität klingt. Wenn wir ihn dennoch hier als eigenständigen Punkt aufnehmen, so basiert das auf der Praxis-Erfahrung, dass dies keineswegs selbstverständlich ist. Eher das Gegenteil ist der Fall: Es ist einer der meist begangenen Fehler im Projekt-Management, Verwaltungsaufwände unter den Tisch fallen zu lassen. Ein Entwickler schreibt jedoch nicht nur Programm-Code, sondern er besucht auch meetings, schreibt e-mails, telefoniert, recherchiert, kalkuliert etc. Unserer Erfahrung nach sind 6 Stunden reine Entwicklungszeit pro Tag bei der Kalkulation des Gesamt-Implementierungs-Aufwandes schon eher hoch gegriffen. Das gleiche gilt natürlich auch für alle anderen Rollen, insbesondere für die des Projekt-Managers. Da aber Kommunikation ja zu dessen Kernaufgaben zählt, wird hier der Aufwand meist weniger unterschätzt als der Aufwand von Rollen, die technisch geprägt sind. Daher sind es meist vor allem Test- und und Entwicklungs-Aufwäde, die geradezu chronisch unterschätzt werden.
Auf Basis all dieser Eckpunkte wird von uns und Ihnen eine gemeinsame Aufwandsschätzung erstellt, die dann die Basis eines vereinbarten Preisrahmens darstellt. Gerne gehen wir in Details auch auf Ihre Wünsche ein. Auf Anfrage beantworten wir gerne Ihre Fragen hierzu.
Der Einsatz agiler Methoden ist unserer Auffassung nach die notwendige Bedingung für ein erfolgreiches Software-Entwicklungs-Projekt. Ihr Einsatz allein bietet jedoch noch keine Garantie für den Projekterfolg. Besonders Groß-Projekte bleiben eine Herausforderung: Da die Werkzeuge fehlen, die ein Gesamt-Softwarekonstrukt fexibil halten, werden Software-Entwicklungs-Projekte nach wie vor desto träger und unbeweglicher, je größer sie sind.
Hier kommt nun WebTactics ins Spiel. Unser Web-Development Framework wurde gezielt daraufhin optimiert, den Aufwand für nachträgliche Änderungen zu minmieren. Erst der Einsatz eines solch flexiblen Werkzeuges sorgt dafür, dass das volle Optimierungspotenzial, das in der Verwendung agiler Methoden liegt, voll ausgeschöpft werden kann!