Best Practices

Download Best Practice Compendium (42 PDF files in German):
PQ4Agile – AP 2.2 – Best-Practice-Kompendium

Best Practices – Requirements Engineering

Anforderungen kontinuierlich priorisieren

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen einarbeiten

Ziele

  • Tatsächlich umzusetzende Anforderungen ermitteln insbesondere im Hinblick auf einen Ressourcenengpass
  • Vereinfachung der Planung für Auftragnehmer, bessere Planung der notwendigen Ressourcen beim Auftragnehmer
  • Erkennen der vom Auftraggeber am dringendsten benötigen Leistungen

Kurzbeschreibung

Eine Priorisierung der Menge der initial erhobenen Anforderungen bringt die Anforderungen in eine absteigende Reihenfolgegemäß ihrer Wichtigkeit. Sie legt somit die Relevanz der einzelnen Anforderungen fest und impliziert letztendlich die Reihenfolge ihrer Umsetzung. Durch die kontinuierliche Priorisierung von Anforderungen in jedem Sprint wird ersichtlich, wie relevant die Anforderungen für einzelne Stakeholder sind. Mit diesen Anforderungen kann anschließend weiter gearbeitet werden. Man stellt somit schon früh fest, auf welche Anforderungen man sich im Entwicklungsprojekt am stärksten konzentrieren sollte, um die späteren Nutzer zufrieden zu stellen.

Download: PQ4Agile – AP 2.2 – Anforderungen kontinuierlich priorisieren (V.1)
Anforderungen mit Hilfe von Prototypen erheben

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Anforderungen systematisch klären, verfeinern, kommunizieren und validieren
  • Entdecken von Anforderungen, die (noch) nicht in Anforderungsspezifikationen enthalten sind
  • Erzeugen eines gemeinsamen Verständnisses des zu entwickelnden Produkts

Kurzbeschreibung

Um die aufgeführten Ziele zu erreichen, kann ein Prototyping Prozess durchgeführt werden, der aus drei Phasen besteht: zunächst wird ein geeigneter Prototyp konzipiert, dieses Konzept wird in der zweiten Phase implementiert und schließlich in der dritten Phase durch Stakeholder evaluiert. Diese drei Phasen werden iterativ durchlaufen. Somit wird ermöglicht, dass kontinuierlich bestimmte Mengen von Anforderungen erhoben, diskutiert, verfeinert und evaluiert werden, bis schließlich das Gesamtbild der Art und Weise, wie welche Anforderungen umgesetzt werden sollen, vervollständigt wird.

Download: PQ4Agile - AP 2.2 - Anforderungen mit Hilfe von Prototypen erheben (V.1)
Anforderungen reviewen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Anforderungen entsprechen den Erwartungen der Stakeholder
  • Anforderungen haben eine Qualität, die geeignet ist, um für weitere Entwicklungsarbeiten zu dienen

Kurzbeschreibung

Bei einem Review von Anforderungen diskutieren mehrere Stakeholder oder Anforderungskonsumenten aus nachgelagerten Entwicklungsaktivitäten über die bereits erhobenen und spezifizierten Anforderungen und deren potentielle Mängel. Dabei gehen sie systematisch vor und wenden die Review-Technik der Inspektion an. Diskutiert wird, welche der identifizierten potentiellen Mängel tatsächliche Mängel sind, die behoben werden müssen. Erst wenn die erhobenen und spezifizierten Anforderungen keine Mängel mehr aufweisen und somit qualitativ hochwertig sind, werden sie zur weiteren Verwendung im Softwareentwicklungsprozess freigegeben.

Download: PQ4Agile - AP 2.2 - Anforderungen reviewen (V.1)
Anforderungen wiederverwenden

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Aufwand bei der Erhebung und Bearbeitung von (Kunden-)Anforderungen senken
  • Qualität der Anforderungen erhöhen
  • Entwicklungsrisiko senken

Kurzbeschreibung

Neue Projekte haben oft eine große Ähnlichkeit mit vergangenen Projekten oder sie setzen direkt auf Vorgängerprojekten auf. Die Anforderungen, die im Rahmen dieser Projekte erhoben und dokumentiert wurden, werden bei dieser Aktivität vollständig oder teilweise übernommen, anschließend geprüft und bei Bedarf angepasst.

Download: PQ4Agile - AP 2.2 - Anforderungen wiederverwenden (V.2)
Aufwand für das Anforderungsmanagement bestimmen

Bereich

Projektplanung und -Steuerung

Aktivität

Aufwand schätzen

Ziele

  • Änderungsaufwände genauer schätzen
  • Tätigkeiten im Bereich Anforderungsmanagement besser planen
  • Fehlplanungen und Ressourcenengpässe vermeiden

Kurzbeschreibung

Anforderungen werden nach der Erhebung weiterverwendet und sie ändern sich im Laufe eines Projektes. Vor allem bei der Entwicklung komplexer Produkte und Systeme sind daher Aktivitäten zur systematischen Steuerung, Kontrolle und Verwaltung der erhobenen Anforderungen notwendig. Die Rahmenbedingungen und bestimmte Einflussfaktoren eines Projektes geben Auskunft darüber, in welchem Umfang Tätigkeiten für das Requirements Management eingeplant bzw. durchgeführt werden sollten.

Download: PQ4Agile - AP 2.2 - Aufwand für das Anforderungsmanagement bestimmen (V.2)
Aufwand für die Anforderungsentwicklung bestimmen

Bereich

Projektplanung und -Steuerung

Aktivität

Aufwand schätzen

Ziele

  • Erhebungsaufwände genauer schätzen
  • Tätigkeiten im Bereich Anforderungsentwicklung besser planen
  • Fehlplanungen und Ressourcenengpässe vermeiden

Kurzbeschreibung

Hochwertige Anforderungen sorgen für reduzierte Entwicklungsaufwände und für eine höhere Produktqualität. Vor allem bei der Entwicklung komplexer Produkte und Systeme sind daher Aktivitäten zur systematischen Ermittlung, Prüfung, Dokumentation und Abstimmung von Anforderungen notwendig. Die Rahmenbedingungen und bestimmte Einflussfaktoren eines Projektes geben Auskunft darüber, in welchem Umfang Tätigkeiten für die Anforderungsentwicklung eingeplant und durchgeführt werden sollten.

Download: PQ4Agile - AP 2.2 - Aufwand für die Anforderungsentwicklung bestimmen (V.2)
Begründungen für Anforderungen dokumentieren

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Anforderungen besser verstehen
  • Notwendigkeit und Priorität einer Anforderung nachvollziehen können

Kurzbeschreibung

