10 Möglichkeiten, mit agilen Qualitätspraktiken Zeit zu sparen

Der Wunsch, agil zu werden, kommt typischerweise aus der Entwicklung. Immerhin wurde Agilität geschaffen von Entwicklern für Entwickler. Ohne eine robuste Strategie für agile Qualität, die die Anforderungen des Unternehmens effektiv erfüllt, bleiben agile Teams jedoch weiterhin im Amt.

Um dies zu vermeiden, können Sie bekannte agile Qualitätspraktiken erweitern, um sicherzustellen, dass Ihre Software die Geschäftsanforderungen effektiv und effizient erfüllt. Hier ist wie:

1. Erweitern Sie die Qualität über die Qualitätssicherung hinaus

Bei der agilen Entwicklung muss jeder im Team, vom Entwickler bis zum Produktmanager, die Qualität während des gesamten Prozesses genau kennen, wobei Qualitätsbedenken ein wesentlicher Bestandteil des täglichen Arbeitsablaufs sind und mehrere Qualitätsaufgaben gleichzeitig ausgeführt werden. Dies ermöglicht Schnellere Erkennung und Behebung von Fehlern… Reduzierung von Zeit, Aufwand und Kosten, die zur Beseitigung jedes Fehlers erforderlich sind.

Beispielsweise können zu einem bestimmten Zeitpunkt die folgenden Aufgaben gleichzeitig ausgeführt werden:

• Qualitätssicherung Durchführen von Funktionstests auf hoher Ebene für eine Anforderung für die aktuelle Iteration.
• Entwickler schreiben Unit-Tests und Code für einen anderen.
• Ein Produktmanager, der sich Sorgen über die allgemeine Zuverlässigkeit / Leistung des Produkts macht und die Qualitätspolitik des Teams an diese Bedenken anpasst.

Um die Qualität in die täglichen Aktivitäten der verschiedenen Teammitglieder zu integrieren, können Sie diese Aufgabenverteilung verfolgen:

Rollen	Aufträge
Entwicklungsmanager / Scrum Masters	Verteilungsanforderungen Festlegen von Codierungsrichtlinien Festlegen der Richtlinien für Entwicklungstests Schätzung der Entwicklungskosten Überwachung der laufenden Arbeiten
Entwickler	Leseanforderungen Anforderungen umsetzen Tracking-Zeit Verfolgen von Änderungen Testanforderungen Teilnahme an Peer-Code-Überprüfungen Befolgen Sie die Qualitätspolitik
QS-Tester	Überprüfung der Entwicklertestbemühungen Zusätzliche Prüfung der Anforderungen durchführen Während der Entwicklung iterativ arbeiten Fehler schnell erkennen und melden Untersuchung der Fehlerursache Einfluss auf die Entwicklungspolitik
Produktmanager	Schreibanforderungen Fristen festlegen Überwachung von Fortschritt und Kosten Überwachung des Qualitätsstatus auf hoher Ebene Anpassen von Anforderungen und Zeitplänen

2. Umfassen Sie Richtlinien als Team

Richtlinien werden traditionell nicht mit agilen Entwicklungstests in Verbindung gebracht, und viele reine „Agilisten“ befürchten, dass der gesamte Begriff der Richtlinie der kollaborativen, leichtgewichtigen Natur agiler Prozesse widerspricht. Wir haben jedoch festgestellt, dass viele Teams, die mit agilen Entwicklungsmethoden arbeiten, es tatsächlich schätzen, klare Erwartungen daran zu haben, wie Code geschrieben und getestet werden sollte. Da die Erwartungen klar definiert sind, muss das Team keine Zeit damit verschwenden, genau herauszufinden, was wann erwartet wird – oder den Code ständig zu überarbeiten, um Missverständnisse zu beheben.

Sie können beginnen, indem Sie eine Richtlinie implementieren, die einfach die Kodierungs- und Qualitätspraktiken formalisiert, die das Team bereits befolgt. Ausgehend von dieser Basis können Sie dann schrittweise neue Richtlinien einführen, die das Team besprochen hat und deren Einhaltung zugestimmt hat.

