JIRA: Regeln für die zeitnahe Erstellung leckerer Software. TLDR 1: Grenzen der Möglichkeiten

Zuvor wurde in dem Artikel „ JIRA als Mittel gegen Schlaflosigkeit und Nervenzusammenbrüche “ eine Option vorgeschlagen, JIRA zur Verwaltung eines Softwareentwicklungsprojekts im Interesse eines großen staatlichen Kunden zu verwenden. Ein unachtsamer Umgang mit Steuerungsautomationsgeräten in der "digitalen Küche" kann jedoch nicht nur das Produkt verderben, sondern auch zu zahlreichen Verletzungen führen. In einer Reihe von Artikeln mit dem Titel "Regeln für die rechtzeitige Vorbereitung köstlicher Software" wird vorgeschlagen, die Regeln für die Organisation der Arbeit an einem Softwareprojekt unter Verwendung eines Katalysators namens JIRA im Detail zu untersuchen. Jede Kritik ist willkommen.

Quelle

Allgemeine Geheimnisse

Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber damit sie erledigt wird.
Linus Tordvalds

Nach der Veröffentlichung des Artikels „ JIRA als Mittel gegen Schlaflosigkeit und Nervenzusammenbrüche “ interessierten sich mehrere Führungskräfte für unsere Erfahrungen mit JIRA und beschlossen, ein ähnliches Automatisierungsschema für das Management ihrer Projekte einzuführen. Als Ergebnis des Schreibens dieses Aufsatzes sollte er daher gleichzeitig „ein paar Kaninchen fangen“:

- sequentielles Betrachten jeder Art von JIRA-Aufgaben als Teilprozess des Projekts während der Präsentation:

• Vereinheitlichen Sie die Spezifikationen dieser Unterprozesse.
• Geschäftsregeln für die organisierte Arbeit standardisieren;
• Karten typischer "Fallstricke" und Orte zu erstellen, die eine vorherige "Strohbettung" erfordern;
• messbare und erreichbare Leistungsindikatoren für jeden Aufgabentyp bestimmen.

- eine Problembeschreibung für den JIRA-Administrator formulieren, um neue Projekte gemäß dem vorgeschlagenen Ansatz bereitzustellen;
- informelle, aber dennoch verständliche und transparente Vorschriften über die Verteilung der Zuständigkeiten aller Mitarbeiter von Projektteams erhalten;
- Formalisierung der besten Rezepte, die bei der Lösung von Problemsituationen gefunden wurden („Life Hacks“ des Projektmanagers);
- bisher nicht festgestellte Schwächen des vorgeschlagenen Ansatzes bei der Diskussion der Einzelheiten seiner Umsetzung mit den Lesern von Habr zu identifizieren.

Ich möchte gleich bemerken: Einige der beschriebenen Techniken haben sich in einer der LANIT Digitalküchen für das Projektmanagement zur Entwicklung und Pflege von Individualsoftware im Interesse eines großen Staatskunden bewährt. Es ist jedoch keineswegs eine Tatsache, dass diese Empfehlungen für Ihr Projekt gleichermaßen nützlich sind. Auf der anderen Seite betreten wir Terra Incognita. Einige der zum Ausdruck gebrachten Überlegungen sind nur für die Umsetzung vorgesehen. Wenn Sie daher Schwächen im vorgeschlagenen Ansatz sehen oder konstruktive Optimierungsvorschläge haben, begrüßen Sie die Diskussion in den Kommentaren.

Es wird davon ausgegangen, dass nach der Vereinheitlichung im Interesse verschiedener Führungskräfte die beschriebene Managementtechnologie erfolgreich auf Softwareprojekte mit unterschiedlichen Ausrichtungen und Maßstäben angewendet werden kann. Die Verwendung eines einzigen konzeptionellen Bereichs bei der Registrierung von JIRA-Aufgaben schafft wiederum die Voraussetzungen für die automatisierte Bewertung des aktuellen Zustands im Rahmen des Projektportfolios . Darüber hinaus wird davon ausgegangen, dass ein einheitlicher Ansatz zur Erfassung der Arbeitsergebnisse in JIRA die Mobilität der Mitarbeiter zwischen mehreren Projektgruppen vereinfacht, was wiederum zur Steigerung des Projekterfolgs beiträgt.

