Führung im Test: Testplanung
Hinweis der Redaktion: Willkommen bei der Leadership-In-Test-Reihe des Gurus und Beraters für Softwaretests Paul Gerrard. Die Reihe soll Testern mit einigen Jahren Erfahrung – insbesondere solchen in agilen Teams – dabei helfen, in ihren Rollen als Testleiter und in Managementfunktionen erfolgreich zu sein.
Im vorherigen Artikel haben wir uns eingehend mit der Dokumentation und einigen Best Practices beschäftigt. Dieses Mal wenden wir viele der Erkenntnisse aus den vorherigen Artikeln an und nutzen sie, um ein Testprojekt zu planen.
Melden Sie sich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Reihe veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership-In-Test-Kurs, den wir wärmstens empfehlen, um tiefer in dieses und andere Themen einzusteigen. Wenn Sie das tun, verwenden Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie 60 $ vom vollständigen Kurspreis!
Was ist ein Plan überhaupt?
Ein Projektplan fasst die Projektaufgaben, geschätzten Zeiträume, Abhängigkeiten und Ergebnisse zu einem terminierten Modell der Realität zusammen.
Wenn Sie den Plan als Vorhersage der Zukunft betrachten, wären Sie sehr vorsichtig damit, sich auf ihn zu verlassen – aber genau das tun wir normalerweise.
Vielleicht sind Sie Projektmanagern begegnet, die ihren Plan als ihre persönliche Realität betrachten – als ihre eigene wahnartige Welt. Wir sollten jedoch nicht zu hart mit Projektmanagern sein – sie sind oft motiviert, einen Plan zu erstellen und ihn um jeden Preis umzusetzen.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Der Plan ist nicht die Realität, sondern ein Modell der Realität, das ständige Änderungen erfordert.
In diesem Artikel behandle ich jede Phase der Testplanung, einschließlich:
- Ergebnisse
- Wie
- Ressourcen
- Ihr Unterstützungsnetzwerk
- Schätzungen
- Abhängigkeiten, Risiken und Annahmen
- Kommunikation, Verbindlichkeit und Fortschrittsberichte
Aber zunächst sollten wir uns ein klares Bild vom Nutzen eines Plans machen.
Warum planen?
Der Zweck der Planung besteht normalerweise darin, einen abgestimmten Ansatz, eine Reihe von Verpflichtungen, Abhängigkeiten, Kosten und einen Zeitplan für die Durchführung eines Projekts zu erstellen. Der Plan ist eine Vereinbarung zwischen Projektbeteiligten, Lieferanten und Teilnehmern, in der typischerweise Folgendes festgelegt wird:
- Welche Ressourcen wann benötigt werden
- Wann Aufgaben beginnen und enden müssen und wer sie ausführt
- Welche Fähigkeiten zum Abschluss der Aufgaben erforderlich sind
- Welche Werkzeuge und Technologien den Plan unterstützen
- Welche Ergebnisse geliefert werden und wann sie geliefert werden
- Die Kosten für den erforderlichen Aufwand und die benötigten Ressourcen
- Der Prozess, mit dem das Projekt bzw. der Prozess durch seine Phasen vorangebracht wird
- Die Risiken, die die Lieferung gefährden.
Einige dieser Aspekte könnten in einer Strategie festgelegt oder bereits vorhanden sein. Beispielsweise könnte bekannt sein, welche Lieferanten beteiligt sind und was sie für das Projekt tun werden. Die zu verwendenden Werkzeuge und Technologien sind möglicherweise bereits bekannt und vorhanden. Die Personen, Testumgebungen und Daten könnten bereitstehen. Möglicherweise gibt es auch eine Strategie, die den zu verwendenden Prozess, Ansatz oder die entsprechenden Techniken definiert.
Während die Strategie jedoch die Prinzipien oder die Theorie darlegt, beschreibt der Plan die praktischen Aspekte oder die Logistik dafür, wie das Projekt in der Realität umgesetzt wird.
Eine Strategie legt fest, wie ein Projekt grundsätzlich durchgeführt wird; der Plan definiert und bestätigt, wie das Projekt in der Praxis durchgeführt wird.
Für viele Projektmanager wird der Plan in Software wie Microsoft Project verwaltet. Ein tragfähiger Plan hängt jedoch davon ab, dass alle Projektbeteiligten wissen, was sie tun und wie sie es tun sollen. Um dies zu erreichen, müssen der Plan und das Wissen darüber, wie die Aufgaben erledigt werden, allen Beteiligten vermittelt werden und von ihnen mitgetragen werden.
Planung ist eine Reise, keine Aufgabe
Um den ehemaligen US-Präsidenten Dwight D. Eisenhower zu zitieren: „Planung ist alles. Der Plan ist nichts.“ Diese Aussage ist so wichtig, dass sie sich in nahezu jedem Arbeitskontext bei Systemprojekten wiederholen lässt. Aber was bedeutet es, zu sagen, der Plan sei nichts? Welchen Sinn hat Planung, wenn das Ergebnis ein wertloser Plan ist?
Der Plan, mit dem man letztendlich arbeitet, ist niemals wertlos, aber Eisenhowers Aussage bezieht sich auf den Akt der Planung und dessen Wert im Vergleich zum Plan. Vergleichen wir kurz, wie Planung in längeren strukturierten Projekten und in agilen bzw. kontinuierlichen Projekten jeweils funktioniert.
Strukturierte Planung im Vergleich zur agilen Planung
In einem längerfristigen Projekt müssen Ihr Unternehmen, Ihre Lieferanten und die internen IT-Mitarbeiter wissen, welches Engagement von ihnen erforderlich ist, damit sie die Verfügbarkeit von Personal und physischen Ressourcen planen können.
Es kostet wertvolle Zeit, die erforderlichen Informationen für die Erstellung eines Plans zusammenzutragen. Aufgrund all der Abhängigkeiten von Ressourcen und Personen sowie der Zusagen und Leistungen von Lieferanten und internen Mitarbeitern kann vieles schiefgehen. Manches wird schiefgehen. Deshalb ist der Plan als Vorhersage der Zukunft mit erheblichen Schwierigkeiten behaftet.
Am Tag, nachdem ein Plan veröffentlicht wurde, und an jedem darauffolgenden Tag, kommen neue Informationen ans Licht und manche Anpassung wird erforderlich. Anforderungen werden gestrichen; Lieferanten liefern zu spät; Umgebungen, Testdaten oder Werkzeuge sind nicht rechtzeitig bereit. Die Liste ließe sich fortsetzen. Planung ist niemals eine einmalige Aufgabe, sondern eine kontinuierliche — beinahe tägliche —Tätigkeit.
Ungeplante Ereignisse werden oft als Störgeräusche behandelt und erhalten nicht viel Aufmerksamkeit. Später werden einige dieser kleineren Störungen jedoch zu größeren Problemen. Eine der Herausforderungen von Wasserfallprojekten besteht darin, dass diese kontinuierliche Anpassung belastend sein kann, weil Änderungen als unnötige Einmischung betrachtet werden. Projekte laufen häufig ungeachtet dessen weiter, in der Hoffnung, dass am Ende schon alles „gut gehen“ wird. Das ist jedoch selten der Fall, und es wurde schon oft gesagt:
Wie kommt es dazu, dass ein Projekt ein Jahr zu spät fertig wird? Einen Tag nach dem anderen.
Der agile Ansatz ist teilweise eine Reaktion auf die Frustration über festgelegte oder unflexible Pläne. Agilität ist die bewährte Alternative zur Trägheit schwerfälliger, in Phasen gegliederter Ansätze. Bedeutet das aber, dass es in agilen Projekten keine Planung gibt? Nein.
Auch in agilen Projekten ist eine gewisse Vorabplanung erforderlich, um die Arbeit zu strukturieren, Ressourcen zu mobilisieren und den Veröffentlichungsprozess für die kommenden Monate — zumindest auf hoher Ebene — zu terminieren. Doch von Iteration zu Iteration und oft von Tag zu Tag wird der Gesamtplan kontinuierlich angepasst, um Ereignisse und neue Informationen zu berücksichtigen, die ans Licht kommen.
Planung ist eine kontinuierliche Lernreise, keine Aufgabe mit einem abzuliefernden Ergebnis.
Testplanung
Bisher haben wir die Projektplanung insgesamt betrachtet und dargelegt, dass sie eine weitgehend kontinuierliche Tätigkeit ist. Nun konzentrieren wir uns speziell auf die Planung von Tests in Projekten.
Die Testplanung ist der Projektplanung sehr ähnlich — es handelt sich im Grunde einfach um einen Plan kleineren Maßstabs. Natürlich muss der Testplan auch in den größeren Projektplan integriert werden, da er von anderen Projektaktivitäten und Liefergegenständen abhängig ist (und andere Aufgaben wiederum von den Tests abhängen). Häufig werden Testpläne gestört, weil diese Abhängigkeiten nicht erfüllt werden.
Testpläne sind in der Übersicht relativ einfach. Es kann mehrere Aktivitäten geben, die vom übergeordneten Projekt abhängen. Diese erscheinen häufig als Aufgaben im größeren Projektplan. Diese Aktivitäten werden jedoch auf ein Team verteilt, das möglicherweise über ein großes Inventar an Testobjekten verfügt, für die Tests geplant und durchgeführt werden müssen.
Dieser Detaillierungsgrad ist für den Zeitplan des Projektmanagers nicht von großer Bedeutung und wird üblicherweise auf lokaler Ebene innerhalb des Testteams definiert und verwaltet.
Sehen wir uns einige der Kernelemente Ihres Testplans an.
Liefergegenstände
Was sind die Liefergegenstände des Testens?
Was für eine Frage! Sicherlich sind es die Testspezifikationen, die Tests, die Ergebnisse und die Berichte? Die Liefergegenstände sind im Wesentlichen in der Dokumentation enthalten, also müssen wir uns nur darum kümmern, den Papierkram zu erledigen und einige Kontrollkästchen abzuhaken.
Dieser Ansatz ist zwar üblich, aber teilweise dafür verantwortlich, dass das Testen (und Tester) den Ruf erlangt hat, teuer, schwerfällig und bürokratisch zu sein und nur wenig Mehrwert zu bieten. Denn wer liest diese umfangreichen Dokumente?
Angenommen, es besteht in einem agilen Projekt nicht die Absicht, Testdokumentation zu erstellen. Das ist sehr wahrscheinlich — was liefert das Testen in solchen Situationen tatsächlich? Welchen Wert hat das Testen überhaupt? Es ist ein bisschen spät, diese Fragen zu stellen, oder?
Wenn eine Komponente, ein Teilsystem oder das gesamte System getestet wird, besteht das Ergebnis aus Nachweisen darüber, wie sich das System in einer bestimmten Situation oder einem bestimmten Kontext verhält. Nachweise über das Systemverhalten werden gesammelt und zusammengestellt, um sie den Beteiligten (Entwicklern, Benutzern, Managern usw.) vorzulegen, damit diese eine Entscheidung treffen können: Fehler zu beheben, eine Komponente zu integrieren, Funktionen zu akzeptieren oder abzulehnen oder ein Teilsystem bzw. das gesamte System zu veröffentlichen oder bereitzustellen.
Der Liefergegenstand des Testens ist ein Nachweis über das Systemverhalten, den Beteiligte für eine Entscheidung verwenden.
Nun ist es in einigen Projekten unerlässlich, Testdokumentation bereitzustellen, um festzuhalten, wie ein Test abgegrenzt, konzipiert, implementiert und durchgeführt wurde. Der letztendliche wertvolle Liefergegenstand für die Stakeholder ist jedoch der Nachweis des Systemverhaltens.
Der Wert des Testens liegt im Maß an Vertrauen, das Stakeholder in Entscheidungen auf Grundlage von Testnachweisen haben.
Dieser Nachweis kann systematisch in hochentwickelten Testmanagementlösungen erfasst, tabellarisch aufbereitet und analysiert sowie den Stakeholdern in ansprechenden grafischen Formaten präsentiert werden. Oder die handschriftlichen Notizen können von einem Tester genutzt werden, um einem Produktverantwortlichen in einer Stand-up-Besprechung mündlich den Verlauf des Testens zu erläutern.
Unabhängig davon, wie der Nachweis erfasst und präsentiert wird, besteht die abschließende Aufgabe des Testens in der Übergabe des Nachweises.
Wie
Unabhängig von Projektgröße oder Methodik hängt das Testen von einer bestimmten Reihe von Aktivitäten ab. Wir betrachten einen allgemeinen Prozess aus der Perspektive des Testers (oder Teams) und sehen uns anschließend einige auftretende Variationen an.
Es gibt sogenannte „Testaktivitäten“ sowie „testunterstützende“ oder „logistische“ Aktivitäten. Damit Sie alle Aktivitäten in den Plan aufnehmen, können sich die folgenden Tabellen als nützliche Checklisten erweisen.
Eine Aktivität in der obigen Tabelle, die Ihnen möglicherweise weniger vertraut ist, ist die Rückmeldungsaktivität. Sie mussten sicher bereits mit unzureichenden Anforderungen arbeiten.
Bei der Aktivität der Rückmeldung, der Überprüfung und der Hinterfragung stellen Tester, nachdem sie eine Anforderung durchdacht und modelliert haben, Probleme fest und können anhand von Beispielen aufzeigen, wo Anforderungen fehlen, mehrdeutig oder widersprüchlich sind.
Wenn Sie Anforderungen als unzureichend einschätzen, lohnt es sich definitiv, diese Aktivität einzuplanen.
Testlogistik
Die Testlogistik unterstützt die oben genannten Testaktivitäten. Während die von mir aufgeführte Liste der Testaktivitäten relativ umfassend ist, unterscheidet sich die Testlogistik bei jedem Projekt und in jeder Organisation. Die folgende Liste ist daher nicht vollständig. Nehmen Sie sich in Ihrem Projekt die Zeit, jede Aktivität oder Abhängigkeit zu durchdenken, die für die Durchführung des Testens erforderlich ist.
Ressourcen (personell, physisch)
Wir verwenden häufig das Wort Ressourcen, um die Personen in unseren Projekten zu bezeichnen, und für manche ist das unangenehm. Menschen sind keine Dinge, sondern natürlich menschliche Wesen. In kleineren Projekten kann es möglich sein, Namen zu verwenden. In größeren Organisationen, wenn Projektteams beteiligt sind und möglicherweise noch nicht besetzt wurden, ist eine Anzahl von Ressourcen jedoch lediglich eine Kurzbezeichnung für eine Anzahl von Personen.
Wichtiger ist, dass nicht unbedingt die Anzahl der Personen entscheidend ist – es sind ihre Fähigkeiten, auf die es wirklich ankommt. Natürlich arbeiten Menschen auf unterschiedliche Weise und gewöhnlich auch mit unterschiedlicher Geschwindigkeit, daher müssen Sie dies bei Ihrer Planung berücksichtigen.
Neben den Personen benötigen Sie in verschiedenen Phasen unterschiedliche physische Ressourcen, damit das Testen fortgesetzt werden kann. Diese reichen vom Alltäglichen bis zum hochspezifischen Bereich, und das Fehlen einer dieser Ressourcen kann den Testauftrag gefährden.
Vielleicht haben Sie bereits das Glück, Zugang zu einem vollständig ausgestatteten, verwalteten und dedizierten Testlabor zu haben. Falls nicht, müssen Sie möglicherweise alles festlegen – vom physischen Raum und der Möblierung bis hin zu Haftnotizen und Radiergummis –, um Ihre Arbeitsumgebung zu definieren.
In der folgenden Tabelle finden Sie einige typische benötigte Ressourcen. Ihre Liste wird zweifellos erheblich davon abweichen.
Nachdem Sie alle Ressourcen ermittelt haben, die für die Umsetzung Ihres Plans erforderlich sind, prüfen Sie, ob Sie zusätzliche Aktivitäten in Ihren Plan aufnehmen müssen, um diese zu beschaffen.
Ihr Unterstützungsnetzwerk
Wenn die Personen und Fähigkeiten, die Sie für das Testen benötigen, Ihrer Kontrolle unterlägen, könnten Projekte deutlich einfacher sein! Doch nur wenige Teams verfügen über alle erforderlichen Fähigkeiten oder über die Genehmigung und den Zugang zu den notwendigen physischen Ressourcen. Viele Projekte werden im Stil einer Matrixorganisation besetzt und durchgeführt. Wichtige Teammitglieder berichten tatsächlich an die Leiter anderer spezialisierter Abteilungen, und Sie erhalten von ihnen nur eine begrenzte Zusage.
Möglicherweise müssen Sie eine bestimmte Anzahl von Stunden pro Tag festlegen oder Zeiten einplanen, zu denen Sie auf die oben genannten Spezialkenntnisse zugreifen können. Manchmal werden Sie gefragt, welches Serviceniveau akzeptabel ist, z. B. „Anfragen mit hoher Priorität werden innerhalb von dreißig Minuten beantwortet“ und so weiter.
Schätzungen
Die Aufwandsschätzung in Softwareprojekten ist eine schwierige Angelegenheit. Es wurde viel darüber geschrieben, dass Schätzungen schwierig oder sogar unmöglich sind. Dennoch sind Schätzungen in allen Projekten erforderlich, und je größer das Projekt ist, desto stärker sind wir auf sie angewiesen.
Wir benötigen Schätzungen, um einen Zeitplan zu erstellen. Das Problem besteht jedoch darin, dass eine Schätzung keine Genauigkeit liefert. Das Beste, was wir erreichen können, ist, einen Aufwand oder eine verstrichene Zeit mit einem gewissen Maß an Sicherheit oder Wahrscheinlichkeit zu berechnen.
Manche Menschen betrachten Schätzungen als schwarze Kunst, und es gibt sogar eine Bewegung namens #NoEstimates mit einer beträchtlichen Anhängerschaft. Es herrscht große Uneinigkeit darüber, ob Schätzungen jemals genau genug sein können oder ob sie in Softwareprojekten überhaupt eine gute Praxis darstellen.
Schätzungen werden niemals eine exakte Wissenschaft sein. Aufgrund meiner Erfahrungen gibt es jedoch einige Grundsätze, die ich gerne weitergebe:
- Anforderungen sind fehleranfällig und ungenau.
- Menschen sind mehr oder weniger kompetent, gewissenhaft und fleißig.
- Je kleiner die Arbeitseinheit ist, desto leichter lässt sie sich schätzen. Teilen Sie große Aufgaben nach Möglichkeit in kleinere Einheiten auf und fassen Sie die Schätzungen anschließend zur größeren Aufgabe zusammen.
- Schätzungen basieren auf Erfahrung. Wenn Sie selbst keine haben, suchen Sie nach Situationen, in denen die Erfahrung anderer relevant ist und angepasst werden kann.
- Ihre Arbeitseinheit ist einzigartig. Suchen Sie daher nach Arbeitsmustern in anderen bekannten Situationen, mit denen Sie Erfahrung haben.
- Bitten Sie andere um eine Schätzung und vergleichen Sie die Ergebnisse. Die Diskussion von Abweichungen macht Unterschiede bei Erwartungen, Zuversicht und Gründlichkeit sichtbar.
- Schätzen Sie zunächst die bestmögliche und anschließend die schlechtestmögliche Situation. Eine gute Schätzung liegt irgendwo dazwischen.
Schätzen Sie heute und beginnen Sie mit der Arbeit. Morgen und an jedem darauffolgenden Tag wird sich Ihre Schätzung bis zur Fertigstellung aufgrund der gewonnenen Erkenntnisse verbessern.
Abhängigkeiten, Risiken und Annahmen
In einem früheren Artikel haben wir Risiken und die Rolle von Tests im Risikomanagement besprochen. Produktrisiken beziehen sich darauf, ob das Produkt die Bedürfnisse der Benutzer im Hinblick auf funktionale oder technische Anforderungen erfüllt. Hier liegt der Schwerpunkt auf den Risiken für den eigentlichen Lieferplan.
In Projekten läuft nicht immer alles planmäßig. Bei Ihrer Planung müssen Sie deutlich machen, welche Ausfallrisiken Sie berücksichtigt und eingeplant haben. Dabei gibt es drei Aspekte: Abhängigkeiten, Risiken und Reaktionen.
Abhängigkeiten
Abhängigkeiten umfassen eine Liste der erforderlichen personellen und physischen Ressourcen sowie vorausgehender Aktivitäten, die abgeschlossen sein müssen, damit Ihre geplanten Aktivitäten erfolgreich durchgeführt und Ergebnisse geliefert werden können.
Bei jeder Testaktivität gibt es Abhängigkeiten, unabhängig davon, ob es sich um einen groß angelegten Test auf Systemebene oder eine explorative Testsitzung für eine Funktion handelt. Abhängigkeiten lassen sich in drei Hauptaspekte unterteilen.
Risiken
Das Risiko ist die Wahrscheinlichkeit, dass Ihr Plan während der Durchführung scheitert. Risiken beziehen sich auf Dinge wie:
- Ihre Schätzungen: Was könnte dazu führen, dass Ihre Schätzungen falsch sind? Ein komplexeres, fehlerhaftes, unvollständiges oder sich ständig änderndes System könnte Ihre Schätzungen beeinflussen.
- Personen, die nicht verfügbar sind, denen Erfahrung oder Kenntnisse fehlen oder die sich Ihrer Projektphase nicht vollständig verpflichtet fühlen. Dabei kann es sich um Teammitglieder oder Personen aus Ihrem Unterstützungsnetzwerk handeln.
- Infrastruktur wie Testumgebungen, Werkzeuge (oder Schulungen zur Nutzung von Werkzeugen) oder Büroräume, die nicht verfügbar, unzureichend vorbereitet oder fehlerhaft sind.
- Vorausgehende Aktivitäten, die nicht rechtzeitig abgeschlossen werden (oder aufgegeben werden, teilweise oder fehlerhafte Produkte liefern oder überhaupt keine Ergebnisse liefern).
Reaktionen
Für jedes dieser Risiken müssen Sie die Wahrscheinlichkeit und die Auswirkungen bewerten und, sofern relevant, eine geeignete Reaktion oder erwartete Konsequenz bestimmen. Diese Reaktionen nehmen typischerweise eine der folgenden Formen an:
- Annahme: Das Risiko wird als gering genug eingeschätzt, um es zu ignorieren oder als unerheblich zu betrachten. Es bleibt jedoch im Blick und wird als Annahme dokumentiert (beispielsweise hinsichtlich Verfügbarkeit oder Vollständigkeit).
- Anpassung: Das Risiko ist erheblich, aber es gibt eine Maßnahme, die seine Auswirkungen auf den Plan verringern kann. Wenn beispielsweise das zu testende System nur teilweise geliefert wurde und Funktionen fehlen, kann der Plan so angepasst werden, dass nur die verfügbaren Funktionen getestet werden.
- Konsequenz: Einige Risiken können nicht aufgefangen werden. Wird das System verspätet geliefert, kann der Test erst beginnen, wenn es geliefert wurde.
Kommunikation, Verpflichtung und Fortschrittsberichterstattung
Zuletzt kommen wir zu einem wichtigen, aber oft übersehenen Aspekt der Planung. Sie könnten einen Projektplan erstellen, der alle Aufgaben, Beteiligten, Ressourcen, Verantwortlichkeiten, Abhängigkeiten, Zeitvorgaben, den Aufwand und die Kosten enthält. Oder es könnte sich um eine mündliche Vereinbarung zwischen den Mitgliedern eines agilen Teams handeln.
In jedem Fall muss der Plan allen wirksam vermittelt werden, damit jeder weiß, was erforderlich ist und wann.
Ein vereinbarter Plan ist ein Vertrag zwischen den Beteiligten. Wenn ein Teammanager einen Plan genehmigt, ist dies implizit oder ausdrücklich eine Verpflichtung, den Teil des Vertrags zu erfüllen, der auf sein Team entfällt.
Der Plan ist ein Vertrag zwischen den Beteiligten.
Bei weniger formellen Projekten gibt es möglicherweise überhaupt keinen schriftlichen Plan oder keine schriftlichen Verpflichtungen. Unter diesen Umständen ist der Plan ein fortlaufendes Gespräch zwischen den Teammitgliedern. Das Team trifft sich täglich, und die aktuell anstehenden Aufgaben im Plan werden in Echtzeit besprochen. Woran arbeiten die einzelnen Personen? Entspricht der Fortschritt den Erwartungen? Mit welchen Problemen haben die Beteiligten zu kämpfen? Welche Probleme blockieren den Fortschritt?
In allen Projekten ist der Zweck der Fortschrittsberichterstattung zweifach. Offensichtlich besteht die Notwendigkeit zu kommunizieren, wo sich jeder im Hinblick auf seine aktuelle Projektaktivität befindet. Der Fortschrittsbericht ist jedoch auch eine regelmäßige fortlaufende Überprüfung, ob der Fortschritt aufrechterhalten werden kann, und dient dazu zu bestätigen, dass auf die Verpflichtungen der Beteiligten Verlass ist.
Vielen Dank fürs Lesen. Wir sehen uns beim nächsten Mal – Sie haben es erraten: bei der Ausführung!
Melden Sie sich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, sobald neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Kurs „Leadership In Test“, den wir sehr empfehlen, um tiefer in dieses und andere Themen einzutauchen. Wenn Sie sich dafür entscheiden, verwenden Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie 60 $ vom vollen Kurspreis!