Mögliche Richtlinienänderungen können dann in täglichen Stand-up-Meetings oder bei Codeüberprüfungen besprochen werden. Auf diese Weise können Teammitglieder wertvolles Feedback zu Richtlinienverfeinerungen (z. B. Feinabstimmung einer statischen Analyseregel, um bestimmte Ausnahmen zuzulassen) und Erweiterungen (z. B. zusätzliche Testabdeckung für ein Modul, das von der Qualitätssicherung als besonders fehlerhaft gemeldet wird) geben.

Neben der Sicherstellung, dass das gesamte Team an Bord ist, ist dies auch wichtig Stellen Sie sicher, dass die Durchsetzung der Richtlinien als Leitfaden und nicht als Eingriff dient. Im Idealfall überprüft eine automatisierte Infrastruktur die Einhaltung automatisch im Hintergrund und funktioniert unsichtbar, sofern die vereinbarten Erwartungen nicht erfüllt werden. Zu diesem Zeitpunkt wird herausgefunden, welches Teammitglied benachrichtigt werden soll, und es wird daran erinnert, die Aufgaben auszuführen, die erforderlich sind, um die vereinbarten Erwartungen zu erfüllen.

Im Wesentlichen funktioniert die automatisierte Infrastruktur wie ein EKG-System, das an einen Krankenhauspatienten angeschlossen ist und ständig die elektrische Aktivität misst. Wenn alles in Ordnung ist, läuft es unauffällig im Hintergrund. Wenn die Messwerte jedoch flach werden, werden Alarme ausgelöst und die Leute verstehen, dass Maßnahmen erforderlich sind.

3. Verwenden Sie automatisierte Tests, um vor der Qualitätssicherung so viele Fehler wie möglich zu erkennen

Wenn Fehler, die auf schlecht implementierten Code zurückzuführen sind, ständig an die Qualitätssicherung weitergeleitet werden, führt dies letztendlich zu:

• Weniger gründliche Abnahmetests durch die Qualitätssicherung,
• Häufige / lange QS-Zyklen, die sich auf die Iterationsfrist und den Iterationsumfang auswirken, und / oder
• Fehler, die in die freigegebenen Produkte eindringen und dann während der für eine nachfolgende Iteration vorgesehenen Zeit behoben / gepatcht werden müssen.

Viele solcher Fehler könnten durch vollständig automatisierte Entwicklungstests erkannt werden – Tests, die auf dem Integrationsserver oder vom Desktop aus mit einem einzigen Klick durchgeführt werden können.

Der Ausgangspunkt ist eine effektive Codierungsrichtlinie und deren Umsetzung mit einer statischen Codeanalyse. Die statische Codeanalyse sucht nach bekannten Anti-Patterns in Quellcodekonstrukten und meldet jedes Vorkommen einer Übereinstimmung. Es ist schnell durchführbar und findet garantiert alle Fälle von Code, die einem Muster entsprechen.

Defensive Codierung kann Code gegen viele Kategorien von Fehlern immun machen, einschließlich vieler Fehler, die beim Testen äußerst schwer zu erkennen sind, indem ihre Grundursachen beseitigt werden.

Zum Beispiel können Sie viele Ursachen verhindern für:

• Ausnahmen
• Blockaden
• Rennbedingungen
• Verpasste Benachrichtigungen
• Endlosschleifen
• Initialisierungsprobleme
• Probleme mit der Speichernutzung
• Serialisierungsprobleme
• Datenkorruption
• Ressourcen- und Speicherlecks

Nicht jede Art von Defekt kann durch statische Code-Analyse verhindert werden. Aber Jeder Fehler, den Sie verhindern können, ist ein Fehler weniger, der die Iteration des Teams verlangsamt. Die Qualitätssicherung muss den Fehler nicht mehr finden und dokumentieren. Die Entwicklung muss nicht mehr aufhören, was sie gerade tun, den Speicher des problematischen Codes auffrischen, den Code reparieren und überprüfen, ob das Problem behoben ist. Und die Qualitätssicherung muss die Modifikation des Entwicklers nicht erneut testen.

Probieren Sie die folgenden Techniken aus, um die Arten von Fehlern zu finden, die über den Rahmen der statischen Analyse hinausgehen. Beide erfordern keinen zusätzlichen manuellen Aufwand:

• Run statische Analyse des Datenflusses über Nacht. Die Datenflussanalyse simuliert statisch Anwendungsausführungspfade, die mehrere Einheiten, Komponenten und Dateien umfassen können. Es ist wie beim Testen, ohne den Code tatsächlich auszuführen. Mit dem Datenfluss können Sie eine große Anzahl von Ausführungspfaden „testen“, ohne einen einzelnen Testfall schreiben oder ausführen zu müssen.
• Ermöglichen Laufzeitfehlererkennung wie Ihre vorhandenen Funktionstests ausgeführt werden (Komponententests und manuelle oder Skript-Tests). Auf diese Weise können Sie kritische Fehler aufdecken, die nur zur Laufzeit auftreten (z. B. Überschreiben von Dateien), und die Hauptursache für den Absturz, die langsame Ausführung oder das unvorhersehbare Verhalten der Anwendung ermitteln. Die Ergebnisse zeigen Fehler an, die tatsächlich während der Ausführung aufgetreten sind. Somit werden Mängel mit beispielloser Genauigkeit gemeldet.

Darüber hinaus empfehlen wir dringend Peer-Code-ÜberprüfungDies ist zwar mühsam, aber der einzig wirksame Weg, um Fehler auf hoher Ebene in Bezug auf Logik, Design usw. aufzudecken. In Tipp 10 werden einige Möglichkeiten zur Verwendung der Automatisierung zur Optimierung von Codeüberprüfungen erläutert.

4. Entwickeln Sie Ihre Qualitätsrichtlinie kontinuierlich als Reaktion auf erkannte Fehler

Wenn Ihre Entwickler- oder QS-Testbemühungen Fehler aufdecken, die über die Qualitätsrichtlinien Ihres Teams hinausgehen, Beheben Sie nicht nur diesen einen Defekt und fahren Sie fort.

Dies ist wie ein Automobilhersteller, der bemerkt, dass ein Auto mit einer fehlerhaften Bremsinstallation vom Band lief, die Bremsen eines Autos repariert und hofft, dass das Problem nicht erneut auftritt. Ein sicherer Ansatz - der auf lange Sicht viel Zeit, Ärger und Kummer sparen würde - wäre die Untersuchung des Fließbandes. Stellen Sie fest, wie das Problem verursacht wurde, und beheben Sie die Grundursache.

In Bezug auf den Softwareentwicklungsprozess umfasst dieser Ansatz die Zusammenarbeit mit der Entwicklung und die Qualitätssicherung, um:

1. Isolieren Sie die Grundursache dieser allgemeinen Art von Defekt.
2. Bestimmen Sie, wie der Entwicklungsprozess geändert werden soll um es zu verhindern.
3. Bestimmen Sie, wie gemessen werden soll wenn das die Modifikation tatsächlich geübt wird.

In vielen Fällen a Änderung der Codierungsrichtlinien wird den Trick machen: von Aktivieren oder Neukonfigurieren bestimmter statischer Analyseregeln, können Sie alle anderen Instanzen von vorhandenem Code finden, der für denselben Fehlertyp anfällig ist – und Sie können auch sicherstellen, dass neuer oder geänderter Code die bekannten Fallstricke umgeht. Häufig Laufzeitfehlererkennung und Datenfluss statisch Code-Analysatoren weisen Sie sogar auf die genauen statischen Analyseregeln hin, die Sie befolgen können, um die spezifischen Fehler zu vermeiden, die sie aufdecken.

Andere Male die Auflösung Möglicherweise müssen Sie die Art und Weise ändern, in der Code entwickelt, getestet oder einer Liste von Elementen hinzugefügt wird, die bei manuellen Codeinspektionen überprüft werden sollen.

Letztendlich immunisiert dies Ihren Softwareentwicklungstestprozess gegen viele Ihrer häufigsten Softwarefehler.

5. Verwalten Sie die Codekomplexität

