Heute werden wir über Scrum sprechen, ein Framework, das in aller Munde ist. Es ist agil und modern (wenn auch nicht neu). Und es ist klar, dass agil und modern besser klingt als langsam und altmodisch. Die Wahrheit ist jedoch, dass Scrum zwar Vorteile, aber auch Nachteile hat und nicht für jede Art von „Projekt“ geeignet ist.

In der Tat ist Scrum kein Rahmenwerk für Projekte, sondern für Produkte. Dennoch glauben (oder behaupten zumindest) viele Entwickler, dass sie Scrum anwenden. Warum? Weil das Wort Scrum sexier ist als realistischere Alternativen. Aber das werden wir später sehen. Lasst uns einen Schritt nach dem anderen machen.

Woher wir kommen: Wasserfall Entwicklung

Zunächst einmal ist es interessant, sich daran zu erinnern, woher wir kommen. Die traditionelle Softwareentwicklung erfolgte nach der Wasserfallmethode. Kurz und bündig lässt sie sich wie folgt zusammenfassen: Die Entwicklung ist in mehrere Phasen unterteilt, die nacheinander in einer bestimmten Reihenfolge durchgeführt werden:

1. Analyse der Anforderungen
2. Entwurf des Systems
3. Umsetzung
4. Prüfung
5. Bereitstellung

Diese Methodik hat einen großen Nachteil: Sie ist einseitig. Das Hauptproblem besteht darin, dass die Anforderungen nicht mehr geändert werden können, sobald die Umsetzung begonnen hat. Leider sind in der Software-Welt die Anforderungen nicht von Anfang an völlig klar, oder sie müssen während der Entwicklung geändert werden, entweder weil der Kunde seine Meinung ändert oder weil sich die Bedürfnisse geändert haben. Dies gilt insbesondere für langfristige Projekte.

Ist die Wasserfallentwicklung also eine schlechte Methode? Ganz und gar nicht. Es handelt sich einfach um eine Arbeitsmethodik, die bei Projekten, bei denen alle Informationen von Anfang an festgelegt sind, gut funktioniert. Es gibt viele Branchen, in denen die Wasserfallentwicklung erfolgreich eingesetzt wird. Die Flexibilität ist einfach begrenzt, was für die Entwicklung eines Softwareprojekts ein Problem darstellen kann.

Einführung in Scrum

Scrum ist ein agiles Framework, das auf der Bereitstellung von Teilschritten in Arbeitszyklen basiert, die Sprints genannt werden. In jedem Sprint wird ein voll funktionsfähiger Teil des Produkts geliefert. Jeder Sprint hat eine Phase der Anforderungsanalyse, des Systementwurfs, der Implementierung, des Testens und der Bereitstellung.Einer der Vorteile dieses Frameworks ist, dass die Anforderungen vor jedem Sprint definiert (oder zumindest diskutiert) werden. Daher legt das Team in jedem Sprint fest, was als nächstes umgesetzt werden soll. Dies ermöglicht es, auf mögliche Veränderungen auf dem Markt zu reagieren oder einfach im Interesse der Endverbraucher des Produkts zu handeln

Projekt vs. Produkt

Vielleicht ist euch aufgefallen, dass ich bei der Wasserfallentwicklung von Projekt gesprochen habe, während ich bei Scrum von Produkt gesprochen habe. Das war kein Zufall.

Die Wasserfallmethodik ist ein Projektmanagementmodell. Ein Projekt hat ein Budget und eine feste Laufzeit. Mit anderen Worten: Wenn ein Projekt durchgeführt wird, muss bekannt sein, wie viel es kosten wird und wann es abgeschlossen sein wird.

Mit dem Scrum-Framework wird die Entwicklung eines Produkts gemanagt, und daher gibt es kein Enddatum. Scrum wird für die periodische Produktentwicklung über einen unbestimmten Zeitraum hinweg eingesetzt. Zu Beginn der Entwicklung ist das Endergebnis noch nicht bekannt, da die zu implementierenden Funktionen im Laufe der Produktentwicklung und in Abhängigkeit von den Entscheidungen, die zur Erfüllung der Marktanforderungen getroffen werden, festgelegt werden. Deshalb ist sie flexibel.

Kann ich Scrum in meinem Projekt einsetzen?

Wenn wir genau gelesen haben, ist die Antwort einfach: Nein. Scrum kann für die Produktentwicklung eingesetzt werden, nicht für ein Projekt (obwohl in den letzten Jahren Scrum-Ansätze für Projekte entwickelt wurden). Und in der beratenden Softwareentwicklung gibt es reichlich Projekte.

