JIRA: Regeln für die rechtzeitige Vorbereitung köstlicher Software. TLDR 2: Anforderungsmanagement
Weiter oben im Artikel „ JIRA: Die Regeln für die rechtzeitige Vorbereitung köstlicher Software. TLDR 1: Grenzen der Möglichkeiten “Es wurde versucht, die allgemeinen Anforderungen für den Einsatz von JIRA bei der Verwaltung mehrerer Projekte zur Entwicklung kundenspezifischer Software in einer der Abteilungen unseres Unternehmens zu vereinheitlichen . Bei der Entwicklung des Themas wird dieser Artikel den Hauptmerkmalen der Registrierung, Klärung und Überwachung der Umsetzung der Kundenanforderungen im Rahmen des zuvor vorgeschlagenen Modells gewidmet . Jede Kritik ist willkommen.QuelleJedes fertige Produkt wird in erster Linie von der Qualität der Originalzutaten bestimmt, und die Software ist keine Ausnahme ( Garbage In - Garbage Out ). Wenn die ursprünglichen Zutaten leicht verfault sind oder einige davon einfach fehlen, ist es unwahrscheinlich, dass Sie die Situation mit Hilfe eines Superofens oder einer wunderbaren Pfanne retten können. Bei Software sind die ersten Komponenten die guten Absichten (Träume) des Kunden über eine glänzende Zukunft (wenn „ Roboter hart arbeiten, ist eine Person glücklich “). Eines der Paradoxe moderner Regierungsaufträge ist, dass der Auftragnehmer häufig einen schwachen Einfluss auf den Prozess der Bildung von Anforderungen hat, d. H. Prozess der Analyse der realen AnforderungenDas Projekt beginnt nach Genehmigung der Liste dieser Anforderungen. Die Tatsache, dass die Empfehlungen des Projektteams bezüglich des Wortlauts der Anforderungen keinen Einfluss auf den Vertragstext hatten, erfährt der Projektmanager normalerweise von dem freudig aufgeregten Vertreter der Vertragsabteilung, der mit einem Gefühl der vollständigen Verschuldung berichtet, dass die lang erwartete Ausschreibung und der Deal endgültig gewonnen sind Bleibt klein. Gleichzeitig behindert der Kunde einerseits die Änderung der Anforderungen im genehmigten Dokument auf jede mögliche Weise (ein Traum ist heilig), und andererseits kann er dieselbe Anforderung je nach Situation leicht auf unterschiedliche Weise interpretieren.Unter diesen Bedingungen ist es wünschenswert sicherzustellen, dass alle Kundenanforderungen in Ihrer „digitalen Küche“ so gespeichert werden, dass bei der Projektabwicklung keine ernsthafte Frustration aller am Projekt beteiligten Parteien auftritt.Um dieses Problem zu lösen, wird im Rahmen des zuvor vorgeschlagenen Ansatzes eine spezielle Art von Aufgabe entworfen - die „Anforderung“. Eine Liste dieser Aufgabenanforderungen wird durch das sogenannte Projekt-Backlog gebildet. In neueren Versionen von JIRA ist ein Analogon dieser Art von Aufgabe der Aufgabentyp „episch“. Wie wir später sehen werden, legt die Art der Aufgaben, die in unserem Projekt „erforderlich“ sind, nicht nur die konzeptionellen Denkformen des Kunden fest, sondern auch Aufgaben, die die Ergebnisse der Aktivitäten des Projektmanagers und der Analysten zum Anforderungsmanagement charakterisieren . Regeln für das Schneiden von Anforderungen
Wenn der Kunde eine Liste der Anforderungen für die Fertigstellung der Software erhält (z. B. eine genehmigte Leistungsbeschreibung), können alle Aktivitäten zur Registrierung und Pflege der Liste der Anforderungen in JIRA auf zwei Grenzszenarien reduziert werden.Im ersten Fall leitet der Projektmanager den Brief mit den Kundenanforderungen einfach an die Analysten mit dem Hinweis „Registrieren Sie die Anforderungen bezüglich der Tangente bei JIRA und stellen Sie deren Umsetzung sicher“ weiter. Danach kann der Projektmanager das Projekt bis zum Beginn der Vorversuche „hämmern“ (das einzige, was sichergestellt werden muss, dass alle Anforderungen ihre verantwortlichen Ausführenden in JIRA finden). Wenn Ihr Projektteam aus vernünftigen Analysten, genialen Programmierern, Workaholic-Testern und technischen Grafikern besteht, unterscheidet sich das Ergebnis dieses Ansatzes nicht von der zweiten, problematischeren Option.Im zweiten Fall ist das Anforderungsmanagement in mehrere Phasen unterteilt.Quellestarten. Registrierung des Quelldokuments zur Softwareentwicklung / -änderung in JIRA. Die empfangenen Materialien werden mit der Nummer der entsprechenden Aufgabe, die im Kommentar des Commits angegeben ist, in das Repository hochgeladen.1. Auf der Grundlage des registrierten Quelldokuments ist eine Besprechung geplant, deren Zweck darin besteht, die Verantwortungsgrenzen für die Erfüllung der Anforderungen festzulegen und „weiße Flecken“ und „esoterische“ Anforderungen zu identifizieren. Die Planung des Meetings erfolgt direkt in JIRA (dazu wird eine Aufgabe vom Typ „Implementierung“ registriert, die für die Aufgabe verantwortliche Person ist der Projektmanager, die Teilnehmer werden als Beobachter registriert, Tagesordnungspunkte werden in der Beschreibung festgehalten). Die Zeit, die für eine vorläufige Analyse der Anforderungen aufgewendet wird, wird von den Analysten unabhängig in Form von Unteraufgaben für das geplante Meeting festgelegt. Wenn während der Analyse Fragen auftauchen, werden diese in den Kommentaren auf der Tagesordnung der Sitzung berücksichtigt.Während des Treffens werden Entscheidungen über die Ernennung der Verantwortlichen für die „weißen Flecken“ getroffen. Risiken in Bezug auf „esoterische“ Anforderungen werden bewertet und Wege zu ihrer Überwindung vorgeschlagen. Die erste, noch sehr ungefähre Version der „Roadmap“ wird erstellt, nach der die Arbeiten organisiert werden (unter Berücksichtigung der Prioritäten und der aktuellen Beschäftigung des Projektteams).2. Nachdem der Analyst für die Umsetzung der Anforderungen verantwortlich gemacht wurde, registriert er jede Anforderung bei JIRA als separate Aufgabe im Zusammenhang mit dem Quelldokument (der Link „ergänzt“). Der anfängliche Status des Anspruchs ist "Rating" .Eine der Grundregeln - jede Kundenanforderung muss als separate Aufgabe registriert werdenbei JIRA. Dieser Ansatz ermöglicht es wiederum, den Status des Projekts unter dem Gesichtspunkt der Umsetzung der einzelnen Anforderungen des Kunden und nicht unter dem Gesichtspunkt der Anzahl der durchgeführten Aufgaben oder der Investition von Arbeitskräften zu bewerten. Der Wortlaut der Anforderung wird wie im Kundendokument Wort für Wort im Feld "Beschreibung" festgehalten.Die „atomare“ Registrierung von Anforderungen ermöglicht es anschließend, automatisch eine Berichtsdokumentation zu generieren, wenn eine Freigabe oder Aktualisierung veröffentlicht wird (Protokoll der funktionalen Zusammensetzung und Prüfung). 3. Angesichts der entwickelten Roadmap für jede der Anforderungen in der Anfangsphase ihrer Implementierung sollten die folgenden Probleme vom zuständigen Analysten gelöst werden:- Klärung des semantischen Inhalts der Anforderung;
- Klärung der Umsetzungsgrenzen.
Zum Zeitpunkt der Klärung kann die Anforderung unter Angabe des entsprechenden Grundes in den Status „ausstehend“ versetzt werden.Alle Materialien zur Klärung (Interpretation) der Anforderungen sind der entsprechenden Aufgabe beigefügt (in das Dokumentations-Repository hochgeladen). Die resultierenden Materialien sollten vom Kunden stammen und eine klare Antwort auf die oben genannten Fragen ermöglichen. Es ist ratsam, dass dies ein Protokoll des Treffens ist, um die Anforderungen zu klären, zumindest eine E-Mail aus der Korrespondenz.Nach Eliminierung von „weißen Flecken“ kann die Anforderung in den Status „zugewiesen“ versetzt werden .4. Im Rahmen der Implementierung eines Funktionsbereichs (ein zentraler Anwendungsfall - Anwendungsfall) Der verantwortliche Analyst muss Aufgaben vom Typ „Analyse“ formulieren, die sich auf die relevanten Anforderungen beziehen. 5. Falls erforderlich, führt der verantwortliche Analyst eine Informationsübersicht über das Automatisierungsobjekt durch. 6. Nach dem Sammeln der erforderlichen Anfangsdaten für das Design trifft der verantwortliche Analyst die Designentscheidung. 7. Basierend auf den Ergebnissen der Entwurfsentscheidung muss der Analyst die Liste der Komponenten erstellen / präzisieren, die entwickelt / geändert werden müssen.8. Die entwickelte Entwurfslösung ist eine notwendige und ausreichende Voraussetzung, um Aufgaben für die Entwicklung, Prüfung und Dokumentation zu erstellen und die Komplexität ihrer Implementierung vorherzusagen.Hier befindet sich häufig der Hauptstolperstein zwischen Managern und Entwicklern. Einer vonDie Ansätze zur Verringerung der Unsicherheit bei der Lösung dieses Problems bestehen darin, die vorgeschlagene Aufgabe durch den verantwortlichen Entwickler zu bewerten, vorausgesetzt, die Gesamtkomplexität der einzelnen Aufgabe sollte 16 Stunden nicht überschreiten. Alexei Kataev zeigt in seinem Bericht überzeugend, dass die Zuverlässigkeit der Prognose der Komplexität einer solchen Aufgabe der Zuverlässigkeit der Prognose von Glücksspielgewinnen entspricht, wenn die Arbeitskosten für die Ausführung der Aufgabe 12 Stunden überschreiten. Um die erforderliche Planungsqualität sicherzustellen, wird daher empfohlen, die Aufgaben zu zerlegen. Andererseits möchte ich aus Sicht des Managements ein Ergebnis erzielen, das aus Sicht des Kunden bei der Ausführung der Entwicklungsaufgabe von Bedeutung ist und das nicht immer in 16 Arbeitsstunden erreichbar ist. In unserem Fall wurde entschieden, dass der Autor der Aufgabe, wenn die Komplexität der Aufgabe 8 Stunden überschreitet, diese in separate Phasen aufteilen sollte (was nicht immer Unteraufgaben bedeutet). Zusätzlich wurden formale Listen mit bestimmten Ergebnissen für jede dieser Stufen erstellt. Darüber hinaus wurden Online-Rechner erstellt , um die Objektivität von Prognosen basierend auf diesen Listen mithilfe der PERT- Methode zu erhöhen.Ermittlung der Gesamtkomplexität für Aufgaben unterschiedlicher Art (eine detailliertere Beschreibung der Arbeit mit diesen Werkzeugen soll bei der Veröffentlichung der folgenden Artikel erfolgen). Gleichzeitig wurde jedoch die Einschränkung festgelegt, dass die maximal projizierte Komplexität einer einzelnen JIRA-Aufgabe 32 Stunden nicht überschreiten sollte. Für den Fall, dass der Auftragnehmer mit der projizierten Komplexität seiner Aufgabe nicht einverstanden ist, muss er als Argument seine Berechnung der Komplexität vorlegen, die mit denselben Werkzeugen durchgeführt wird. Der Schiedsrichter bei der Beilegung solcher Streitigkeiten zwischen dem für die Umsetzung der Anforderung verantwortlichen Analysten und den Ausführenden ist der Projektmanager (teamlead).9. Unmittelbar nach der Registrierung der Anforderungen im Zusammenhang mit der Anforderung für die Entwicklung, Prüfung und Dokumentation sollte der Projektmanager die Priorität und den Zeitpunkt der Umsetzung dieser Anforderung festlegen (unter Berücksichtigung der Gesamtarbeitskosten der damit verbundenen Aufgaben, Prioritäten und der erforderlichen Fristen für die Umsetzung anderer Aufgaben des Projekts). Angesichts dieser Klarstellungen kann der verantwortliche Analyst wiederum den Zeitpunkt der Aufgaben für Entwicklung, Test und Dokumentation anpassen.10. Die Implementierung der Entwurfslösung erfolgt im Rahmen von Aufgaben vom Typ „Entwicklung“.Nachdem die erste anforderungsbezogene Aufgabe für die Softwareentwicklung ausgeführt wurde, muss die Anforderung in den Status "in Arbeit" versetzt werden (dies kann mit dem Plugin Automation for Jira erfolgen ).11. Auf der Grundlage der festgelegten Implementierungsfristen wird beschlossen, die Implementierung der Anforderung in die eine oder andere Softwareversion aufzunehmen. Der Kunde muss über Änderungen der Zusammensetzung oder Lieferzeit der Freigabe informiert werden.12. Parallel zum Entwicklungsprozess wird auf der Grundlage der Entwurfsentscheidung eine Version der Benutzerdokumentation erstellt.13. Nach Abschluss der Entwicklungsaufgaben sollte der Programmierer die Liste der Komponenten klären, die entwickelt / geändert wurden.14. Die erneute Klärung der Benutzerdokumentation sollte im Rahmen eines Offline-Tests erfolgen. Die Erfüllung aller Anforderungen in Bezug auf die Anforderung für Entwicklung, Dokumentation und Prüfung ist ein Signal für die Umsetzung dieser Anforderung in den Status "abgeschlossen" und deren Aufnahme in die Freigabe.15. Die Überarbeitung ist in der Softwareversion gemäß der vom Projektmanager getroffenen Lieferentscheidung enthalten.16. Bevor die Tests durchgeführt werden, werden wiederholte Integrationstests der in der Version enthaltenen implementierten Anforderungen durchgeführt.17. Die Bestätigung der Richtigkeit der implementierten Anforderungen kann während des Softwaretests (Vorprüfung, Testbetrieb, Abnahme) erfolgen. Die Testergebnisse werden in JIRA als Teil der Aufgaben vom Typ "Implementierung" aufgezeichnet.Nachdem ein Dokument vom Kunden über die korrekte Umsetzung der Anforderung eingegangen ist, kann es in den Status „geschlossen“ versetzt werden . Falls vom Kunden Kommentare zu der Anforderung eingehen, wird diese in den Status „zugewiesen“ zurückversetzt(auf Stufe 8). Gleichzeitig können die Kommentare selbst in JIRA als separate Anforderungen in Bezug auf die Hauptanforderung unter Verwendung des Kommunikationstyps "Relates" festgelegt werden .Ich möchte Sie daran erinnern, dass das beschriebene Schema nicht den Workflow einer separaten Aufgabe in JIRA widerspiegelt, sondern die Erstellung einer Reihe miteinander verbundener Aufgaben verschiedener Typen umfasst (was sich im Schema mit den entsprechenden Farben widerspiegelt). Die angegebene Reihenfolge gibt einen Überblick über das Standardverfahren zur Implementierung neuer Kundenanforderungen. Gleichzeitig schließt dieses Schema die Möglichkeit von Abweichungen davon nicht aus, beispielsweise bei vorläufigen Prototypen vor der Entwurfsentscheidung. In unserem Projekt müssen solche Ausnahmen jedoch mit dem Projektmanager vereinbart werden.Während des Tests oder des kommerziellen Betriebs werden unweigerlich Kundenkommentare zur erstellten Software angezeigt. Diese Bemerkungen können bedingt in folgende Gruppen unterteilt werden:- neue Anforderungen;
- Klarstellungen zur Umsetzung;
- Mängel;
- Fehler.
Trotz der Tatsache, dass gemäß dem ursprünglich vorgeschlagenen Ansatz Kommentare in JIRA sowie Anforderungen für die Software-Verfeinerung (als Aufgaben vom Typ „Anforderung“) aufgezeichnet werden, verdient der Prozess ihrer Beseitigung eine gesonderte Prüfung. Regeln zum Färben von Kakerlaken
Wer nichts tut, irrt sich nicht.
Theodore Roosevelt
Es gibt keine Software ohne Fehler. Absolut. Selbst wenn der Code keine Fehler enthält, findet ein erfahrener Benutzer sie in der Dokumentation oder erfindet sie einfach. Auf die eine oder andere Weise habe ich keine Projekte gesehen, bei denen es keine Software-Vorfälle gab. Analyse der Softwarewartung durch das American Institute of Software Engineering ( SEI)) in den frühen 90er Jahren gezeigt, dass der Korrelationskoeffizient zwischen der Anzahl der beim Testen einzelner Module festgestellten Fehler und der Anzahl der von Benutzern im fertigen Produkt gefundenen Fehler 0,91 beträgt. Einfach ausgedrückt, wenn in der Testphase 10 Fehler festgestellt wurden, werden während des Testvorgangs 9 weitere angezeigt. Das Erreichen der erforderlichen Qualität bei der Entwicklung von Software für Raumstationen wird insbesondere durch die zehnfache Überlegenheit des Testpersonals gegenüber dem Entwicklungspersonal erreicht, ohne den Einsatz fortschrittlicher Techniken, beispielsweise Unit-Tests oder GUI-Testautomatisierung. Meiner Meinung nach wird die Zuverlässigkeit einer solchen Software durch die möglichst geringe Beteiligung von Live-Benutzern an ihrer Arbeit erreicht. Natürlich ist es sehr cool, wenn ein professionelles Qualitätskontrollteam an dem Projekt arbeitet . In vielen Softwareprojekten ist es jedoch aus verschiedenen objektiven und subjektiven Gründen nicht möglich, alle diese Empfehlungen umzusetzen.Wenn der Projektmanager den Fluss eingehender Vorfälle nicht verwaltet, wird dieser Thread sehr bald einen solchen Manager verwalten (wenn er in diesem Thread nicht "erstickt"). Andererseits ist, wie die Erfahrung zeigt, ein wesentlicher Teil der Kommentare des Kunden, die ursprünglich von ihm als Softwarefehler eingestuft wurden, kein Fehler. Das Auftreten derartiger Kommentare kann folgende Gründe haben:- Verletzung der technischen Betriebsbedingungen von Software („krumme Hände“ der Systemadministratoren des Kunden);
- Einschränkungen der Benutzerzugriffsrechte (zugewiesene Benutzerzugriffsrechte entsprechen nicht seinen Erwartungen);
- die Nichtübereinstimmung der funktionalen Erwartungen des Benutzers mit den implementierten Anforderungen (wenn nichts hilft, sollten Sie vielleicht die Anweisungen lesen?);
- Inkonsistenz in der Beschreibung der Softwareimplementierung (eine eher seltene Bemerkung, da die Benutzer und Administratoren des Kunden die Handbücher nach der ersten Bekanntschaft mit der Software in der Regel nicht lesen).
In diesem Zusammenhang wird empfohlen, während der Korrespondenz mit dem Kunden bezüglich Kommentaren zur Software Wörter wie „Fehler“ oder „Fehler“ zu vermeiden, zumindest bis diese vollständig eindeutig sind. Bis zu diesem Punkt wird empfohlen, die Wörter "Bemerkung" oder "Vorfall" zu verwenden.Der einheitliche Prozess der Ausführung von Arbeiten zur Beseitigung von Vorfällen kann als eine Folge der folgenden Schritte dargestellt werden.Quellestarten. Registrieren Sie einen Antrag auf Behebung von Vorfällen bei JIRA. Diese Phase für verschiedene Projekte kann auf eigene Weise organisiert werden. Sie können beispielsweise vom Kunden empfangene Anträge manuell bei JIRA registrieren oder ein spezielles Postfach verwenden, in dem JIRA Aufgaben basierend auf eingehenden Briefen unabhängig anzeigt und konfiguriert. Wenn Sie eine Webanwendung entwickeln, können Sie den JIRA-Task-Collector verwenden , um Benutzerkommentare zu sammeln . In dem Feld, in dem sich herausstellte, dass der Kommentar in JIRA registriert war (im Status "Bewertung" ), muss er vorverarbeitet werden.1. Klärung der Vorfallbedingungen. Im Rahmen dieser Aktion müssen die vollständigsten Informationen zum Softwarekommentar erfasst werden:- die Abfolge von Aktionen, während der der Vorfall auftritt, eine Kombination von Eingabedaten;
- Details und Autorität des Benutzers des Kommentars;
- Standort der Workstation (Server);
- Screenshots von Benutzerbildschirmen;
- Überwachungsprotokolle;
- Beispiele für falsch generierte Dateien (Berichte).
Oft beendet ein erheblicher Teil der Vorfälle zu diesem Zeitpunkt ihre Lebensreise, da sich bei der Sammlung von Artefakten herausstellt, dass der erkannte „Fehler“ das Standardverhalten des Systems ist. Wenn der JIRA anfängt, Anforderungen für die Lösung von Vorfällen zu sammeln, die behoben wurden, ohne Entwicklungsaufgaben zu erstellen, sollten Sie die Benutzerfreundlichkeit der Benutzeroberfläche und die Relevanz des Benutzerhandbuchs genau beachten.2. Aufteilung des Vorfalls in "atomare" Anforderungen. Oft kann der Kundenvertreter in einem Brief mehrere Kommentare wiedergeben. Daher werden im zweiten Schritt, basierend auf dem eingeschriebenen Brief des Kunden an JIRA, bei Bedarf separate Anforderungsaufgaben gebildet. Darüber hinaus ist jede dieser Aufgaben mithilfe der Cloners-Beziehung der übergeordneten Anforderung zugeordnet . Für jede dieser Aufgaben sind die in der vorherigen Phase gesammelten Materialien beigefügt (teilweise in Bezug auf). Darüber hinaus sind alle Arbeiten mit jeder Anforderung separat organisiert.3. Festlegung des vertraglichen Rahmens. Nach Angabe der festgestellten Mängel wird festgestellt, welcher Art von Vertragsverhältnis die Arbeiten zur Beseitigung zugeordnet werden können. Aus Sicht der weiteren Arbeitsorganisation kann diese Phase die Priorität weiterer Aufgaben grundlegend verändern. In vielen Projekten wird der Testbetrieb neuer Komponenten, die im Rahmen der Entwicklung entwickelt wurden, durchgeführt, indem diese Komponenten nach einem kurzen autonomen Test direkt auf der aktuellen Version installiert werden. Der Kunde korreliert die in diesen Fällen auftretenden Fehler jedoch bereits mit den Verträgen über Basis- oder Garantiesupport, in denen strenge Fristen für die Beseitigung der Mängel festgelegt sind. Wenn im Rahmen der Grundversorgung die Vertragslaufzeit zur Beseitigung des Mangels in Stunden gemessen werden kann, dann wird der Mangel in Bezug auf die neue Funktionalität festgestellt,Die Frist für die Beseitigung desselben Mangels richtet sich nach dem Enddatum des Probebetriebs (bis zu mehreren Monaten). Wenn der Projektmanager diese „kleine“ Nuance nicht beachtet, hat das ausführende Unternehmen jede Chance, eine Strafe für einfache Software zu zahlen, noch bevor diese in Betrieb genommen wird.4. Kontrolle von Duplikaten. Im Falle eines erneuten Beitrittsantrags zur Beseitigung zuvor festgestellter Mängel ist diese Anforderung mit der zuvor eingereichten Aufgabe über die Verbindung "Duplizieren" ( Duplizieren ) verbunden. Basierend auf den Ergebnissen der vorläufigen Analyse des Vorfalls ist es notwendig, den Kunden über seine Ergebnisse zu informieren, da die Vision des Kunden vom Zeitpunkt der Beseitigung des Vorfalls schwach mit vertraglichen Verpflichtungen korrelieren kann.5. Der Vorfall sollte vom Support-Team auf dem Testserver wiederholt werden, bevor die Anfrage an den Analysten des Entwicklungsteams gesendet wird. Die Erstprüfung kann in JIRA in Form einer Unteraufgabe entsprechend der jeweiligen Anforderung aufgezeichnet werden.6. Wenn der Vorfall im Verlauf der vorherigen Schritte nicht behoben wurde, wird die Anforderung in den Status „zugewiesen“ versetzt und an den Analysten des Entwicklungsteams übertragen, um die Gründe für das Auftreten des Vorfalls zu ermitteln und Aufgaben für dessen Beseitigung zu formulieren.7. Falls erforderlich, muss der Analyst den vertraglichen Umfang der Anforderung klarstellen. Wenn ein Kommentar zur neuen Funktionalität der Software abgegeben wird, muss der Analyst diesen Fehler mit den relevanten Anforderungen für Entwicklung / Entwicklung / erweiterten Support verknüpfen (Link „Hinzufügen“).8. Die Analyse sollte auch die Liste der Komponenten ermitteln, die diesen Kommentar beeinflussen. Wenn es sich bei dem Kommentar tatsächlich um einen Softwarefehler handelt, muss er generiert werden.Typisierung des erkannten Mangels.9. Nach der Identifizierung der Fehlerursachen formuliert der Analyst der Entwicklungsgruppe Entwicklungsaufgaben, um den identifizierten Fehler zu beseitigen. Bei Bedarf werden Aufgaben zum Testen und Klären der Dokumentation gebildet. Im Rahmen dieser Aufgaben werden geplante Arbeitskosten ermittelt. Wenn die Arbeitslast einer bestimmten Aufgabe 8 Stunden überschreitet, muss die Komplexität mit den im vorherigen Abschnitt angegebenen Tools begründet werden. Unter Berücksichtigung der Priorität und der Arbeitsbelastung des Projektteams werden die geplanten Termine für die Umsetzung dieser Aufgaben festgelegt. Nachdem die erste Anforderung in Bezug auf die Entwicklung der Software erfüllt wurde, muss der Vorfall in den Status "in Arbeit" versetzt werden .10. Das Auftreten verwandter Aufgaben für die Entwicklung, Prüfung und Dokumentation einer Anforderung ist ein Signal für den Projektmanager, eine Entscheidung darüber zu treffen, welche Version der Software der festgestellte Fehler behoben wird. Gleichzeitig plant der Projektmanager eine Veranstaltung zur Implementierung von Software, indem er die entsprechenden Anforderungen mit der JIRA-Aufgabe vom Typ "Implementierung" verknüpft. 11. Falls erforderlich, klärt der Projektmanager die geplanten Termine für die Umsetzung der damit verbundenen Aufgaben und informiert den Kunden darüber.12. Die Behebung des Mangels erfolgt im Rahmen von Aufgaben vom Typ "Entwicklung".13. Nach Beseitigung des Defekts sollte der Entwickler gegebenenfalls die Art des erkannten Defekts und die Zusammensetzung der abgeschlossenen Komponenten klären.14. Falls erforderlich, wird die Dokumentation angegeben.15. Spezialisten der Selbsthilfegruppe führen autonome Tests der korrigierten Funktionalität durch (als Teil der vom Analysten der Entwicklungsgruppe festgelegten Testaufgabe).Ebenso wie bei der Umsetzung der neuen Anforderung ist die Grundlage für die Übertragung des Vorfalls in den Status „erledigt“ die Erfüllung aller auf dieser Grundlage erstellten Aufgaben (mit Ausnahme von Aufgaben vom Typ „Umsetzung“).16. Nach der Durchführung von Offline-Tests ist das Update im Update und in der aktuellen Version enthalten.17. Nach der Bereitschaft aller Verbesserungen, die für die Aufnahme in die Freigabe der Lieferung geplant sind, werden Integrationstests durchgeführt. Das Durchführen von Integrationstests kann in JIRA in Form einer Unteraufgabe für die entsprechende Aufgabe vom Typ "Implementierung" festgelegt werden.18. Software-Updates werden in der festgelegten Weise an den Kunden übermittelt. Die Übertragung von Aufgaben der relevanten Anforderungen in den Status "geschlossen" ist jedoch erst möglich, nachdem vom Kunden dokumentarische Nachweise über die Beseitigung des Vorfalls erhalten wurden. QuelleJeder Entwickler weiß, dass die größten Fehler diejenigen sind, die zum Zeitpunkt der Erstellung / Spezifikation der Anforderungen nicht rechtzeitig erkannt wurden.Anforderungs-Einfrierregeln
Das Gehen auf dem Wasser und das Entwickeln von Software gemäß der Spezifikation ist sehr einfach, wenn beide gefroren sind.
Edward V. Berard
Es ist zu beachten, dass sich die Klärung von Anforderungen am effektivsten bewährt hat, indem eine Situation geschaffen wurde, in der der Kunde eine einfache Antwort auf das Klärungsschreiben geben muss: „Ich stimme zu“. Hierzu müssen im Brief mehrere mögliche Antworten formuliert werden . Die Kunst, solche Buchstaben zu bilden, besteht darin, dass die Option, die der Kunde wählt, für Sie als Darsteller am besten geeignet ist.
QuelleBeispielsweise kann die „einfache“ Anforderung, „die Möglichkeit der Probenahme nach Regionen in allen Bildschirmen bereitzustellen“ in der Lieferphase viele Probleme verursachen, da nicht festgelegt wird, auf welchen Bildschirmformen die Probenahme erfolgen soll, ob die Probenahme nach einem oder mehreren Parameterwerten erfolgt wie die Historizität von Änderungen im Namen von Regionen berücksichtigt werden sollte. Wenn Sie nur darum bitten, diese Anforderung zu klären, ist es unwahrscheinlich, dass die Antwort die angegebenen Probleme löst. In diesem Fall kann die Klarstellung mit einem Brief mit folgendem Inhalt erfolgen:. 4.5.6. : « 1, 2 3 «». , , ».
Eine Kopie des Briefes ist der Aufgabe beigefügt. Die Aufgabe wird in den Status "Ausstehend" versetzt, bis eine Antwort des Kunden eingeht, die anschließend auch an die Aufgabe angehängt wird. Dieser Wortlaut spiegelt sich im entsprechenden Feld der JIRA-Aufgabe wider (siehe unten „Klarstellung“). Auf dieser Grundlage werden entsprechende Entwurfsentscheidungen, Entwicklungsaufgaben und Testaufgaben gebildet.Idealerweise ist es aus objektiven und subjektiven Gründen oft als Horizont erreichbar, um die Anforderung auf die weitere Entwicklung zu übertragen, und sicherzustellen, dass alle Mitglieder des Projektteams ihre Grenzen verstehen. Sobald eine Aufgabe vom Typ „Anforderung“ mit Entwicklungsaufgaben verknüpft ist, überprüft der Projektmanager daher, ob er die unten beschriebenen Qualitätskriterien erfüllt ( Definition von Bereit)) Wenn der grundlegende Wortlaut der Anforderung diese Kriterien nicht erfüllt, müssen die Arbeiten zu ihrer Verfeinerung unbedingt durchgeführt werden. Das Ergebnis der Verfeinerungsarbeiten sollte entweder ein aktualisierter Wortlaut der Anforderung oder eine vom Kunden im Zusammenhang mit dieser Anforderung vereinbarte Entwurfsentscheidung (SCF) sein. Bei der Berücksichtigung von Arbeitskosten in einer Aufgabe vom Typ „Anforderung“ wird nur die Zeit erfasst, die direkt für deren Verfeinerung aufgewendet wurde. Alle anderen Arbeitskosten werden in Aufgaben der entsprechenden Typen (oder deren Unteraufgaben) erfasst.Zusätzlich zu den im vorherigen Artikel beschriebenen allgemeinen Attributen wurde für jede Aufgabe des Typs "Anforderung" in JIRA während eines langen und schmerzhaften Prozesses eine Reihe zusätzlicher Attribute definiert.* Features Füllattribut, das allen Arten von Aufgaben gemeinsam ist.Das Ändern der spezifischen Attribute einer Aufgabe vom Typ "Anforderung" beim Übergang von Status zu Status wird in der folgenden Tabelle beschrieben, in der:
- eine Attributänderung möglich ist;
- erforderliche Dateneingabe.Fortsetzung folgt
Viele Projektmanager glauben, dass wenn die Leistungsbeschreibung vom Kunden genehmigt wurde, dies die ultimative Wahrheit ist, die keinen Änderungen unterliegt. Dies ist teilweise richtig - es ist unwahrscheinlich, dass der Wortlaut der Anforderungen der technischen Spezifikationen bis zum Abschluss des Projekts geändert wird. Bereits in der Anfangsphase des Projekts (lange vor der Genehmigung des Programms und des Testverfahrens) bemüht sich jedoch niemand, mit dem Kunden die Grenzen jeder Anforderung zu klären und das vorgeschlagene Verfahren für die Überprüfung festzulegen. Wenn solche Arbeiten nicht durchgeführt wurden, entscheiden Sie höchstwahrscheinlich innerhalb des Budgets und des Zeitpunkts desselben Projekts über die gesamte „Wunschliste“ des Kunden, die während der Implementierung angegeben wurde.Vergessen Sie nicht die objektiven Gesetze, die Barry Boehm ( Barry W. Boehm ) Ende der 80er Jahre des letzten Jahrhunderts auf sich aufmerksam machten . Wenn es dem Projektmanager nicht darum geht, die Unsicherheit und Ungenauigkeit der Anforderungen in der Anfangsphase des Projekts zu beseitigen, werden ihm in der Phase des Abschlusses des Projekts garantiert viele unangenehme „Entdeckungen“ gemacht. Die Erfahrung hat jedoch gezeigt, dass die meisten Unklarheiten nicht durch einfache Klärung der Anforderungen gelöst werden können. Darüber hinaus ist es oft unmöglich, Anforderungen isoliert voneinander zu betrachten, da die Ziele, in deren Interesse die Software erstellt wird, nur durch die integrierte Umsetzung der Kundenwünsche erreicht werden können.Im Rahmen des beschriebenen Ansatzes wird vorgeschlagen, die Koordination eines zusammenhängenden Anforderungssatzes sowie eine realistische Interpretation der Kundenphantasien, die sich in den genehmigten Aufgabenbereichen widerspiegeln, bei der Lösung von Problemen vom Typ „Analyse“ durchzuführen, deren Merkmale im Artikel „JIRA: Regeln für die rechtzeitige Erstellung schmackhafter Software“ vorgestellt werden. TLDR 3: Design Solutions. “ Source: https://habr.com/ru/post/undefined/
All Articles