Da sich immer wieder herausstellt, dass übermäßig komplexer Code langsamer, schwieriger und riskanter zu aktualisieren und zu erweitern ist als einfacherer Code, ist es hilfreich, sich auf komplexen Code zu konzentrieren - beispielsweise auf jede Klasse oder Methode, deren zyklomatische Komplexität vorliegt 10 oder höher. Dieser Code könnte im Moment gut funktionieren, aber er könnte dem Team später erhebliche Sorgen bereiten, wenn eine scheinbar einfache Funktionserweiterung ein umfangreiches Umschreiben erfordert.

Verwenden Sie die Metrikberechnungen für eines Ihrer einfach zu wartenden Projekte als Richtlinie, legen Sie realistische Grenzen und Schwellenwerte für ausgewählte Metriken fest und stellen Sie dann sicher, dass die Teammitglieder benachrichtigt werden, wenn die Metriken außerhalb des vorgeschriebenen Bereichs liegen. Dies reduziert den Zeit- und Arbeitsaufwand für das Ändern und Erweitern von Code in nachfolgenden Iterationen. Es wird auch neuen Entwicklern helfen, schneller auf den neuesten Stand zu kommen.

6. Erweitern Sie TDD- und Funktionstests mit automatisch generierten Regressionstests

Wenn Sie bereits testgetriebene Entwicklung (TDD) und kontinuierliche automatisierte Regressionstests praktizieren, haben Sie eine hervorragende Grundlage, um festzustellen, wann Änderungen Ihre zuvor validierte Funktionalität ändern oder beschädigen. Wenn Sie jedoch wirklich sicher sein möchten, dass Ihre Änderungen dies nicht tun Ändern oder Unterbrechen eines Anwendungsverhaltens, das Sie nicht explizit mit Ihren TDD-Testfällen getestet haben, umfangreicher Regressionstests benötigt.

Erweiterung der TDD Test Suite

Eine Möglichkeit besteht darin, viel Zeit damit zu verbringen, viele weitere Testfälle zu schreiben. Aber wer hat Zeit dafür? Ein viel einfacherer Ansatz ist es, automatisch Generieren Sie eine Reihe von Regressionstests, mit denen Sie das Anwendungsverhalten überprüfen können:  

• Generieren Sie automatisch eine Basislinie indem Sie Testfälle erstellen, die die aktuelle Funktionalität des Projektcodes erfassen. In den meisten Fällen kann eine solche Testsuite über Nacht mit generiert werden automatisierte Unit-Testing-Tools. Da Ihr Ziel darin besteht, eine Verhaltensgrundlage festzulegen, anstatt die aktuelle Funktionalität der Anwendung zu überprüfen, Es ist nicht erforderlich, die generierten Tests oder Behauptungen tatsächlich zu überprüfen oder gar zu betrachten/ Beobachtungen / Ergebnisse erzielt.

• Erkennen Sie Änderungen von dieser Basislinie indem Sie diese Tests regelmäßig für Ihre sich entwickelnde Codebasis ausführen. In der Regel ist dies so einfach wie das Hinzufügen dieser neuen Testfälle zu Ihrer aktuellen automatisierten Regressionstestinfrastruktur. Bei nachfolgenden Testläufen Testfehler werden nur gemeldet, wenn das aktuelle Codeverhalten nicht mit dem erfassten Verhalten übereinstimmt in der Baseline-Testsuite.

Das Ergebnis ist ein Einfache und effiziente Methode, um festzustellen, wann und wie sich Ihre Codeänderungen auf Ihren Code auswirken-Sogar die Teile der Anwendung, die nicht durch die von Ihnen manuell geschriebenen Funktions- / TDD-Tests abgedeckt sind.

Synchron bleiben

Die einzige Arbeit, die erforderlich ist, besteht darin, die Testsuite mit Anwendungsänderungen synchron zu halten. Wenn Entwickler jeden Morgen zur Arbeit kommen, überprüfen sie alle für ihren Code gemeldeten Testfehler und reagieren darauf. Dabei werden sie Beheben Sie entweder Funktionsfehler in ihrem Code oder aktualisieren Sie die Testsuite, um das korrekte Verhalten des Codes widerzuspiegeln.

7. Reduzieren Sie die Komplexität von Entwicklertests