Aus diesem Grund scheitern Projekte, die im Rahmen von Scrum entwickelt werden, häufig, oder diese Projekte werden tatsächlich mit einer Methodik entwickelt, die an Scrum erinnert, aber nicht wirklich Scrum ist, da das Framework nicht richtig angewendet wird (in einem Projekt kann es sogar überhaupt nicht angewendet werden). Infolgedessen können genau deswegen auch die Prinzipien, die Scrum ausmachen, nicht erfüllt werden.

Pseudo-Scrum ist eine Annährung der Wasserfall-Entwicklung und Scrum, mit den Vorteilen von beiden. Die Vorsilbe Pseudo mag den Eindruck erwecken, dass es sich um eine weniger gültige Methode als Scrum handelt, aber das ist nicht so. Manchmal wird auch der Begriff Hybrid verwendet, was besser klingt. Aber es kommt nicht darauf an, wie wir es nennen, sondern auf die Methodik selbst. Es ist wichtig, die Arbeitsmethode zu wählen, die am besten zu den Bedürfnissen passt, und sich nicht danach zu richten, was gerade in Mode ist oder gut klingt. Oberstes Ziel ist es, den Erfolg des Projekts oder Produkts und die Zufriedenheit sowohl des Kunden als auch des intern arbeitenden Teams zu gewährleisten.

Zusammenfassend bezeichnen wir ein Framework, das scheinbar Scrum-Merkmale verwendet, aber kein reines Scrum ist, als Pseudo-Scrum-Framework. Im Folgenden erklären wir, wie wir das bei WATA Factory machen.

Pseudo-Scrum bei WATA Factory

Zunächst einmal möchten wir erwähnen, dass wir bei WATA Factory die Arbeitsmethode anwenden, die am besten zum jeweiligen Projekt passt. Bei der Entwicklung einiger Produkte verwenden wir Scrum, aber dieses Framework ist im Allgemeinen nicht an die Anforderungen unserer Kunden angepasst. In den meisten Fällen müssen die Kunden wissen, was sie erhalten werden, wie viel die Entwicklung kosten wird und wann die Lieferung erfolgen wird. Dies ist per Definition unvereinbar mit Scrum.

Unser Pseudo-Scrum ist ein Hybrid aus Wasserfallentwicklung und Scrum, die die Vorteile beider Methoden vereint.

Zunächst haben wir eine Phase der Anforderungserfassung und -analyse. Anschließend erstellen wir einen interaktiven Prototyp, damit der Kunde sehen kann, wie das Produkt aussehen wird. Zusätzlich unterbreiten wir ein Angebot, das die Entwicklungskosten und den Liefertermin enthält, es sei denn, wir können gemeinsam mit dem Kunden auf der Grundlage von Stundenbudgets für die kontinuierliche Verbesserung eines bestimmten Produkts arbeiten, wobei wir in diesem Fall reines Scrum anwenden würden

Bei der Wasserfallentwicklung hätte das technische Team bis zum Liefertermin keinen weiteren Kontakt mit dem Kunden, da alles im Voraus festgelegt wäre. Doch genau hier kommt Scrum ins Spiel.

Die Umsetzung erfolgt in Produkt-Teilschritten mit voll funktionsfähigen Lieferungen. Das heißt, der Kunde könnte die gelieferte Funktionalität bereits nutzen. Dies hat zwei Vorteile. Erstens kann der Kunde Ihr Produkt bereits vor der endgültigen Lieferung nutzen. Der zweite ist, dass der Kunde die Funktionalität sehen und testen kann. Nach der Implementierung stellt der Kunde manchmal Verbesserungen in dem entwickelten Teil des Produkts fest. Eine Implementierung mit Pseudo-Scrum erlaubt es dem Kunden, die Funktionalitäten, die er für angemessen hält, während der Entwicklung neu zu definieren

Natürlich müssen die Änderungen in der gleichen Größenordnung liegen wie die ursprüngliche Implementierung, damit der Liefertermin und die Entwicklungskosten eingehalten werden können. Alternativ wird dies durch den Verzicht auf andere Funktionen oder deren Vereinfachung kompensiert. Dabei arbeiten wir mit einem priorisierten Backlog, in dem der Kunde die Reihenfolge der Umsetzung der Funktionalitäten bestimmt.

Nutze Pseudo-Scrum mit Stolz

Häufig werden Arbeitsweisen kritisiert, die an Scrum erinnern oder vorgeben, Scrum zu sein, sich aber in Wirklichkeit nicht getreu an das Framework halten. Zum Teil ist dies verständlich. Wenn Sie Scrum nicht verwenden, sollten Sie nicht predigen, dass Sie es verwenden. Es ist nicht richtig, zu sagen, dass die reine Umsetzung die richtige ist und jede andere Option nur ein Versuch der Nachahmung ist Nichts könnte weiter von der Wahrheit entfernt sein.

Wende die Methode an, die für die jeweilige Situation am besten geeignet ist, und verteidige sie mit erhobenem Haupt.