Projektgrenzen

Jede schwierige Aufgabe hat eine einfache, leicht verständliche und falsche Lösung.
Arthur Bloch

Da sich der vorgeschlagene JIRA-Anwendungsalgorithmus allmählich auf andere Projekte "auszubreiten" begann, war es notwendig, die Frage zu überdenken: "Was genau bestimmt die Grenzen eines Softwareprojekts in JIRA?"

Laut den Anhängern des ungetrübten PMBoK ist die Antwort auf diese Frage elementar: "Natürlich werden die Grenzen des Projekts durch die Charta (Reisepass) des Projekts bestimmt ." Aus dieser Sicht muss für jeden Vertrag mit dem Kunden ein eigenes Projekt in JIRA gebildet werden. Darüber hinaus kann die Entwicklung eines Softwarepakets häufig mehrere Tätigkeitsbereiche umfassen, in denen in der Regel mehrere Verträge abgeschlossen werden:

• Entwicklung - Anforderungen im Rahmen von Verträgen für die Schaffung neuer Systeme (Teilsysteme);
• Entwicklungsanforderungen im Rahmen von Verträgen, die auf eine wesentliche Überarbeitung bestehender Teilsysteme abzielen;
• erweiterter Support - die Anforderungen von Verträgen zur operativen Fertigstellung einzelner Systemmodule für aktuelle Änderungen der Geschäftsprozesse des Kunden;
• Garantieunterstützung - Beseitigung von Softwarefehlern, die während der Garantiezeit festgestellt wurden;
• Grundlegender Support - Beseitigung von Softwarefehlern, die nach Ablauf der Garantiezeit festgestellt wurden.

Darüber hinaus muss das Projektteam im Rahmen der Erstellung der Software Anforderungen lösen, die in keinem der Verträge definiert sind. Dies sind die Anforderungen des Projektmanagers in Bezug auf die Aktivitäten vor dem Projekt, das Refactoring, den Vorverkauf, die Beseitigung von Fehlern, die unabhängig identifiziert wurden, die Schulung des Personals usw.

Wie die Praxis jedoch gezeigt hat, ist es bei der tatsächlichen Entwicklung eines langfristigen Softwareprodukts schwierig, die Entwicklungs- und Wartungsarbeiten voneinander zu trennen. Der Probebetrieb ist noch nicht beendet (der Entwicklungsvertrag ist noch nicht abgeschlossen) und der Kunde ist bereits in vollem Umfang in der Lage, Anforderungen für einen erweiterten Support für Systemkomponenten zu formulieren, die noch nicht kommerziell in Betrieb genommen wurden. Der Kunde kann verstanden werden, weil sich die Welt schneller verändert, als es in den genehmigten Verträgen geplant war. Gleichzeitig wird die Identifizierung neuer Softwarefehler fortgesetzt. Und dem Benutzer, der den Defekt entdeckt hat, ist es egal, unter welchem ​​Vertrag dieser Fehler behoben werden soll. Aus seiner Sicht - es hätte einfach nicht sein dürfen. Um den identifizierten Fehler dem einen oder anderen Vertrag zuzuschreiben, braucht es Zeit, ihn zu analysieren, und wenn die JIRA-Projekte auf der Grundlage der Verträge aufgeteilt werden, entsteht ein Dilemma : „Und in welchem ​​JIRA-Projekt sollte dieser Fehler registriert werden?“. Darüber hinaus ist es erforderlich, die Übertragung von Aufgaben von einem Projekt auf ein anderes zu organisieren, wenn ein Klassifizierungsfehler gemacht wurde. Wenn Sie alle erkannten Softwaremängel einem separaten Projekt der Support-Gruppe zuordnen, entstehen die Risiken von Problemen bei der Lösung von Zahlungsproblemen für Arbeiten auf der Stufe des Entwicklungsvertrags oder bei der Überprüfung von Beschwerden über die Nichteinhaltung des Service Level Agreements ( SLA ).