Die Systeme, die agile Teams heute aufbauen, werden immer größer und komplexer. Infolge. Entwickler haben häufig Schwierigkeiten, die spezifischen Komponenten zu testen, an denen sie gearbeitet haben, da diese Komponenten als Teil komplizierter Systeme arbeiten-Sie sind mit der Außenwelt verbunden, Staging-Systeme sind schwer einzurichten und zu warten, jeder Test erfordert eine beträchtliche Einrichtung und so weiter. Es ist möglicherweise möglich, einen Test einmal auszuführen, aber Sie müssen wirklich alle Tests Ihres Teams täglich ausführen, damit Sie sofort benachrichtigt werden, falls Ihre ständigen Änderungen die zuvor überprüften Funktionen beeinträchtigen.

Mithilfe der Testfallverfolgung kann das Team Teile der Anwendung kontinuierlich testen, ohne sich um das komplizierte System kümmern zu müssen. Mithilfe einer Ablaufverfolgungstechnologie wie Parasoft Tracer können Sie Unit-Testfälle erstellen, die die in den Anforderungen angegebenen Funktionen erfassen.

Über die Anwendungs-GUI oder mithilfe eines SOA- oder Web-Test-Clients üben Sie Ihre Anwendungsfälle nur aus, während die Ablaufverfolgung aktiviert ist. Während der Ausführung des Anwendungsfalls überwacht die Technologie alle erstellten Objekte, alle ein- und ausgehenden Daten und erstellt dann eine Gerätetest das stellt diese Operation dar - und stellt sogar die richtigen Anfangsbedingungen ein.

Sie können dies dann nehmen Unit-Testfall und führen Sie es auf einem separaten Computer außerhalb des ursprünglichen Systems aus. Das bedeutet, dass Sie können einen einzelnen Computer verwenden, z. B. den Continuous Integration Server oder sogar einen Standard-Entwickler-Desktop, um das Verhalten eines komplizierten Systems während des Überprüfungsvorgangs zu reproduzieren. Fügen Sie alle diese Tests zu Ihrer Regressionstestsuite hinzu, führen Sie sie kontinuierlich aus, und Sie werden sofort benachrichtigt, wenn diese von Ihnen erfasste Funktionalität durch Ihre Codeänderungen beeinträchtigt wird.

Dies hilft Ihnen im Wesentlichen dabei, die Komplexität heutiger Systeme auf zwei Arten anzugehen:

• It richtet automatisch realistische Testbedingungen einDies entlastet Sie von der zeitaufwändigen und mühsamen Arbeit, die sonst erforderlich wäre, um dies zu erreichen.
• It gibt Ihnen einen Testfall, den Sie getrennt vom System ausführen können- Ein Testfall, den Sie kontinuierlich und vollautomatisch ausführen können.

8. Reduzieren Sie die Komplexität von End-to-End-Tests durch Service-Virtualisierung

Agile Teams arbeiten üblicherweise an verteilten heterogenen Anwendungen (z. B. SOA, Web, Cloud) Eine oder mehrere Komponenten sind unvollständig, entwickeln sich, sind instabil, unzugänglich oder auf andere Weise nicht zum Testen verfügbar. Agile Methoden erfordern kontinuierliche und automatisierte (wenn möglich) Regressionstests, aber Wie können Sie jeden Abend automatisierte End-to-End-Funktionstests durchführen, wenn Teile des zu testenden Systems nicht ohne weiteres verfügbar sind?? Wenn Sie den Test verzögern, bis alles zum Testen bereit und verfügbar ist, besteht die Gefahr, dass Sie in ein wasserfallähnliches Paradigma geraten.

Eine Möglichkeit, diese Herausforderung anzugehen, besteht darin, emulieren das Verhalten der notwendigen Komponenten. Im Wesentlichen konstruieren und implementieren Sie virtualisierte Assets, die Anwendungsverhalten, Leistung und Daten emulieren (virtualisieren). Dies wird durch die Anwendung eines Konzepts erreicht, das als Service-Virtualisierung bekannt ist.