Da in der agilen Entwicklung ohnehin Anforderungen mit Hilfe von Satzschablonen erfasst werden, bietet es sich an, in diesen Satzschablonen den Begründungen der Anforderungen besondere Aufmerksamkeit zukommen zu lassen. Bisher benutzte User Story-Schablonen sehen die Angabe einer Begründung bereits vor, liefern aber nur unmittelbare Begründungen, die ohne Kontext nicht unbedingt verständlich sind. Oft handelt es sich bei den Begründungen nur um Wünsche, nicht aber um deutliche Gründe, die auf eine echte Anforderung schließen lassen. Es sollte daher eine erweiterte User Story-Schablone verwendet werden, die Kontextinformationen integriert, die Begründungen für Begründungen liefern, also den Wunsch in einen bestimmten Kontext stellen und somit nachvollziehbar werden lassen, warum er geäußert wird.

Download: PQ4Agile - AP 2.2 - Begründungen für Anforderungen dokumentieren (V.1)
Entwickleranforderungen dokumentieren

Bereich

Anforderungen

Aktivität

Kunden-Anforderung einarbeiten

Ziele

  • Entwickleranforderungen in kleine Arbeitspakete aufteilen
  • Agilere Entwicklung

Kurzbeschreibung

Die Kunden-Anforderungen werden in technische Anforderungen übertragen, sodass definierte, klar strukturierte, zeitlich kleine Arbeitspakete (Tasks, Tickets) entstehen, die in ein Ticket-System eingepflegt und im Rahmen eines agilen Entwicklungsprozesses abgearbeitet werden können.

Download: PQ4Agile - AP 2.2 - Entwickleranforderungen dokumentieren (V.1)
Experimentelles und exploratives Prototyping durchführen

Bereich

Evaluation

Aktivität

Prototypen erstellen

Ziele

  • Vervollständigen der Anforderungen
  • Visualisieren und Abwägen von Problemlösungen
  • Senken der Projektkosten

Kurzbeschreibung

Experimentelle und explorative Prototypen dienen der Veranschaulichung komplexer Sachverhalte innerhalb eines Systems. Sie helfen, vor allem funktionale Anforderungen zu erkennen und deren Ausprägung frühzeitig zu beurteilen. Anhand von Prototypen können technische Sachverhalte und Lösungsansätze erläutert (Experimentelles Prototyping) oder Lösungsmöglichkeiten demonstriert werden (Exploratives Prototyping).

Download: PQ4Agile - AP 2.2 - Experimentelles und exploratives Prototyping durchführen (V.1)
Funktionale Anforderungen erheben

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Basis für die Entwicklung funktional hochwertiger Produkte schaffen
  • Kommunikationsgrundlage zwischen Entwicklungsteam und Stakeholdern herstellen

Kurzbeschreibung

Bei der Erhebung der funktionalen Anforderungen wird ermittelt, was ein Produkt aus Sicht der Stakeholder leisten können soll (in Bezug auf systeminterne Funktionen und Benutzerinteraktionen). Um diese Anforderungen vollständig zu ermitteln, können verschiedene Erhebungstechniken eingesetzt bzw. miteinander kombiniert werden.

Download: PQ4Agile - AP 2.2 - Funktionale Anforderungen erheben (V.2)
Kundenanforderungen dokumentieren

Bereich

Anforderungen

Aktivität

Kunden-Anforderungen erheben

Ziele

  • Gesteigerte Kundenzufriedenheit
  • Dokumentation der genauen Erwartungen des Kunden
  • Bessere Kommunikation mit dem Kunden

Kurzbeschreibung

Funktionale Anforderungen und Qualitätsanforderungen werden in Gesprächen mit dem Kunden strukturiert erfasst. Der Kunde ist jeder beliebige Anforderungssteller; er kann sowohl der Auftraggeber einer Software als auch der Endkunde (Anwender) selbst sein.

Download: PQ4Agile - AP 2.2 - Kundenanforderungen dokumentieren (V.1)
Kundenanforderungen in technische Anforderungen übertragen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen einarbeiten

Ziele

  • Aufbereitung von Kundenanforderungen
  • Grobaufteilung in technische Anforderungen
  • Erkennen von Umsetzungsproblemen

Kurzbeschreibung

Der Anforderungskatalog wird in Anwendungsfälle (Use Cases) mit klarem Anfangs- und Endzustand unterteilt und mit funktionalen Merkmalen, Qualitätsmerkmalen und Randbedingungen versehen.

Download: PQ4Agile - AP 2.2 - Kundenanforderungen in technische Anforderungen übertragen (V.1)
Nichtfunktionale Anforderungen erheben

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Basis für die Entwicklung qualitativ hochwertiger Produkte schaffen
  • Kommunikationsgrundlage zwischen Entwicklungsteam und Stakeholdern herstellen
  • frühe Qualitätssicherung ermöglichen
  • Kundenzufriedenheit und Kundenbindung erhöhen

Kurzbeschreibung

Bei der Erhebung der nichtfunktionalen Anforderungen wird ermittelt, welche Qualitätseigenschaften ein Produkt bzw. die von ihm bereitgestellten Dienste aus Sicht der Stakeholder haben sollen. Um diese Anforderungen vollständig zu ermitteln, können verschiedene Erhebungstechniken eingesetzt bzw. miteinander kombiniert werden.

Download: PQ4Agile - AP 2.2 - Nichtfunktionale Anforderungen erheben (V.2)
Product Canvas erstellen

Bereich

Projektplanung und -Steuerung

Aktivität

Projekt planen

Ziele

  • Projektvision und Projektausrichtung kommunizieren
  • Gesamtbild des Projekts und des Entwicklungsprozesses visualisieren
  • Teamwork und zielorientiertes Arbeiten fördern

Kurzbeschreibung

Das Product Canvas ist ein visuelles Produktplanungstool, das in leicht verständlicher und strukturierter Form die wichtigsten Informationen zusammenfasst, die bei der Entwicklung eines neuen Produkts benötigt werden. Es enthält Angaben zu den Benutzern bzw. den Kunden und ihren Bedürfnissen, zum Big Picture (Features, UI-Design und Benutzerinteraktion) sowie zu den aktuell wichtigen Produktdetails.

Download: PQ4Agile - AP 2.2 - Product Canvas erstellen (V.2)
Produktvision erstellen

Bereich

Projektplanung und -Steuerung

Aktivität

Projekt planen

Ziele

  • Projektziel und -ausrichtung vorgeben
  • ersten Eindruck des zu entwickelnden Produkts vermitteln
  • Verbindung der Stakeholder mit dem Produkt herstellen