Andererseits schlagen die eifersüchtigen Abteilungsleiter vor, im Rahmen des Projekts getrennte Projekte für das Support-Team, die analytische Abteilung und die Entwicklungs- und Testabteilung zu erstellen. Jeder möchte ein vollwertiger Meister in seiner Diözese sein und nicht für die "Schwärme" der Nachbarn verantwortlich sein. Dank der erstaunlichen Flexibilität von JIRA können Sie außerdem Verbindungen zwischen den Aufgaben verschiedener Projekte herstellen.

Quelle

Meiner Meinung nach ähneln die obigen Ansätze zur Registrierung von Projekten in JIRA dem Versuch, eine Suppe in mehreren verschiedenen Töpfen in verschiedenen Küchen zu kochen. Das Hauptziel des Projekts ist die rechtzeitige Erstellung eines Softwareprodukts einer bestimmten Qualität. Aus Sicht des Kunden wird die Qualität des Produkts durch die Menge der Funktionsfähigkeiten dieses Produkts bestimmt, mit denen der Kunde seine Probleme garantiert (d. H. Zuverlässig) lösen kann. Dabei ist es für den funktionalen Endkunden unerheblich, unter welchen Vertragsverhältnissen die erforderliche Funktionalität geschaffen wurde. Ebenso wenig ist es für den Piloten wichtig, die Liste der Subunternehmer zu kennen, die an der Erstellung seines Flugzeugs beteiligt sind.

In diesem Sinne sollte das Definieren der Grenzen eines JIRA-Projekts die Harmonie zwischen den folgenden beiden Überlegungen sicherstellen.

1. Das Projekt muss alle Arbeiten widerspiegeln, die während der Erstellung / Änderung des Softwareprodukts (oder seines Subsystems) ausgeführt werden. Das Projekt sollte als ein einziger Prozess zur Erstellung eines Softwareprodukts (eines „Flugzeugs“) betrachtet werden. Daher das Hauptprinzip: ein Softwareprodukt - ein JIRA-Projekt. Es ist wichtig, nicht zu vergessen, was Ihr Unternehmen produziert - ein "Flugzeug" oder ein "Motor für Flugzeuge". In jedem Fall sollten sich Softwareentwickler nicht von den Konsequenzen ihrer Entscheidungen entfremden .
   
   Unabhängig von der Art des Vertragsverhältnisses mit dem Kunden ist der Einstiegspunkt in den Prozess der Erstellung eines Softwareprodukts für dessen Änderung ein beliebiges Erfordernis. Das letzte Ereignis ist der Erhalt der Bestätigung des Kunden, dass diese Anforderung umgesetzt wurde (oder für insolvent erklärt wurde). Diese Regel ist die wichtigste für die Beurteilung der Vollständigkeit der Planung und der Vollständigkeit der Aufgaben im JIRA-Projekt.
   
   Es ist ratsam, dass das JIRA-Projekt auch einen Ort für Hilfsarbeiten findet, der im Interesse der Erfüllung der Kundenanforderungen initiiert wurde. Während der Entwicklung von Software finden viele Ereignisse statt, die in der Regel „hinter den Kulissen“ bleiben: regelmäßige Besprechungen zur Klärung von Fristen, Bereitstellung von Testservern, Vorbereitung von Testdaten, Generierung zusätzlicher Anweisungen usw. JIRA kann eine große Hilfe bei der Erkennung von Löchern sein, durch die die Arbeitszeit der Mitarbeiter des Projektteams großzügig und unwiderruflich fließt. Aber nur unter der Bedingung, dass diese Werke im JIRA-Projekt registriert werden.
2. Bei der Entwicklung sehr großer Softwaresysteme sollten Sie nicht alles in einem JIRA-Projekt zusammenfassen, was das Risiko von Störungen erheblich erhöht. In solchen Fällen ist es ratsam, innerhalb eines separaten JIRA-Projekts Softwarefunktionen zu gruppieren, die einen der Geschäftsprozesse des Kunden unterstützen (in der Regel werden solche Funktionen bereits in der Phase der Konzeptentwicklung separaten Subsystemen zugewiesen).

Quelle: Sergey Arkhipenkov. Projektevaluation: Quacksalber oder Schamanismus