Die Dienstvirtualisierung wurde entwickelt, um das Verhalten nicht verfügbarer und sich weiterentwickelnder Webdienste zu emulieren, und wurde dann über die kanonischen Dienstprotokolle hinaus entwickelt, um mehrere Nachrichtentypen und -protokolle zu unterstützen - JDBC, MQ, JMS und mehr. Diese erweiterte Service-Virtualisierung reduziert die Konfigurationszeit, den Hardware-Overhead und den Datenverwaltungsaufwand für das Aufstehen und Verwalten einer realistischen und nachhaltigen Entwicklungs- / Testumgebung drastisch.

Die ideale Service-Virtualisierung sollte auf virtualisierte Assets abzielen, die Folgendes können:

• Ersetzen Sie die verschiedenen Endpunkte in der Systemarchitektur (Dienste, Anwendungen, Mainframes, gespeicherte Prozeduren usw.) sowie emulieren das Anwendungsverhalten auf Einheitenebene.
• Be zur Testumgebung hinzugefügt um das Verhalten verschiedener Komponenten zu ersetzen, die andernfalls die Fähigkeit Ihres Teams beeinträchtigen würden, den End-to-End-Geschäftsprozess effektiv auszuüben und zu validieren.
• Be verwaltet und in einer Teamumgebung geteiltund einfach zwischen gemeinsam genutzten Servern und Benutzerdesktops auszurollen. Geschäftsdaten, die von den virtualisierten Assets verwendet werden, können problemlos mit Tabellenkalkulationen oder verschiedenen anderen Datenquellen verwaltet werden.

Mit solchen virtualisierten Assets können Sie Ersetzen Sie abhängige Systeme, Methoden oder Komponenten Dies würde ansonsten die Fähigkeit des Teams beeinträchtigen, die zu testenden Anforderungen effektiv zu validieren oder zu überprüfen, ob erkannte Probleme effektiv gelöst wurden.

Stellen Sie sich beispielsweise ein dienstbasiertes Kontobereitstellungssystem vor, bei dem Aufträge verloren gehen. Um dieses Problem zu lösen, muss das Entwicklungsteam die feste Anwendung in einer sicheren Sandbox testen, die die Transaktionsabläufe der Produktionsumgebung emuliert. Andernfalls besteht die Gefahr, dass das System bei der erneuten Bereitstellung der Anwendung beschädigt wird. Mithilfe der Emulation kann das Team seine Dienste im Kontext ausüben, ohne die normalen Geschäftstransaktionen der Partner zu beeinträchtigen.

Dieses Konzept ist nicht neu, wird jedoch immer wichtiger, da Unternehmenssysteme immer verteilter und heterogener werden. Darüber hinaus macht es diese erhöhte Komplexität erforderlich, das Konzept der Emulation zu erweitern, um über die Dienste hinauszugehen und auch andere wesentliche Systemkomponenten - beispielsweise die Datenbank, die Webschnittstelle, den Broker usw. - einzubeziehen und die zu emulieren verschiedene Protokolle, die üblicherweise in solchen Systemen nebeneinander existieren.

9. Testen Sie den Test nur nach Bedarf

Obwohl agile Methoden nach Möglichkeit automatisierte Tests empfehlen, Es ist immer ein gewisses Maß an manueller Prüfung erforderlich. Jedes Mal, wenn die Anwendung aktualisiert wird, wiederholt das QA-Team in der Regel entweder alle manuellen Tests oder verbringt viel Zeit damit, herauszufinden, welche dieser Testfälle mit dem geänderten Anwendungsteil zusammenhängen könnten. In jedem Fall wird viel Zeit verschwendet.

Mit änderungsbasierten Tests kann das Team sofort erkennen, welche Anforderungen von den jüngsten Änderungen betroffen sind und welche Tests müssen erneut ausgeführt werden. Dies spart enorm viel Zeit und Ressourcen für die Qualitätssicherung, die besser für Aufgaben mit Mehrwert eingesetzt werden könnten.

Um änderungsbasierte Tests zu ermöglichen, Anforderungen werden automatisch mit Tests, Quellcode und Entwicklungs- / Testaufgaben korreliert. Mit diesen Korrelationen kann der aktuelle Überprüfungsgrad für jede Anforderung oder Aufgabe (einschließlich des Bestehens / Nichtbestehens der Aufgabe und der Abdeckung) jederzeit durch Rückverfolgung auf alle zugehörigen Tests bewertet werden.