Kurzbeschreibung

Eine überzeugende Produktvision gibt dem Team ein klares Ziel vor, das von allen Mitgliedern geteilt wird. Sie zeigt die Richtung auf, die eingeschlagen werden muss, um dieses Ziel zu erreichen, und leitet das selbstorganisierte Team auf seinem Weg dorthin an. Zugleich lässt sie genug Freiraum, damit sich die Mitglieder kreativ in das Projekt einbringen können. Die Produktvision motiviert und inspiriert das Entwicklungsteam, sie begeistert aber auch die übrigen Beteiligten (z. B. Auftraggeber, Kundenvertreter, Marketing und Vertrieb) für das Produkt und schafft die Grundlage für eine wirkungsvolle Produktstrategie.

Download: PQ4Agile - AP 2.2 - Produktvision erstellen (V.2)
Projekttag durchführen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen einarbeiten

Ziele

  • Konzentrierte, zielgerichtete und effektive Entwicklung
  • Förderung des Team-Gedankens
  • Motivationssteigerung

Kurzbeschreibung

Ein Projekttag sieht die Abspaltung eines sich für einen Tag formierenden und auf wenige Personen (in der Regel 2 bis 4) beschränkten SCRUM-Teams vor, welches unter allen Umständen ungestört gemeinsam an einem vorab festgelegten Aufgabenbereich arbeiten darf. Den Tagesablauf können die Beteiligten frei bestimmen; vorgegeben sind lediglich zwei Abstimmungsmeetings am Anfang und Ende.

Download: PQ4Agile - AP 2.2 - Projekttag durchführen (V.1)
Soll-Ist-Vergleich durchführen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Erfassen, was das aktuelle System kann
  • Festlegen, was das neue System können soll

Kurzbeschreibung

Durch einen Vergleich des vorhandenen Systems bzw. des aktuell durchgeführten Prozesses mit dem durch die Menge der Anforderungen beschriebenen zu entwickelnden System, lässt sich die Menge der umzusetzenden Anforderungen ermitteln. Dadurch wird sowohl vermieden, dass positive Aspekte des aktuellen Systems bzw. Prozesses im zukünftigen System nicht mehr berücksichtigt werden als auch, dass im zukünftigen System Anforderungen umgesetzt werden, die sich im aktuellen System bzw. Prozess als wenig sinnvoll erwiesen haben.

Download: PQ4Agile - AP 2.2 - Soll-Ist-Vergleich durchführen (V.1)
Systematisch vom Groben ins Feine vorgehen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Verfeinerung von Anforderungen
  • Konsistente und vollständige Erhebung von Anforderungen

Kurzbeschreibung

Die unterschiedlichen Sichten verschiedener Stakeholder auf Anforderungen für eine Software-Anwendung müssen während der Anforderungserhebung kontinuierlich verfeinert werden. Dadurch entsteht das Big Picture der unterschiedlichen Anforderungen, die Anforderungen der verschiedenen Stakeholder werden berücksichtigt und Anforderungen liegen so detailliert vor, dass von ihnen Systemanforderungen abgeleitet werden und sie in Programmcode umgesetzt werden können. Dafür sind verschiedene Entscheidungen zu treffen und Systemaspekte zu diskutieren bzw. zu spezifizieren.

Download: PQ4Agile - AP 2.2 - Systematisch vom Groben ins Feine vorgehen (V.1)
Systemkontext und -umfang festlegen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Identifikation der fachlichen Einsatzumgebung eines Softwaresystems
  • Identifikation des funktionalen Umfangs des Softwaresystems innerhalb seiner Einsatzumgebung in Verbindung mit der Schätzung des Zeit- und Kostenaufwands für die Umsetzung der Anforderungen

Kurzbeschreibung

Die Festlegung des Systemkontexts und -umfangs erfolgt zu Beginn eines neuen Projekts bzw. sobald ein Projekt vorgeschlagen wurde, also noch vor dem ersten Sprint eines agilen Entwicklungsprozesses. In Gesprächen mit Vertretern des Auftraggebers (auch Vorgesetzte innerhalb des eigenen Unternehmens) wird über die Projektmotivation, die Projektziele, die Unternehmensziele, die zu unterstützenden Stakeholder, Projekteinschränkungen (z.B. Zeit, Budget, Mitarbeiter) und technische Einschränkungen (z.B. Rechenkapazität, Entwicklungsumgebungen) gesprochen und die jeweiligen Anforderungen erhoben. Somit wird bereits zu Beginn eines Projekts sichergestellt, dass die fachliche Einsatzumgebung des zu entwickelnden Systems und dessen funktionaler Umfang feststehen sowie die für die Umsetzung der dafür relevanten Anforderungen benötigten Kosten und Zeit geschätzt wurden.

Download: PQ4Agile - AP 2.2 - Systemkontext und -umfang festlegen (V.1)
Viele Augen sehen mehr

Bereich

Entwickleranforderung

Aktivität

(Kunden-)Anforderungen einarbeiten

Ziele

  • Vervollständigung der Realisierungsvorgaben
  • Stärkung der Zusammenarbeit und des Wissensaustauschs
  • Steigerung der Motivation der Mitarbeiter

Kurzbeschreibung

Diese Best-Practice sieht vor, in kurz gehaltenen Gesprächsrunden mit intensivem Workshop-Charakter unter Beteiligung einer heterogenen Personengruppe Anforderungen der Software zu beleuchten und deren Beschreibung zu vervollständigen. Neben Spezialisten, die die Facette einer Anforderung besonders gut überblicken, werden auch Personen aus Randgebieten eingebunden. Die Workshops sollten nicht länger als eine Stunde in Anspruch nehmen, dafür aber so oft wiederholt werden, bis ein zufriedenstellendes Ergebnis erzielt wurde. Wichtig ist, dass ein offenes Gesprächsklima gepflegt wird, damit auch Randaspekte zu ihrem Recht kommen, die sonst unberücksichtigt bleiben würden. Unter diesen Voraussetzungen werden Risiken frühzeitig benannt, der Qualitätsgedanke im Allgemeinen hochgehalten; man zeigt früh Interesse an der Wiederverwendbarkeit, der Generalisierung und Verständlichkeit der Lösung. Ausschlaggebend für den erfolgreichen Einsatz dieses Best-Practice ist die Kombination einfacher und bewährter Mittel, die für sich genommen trivial erscheinen, aber im Zusammenspiel Entscheidendes erreichen. Wichtig ist also, dass die Meetings kurz gehalten, gut vorbereitet und zeitnah nachbearbeitet werden und dass der Personenkreis viele Interessen und Sichtweisen abdeckt, um eine möglichst vollständige Erfassung sämtlicher Aspekte der Spezifikation zu erreichen.

