09.12.2019
Zu breite oder nicht verhandelbare Stories, undefinierte Benutzer, fehlender Kontext: typische Fehler beim Schreiben von User Stories und wie Sie sie vermeiden.
Heute will jedes Team auf die agile Methodik der Agilen Programmierung umsteigen, d.h. den Anwender in den Mittelpunkt der Prozessplanung bei der Produktentwicklung stellen. Sie bauen schließlich ein Produkt für die Endbenutzer, richtig?
User Stories sind eines der grundlegenden Werkzeuge, die Teams helfen, sich bei der Definition eines Produkts und seiner Funktionalität an den Benutzer zu erinnern. Es wird viel darüber gesprochen, wie man sie richtig schreibt.
Wenn wir User Stories schreiben, haben wir oft den Eindruck, dass wir sie aus der Perspektive des Benutzers schreiben. Letztlich sind sie aber immer durch unsere Sichtweise und unser Fachwissen verzerrt. Oft sind diese Fehler miteinander verbunden und enden nie nur bei einer falschen Einschätzung. Deshalb möchte ich hier einige der häufigsten Fehler besprechen, die Teams beim Schreiben von User Stories machen.
Wenn User Stories zu allgemein gehalten sind, kann es leicht passieren, dass wichtige Informationen über die erwartete Aktivität und den Bedarf übersehen werden. Wenn es viele "und" oder "oder" in User Stories gibt, ist das ein Hinweis darauf, dass sie zu breit sind und Sie sollten in Betracht ziehen, sie neu zu schreiben.
Wenn User Stories zu gut geschrieben sind, fangen wir an, darüber zu reden, wie wir sie umsetzen wollen. Das entfernt den Benutzerfokus und führt zu schlechter Kommunikation im Team.
User Stories sollten nicht eine spezifische und genaue Beschreibung der Funktion sein. Manchmal ist die User Story so charakteristisch geschrieben, dass das Team Schwierigkeiten hat, sie korrekt umzusetzen, weil es eine einfachere Alternative gibt. In solchen Fällen sollte das Team bereit sein, Kompromisse bei der Herangehensweise einzugehen, vorausgesetzt, es schadet nicht dem zu erzielenden Nutzen für den Benutzer.
Mit Akzeptanzkriterien können Sie die Bedingungen beschreiben, die erfüllt sein müssen, damit eine Story als abgeschlossen markiert wird. Dies dient der Rückmeldung, der Unterstützung bei der Planung des Teams und der Verfolgung ihrer Arbeit. Dadurch wird die User Story reichhaltiger, präziser und testbarer. Ein häufiger Fehler ist, in den Akzeptanzkriterien nur die User Story zu wiederholen, statt prüfbare Bedingungen zu formulieren.
Die Erwähnung der Persona des Benutzers in jeder User Story mag frivol erscheinen, aber auf der anderen Seite kann es einen großen Wert in Bezug auf die Ergebnisse bringen. Dies ist besonders wichtig, wenn Ihr Produkt mehr als einen Benutzer hat. Natürlich wird es Features geben, die auf verschiedene Charaktere zugeschnitten sind. Wenn Sie möchten, dass Ihr Team die Ergebnisse, die Sie von ihm erwarten, besser umsetzen kann, muss es wissen, wer die Endbenutzer sind und welche Vorteile sie durch die Einführung der jeweiligen Funktion erhalten.
Nach einiger Zeit sieht fast jede User Story gleich aus, z.B. als Content Manager möchte ich einen Texteditor haben, um den Inhalt bearbeiten zu können. All dies sagt dem Team, dass Sie wollen, dass sie eine Textverarbeitung bauen und nichts weiter. Wenn Sie einige User Stories für eine lange Zeit geschrieben haben, machen Sie eine Pause und kommen Sie mit einer neuen Perspektive zurück. Manchmal kann es sein, dass Sie auch nach einer Pause nicht in der Lage sind, sich etwas sinnvolleres einfallen zu lassen. Das ist ein guter Indikator dafür, dass Sie mehr mit den Benutzern sprechen sollten, um ihre Bedürfnisse besser zu verstehen. Es ist wirklich nicht nötig, das Rad neu zu erfinden.
Die Verwendung von User Stories kann zwar nützlich sein, ist aber nie so einfach, wie es klingt. Ein Fehler beim Schreiben führt oft zu einer Reihe von anderen als Nebenprodukt. Und dann finden wir uns in einem noch größeren Schlamassel wieder, als wenn wir sie gar nicht geschrieben hätten. Deshalb, wenn wir uns entscheiden, es vorzubereiten, sollten wir viel Zeit und Aufmerksamkeit darauf verwenden.
Wir erweitern ständig unser Beratungsportfolio. Über 600 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen.
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>Web-Anwendungen sind Kompositionen unterschiedlichster Technologien. Für den Einsteiger ist diese Vielfalt verwirrend. Sie erhalten wichtige und wertvolle Entscheidungskriterien für die richtige Auswahl einer Software-Architektur.
Sie richten den quelloffenen Pi Coding Agent mit Modellen Ihrer Wahl ein, sichern ihn ab und bauen ihn mit AGENTS.md, Skills, Prompt Templates, Packages und eigenen Extensions zu Ihrem Werkzeug aus.
Produktiver entwickeln im Team: Sie binden Claude Code in Spezifikation, TDD, UI-Designsysteme, automatisierte Abnahmetests sowie GitHub-, Jira- und Pull-Request-Workflows ein – mit MCP, Skills, Hooks und klaren Freigaben.
Moderne KI-Entwicklungsprozesse für die eigene Arbeit: Sie ordnen Aufgaben zwischen sich und intelligenten Assistenten neu, erweitern Ihre Werkzeuge mit MCP und Skills, koordinieren mehrere Agenten und sichern das Ergebnis ab.
Sie setzen OpenAI Codex in CLI, IDE und Cloud mit AGENTS.md, Plan Mode, passender Sandbox und Git-Worktrees ein, erweitern es um Skills und MCP-Server und steuern es mit dem Codex SDK aus eigenen Skripten.
Sie führen KI-Werkzeuge im Entwicklungsteam mit klaren Regeln ein: Standortbestimmung, Governance und EU AI Act, Werkzeug- und Modellwahl, Context Engineering, eine KI-freundliche Codebasis, MCP und messbarer Nutzen.
Softwareentwickler:innen nutzen GitHub Copilot in Visual Studio, JetBrains-IDEs und VS Code gezielt für Vervollständigung, Debugging, Dokumentation und Tests – geübt an kurzen Aufgaben in Python, C#, Java und TypeScript.
Vibe Coding als Arbeitsweise: Sie bauen Anwendungen im Dialog mit einem KI-Agenten von der Idee bis zum lauffähigen Stand und sichern das Ergebnis mit Tests, Review und Versionskontrolle ab, damit es wartbar bleibt.
Software Tests mit ChatGPT und GitHub Copilot: Sie leiten Testfälle aus Anforderungen ab, automatisieren Unit-, API- und UI-Tests mit Playwright, erzeugen Testdaten und Berichte – und prüfen per Mutationstest, ob die Tests Fehler wirklich finden.
Sie bauen in VS Code mit GitHub Copilot eine vollständige REST-API – von Vervollständigung und Chat über den Agenten bis zum cloud agent – und sichern sie mit Tests, Dokumentation, Teamregeln und einer Deployment-Pipeline ab.
Sie klären Kontext und Stakeholder, finden mit Double Diamond, Ishikawa und 5-Why die eigentlichen Ursachen und entscheiden begründet, welche Lösung in die Anforderungen eingeht.
Sie formulieren Anforderungen nach Schablone, beseitigen Mehrdeutigkeiten und liefern eine Anforderungsdokumentation, mit der Fachbereich, Entwicklung, Test und Coding-Agenten ohne Rätselraten arbeiten können.
Sie entwerfen Cloud-Architekturen unabhängig vom Anbieter, begründen die Wahl von Cloud-Modell, Dienstschnitt, Datenhaltung und Betriebsmodell und machen Zielkonflikte zwischen Skalierbarkeit, Sicherheit, Kosten und Nachhaltigkeit sichtbar.
Full-Stack-Webentwicklung mit KI an einem durchgehenden Projekt: vom Wireframe über Frontend, API und Datenbank bis zu Tests, Pipeline, Deployment und Dokumentation – jeder Schritt mit passenden Werkzeugen und überprüfbarem Ergebnis.
Sie beschreiben APIs kompakt in TypeSpec, erzeugen daraus OpenAPI 3, JSON Schema und Protobuf und setzen einheitliche API-Richtlinien über wiederverwendbare Bibliotheken und Linter durch.
Sie bauen in Go, Rust und TypeScript je einen kleinen Prototyp, messen Performance, Speicher und Entwicklungstempo und verlassen den Workshop mit einer begründeten Entscheidungsvorlage samt Bewertungsmatrix für Ihre Backend-Sprache.
Sie lernen die Grundlagen, nach denen moderne Software-Anwendungen aufgebaut sind – vom Python-Skript über die Full-Stack-Anwendung bis zur Cloud – und begründen Architekturentscheidungen nachvollziehbar.
Sie beschreiben die IT-Landschaft Ihrer Organisation mit Frameworks wie TOGAF und ArchiMate, senken Komplexität durch Standards und Konsolidierung und begründen, wie Sicherheit, Cloud und Betrieb ins Zielbild passen.
Erzeugungs-, Struktur- und Verhaltensmuster so umsetzen, wie Node.js sie nahelegt – mit Modul-Caching, EventEmitter, Proxy, async Iteratoren und Streams – und erkennen, wann ein einfaches Modul das bessere Muster ist.
Sie verankern Sicherheit in jeder Phase der Entwicklung – mit Bedrohungsmodellen im Entwurf, sicheren Mustern im Code, SAST und DAST in der Pipeline und einer SBOM für jede Auslieferung.
Wo die Grenze zwischen zwei Services verläuft, wann ein Event besser ist als ein Aufruf und welche Kompromisse bei Daten, Latenz und Betrieb dazugehören – danach entscheiden Sie begründet, ob Microservices zu Ihrem System passen.
Sie wählen für jedes Problem verteilter Systeme das passende Microservices-Entwurfsmuster – von Zerlegung, Gateway und Datenbank je Service über Circuit Breaker und Bulkhead bis Saga und Transactional Outbox – und kennen seine Kosten.
Sie planen API-Tests unabhängig vom Werkzeug: von der Erkundung und Authentifizierung über gezielte Fehlerfälle und Vertragstests gegen OpenAPI bis zu automatisierten Tests als Code, Sicherheitsprüfungen und ersten Lasttests.
Sie erkennen und beheben die häufigsten Schwachstellen in Webanwendungen und APIs nach den OWASP Top 10 – von fehlerhafter Zugriffskontrolle über Injection bis zu unsicherem Design und neuen Risiken durch Lieferketten und LLM-Funktionen.
Sie wenden die fünf SOLID-Prinzipien und die GRASP-Muster an Python-Code mit Typ-Hinweisen und Protocols an, erkennen Verstöße im Code-Review und machen Klassen leichter erweiterbar und testbar.
Sie entwerfen RESTful APIs von den Konsumenten her, bilden Aktivitäten sauber auf Ressourcen, Methoden und Statuscodes ab und beschreiben das Ergebnis als prüfbaren OpenAPI-Vertrag – unabhängig von Programmiersprache und Framework.
Sie setzen Erzeugungs-, Struktur- und Verhaltensmuster in Python um, nutzen dafür Funktionen, Module, Dekoratoren und Protocols und erkennen, wann ein klassisches Muster in Python schlicht überflüssig ist.
Sie treffen die tragenden Entscheidungen für React im Großprojekt: Modulgrenzen und Monorepo, die Wahl zwischen clientseitigem Rendering, SSR und Server Components, eine belastbare Zustandsarchitektur und ein Design-System, das mehrere Frontends trägt.
Sie verstehen, warum große native iOS- und Android-Apps anders gebaut, getestet und betrieben werden als Webanwendungen, und kennen bewährte Lösungen für Releases, Architektur, Teams und Betrieb.
Sie entwerfen Dienstverträge mit Protocol Buffers, bauen Java-Microservices mit gRPC über HTTP/2 – unär und mit Streaming – und sichern sie mit Deadlines, TLS, Tests und Tracing ab, pur oder mit Spring Boot und Quarkus.
Sie zerlegen einen gewachsenen Monolithen Schritt für Schritt in Microservices – mit klarem Ziel, sauberem Service-Schnitt, Migration im laufenden Betrieb und einem Team, das die neue Architektur auch betreiben kann.
Sie analysieren gewachsene COBOL-Programme, sichern ihr Verhalten mit Tests ab, refaktorisieren sie schrittweise und wählen eine Migrationsstrategie, die Fachlogik und Daten nicht unterwegs verliert.
Sie kennen die wichtigsten Software-Architekturmuster von Monolith und Microservices über Hexagonal, CQRS und Event Sourcing bis MVC und MVVM, sehen ihre Struktur im Code und sichern die gewählte Architektur mit Fitness Functions ab.
Sie automatisieren Webanwendungen mit Selenium WebDriver, wählen robuste Locators, lösen Synchronisationsprobleme mit expliziten Wartezeiten und bringen Ihre Testsuite mit Page Objects und Selenium Grid in die CI-Pipeline.
Sie führen ein kleines Produkt in drei Sprints von der Problemaussage über geprüfte Anforderungen, Proof of Concept und Modelle bis zum Release 1.0 – und halten jede Entwurfsentscheidung nachvollziehbar fest.
Sie modellieren eine komplexe Fachdomäne gemeinsam mit dem Fachbereich, schneiden daraus Bounded Contexts und setzen Aggregate, Value Objects und Domain Events so um, dass Fachsprache und Code übereinstimmen.
Sie verstehen die Entwurfsprinzipien hinter den klassischen Entwurfsmustern, setzen Strategy, Adapter, Observer, Decorator, Iterator und Factory in Java und TypeScript um und erkennen, wann ein Muster mehr schadet als nützt.
Sie verstehen, was Software-Architekt:innen tatsächlich tun, leiten Architekturmerkmale aus Anforderungen ab und wählen zwischen Schichten, Plugin-Kern, Ereignissen und Services mit einer begründeten Abwägung.
Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.
Der Artikel beleuchtet den Alltag eines COBOL-Entwicklers und räumt mit Klischees über “veraltete” Technologien auf. Er zeigt, wie moderne Tools, tiefes Domänenwissen, stabile Mainframe-Systeme und geschäftskritische Prozesse den Beruf prägen. Statt Nostalgie herrschen Effizienz, Verantwortung und erstaunliche Zukunftssicherheit. COBOL bleibt unsichtbar – doch essenziell.
Domain Storytelling überbrückt die Sprachbarrieren zwischen Business und IT. Fachanwender erzählen Geschichten aus ihrem Alltag, die in einfache Bilder übersetzt werden – live, verständlich und greifbar. So entstehen gemeinsame Modelle, die Prozesse klar machen und Wissen effizient teilen. Ob Logistik, E-Commerce oder Finanzbranche: Die Methode liefert konkrete, praxistaugliche Ergebnisse, fördert Zusammenarbeit und macht komplexe Abläufe für alle verständlich.
Der Artikel vergleicht .NET-GUI-Frameworks (WinForms, WPF, UWP/WinUI, .NET MAUI, Avalonia, Uno, Blazor) und zeigt ihre Grenzen: meist Windows-Bindung, geringe Innovationsdynamik, kleines Ökosystem und Investitionsrisiken. Empfohlen werden stattdessen Web-Frameworks (Angular, React, Vue) sowie Cross-Plattform-Stacks (Flutter, React Native) wegen Reichweite, Community, Performance und Zukunftssicherheit. Fazit: kritisch prüfen, oft führt der Weg ins Web.
Rust gilt als eine der leistungsstärksten, aber auch komplexesten Programmiersprachen. Forscher der Brown University entwickeln mit Tools wie Aquascope, Argus und Flowistry neue Lern- und Debugging-Werkzeuge, die Rust zugänglicher machen. Statt die Sprache zu vereinfachen, setzen sie auf kognitionswissenschaftliche Ansätze, Visualisierungen und interaktive Tools. Ihr Ziel: Entwickler stärken, nicht ersetzen – und den Weg für menschzentrierte Softwareentwicklung ebnen.
Systematische Problemanalyse ist der Schlüssel zu erfolgreichem Requirements Engineering. Dieser Artikel zeigt Ihnen bewährte Methoden und Techniken zur Problemidentifikation, -analyse und Lösungsentwicklung. Erfahren Sie, wie der Double-Diamond-Prozess Ihre Anforderungsanalyse verbessert und warum iteratives Vorgehen entscheidend für den Projekterfolg ist.
Effektives Anforderungsmanagement entscheidet über Erfolg oder Scheitern eines Projekts. In diesem Artikel erfahren Sie, warum klar definierte Anforderungen der Schlüssel zu reibungslosen Prozessen sind und wie Sie diese mit den richtigen Methoden und Tools optimal verwalten. Von der Anforderungsplanung bis hin zu agilen Best Practices – entdecken Sie Strategien, um Missverständnisse zu vermeiden und Produkte zu entwickeln, die den wahren Bedürfnissen Ihrer Kunden entsprechen.
Tauchen Sie ein in die Welt des Domain-Driven Designs (DDD), eine Methode, die nicht nur die Art und Weise verändert, wie wir Software entwickeln, sondern auch wie Teams zusammenarbeiten und kommunizieren. Von den Grundlagen und der historischen Entwicklung von DDD über die Rolle von Microservices und Monolithen bis hin zu Bounded Contexts und Entitäten deckt dieser Artikel alles ab. Erkunden Sie zudem die dynamische Welt des Event Storming, ein Werkzeug, das das Verständnis geschäftlicher Abläufe auf eine neue Ebene hebt und zeigt, wie DDD dazu beitragen kann, komplexe Softwareprojekte erfolgreich zu meistern. Entdecken Sie, wie Sie die Prinzipien von DDD nutzen können, um Ihre Softwareprojekte und Teams zu transformieren.
Dieser Artikel beleuchtet die Prinzipien nachhaltiger Softwarearchitektur, darunter Modularität, Schichtung und die Anwendung von Design Patterns. Er betont die Wichtigkeit, technische Schulden zu minimieren und die Rolle von KI und Automatisierung in der zukunftssicheren Softwareentwicklung. Durch Fallstudien und FAQs werden praktische Einblicke und Strategien zur Implementierung und Erhaltung einer nachhaltigen Architektur aufgezeigt, um langfristige Wartbarkeit, Skalierbarkeit und Flexibilität von Softwareprodukten zu gewährleisten.
Künstliche Intelligenz (KI), maschinelles Lernen (ML) und Data Science (DS) sind die Schlagworte in der Informationstechnologie (IT)-Branche. Die Mehrheit der Unternehmen bewegt sich von der Proof of Concept (POC)-Phase zur Produktion und Monetarisierung von KI/ML/DS-Lösungen. Aufgrund der Art der Arbeit, die in die Projekte involviert ist, unterscheiden sich Teamzusammensetzung, Qualifikationsanforderungen und die Kernentwicklung von KI/ML/DS etwas von der traditionellen Softwareentwicklung. Die Einbeziehung von Datenexploration, Data Engineering, Experimenten und spezialisierten Tools wie Jupyter-Notebook trägt zur Komplexität bei.
Der Business Analyst fungiert als Bindeglied zwischen den verschiedenen Projektrollen während des gesamten Projektlebenszyklus - von der Ermittlung bis zur Lieferung. Das bedeutet, dass der Business Analyst das "große Ganze" und die Art und Weise, wie das Team am Projekt zusammenarbeitet, kennenlernt. Dies versetzt den Business Analyst in eine gute Position, um Verbesserungen in Bezug auf Anforderungen, Kommunikation, Teamausrichtung, Einbeziehung der Stakeholder, Projektplanung und Fortschrittsüberwachung zu identifizieren und einzuführen.
Warum brauchen Sie einen Prototypen? Haben Sie zufällig eine Menge Ideen und Anforderungen von Kunden, wenn es um das Projekt geht? Wenn ja, dann ist ggf. die Entwicklung eines Prototypen eine geeignete Methode diese Ideen und Anforderungen zu überprüfen. Ein Prototyp ist etwas, das die meisten Menschen mit materiellen Produkten assoziieren, nicht unbedingt mit mobilen oder Web-Anwendungen. In der IT-Branche - und insbesondere in modernen Softwarehäusern - wird der Prototyp jedoch sehr häufig im Softwareentwicklungsprozess eingesetzt. Zunehmend ist er auch ein Schlüsselelement im Prozess der Vertragsabschlüsse.
So werden Ihre Code-Reviews (noch) besser. Wir alle wissen, dass wir ohne Code-Review nicht weit kommen. Es verbessert die Qualität des Codes und macht seine Struktur stabiler. Außerdem helfen Reviews den Programmierern, Beziehungen aufzubauen und effektiver zu arbeiten. Es lässt sich jedoch nicht leugnen, dass ein Review von gleichem Code viel einfacher zu planen als durchzuführen ist, und solche Reviews können ein Alptraum für Teamleiter sein.
Start-ups sind aus unserer Gegenwart nicht mehr wegzudenken. Immer mehr davon sind Unternehmen, die mit IT zu tun haben. Doch wir kennen nur die, die erfolgreich waren. Von denen, die gescheitert sind, hat noch nie jemand etwas gehört. Manchmal war ihr Scheitern mit überbewerteten Plänen verbunden, ein anderes Mal scheiterten sie, weil sie sich darauf konzentrierten, sofort etwas Neues zu schaffen, ohne einen richtigen langfristigen Ansatz zu verfolgen.