Es lohnt sich, über die Bildung einzelner JIRA-Projekte nachzudenken, um die Ergebnisse von Arbeiten zu erfassen, die regelmäßig im Rahmen mehrerer Softwareprodukte durchgeführt werden (z. B. die Berücksichtigung der Zeit, die die Mitarbeiter für das Studium neuer Technologien oder für Arbeiten im Zusammenhang mit Sicherungen aufwenden).

Eine der Einschränkungen für ein JIRA-Projekt kann die maximale Anzahl der Mitarbeiter des Projektteams sein. Persönliche Erfahrungen lassen folgende Schlussfolgerung zu: Die maximale Zusammensetzung des Entwicklungsteams in einem einzelnen JIRA-Projekt folgt der Miller-Regel (in den besten Traditionen von Agile). Die Entwicklungsgruppe bezieht sich hier auf Programmierer und Analysten, die die Aufgaben für sie formulieren. Und natürlich der Projektleiter. (Wie Sie vielleicht denken! Das ist heilig!) Außerdem können, wenn das Projektbudget dies zulässt, die verbleibenden 80% der Mitarbeiter des Projektteams, bestehend aus freundlichen Support-Team-Mädchen, mürrischen Testern, langweiligen technischen Redakteuren und einem lustigen Systemadministrator, sicher und harmonisch in das Projekt einbezogen werden JIRA.

Wie man Aufgaben in die Regale stellt

Auf meinem Dachboden gibt es nur die Werkzeuge, die ich brauche. Es gibt viele von ihnen, aber sie sind in perfekter Ordnung und immer zur Hand.
Sherlock Holmes

Bei jedem Projekt ist die Navigation der Mitarbeiter im Strom der zu lösenden Aufgaben eine der wichtigen Komponenten für den Erfolg. Mit zunehmendem Projektvolumen wird es jedoch immer schwieriger, diesen Ablauf zu verstehen, der für sich genommen zu einem der Probleme bei der Verwaltung eines großen Projekts werden kann. Die Definition eines einzigen Koordinatensystems, durch das alle wichtigen Teilnehmer gleichermaßen navigieren können, ist daher ein wesentlicher Bestandteil der Automatisierung des Projektmanagements.

Die Grundlage eines solchen Koordinatensystems in unserem Projekt waren die folgenden Überlegungen: Ein Softwareprodukt kann in der Regel als Black Box betrachtet werden, die über drei Hauptwege mit der Außenwelt kommuniziert:

• über die Benutzeroberfläche ;
• durch zum Drucken auf Papier geformte Dokumente;
• über elektronische Datenaustauschprotokolle ( API / EDI ).

Im Raum dieser drei Dimensionen sehen Endbenutzer Software. Zum anderen zielt die Erstellung von Software genau auf die Bildung und Verarbeitung dieser Datenströme ab.

Quelle

Darüber hinaus wurden die Hauptdatenbankobjekte und automatisierten Geschäftsprozesse als zusätzliche Koordinaten innerhalb des Projekts übernommen. Um in diesem Koordinatenraum navigieren zu können, wurden entsprechende Klassifikatoren gebildet, die vom Projektmanager und den Analysten unterstützt wurden. Jedes Element des Klassifikators bestand aus einem Code und seiner Definition.

Im Verlauf meiner Projekte wurden für jeden Klassifikator nach und nach eigene Merkmale herausgearbeitet, die berücksichtigt werden sollten, wenn Sie sich für einen ähnlichen Ansatz entscheiden.

• In unserem Fall haben die Codes der gedruckten Formulare die Nummerierung der Formulare gemäß den Dokumenten des Kunden nicht wiederholt. Darüber hinaus verfügten einzelne Formulare über mehrere Druckoptionen. Während der gesamten Existenz von Software hat sich beispielsweise die Form eines Berichts aufgrund von Änderungen in den Zulassungsdokumenten mehrmals geändert (der Name und das Wesen des Berichts haben sich nicht geändert). Gleichzeitig musste für die alten Daten der Ausdruck dieses Berichts in den alten Formularen aufbewahrt werden. Die gleichen Überlegungen gelten für die Einstufung nach den Entwürfen für den elektronischen Datenaustausch.
• In der Hierarchie der Formulare können einzelne Elemente Navigationsfelder (Menüs), Listenformulare, Objektkarten, Registerkarten, Filterfelder, Formulare zum Laden / Entladen von Daten sowie Formulare für komplexe Gruppenoperationen enthalten.
• Es ist wünschenswert, die "Bäume" von technologischen Prozessen so "zu züchten", dass ihre Blätter atomare (unteilbare) technologische Vorgänge sind, auf deren Grundlage wiederum die Funktionsfähigkeit des Zugangsverteilungssystems (Sicherheitssubsystem) sichergestellt werden kann.
• Da alle Klassifizierungselemente mit diesem Ansatz auf JIRA-Bildschirmen in einem Feld angezeigt werden, muss zusätzlich zu den Komponentennamen mindestens eine primitive Codierung angegeben werden, um das Formular „Mitarbeiterregistrierung“ vom Prozess „Mitarbeiterregistrierung“ zu unterscheiden.