Download: PQ4Agile - AP 2.2 - Viele Augen sehen mehr (V.1)

Best Practices – Software Architecture

Architekturentscheidungen dokumentieren

Bereich

Planung und Design

Aktivität

Lösungskonzept entwerfen

Ziele

  • Wichtige Architekturentscheidungen festhalten und archivieren
  • Inkonsistenzen im System vermeiden
  • Wiederholte Diskussionen und Umentscheidungen vermeiden
  • Neue Mitarbeiter schnell einarbeiten

Kurzbeschreibung

Mit der Aufnahme von Dokumentation in die Definition of Done und der Bestimmung eines Verantwortlichen für Dokumentation kann eine Zunahme von Dokumentation im Projekt erreicht werden. Das gesamte Team erstellt Dokumentation, indem nach einer Konzeptentwicklung die wichtigsten Entscheidungen, Whiteboarddiagramme und einige Stichpunkte als Erklärung festgehalten werden. Abgelegt werden die Informationen bei der jeweiligen Aufgabe in dem Taskmanagement-Werkzeug mit dem das Team ohnehin bereits arbeitet. Optimalerweise wird dies direkt nach der Erarbeitung eines Konzepts, spätestens aber vor dem Iterationsende erledigt.

Download: PQ4Agile - AP 2.2 - Architekturentscheidungen dokumentieren (V.1)
Architekturlösungen im Team entwickeln

Bereich

Planung & Design

Aktivität

Lösungskonzept entwerfen

Ziele

  • Explizite Erarbeitung von Lösungskonzepten
  • Wissensverbreitung im Team
  • Alle Teammitglieder können sich mit den entwickelten Lösungen identifizieren
  • Konsolidierte Architekturdefinition und -Beschreibung

Kurzbeschreibung

Die Auswahl einer User-Story oder eines Epics zur Bearbeitung, welches ein umfassendes Konzept benötigt oder das Auftreten neuer Anforderungen, deren Lösung noch unklar ist, sind typische Startpunkte für den Einsatz dieser Best Practice. Fragestellungen wie Synchronisation von Offline-Daten, Backup-Strategie oder Sicherstellung von Hochverfügbarkeit sind Beispiele. Die Erarbeitung einer Architekturlösung wird als explizite Aufgabe in der Iteration eingeplant. Dabei übernimmt ein Entwickler die Verantwortung für die Ausarbeitung der Architekturlösung, bezieht aber andere Entwickler oder das gesamte Entwicklungsteam mit ein. Eine Aufgabenstellung wird dabei in Teilaufgaben unterteilt, offene Fragestellungen identifiziert, Aufgaben verteilt und von verschiedenen Entwicklern ausgearbeitet. Der Konzept-Verantwortliche übernimmt die Organisation und Konsolidierung. Das Konzept wird so lange diskutiert und weiterentwickelt, bis es sich zur direkten Umsetzung eignet.

Download: PQ4Agile - AP 2.2 - Architekturlösungen im Team entwickeln (V.1)
Einfache, aber konsistente Diagramme erstellen und verwenden

Bereich

Planung und Design

Aktivität

Lösungskonzept entwerfen

Ziele

  • Ein grundlegendes Verständnis für das System bei Stakeholdern etablieren
  • Eine Basis für die Diskussion im Team schaffen
  • Festhalten und Verfügbarmachen der wichtigsten Konzepte

Kurzbeschreibung

Zur Beschreibung grundsätzlicher Aspekte des Systems oder spezifischer Konzepte können Entwickler Diagramme erstellen. Dies ist sowohl während der Erarbeitung von Lösungskonzepten als auch im Nachgang zur weiteren Verwendung während der Umsetzung sinnvoll. Damit Diagramme einen Mehrwert liefern, sollten Sie so gestaltet sein, dass sie den Konsumenten effizientes Arbeiten erlauben. Dafür sollten die Diagramme einen geringen Grad an Komplexität aufweisen und möglichst konsistent sein, das heißt grundsätzliche Prinzipien der Diagrammgestaltung sollten berücksichtigt und einheitliche Diagrammtypen und Notationen verwendet werden.

Download: PQ4Agile - AP 2.2 - Einfache, aber konsistente Diagramme erstellen und verwenden (V.1)
Feature-Entwicklung und interne Qualitätsarbeiten verzahnen

Bereich

Realisierung

Aktivität

Softwareinkrement realisieren

Ziele

  • Mittel- und langfristige Bewahrung interner Produktqualität
  • Vereinheitlichung von Konzepten
  • Verbesserung bestehender Konzepte

Kurzbeschreibung

Die Kernidee dieser Best Practice ist es, nicht den kompletten Entwicklungs-Aufwand in die Realisierung von Features zu stecken, sondern einen gewissen Teil auch zur Bewahrung der internen Produktqualität zu investieren. Die genaue Verteilung muss das Team einmalig festlegen. Während der Entwicklung sammelt das Team Indikatoren für Qualitäts-Defizite, die bei der Realisierung eines Features aufgefallen sind. Bei der Planung der Aufgaben für die nächste Iteration (hier als Iteration n bezeichnet) werden die gefundenen Indikatoren für Qualitäts-Defizite im Team analysiert und der durch das Defizit potentiell entstehende Schaden bewertet. Aus den hoch priorisierten Indikatoren für Qualitäts-Defizite werden Aufgaben abgeleitet, die dazu dienen, Konzepte zu erarbeiten, die diese Defizite beheben. Das können zum einen neue Konzepte sein, die ein Konzept ersetzen, das in einer bestehenden Realisierung verwendet wurde, aber dessen Qualität als nicht mehr ausreichend erachtet wird. Trotz sorgfältiger Arbeit gibt es immer wieder solche Stellen im Produkt, die entweder unter Zeitdruck entstehen mussten, oder die im Lichte neuer Erkenntnisse als nicht mehr geeignet erachtet werden. Weiterhin kann auch die Vereinheitlichung von mehreren ähnlichen Konzepten angestrebt werden. In dieser Iteration n werden im Team diese geplanten Konzeptionierungsaufgaben erledigt. Das Ergebnis daraus ist eine Menge an Realisierungsaufgaben, die der Umsetzung von Lösungsansätzen der gesammelten Qualitäts-Defizite dient. In der nächsten Iteration (hier als Iteration n+1 bezeichnet) liegen damit für die hoch priorisierten Indikatoren für Qualitäts-Defizite sowohl Lösungskonzepte als auch konkrete Aufgaben vor. Während der Planung der nächsten Iteration n+1 wird nun das interne Qualitätsbudget zu einem großen Teil mit der Realisierung dieser Aufgaben belegt, im anderen Teil werden Lösungen für neue Refactoring-Wünsche konzipiert, die dann wieder in Iteration n+2 umgesetzt werden. Die genaue Verteilung muss das Team einmalig festlegen. Somit werden in jeder Iteration sowohl neue Konzepte erstellt als auch umgesetzt. Insgesamt findet somit kontinuierlich eine Investition in die interne Qualität und die Infrastruktur innerhalb der Software statt. Beispielsweise könnte ein Indikator für ein internes Qualitätsproblem sein, dass während der Umsetzung eines neuen Features zwar eine Ähnlichkeit zur Realisierung mehrerer anderer Features erkannt wird, die dabei verwendeten Architektur-Konzepte jedoch voneinander abweichen. Um die Wartbarkeit und Erweiterbarkeit zu erhöhen wird hier ein gemeinsames Architektur-Konzept erarbeitet und umgesetzt, das alle Features konsistent umsetzt und dabei gemeinsame Bestandteile verwendet.