The post Pseudo-Scrum, unser eigenes angepasstes Framework bei WATA Factory appeared first on WATA Factory.

Das scheint selbstverständlich zu sein, aber leider gibt es in der Welt der Softwareentwicklung immer wieder Diskrepanzen zwischen dem, was der Kunde gefordert hat, und dem, was schließlich umgesetzt wurde. Dieses Problem tritt besonders bei Projekten mit Komplettlösungen auf, daher erläutern wir hier unsere bewährten Praktiken für diese Art von Projekten, die auch als schlüsselfertige Projekte bekannt sind.

Ein neues Projekt damit zu beginnen, indem man sich die Zeit nimmt, den tatsächlichen Bedarf des Kunden zu verstehen, ist eine Investition, die sich während der Implementierung mehr als bezahlt macht und nicht nur Entwicklungskosten für den Kunden spart, sondern auch die Kundenzufriedenheit gewährleistet.

Ein zufriedener Kunde ist die beste Geschäftsstrategie von allen.

Michael Leboeuf

Bei WATA Factory haben wir drei Schlüsselphasen herausgearbeitet, die uns helfen zu bestimmen, was entwickelt werden soll, und die über das bloße Aufnehmen von Anforderungen hinausgehen.

1. Die tatsächlichen Bedürfnisse des Klienten erfassen

In den meisten Fällen lesen die Softwareentwicklungsfirmen nur das Pflichtenheft und führen dann ein Treffen mit der Kontaktperson durch, um alle Zweifel zu klären. Im besten Fall, und wenn alles richtig gemacht wird, weiß der Anbieter dann im Detail, was der Kunde umsetzen möchte.

Aber in manchen Fällen ist das nicht genug. Oftmals ist dem Kunden das gesamte Potenzial der heutigen Technologie gar nicht bekannt. Als Experten ist es unsere Pflicht die Möglichkeiten, welche die endgültige Software dem Kunden bieten könnte, gründlich zu analysieren.

Daher untersuchen wir die verschiedenen Teile des Management- oder Herstellungsprozesses des Kunden. Wir sprechen auch mit den verschiedenen Beteiligten und versuchen Abläufe aufzudecken, bei denen Zeit oder Ressourcen verschwendet werden. Nicht alle Kunden nutzen diese Möglichkeit, insbesondere in komplexen Organisationen mit verschiedenen beteiligten Abteilungen.

2. Konzeptentwicklung

Sobald wir uns über alle tatsächlichen Bedürfnisse des Kunden im Klaren sind, wenden wir verschiedene kreative Methoden an um Ideen für die Erstellung eines Konzepts zu generieren, welches einen bemerkenswerten Mehrwert für den Kunden darstellt, der sogar manchmal über das hinausgehen kann, was sich der Kunde ursprünglich vorstellte.

Je nach Art des Projekts wenden wir Techniken an, die vom Design Thinking bis zum Lateral Thinking reichen. Diese Phase unterscheidet uns wesentlich von anderen Unternehmen in diesem Sektor.

An dieser Stelle bemühen wir uns besonders, Experten aus verschiedenen Bereichen einzubeziehen, um ein Ergebnis zu erzielen, das den hohen Erwartungen unserer Kunden entspricht.

3. Vorstellung des Konzepts

Nachdem wir zu Beginn des Projekts sichergestellt haben, dass wir die Anforderungen des Kunden verstehen (durch die Vermeidung von Missverständnissen, die den Erfolg des Projekts gefährden könnten), stellen wir in dieser Phase sicher, dass der Kunde das Konzept, welches wir im vorherigen Schritt für ihn entwickelt haben, auch versteht.

Hierfür verwenden wir verschiedene visuelle Vorlagen, die das erdachte Konzept klar vermitteln. Je nach Projekt nutzen wir Wireframes, Mockups oder interaktive proof on concepts.

Obwohl einige Softwareanbieter nach Stundensätzen arbeiten, garantieren wir dem Kunden ein Ergebnis und einen Liefertermin. So hat der Kunde die Gewissheit was er wann bekommt.

Darüber hinaus legen wir besonderen Wert auf die Kommunikation mit dem Kunden. Wir überarbeiten hiermit nicht nur regelmäßig das Konzept, bis eine zufriedenstellende Lösung erreicht ist, sondern sorgen während der Umsetzung durch kontinuierliche Übergaben an den Kunden auch dafür, dass wir in die gewünschte Richtung gehen. Der Kunde kann uns besuchen, wann immer er will, und er kann sogar, falls dies gewünscht wird, mit uns zusammen in unseren modernen Büroräumen arbeiten.

Unser Hauptziel ist nicht die Software selbst, sondern die Zufriedenheit unseres Kunden. Die Software ist das Mittel, um diese Zufriedenheit zu erreichen.

The post Wie man ein neues Software-Projekt zu einem guten Start bringt appeared first on WATA Factory.