Für diejenigen, die keine einfachen Wege suchen, können JIRA-Aufgaben anhand der Registrierung der entsprechenden Codes im Feld „Komponenten“ gekennzeichnet werden. Wenn Sie Aufgaben jeglicher Art in JIRA registrieren, müssen Sie im Feld "Komponenten" nur die Liste der Objektcodes angeben, für die die geplante Arbeit geändert / umgeformt werden soll. Basierend auf den Ergebnissen der Problemlösung sollte der verantwortliche Ausführende die Zusammensetzung der Komponenten klären (falls erforderlich). Die Komponentenklassifikatoren selbst werden dann außerhalb von JIRA verwaltet.

Für Liebhaber von Komfort in dieser Hinsicht können möglicherweise die Subcomponents für das JIRA- Plugin viel helfen.

Es sollte beachtet werden, dass die Verwendung korrekt kompilierter Klassifikatoren von Softwarekomponenten implizit das kollektive Bewusstsein und die Kommunikationssprache des Projektteams standardisiert, was zu einer Verbesserung des allgemeinen Verständnisses führt. Auf der anderen Seite ist dieser Ansatz eine der Methoden des gewaltfreien Zwangs von Analysten zu detaillierteren Aufgaben, was wiederum die Genauigkeit der Schätzung des Zeitpunkts für die Umsetzung der Anforderungen an das Projekt erhöht.

Die übernommenen Klassifizierungsregeln für Aufgaben reduzieren nicht nur den Zeitaufwand für die Suche, sondern bieten auch die Möglichkeit, Folgendes zu automatisieren:

• Schätzungen des gesamten geplanten Arbeitseinsatzes (oder der tatsächlichen Arbeitskosten) für Arbeiten, die auf die Implementierung bestimmter Softwareelemente abzielen,
• Einschätzung der tatsächlichen Verteilung der Prioritäten - in einem bestimmten Stadium des Projekts kann sein Manager überrascht sein, dass der Großteil der Arbeit nicht in Bezug auf Prioritätskomponenten ausgeführt wird.
• Analyse der Qualität der Dokumentationsentwicklung ,
• Einschätzung der Qualität des Projektmanagements im Hinblick auf die Planung. Einerseits ist es nicht sinnvoll, Aufgaben zu planen, bei denen Komponenten nicht gebildet (geändert) werden, und andererseits gibt die Aufgabenplanung, bei deren Entwicklung sich Dutzende von Objekten ändern, an, dass das Problem nicht ausführlich dargelegt wird.

Binden Sie sich beim Binden von Aufgaben nicht die Hände

Bei der Beschreibung der allgemeinen Prinzipien unseres Modells wurde gesagt , dass nur ein Verbindungstyp "Grund" -> "Handlung" verwendet wird (und im Rahmen des beschriebenen Projekts war dieser Zusammenhang völlig ausreichend). Der Wunsch, dieselben JIRA-Mechanismen zur Automatisierung der Verwaltung in mehreren verschiedenen Projekten zu verwenden, ist jedoch erforderlich, um die Anzahl der verwendeten Beziehungstypen zu erhöhen und die Ansätze für ihre Anwendung zu vereinheitlichen.

Quelle

JIRA "out of the box" bietet dem Benutzer verschiedene Arten von Verbindungen zwischen Aufgaben, und die unkontrollierte Verwendung dieser Verbindungen kann zu traurigen Konsequenzen führen. Um uns und andere nicht zu verwirren, haben wir uns auf die folgenden Grundregeln für die JIRA-Aufgabenbindung geeinigt.