Download: PQ4Agile - AP 2.2 - Grob- und Detailplanung bei der Implementierung nutzen (V.1)
Grob- und Detailplanung bei der Implementierung nutzen

Bereich

Realisierung

Aktivität

Softwareinkrement realisieren

Ziele

  • Vermitteln einer Orientierungshilfe für alle Entwickler
  • Etablierung einer gemeinsamen Sprache
  • Entscheidungsgrundlage für schnelle Problemlösungen

Kurzbeschreibung

Ziel der Praktik ist es die geplante Architektur so bald als möglich sichtbar machen. Dabei wird eine gemeinsame Sprache verwendet, die im gesamten Team die gleiche Semantik hat, um Missverständnisse zu vermeiden. Generell werden zwei Arten von Architekturdokumentationen benutzt: Eine abstraktere, die langfristige Architekturentscheidungen zueinander in Bezug setzt und zeigt, wie das Produkt die nächsten Blöcke an Anforderungen umsetzen soll. Weiterhin wird ein detailreicherer Ausschnitt dargestellt, der die genauere Ziel-Architektur und damit das Design der aktuellen Iteration dokumentiert. Bei beiden wird zu mehr Details und anderen Artefakten verwiesen. Dies sind beispielsweise Anforderungen, die durch ein Architektur-Konzept umgesetzt werden sollen, oder auch konkrete Entwicklungstasks, die ein Ausschnitt der Architektur realisieren. Hierbei wird von folgender gängiger Praxis ausgegangen: Zu den Anforderungen des Produktes werden durch das Team Entwicklungstasks definiert, die diese Anforderungen umsetzen. Diese Entwicklungstasks werden in Iterationen durch das Team umgesetzt, wobei anhand dieser Aufgaben eine Koordination der Entwicklung stattfindet. Dazu sind Tasks eindeutig bezeichnet und werden während ihrer Bearbeitung eindeutig Personen zugeordnet. Sowohl die Grob-Architektur als auch das Design sollen verständlich für alle Team-Mitglieder dokumentiert werden. Hierbei ist eine immer präsente Dokumentationsform vorzuziehen. Diese kann direkt im Blickfeld des Teams untergebracht werden. Dies kann beispielsweise ein großes Diagramm am Whiteboard oder Flipchart sein, oder ein großformatiger Ausdruck. Dabei sollen diese Diagramme immer auch vom Schreibtisch aus lesbar sein, die Größe soll nicht dazu dienen sehr viele Details unterzubringen.

Download: PQ4Agile - AP 2.2 - Grob- und Detailplanung bei der Implementierung nutzen (V.1)
Kontinuierliche Architekturbewertung durchführen

Bereich

Evaluation/Kontrolle

Aktivität

Machbarkeitsanalyse/Interne Qualitätssicherung

Ziele

  • Inkonsistenzen und offene Punkte in der Lösung identifizieren und deren frühzeitige Bearbeitung ermöglichen
  • Architekturlösungen nachhaltig bewahren
  • Konfidenz in die Eignung der entwickelten Architekturlösungen erreichen
  • Wissensverteilung über Architekturkonzepte im Team fördern

Kurzbeschreibung

Die Eignung eines Lösungskonzeptes für die Erfüllung von bestimmten Anforderungen soll geprüft werden. Zusätzlich zu diesen können noch weitere, wichtige Anforderungen ausgewählt werden, deren Erfüllung bei der Realisierung des neuen Konzeptes bewahrt bleiben soll. Ein Teammitglied wird als Assessor ausgewählt, der die Architekturbewertung durchführt. Dieser befragt ausgewählte Mitglieder des Teams über die Lösungen, die die gewählten Anforderungen erfüllen sollen. Dabei versucht er offene Punkte, Inkonsistenzen und Verbesserungspotentiale herauszufinden. Für diese werden Vorschläge für Stories erstellt, die diskutiert und bei Bedarf in das Backlog eingeplant werden.

Download: PQ4Agile - AP 2.2 - Kontinuierliche Architekturbewertung durchführen (V.1)

Best Practices – Usability / User Experience

Informationsarchitektur erstellen

Bereich

Planung und Design

Aktivität

Lösungskonzept entwerfen

Ziele

  • Ermöglichung einer leichten und intuitiven Bedienung
  • Effiziente Interaktion mit der Software-Anwendung
  • Verbessern der pragmatischen Qualität des Systems

Kurzbeschreibung

Die Erstellung der Informationsarchitektur umfasst mehrere Aspekte. Sie befasst sich mit der Benennung, Aufteilung und Strukturierung der Inhalte, der Navigation durch diese und der Suche. Anhand der gegebenen Anforderungen werden die Inhalte strukturiert und benannt. Zur Strukturierung (Kategorisierung/Gruppierung) der Inhalte und festlegen der Navigationswege können beispielsweise Techniken wie Card Sorting verwendet werden. Die Festlegung klarer Navigationswege durch die Software ist ein entscheidender Punkt. Eine schlechte Navigation reduziert die Effizienz mit der eine Software genutzt werden kann. In einem weiteren Schritt werden die Inhalte organisiert, d.h. es wird festgelegt, welche Informationen an welcher Stelle gezeigt werden.

Download: PQ4Agile - AP 2.2 - Informationsarchitektur erstellen (V.1)
Kontextuelles Benutzerinterview durchführen

Bereich

Anforderungen

Aktivität

(Kunden-)Anforderungen erheben