Darüber hinaus kann das Team sofort eine objektive Bewertung von erhalten Welche Anforderungen funktionieren tatsächlich wie erwartet, welche Fehler werden behoben und welche Anforderungen und Fehler müssen noch getestet werden. Diese Echtzeit-Übersicht über den tatsächlichen Anforderungs- und Fehlerstatus hilft Ihnen, Überraschungen im späten Zyklus zu vermeiden, die Zeitpläne und Budgets zu entgleisen drohen.

10. Verwenden Sie die Automatisierung, um Stand-Up-Meetings zu optimieren

Stand-up-Meetings sind ein wichtiger Bestandteil agiler Prozesse - und ein ideales Forum, um Qualitätsprobleme an der Spitze der Entwicklung zu halten. Um diese Besprechungen auf der empfohlenen Länge von 15 Minuten zu halten (und dennoch etwas Zeit für die Qualitätssicherung zu haben), ist es wichtig, rationalisieren, was abgedeckt ist und  Nehmen Sie mehr involvierte Themen "offline".

Zwei Strategien, mit denen Sie diese Besprechungen optimieren können, sind:

• Automatisierte Aufgabenverteilung und -verfolgung.
• Automatisierter Peer-Code-Überprüfungsworkflow.

Automatisierte Aufgabenverteilung und -verfolgung

Viele der langweiligsten und langwierigsten Aspekte von Stand-up-Meetings können durch automatisierte Aufgabenverteilung und -überwachung beseitigt werden.

Mithilfe eines Softwareentwicklungs-Managementsystems wie Parasoft DTP wandelt der Manager oder Scrum Master Anforderungen und Probleme in umsetzbare, messbare Arbeitsaufgaben um, die dann automatisch direkt an die IDE des verantwortlichen Entwicklers verteilt werden (gemäß manuellen Zuweisungen oder vordefinierten Richtlinien).

Wenn ein Entwickler bereit ist, mit der Arbeit an einer zugewiesenen Aufgabe zu beginnen, markiert er sie als "in Bearbeitung", bearbeitet die Aufgabe wie gewohnt und markiert sie dann als "erledigt", wenn sie abgeschlossen ist. Ohne den Workflow des Entwicklers zu unterbrechen, können Sie automatisch verfolgen, welche Dateien sich auf die jeweilige Aufgabe beziehen und wie viel Zeit für die Arbeit an diesen Dateien aufgewendet wird. Echtzeit-Statusinformationen sind immer im System verfügbar.

Das Tracking ist der Schlüssel zur Bewertung des aktuellen Fortschritts und der Kapazität des Teams in Vorbereitung auf die Stand-up-Meetings. Außerdem hält es die QA gut darüber auf dem Laufenden, was zum Testen bereit ist.

Peer Code Review Workflow-Automatisierung

Die Überprüfung des Codes erfordert in der Regel lange und langwierige Besprechungen, die einen enormen Vorbereitungsaufwand erfordern. Ein automatisiertes Codeüberprüfungssystem kann dem Team dabei helfen, Codeüberprüfungen automatisch zu optimieren:

1. Identifizieren aktualisierter Code von der Quellcodeverwaltung oder dem lokalen Dateisystem.
2. Abstimmung den Code mit ausgewiesenen Gutachtern.
3. Alarmieren der Prüfer & erlaubt ihm, den Code in seiner IDE zu überprüfen.
4. POSITIONIERUNG den Fortschritt jedes Überprüfungselements bis zum Abschluss.

Das Team ist dann Es steht Ihnen frei, sich auf die eigentliche Begutachtung durch Fachkollegen zu konzentrieren: Ein kreativer Prozess, der nicht automatisiert werden kann (und sollte).

Codeüberprüfungen müssen nicht unbedingt jede Codezeile abdecken. Einige Teams ziehen es beispielsweise möglicherweise vor, nur die gefährlichsten Segmente ihres Codes zu überprüfen (z. B. die sicherheitsrelevantesten oder Deadlock-anfälligsten Bereiche der Codebasis). Die Erwartungen bezüglich der Codeüberprüfung sollten mit dem Team besprochen und in der Qualitätsrichtlinie festgelegt werden.