• Das Schließen des gleichen Verbindungstyps in der Schleife ist nicht akzeptabel (obwohl JIRA dies zulässt).
• Eine zusätzliche Beziehung "Abhängig" ("Grund" => "Handlung") wird nur verwendet, um Aufgaben verschiedener Art und nur in der Richtung des "Flusses" des klassischen Kaskadenmodells (Wasserfall) zu verbinden: Anforderung => Analyse => Entwicklung => Testen => Dokumentation => Implementierung. Es ist nicht akzeptabel, diese Verbindungen in umgekehrter Reihenfolge anzugeben und Aufgaben desselben Typs damit zu verknüpfen. Wenn während der Implementierung neue Anforderungen entstanden sind, wird bei der Registrierung dieser Anforderungen bei JIRA die Verbindung zwischen ihnen und der Implementierungsaufgabe, in der sie aufgetreten sind, nicht hergestellt.
• Die Verbindung " Blöcke " ("Blöcke" => "Blöcke") kann innerhalb eines beliebigen Aufgabentyps zum Erstellen von Workflowsequenzen verwendet werden (z. B. zum Erstellen eines Testausführungsskripts).
• Die Beziehung " Cloners " ("parent" => "child") wird nur zur Übermittlung von Aufgaben des Typs "request" verwendet. Verknüpft das Originaldokument des Kunden mit mehreren Anforderungen ("übergeordnet") mit Aufgaben, die atomare Anforderungen "Nachkommen" enthalten.
• Die Beziehung "Ergänzung" ("Ergänzungen" => "ergänzt") wird nur für Beziehungen im Rahmen von Aufgaben des Typs "Anforderung" verwendet. Es wird verwendet, um die Beziehung zwischen der Aufgabe der Hauptanforderung und den Aufgaben zu registrieren, in denen Fehler, Kommentare und Erläuterungen, die während der Prüfung festgestellt wurden, aufgezeichnet werden. Tatsächlich wird bei Verwendung dieser Art von Kommunikation die Aufzeichnung des Verlaufs von Änderungen der Anforderungen bereitgestellt.
• Die Beziehung "Duplizieren" ("Duplizieren" => "Duplizieren") wird nur für die Kommunikation von Aufgaben des Typs "Anforderung" verwendet. Bei der Angabe von Duplikaten ist die Grundvoraussetzung zu bestimmen, in deren Rahmen die Umsetzung geplant wird. In Bezug auf Duplikate wird keine Kommunikation mit Implementierungsaufgaben erstellt.

Workflow für alle Gelegenheiten

Der Grund für viele Probleme ist, dass wir so viele Aufgaben festlegen, wie wir ausführen müssen, und nicht so viele, wie wir ausführen können.
Maxim Dorofeev

, JIRA, . , JIRA (workflow). .

. «» . , JIRA . , .

, «» «», «» ( , ).






, .
*

, :

— ;

— ;

— .


« » «» . , . «». , . «» ( ).

Fortsetzung folgt

BPM ( business process management ), . BPM «» , :

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

PMP ITIL . , , BPM , , . BPMS . - BPM ( , , Agile ). BPM « » ( , ). «» «» ( ). «»?

BPM . , , , BPM , .

Quelle

JIRA . , JIRA , , . BPM. , JIRA BPMS. Alle weiteren Vorschläge zur Verwendung von JIRA zur Automatisierung des Softwareprojektmanagements werden unter Berücksichtigung dieser Schlüsselüberlegung gemacht.

Einer der ersten Schritte auf der CMMI- Leiter besteht darin, Organisationsprozesse zu identifizieren, zu dokumentieren und zu vereinheitlichen. Im Rahmen der Artikelserie „JIRA: Die Regeln für die zeitnahe Erstellung schmackhafter Software“ sollen daher Vorgaben für alle zu lösenden Aufgabentypen konsequent formuliert und die Kriterienapparaturen für deren umfassende Bewertung aus Sicht des Prozessansatzes formuliert werden. Der nächste Artikel befasst sich mit den Merkmalen der Registrierung von Aufgaben des Typs "Anforderung" und von Geschäftsprozessen für deren Implementierung.