Ziele

  • Anforderungen und Bedürfnisse der Anwender verstehen
  • Einflüsse der Umgebung auf die Interaktion erkennen
  • Ablauf aktueller Prozesse kennenlernen und deren Schwachstellen aufdecken

Kurzbeschreibung

Beim kontextuellen Benutzerinterview (engl. Contextual inquiry) werden detaillierte Informationen erhoben, auf welche Art der Anwender bestimmte Arbeitsprozesse durchführt und welcher Hilfsmittel er sich hierbei bedient. Das kontextuelle Benutzerinterview verbindet ein halbstrukturiertes Interview mit einer teilnehmenden Beobachtung des Anwenders im natürlichen Anwendungskontext.

Download: PQ4Agile - AP 2.2 - Kontextuelles Benutzerinterview durchführen (V.2)
Produktphilosophie erstellen

Bereich

Anforderungen

Aktivität

Anforderungen erheben

Ziele

  • Erleichterte Kommunikation zwischen Stakeholdern
  • Designentscheidungen erleichtern/rechtfertigen

Kurzbeschreibung

Die Best Practice „Produktphilosophie erstellen“ unterstützt die Definition und Bewertung von Faktoren der User Experience einer Softwareanwendung. Sie wird im Rahmen agiler Projekte hauptsächlich zur Entscheidungsunterstützung bzw. Priorisierung durch das Team und als Kommunikationsmedium zwischen involvierten Stakeholdern verwendet. Dabei wird insbesondere der Trade-off zwischen funktionalen Features und User-Experience-Features aufgelöst. Je nach Softwaretyp gibt es verschiedenen Vorlagen (sog. Templates), die verwendet werden können. Abbildung 1 zeigt das Mobile Template der Produktphilosophie, bei dem es vordefinierte Attribute gibt, auf die man sich in den ersten Sprints einigt. Dahinter steckt jeweils eine Erklärung der Bewertung bzw. die Unterstützung durch Beispiele. Die Wertepaare und die Bewertung geben hierbei an, welchen Eindruck die Software vermittelt bzw. vermitteln soll. Beispielsweise besagt die Produktphilosophie in Abbildung 1, dass das zu entwickelnde Produkt einem individuellen Look & Feel folgen soll. Dies bedeutet, dass es bei Entscheidungen hinsichtlich des Interaktionskonzepts und der Benutzeroberfläche eher ein individuelles Look & Feel (z.B. Company CI/Guidelines) verfolgt werden, anstatt Standards der Plattformen zu benutzen. Der Entwickler erhält durch die jeweilige Ausprägung eine Idee, in welchem Maße die genannten Aspekte zu berücksichtigen sind. Darüber hinaus fällt es ihm leichter, Designentscheidungen zu rechtfertigen, da er sich auf die Vorgabe auf der Produktphilosophie beziehen kann. Die Best Practice „Produktphilosophie erstellen“ verbessert die Kommunikation zwischen UI-Verantwortlichen, Vertrieb und Entwicklern. Insbesondere unterstützt sie Entwicklerteams bei kontinuierlicher Anwendung dabei, systematisch eine spezifische User Experience in das fertige Produkt zu „injizieren“. Um dies zu erreichen, können z. B. einzelne User Stories auf die Attribute gemappt werden. Einen besonderen Nutzen erzielen Unternehmen, wenn sie die vorhandenen Templates vor der Verwendung auf ihre konkreten Bedürfnisse anpassen. Verschiedene Templates, die den unterschiedlichen Anwendungsarten (z. B. Mobile, Security, Software Renovation) gerecht werden, stehen zur Auswahl.

Download: PQ4Agile - AP 2.2 - Produktphilosophie erstellen (V.1)
Severity Rating durchführen

Bereich

Evaluation

Aktivität

Walkthroughs durchführen

Ziele

  • Bewerten und Priorisieren von Usability-Problemen

Kurzbeschreibung

Grundlage des Severity Ratings ist ein Usability Walkthrough. Beim Usability Walktrough handelt es sich um eine Expertenevaluation der Gebrauchstauglichkeit, welche an einem fertigen Produkt aber auch schon an Prototypen angewendet werden kann. Grundsätzlich kann die Methode auch ohne die dedizierten Benutzer durchgeführt werden, jedoch kann das Ergebnis verbessert werden, indem repräsentative Benutzer an der Evaluation teilnehmen. Im Allgemeinen ist ein Usability Walkthrough ein angeleitetes Vorgehen, um sich in dedizierte Benutzer hineinzuversetzen oder die Gedanken dieser während der Interaktion mit der Software zu erfassen. Ziel ist es, so viele Usability Issues wie möglich aufzudecken. Unter den Begriff Usability Issue fallen sämtliche Auffälligkeiten der Benutzungsschnittstelle, welche die Usability negativ beeinflussen können. Um so viele Usability Issues wie möglich aufzudecken ist es wichtig, dass die Teilnehmer explorativ die Funktionalität der zu evaluierenden Benutzungsschnittstelle erfahren. Dabei wird die komplette Benutzungsschnittstelle in Betracht gezogen und nicht nur die zur Erfüllung der Aufgabe notwendigen Ausschnitte. Prinzipiell kann ein Usability Walkthrough während des gesamten Software Entwicklungszyklus angewendet werden. Nachdem der Usability Walkthrough durchgeführt wurde, werden die gefundenen Usability Issues von Usability Experten intern reflektiert und je nach Kritikalität bewertet und jeweils eine mögliche Behebung der einzelnen Usability Issues vorgeschlagen.

Download: PQ4Agile - AP 2.2 - Severity Rating durchführen (V.1)
Template-basierte UI Konzeption durchführen

Bereich

Planung und Design

Aktivität

Lösungskonzept entwerfen

Ziele

  • Entwicklung einer konsistenten Benutzeroberfläche
  • Schnelle und konsistente Umsetzung von Änderungswünschen bezüglich des UI-Designs
  • Erreichung einer Verfolgbarkeit von Änderungen im UI-Design
  • Schaffung einer Grundlage für eine effektive und effiziente Implementierung von UI-Designs
  • Verbesserung der Kommunikation zwischen UI-Designer und Programmierer

Kurzbeschreibung

Bei der template-basierten UI-Gestaltung geht es um die Erstellung und Verwendung von Vorlagen zur Gestaltung der Benutzeroberfläche. Diese Vorlagen definieren das Grundgerüst einer Anwendung durch instanziierbare UI-Elemente (z.B. Schaltflächen, Tabellen, Header, Navigationsmenüs), die innerhalb der Anwendung zum Einsatz kommen. Eine hierarchische Struktur dieser Elemente wird dabei festgelegt, um zum einen die Zuordnung einzelner Elemente zu übergeordneten Elementen zu kennen, zum anderen die Einflüsse von Änderungen bestimmter Elemente auf untergeordnete, von ihnen abhängige Elemente von vornherein festzulegen und zu kennen. Weiterhin werden sämtliche Attribute jedes einzelnen Elements spezifiziert, um bei deren Implementierung keine unterspezifizierten oder nichtspezifizierten Aspekte auftreten zu lassen. Einzelne Dialoge der entwickelten Anwendung werden unter (ausschließlicher)Verwendung dieser Vorlagen gestaltet. Ähnlich einem Styleguide werden somit die Elemente für ein einzelnes Projekt, eine Produktlinie oder das gesamte Unternehmen spezifiziert. Durch die Verwendung von gleichen Identifikatoren in UI-Template und Source Code kann zusätzlich zur Erstellung konsistenter Prototypen, auch die Nachverfolgbarkeit von prototypisch instanziierten UI-Elementen zu ausführbarem Code ermöglicht werden.

Download: PQ4Agile - AP 2.2 - Template-basierte UI-Konzeption durchführen (V.1)
Usability-Patterns verwenden

Bereich

Planung und Design

Aktivität

Oberflächenentwurf erstellen

Ziele

  • Usabilitymängel vermeiden
  • Konsistenz von Benutzeroberflächen erhöhen
  • Entwicklungseffizienz steigern

Kurzbeschreibung

Usability-Patterns sind bewährte Lösungsmuster für typische Gestaltungs- bzw. Interaktionsprobleme, die in bestimmten Nutzungskontexten auftreten. Sie können beim Entwurf oder der Entwicklung von Software eingesetzt werden. Usability-Patterns sind in strukturierter, relativ abstrakter Form beschrieben. Sie ermöglichen es, die für ein Produkt relevanten Usability-Merkmale bereits in frühen Phasen der Produktentwicklung und ohne weitere Usability-Expertise systematisch zu betrachten und besser zu berücksichtigen.

Download: PQ4Agile - AP 2.2 - Usability-Patterns verwenden (V.2)
Usability-Review durchführen

Bereich

Evaluation

Aktivität

Reviews durchführen

Ziele

  • Usabilityprobleme identifizieren
  • Verbesserungspotenzial aufzeigen

Kurzbeschreibung

Beim Usability-Review wird eine Repräsentation der Benutzerschnittstelle (z. B. Designkonzept, Prototyp oder fertige Software) anhand zuvor definierter Szenarios und Usabilityprinzipien untersucht. Hierzu versetzt sich der Gutachter in die Lage des späteren Benutzers, um mögliche Schwierigkeiten bei der Bedienung aufzudecken. Das Usability-Review kombiniert die beiden Inspektionsmethoden Cognitive Walkthrough und Heuristische Evaluierung.

Download: PQ4Agile - AP 2.2 - Usability-Review durchführen (V.2)
Usability-Test durchführen

Bereich

Kontrolle

Aktivität

Externe Qualitätssicherung durchführen

Ziele

  • Gebrauchstauglichkeit überprüfen
  • Usabilityprobleme identifizieren
  • Entscheidungs- und Informationsverhalten der Nutzer erkennen

Kurzbeschreibung

Beim Usability-Test bearbeitet eine Gruppe Testpersonen in einem bestimmten Zeit-raum eine Auswahl typischer Testaufgaben. Hierdurch sollen softwareergonomische Probleme, aber auch positive Aspekte des Produkts aufgedeckt werden. Der Usability-Test ist geeignet für fertige Software, aber auch für Zwischenstände, Prototypen und Designkonzepte.

Download: PQ4Agile - AP 2.2 - Usability-Test durchführen (V.2)

Best Practices – Testing

Erfahrungsbasiertes Testen durchführen

Bereich

Kontrolle

Aktivität

Interne Qualitätssicherung durchführen (Verifikation)

Ziele

  • Vertrauen in die Qualität der Software erhöhen
  • Informationen über das Qualitätsniveau gewinnen
  • Fehler finden

Kurzbeschreibung

Das erfahrungsbasierte Testen beschreibt eine Art des Testens, bei der Testfälle nicht anhand einer Testbasis im Voraus spezifiziert werden, sondern von der testenden Person direkt bei der Ausführung der Applikation / Software entworfen werden. Bei dieser Vorgehensweise wird oft keine Dokumentation der Testfälle vorgenommen, sondern es werden lediglich die zu testenden Bereiche der zu testenden Applikation / Software beschrieben. Neben dem rein explorativen Testen, bei dem ein Tester während des Testens intuitiv durch die Software navigiert, um Probleme zu finden, kann auch eine Checkliste genutzt werden, die beispielsweise gewisse Fehlerbilder enthält, auf die geprüft wird. Eine Testcharta, welche Anweisungen oder Ideen für den erfahrungsbasierten Test enthält, kann genutzt werden, um Bereiche für den erfahrungsbasierten Test festzulegen, und somit diese Art des Testens grob zu steuern.

Download: PQ4Agile - AP 2.2 - Erfahrungsbasiertes Testen durchführen (V.1)
Fehlermanagement einsetzen

Bereich

Projektplanung und -Steuerung

Aktivität

Projekt planen

Ziele

  • Fehlerklassifikation erstellen
  • Fehlerstatusmodell einführen
  • Einheitliches Schema für Fehlermeldungen
  • Nachvollziehbarkeit und Reproduzierbarkeit

Kurzbeschreibung

Fehlermeldung sollten in einem einheitlichen Schema geschrieben werden, dass im Idealfall im Team abgesprochen ist. Ziel ist hierbei, die Nachvollziehbarkeit durch die Entwickler und die Reproduzierbarkeit der gemeldeten Fehler zu ermöglichen. Weiterhin sorgt ein Fehlerstatusmodell für einen exakt definierten Ablauf bei der Bearbeitung der Fehlermeldungen. Die Fehlerklassifikation wiederum erlaubt die Priorisierung bestimmter Meldungen je nach der Wichtigkeit / Kritikalität der Meldung.

Download: PQ4Agile - AP 2.2 - Fehlermanagement einsetzen (V.1)
Reviews von Entwicklungsartefakten durchführen

Bereich

Evaluation

Aktivität

Reviews durchführen

Ziele

  • Fehler und Probleme frühzeitig finden
  • Wissenstransfer ermöglichen
  • Teamzusammenhalt fördern
  • Lösungen erarbeiten

Kurzbeschreibung

Nachdem ein Entwicklungsartefakt (z.B. Anforderungen, Design, Code) erstellt wurde, kann es von einem oder mehreren Reviewern überprüft werden. Der bzw. die Reviewer können das entsprechende Dokument basierend auf ihren eigenen Erfahrungen nach Fehlern prüfen, sowie Anmerkungen und Verbesserungsvorschläge dokumentieren (direkt in dem Dokument, in einer Fehlerliste, oder werkzeugunterstützt). Darüber hinaus besteht die Möglichkeit, den Reviewern Leseunterstützung bei der Prüfung zur Verfügung zu stellen, beispielsweise in Form einer Checkliste, die eine Anzahl von Fragen enthält, auf die das Dokument zu prüfen ist. Neben der Möglichkeit, die gleiche Checkliste für alle Reviewer zu nutzen, können auch unterschiedliche Checklisten, die verschiedene Arten von Fehlern bzw. Perspektiven abdecken, genutzt werden. Darüber hinaus können auch Szenarien für ein Review eingesetzt werden, welche den Reviewer aktiv auffordern, eine Aktivität durchzuführen, und dabei die Qualität zu prüfen. Beispielsweise kann ein Testerszenario einen Reviewer auffordern, Testfälle aus einem Anforderungsdokument oder auch User Stories abzuleiten, und dabei zu prüfen, ob alle Informationen vorhanden sind. Im Anschluss an das Review können die Auffälligkeiten dem Autor in einer Gruppensitzung kommuniziert bzw. direkt übergeben werden. Der Autor ist dann schließlich für die Korrekturen verantwortlich. Weitere Detailbeschreibungen sind auch in den Best Practices „Usability-Review durchführen“ sowie „Anforderungen reviewen“ zu finden.

Download: PQ4Agile - AP 2.2 - Reviews von Entwicklungsartefakten durchführen (V.1)
Systematische Testfallableitung und Tests durchführen

Bereich

Kontrolle

Aktivität

Interne Qualitätssicherung durchführen (Verifikation)

Ziele

  • Tests werden systematisch und zielgerichtet erstellt
  • Vertrauen in die Qualität der Software erhöhen
  • Informationen über das Qualitätsniveau gewinnen
  • Fehler finden

Kurzbeschreibung

Die systematische Testfallableitung sorgt für eine zielgerichtete Erstellung von aufeinander abgestimmten Testfällen. Es wird klar, welche Teile der Software wie gut durch Tests abgedeckt sind. Für unterschiedliche Qualitätsanforderungen können unterschiedliche Testfallableitungsmethoden verwendet werden. Als Basis für die Testfallableitung dient entweder eine Spezifikation, Modelle (für Black Box-Tests) oder der Code selbst (für White Box-Tests). An Black Box-Methoden werden unter anderem die Äquivalenzklassen und Grenzwertanalyse, der zustandsbezogene Test, Ursache-Wirkungs-Graphen und Entscheidungstabellen oder der anwendungsfallbezogene Test empfohlen. Die Wahl der Methodik hängt zum Beispiel ab von den Eigenschaften des Systems, der verfügbaren Testbasis, der Teststrategie, den Testressourcen oder dem Wissen über die Methodiken. An White Box-Tests werden die Anweisungsüberdeckung, die Entscheidungsüberdeckung sowie die Bedingungsüberdeckung empfohlen, wobei die genaue Wahl zum Beispiel von den Qualitätsanforderungen, der Systemstruktur, oder dem zu erreichenden Qualitätslevel abhängt. Die systematisch abgeleiteten Tests werden im Anschluss durchgeführt.

Download: PQ4Agile - AP 2.2 - Systematische Testfallableitung und Tests durchführen (V.1)
Teststrategie festlegen und Teststufen aufeinander abstimmen

Bereich

Projektplanung und -steuerung

Aktivität

Projekt planen

Ziele

  • Effiziente Testausführung
  • Vermeidung von doppelter Arbeit

Kurzbeschreibung

Diese Best Practice beschreibt Möglichkeiten, wie der Test ausgerichtet werden kann. Zudem wird der Fokus der einzelnen Teststufen im Testprozess definiert und wie diese Teststufen ineinander greifen, um doppelte Prüfungen zu vermeiden. Zu den Teststufen gehören in der Regel der Entwicklertest (Modultest), der Integrationstest, der Systemtest und der Akzeptanztest. Jede dieser Teststufen hat einen bestimmten Fokus und sollte für bestimmte Zwecke genutzt werden. Die durch eine Teststufe abgedeckten Prüfungen müssen auf anderen Teststufen nicht mehr wiederholt werden. In einer Teststrategie, die für das Projekt erstellt wird, sowie eine Detailplanung für jeden Sprint, sollte das Vorgehen frühzeitig definiert werden, um eine effiziente Testausführung zu gewährleisten.

Download: PQ4Agile - AP 2.2 - Teststrategie festlegen und Teststufen aufeinander abstimmen (V.1)

Best Practices – Supporting Practices

Checklisten verwenden

Bereich

Projektplanung und -Steuerung

Aktivität

Projekt koordinieren

Ziele

  • Abläufe strukturieren und standardisieren
  • Effizienz und Ergebnisqualität von (Routine-)Arbeiten steigern
  • Delegieren von Arbeiten vereinfachen

Kurzbeschreibung

Checklisten enthalten in korrekter Reihenfolge die Handlungsanweisungen bzw. Abfrageparameter, die zum Durchführen einer bestimmten Maßnahme erforderlich sind. Sie können als Arbeitshilfe verwendet werden, um sich wiederholende Abläufe zu strukturieren, zu kontrollieren und zu dokumentieren.

Download: PQ4Agile - AP 2.2 - Checklisten verwenden (V.2)
Standardisierte Dokumentstrukturen verwenden

Bereich

Realisierung

Aktivität

Dokumentation erstellen

Ziele

  • Erstellung technischer Dokumentation vereinfachen
  • Qualität und Lesbarkeit von Dokumenten erhöhen
  • Vollständigkeitsprüfung von Dokumenten erleichtern

Kurzbeschreibung

Die Verwendung standardisierter Dokument- und Inhaltsstrukturen vereinfacht die Erstellung vollständiger Dokumente und die Wiederverwendung bestehender Dokumentinhalte. Standardisierte Strukturen helfen dabei, die Qualität der internen und externen Produktdokumentation zu verbessern. Ein konsistenter Aufbau, der über alle Dokumente bzw. Dokumentarten hinweg verwendet wird, sorgt zudem für eine wesentlich einfachere Nutzung der Dokumente.

Download: PQ4Agile - AP 2.2 - Standardisierte Dokumentstrukturen verwenden (V.2)