Wie kann ein effektiver Projektmanagementprozess unter Bedingungen eingerichtet werden, unter denen "richtig" und "was besser" nicht möglich ist, aber noch getan werden muss? Der Artikel bietet einen Überblick über die Verwendung von JIRA zur Verwaltung eines Softwareentwicklungsprojekts im Interesse eines großen Regierungskunden. Ich würde mich freuen, wenn die beschriebenen Ansätze Ihnen persönlich helfen, die Effektivität Ihres Teams zu steigern und die Spannung im Projekt zu verringern. Jede Kritik ist willkommen.
QuelleSohn schwieriger Fehler
Nach der großen Anzahl von Modellartikeln im Internet zu urteilen, wie Projektmanagementsysteme in der Softwareentwicklung richtig angewendet werden können, ist dies ein einfaches und dankbares Geschäft. Der tatsächliche Einsatz automatisierter Steuerungssysteme in Projekten, an denen ich teilnehmen konnte, war jedoch nicht so "rosig", wie man es erwarten könnte. In der Praxis sind mehrere typische Fälle aufgetreten.
Die besten Optionen waren die Verwendung eines der vielen Fehlerverfolgungssysteme durch das Projektteam. Die Struktur von Aufgaben und Geschäftsprozessen eines Projekts entwickelte sich normalerweise „out of the box“. Diese Systeme wurden hauptsächlich von Teams von Programmierern und Testern verwendet. Eine solche Entwicklungsorganisation hat sich bei kleinen Projekten mit Privatkunden gut ausgezahlt, oder wenn die Aufgaben der ausübenden Künstler nur Garantiesupport für das Softwareprodukt umfassten (Korrektur erkannter Fehler). Mit dem Wachstum neuer Anforderungen begann dieser Ansatz jedoch zu rutschen. Dies äußerte sich in einem längeren Zeitaufwand für den Vergleich der Kundenanforderungen und der im Bugtracker gespeicherten Informationen (und die manuelle Erstellung integrierter Berichte) sowie in der Aufteilung des Teams in zwei Lager („gute“ Programmierer und „schlechte“ Analysten).
Andere Situationen beschränkten sich auf „brillante“ Inspirationen der Führung, als mithilfe von Verwaltungshebeln die besten Methoden für die Softwareentwicklung in die Aktivitäten der Projektteams „eingeführt“ wurden. Diese Führer glaubten zwar, dass ihre Handlungen nur auf den Prozess der Suche nach dieser "Silberkugel" beschränkt waren. Sie beschäftigten sich nicht mit Konzepten wie „
Sprint “, „
Aufgabenverbrennungsdiagramm “ oder „
kumulatives Flussdiagramm “. Und selbst wenn sie sich die Mühe machten, waren die Berichtsdokumente, die (erneut manuell) über den Stand des Projekts erstellt werden mussten, lose mit dieser besten Methodik verbunden. Versuche, Kunden mit diesen Methoden vertraut zu machen, führten dazu, dass sich die Bedingungen des Projekts nicht änderten, und bei den alten Berichten mussten zusätzlich neue zusätzliche Berichte (gemäß der neuen Methode) erstellt werden. Solche Widersprüche waren besonders ausgeprägt bei Regierungsauftragsprojekten, deren Organisationsbedingungen direkt mit der erfolgreichen Anwendung von
Agile ,
RUP oder
PMBOK in Konflikt standen.
Die Apotheose der Managementautomatisierung war das Projekt, das Informationssystem auf Bundesebene im Interesse eines großen Landeskunden zu verfeinern. Im Rahmen dieses Projekts verwendete der Kunde selbst
HP Service Manager und
JIRA . HP Service Manager wurde zum Sammeln und Analysieren von Softwarefehlern verwendet. Mit Hilfe von JIRA plante der Kunde die Aktivitäten seiner Mitarbeiter im Zusammenhang mit der Korrektur dieser Fehler und der Weiterentwicklung des Systems. Die Liste der Aufgabenzustände in diesen Systemen bot eine Vielzahl möglicher Optionen für ihre Verarbeitung. Die detaillierten Verfahren zur Unterstützung dieser Aufgaben, die vom Projektbüro des Kunden festgelegt wurden (d. H. Personen, die nicht für Wartung und Entwicklung verantwortlich sind), wurden auf der
Confluence- Plattform veröffentlicht. Die Mitarbeiter des Auftragnehmers durften beide Systeme nutzen und wurden mit der Verantwortung für die Unterstützung von Vorfällen und Anforderungen betraut (mit vorübergehenden Richtlinien für die Bearbeitung von Aufgaben und einer progressiven Höhe von Geldbußen). Zusätzlich wurde eine Kopie von JIRA auf der Baustelle des Auftragnehmers bereitgestellt, mit deren Hilfe die Aktivitäten des Projektteams geplant wurden. Die Synchronisation der Aktivitäten aller drei Systeme erfolgte manuell (dazu musste ich in Excel ein „Blatt“ führen, in dem die Beziehung der Aufgaben und deren aktueller Zustand vermerkt war). Darüber hinaus passten die von JIRA erstellten Berichte nicht zum Management. Daher musste das Projektteam stündliche Berichte über ihre Aktivitäten bereitstellen, die auch manuell in Excel erstellt wurden. Die Situation war nicht ungewöhnlich, als der Leiter des Entwicklungsteams oder der Leiter der Selbsthilfegruppen bis spät in die Nacht „auflegte“ und auf der Grundlage der Ergebnisse des Projektteams zusammenfassende Berichte über den Stand des Projekts erstellte. Dieses Projekt wurde pünktlich erfolgreich abgeschlossen und mit Ausnahme einer Rekordproduktivität, einer erhöhten Anzahl von Nervenzusammenbrüchen, eines schnellen professionellen Burnouts und einer unerwartet niedrigen Marge in Erinnerung gerufen, gemessen an den Prämien „überlebender“ Mitarbeiter. Nach solchen Projekten verfolgt uns der Gedanke lange Zeit: „Wenn wir Werkzeuge entwickeln, die das Leben der Kunden erheblich erleichtern, warum verschlechtern wir dann aufgrund solcher Werkzeuge unser Leben so raffiniert?“
Merkmale der nationalen Entwicklung
Zusammenfassend können wir den Schluss ziehen, dass die größten Probleme bei der Automatisierung des Softwareentwicklungsmanagements bei Projekten für staatliche Aufträge aufgetreten sind.
QuelleDarüber hinaus führten wiederholte Versuche, diese Probleme in Übereinstimmung mit den Best Practices der Softwareentwicklung zu lösen, zu der Schlussfolgerung: Dies sind keine Probleme, sondern unvermeidliche Bedingungen für die Umsetzung des Projekts für den staatlichen Kunden. Eine Analyse mehrerer Projekte ermöglichte es uns, die folgenden verallgemeinerten charakteristischen Merkmale solcher Bedingungen zu identifizieren:
- Oft werden die anfänglichen Anforderungen der technischen Spezifikationen vage formuliert. Der Kunde gibt diesen Anforderungen im Verlauf des Projekts neue Bedeutungen (was unter anderem mit einer Änderung des aktuellen rechtlichen Rahmens für automatisierte Geschäftsprozesse verbunden ist).
- Das Spektrum der Anforderungen, die in den Leistungsbeschreibungen aufgeführt sind, reicht von „Korrektur der Inschrift“ bis „Implementierung eines Subsystems zur Überwachung und Analyse aller Prozesse“, während alle Anforderungen unbedingt umgesetzt werden müssen (Vorschläge zur Verfeinerung des Wortlauts werden in der Regel nicht akzeptiert, Sie können nur einige beeinflussen Grenzen der Umsetzungsmethode);
- Manchmal „schiebt“ der Kunde, der keine Ahnung hat, wie das Problem zu lösen ist, diese Probleme auf den Auftragnehmer, einschließlich der Anforderungen, die, gelinde gesagt, „esoterisch“ sind (so etwas wie „... das Subsystem sollte eine Prognose für den Wechselkurs der Hauptwährungen für liefern) kurz-, mittel- und langfristig ... ");
- Für den Fall, dass der Vertrag mit der Weiterentwicklung des bestehenden Systems zusammenhängt, verlangt der Kunde die Einführung einzelner Komponenten vor dem Testbetrieb mit der Garantie des unterbrechungsfreien Betriebs des gesamten Systems (vergleichbar mit der Fertigstellung eines Automotors für unterwegs).
- Der Kunde wird durch mehrere Einheiten (Organisationen) vertreten, deren Anforderungen häufig widersprüchlich sind.
- Das Budget und die Fristen für das Projekt bleiben trotz der Änderung und Hinzufügung von Anforderungen unverändert.
- Kunden suchen keine Zusammenarbeit mit Entwicklern (die Zusammenarbeit basiert auf dem Prinzip „Sie tun es zuerst und dann werden wir sehen“). Kundenvertreter vermeiden die Verantwortung, Entscheidungen bezüglich der Spezifikation von Anforderungen zu treffen, der Zeitpunkt der Koordination problematischer Probleme wird ignoriert, es ist sinnlos, vor Beginn der Entwicklung eine Koordination zu verlangen, weil Die Tatsache, dass das Team die Fristen nicht einhält, betrifft den Kunden nicht (d. h. dies sind unsere Probleme als Darsteller).
- Zum einen verlangt der Kunde die genaue Übereinstimmung des gesamten Dokumentationspakets mit den formalen Anforderungen von GOST, zum anderen die Entwicklung zusätzlicher Anweisungen zur Verwendung des Produkts bei der Lösung bestimmter Probleme.
All diese Faktoren provozieren in der Regel die Empörung des Projektteams über „unzureichende Kunden“ und „Missmanagement des Projekts“. Angesichts der Objektivität und Wiederholbarkeit der oben genannten Bedingungen sind die Beschwerden des Projektteams über die „Komplexität“ des Staatskunden mit den Beschwerden des Schiffsteams über die Kälte und Dunkelheit der Polarnacht vergleichbar, nachdem die Reederei eine große Ausschreibung für den Transport entlang der
Nordseeroute gewonnen hatte .
Wie sich herausstellte, teilen die am Softwareprojekt beteiligten Mitarbeiterteams neben den äußeren Bedingungen die gemeinsamen charakteristischen Merkmale.
- Der Kern des Projektteams kann aus 5-12 Mitarbeitern bestehen: Projektmanager, Analysten, Tester, technische Redakteure, Programmierer. Trotz der Tatsache, dass einige Mitarbeiter manchmal mehrere Rollen übernehmen können, zeichnen sich diese Projektteams in der Regel durch einen niedrigen „ Busfaktor “ aus. Dies an sich führt auch zu Einschränkungen bei der Verwendung agiler Methoden (zum Beispiel ist es unwahrscheinlich, dass die Verwendung der Pokerplanung unter solchen Bedingungen sinnvoll ist).
- Das Projektteam muss zusammen mit den Softwareentwicklungsprozessen gleichzeitig Garantieunterstützung (Korrektur von Softwarefehlern) und erweiterten Support (betriebliche Fertigstellung einzelner Systemmodule für aktuelle Änderungen in den Geschäftsprozessen des Kunden) bereitstellen.
- Im Rahmen der Ausführung einzelner Aufgaben sind Mitarbeiter aus benachbarten Abteilungen des Unternehmens sowie Subunternehmer (vom Kunden auferlegte externe Unternehmen) beteiligt, für die die Aufgaben des Projekts in der Regel zweitrangig sind.
Sieg der Hoffnung
Die zweite Ehe ist der Sieg der Hoffnung über die Lebenserfahrung.
Samuel Johnson
Vor zwei Jahren wurde ich als führender Analyst zu einem Projekt eingeladen, das
LANIT auf Anordnung der Regierung durchgeführt hatte. Das Projektteam wurde früher gebildet, das Projekt bestand in einer wesentlichen Verfeinerung des seit mehr als einem Jahrzehnt bestehenden automatisierten Systems. Im Allgemeinen waren die Projektbedingungen wie oben beschrieben. Zu diesem Zeitpunkt verwendete das Entwicklungsteam keines der vorhandenen Projektmanagementsysteme in seiner Arbeit (obwohl fast alle Mitarbeiter an Projekten teilnahmen, in denen solche Systeme verwendet wurden, und eine eher skeptische Meinung über die Notwendigkeit der Automatisierung des Managements hatten). Die aktuelle Ausgangssituation bot jedoch die Möglichkeit, die Automatisierung des Projektmanagements „von Grund auf“ zu testen.
Als Automatisierungsplattform wurde JIRA ausgewählt. Eine Kombination der folgenden Faktoren trug zu dieser Wahl bei:
- die Fähigkeit, Beziehungen zwischen vielen zu vielen Aufgaben aufzuzeichnen;
- Flexibilität der Einstellungen für die Box-Version;
- Speichern des Verlaufs aller Änderungen im Projekt;
- teilweise offene Architektur, die Möglichkeit der Verfeinerung auf Ihre eigenen Bedürfnisse;
- die Fähigkeit zur Schnittstelle mit externen Systemen, die bereits vom Projektteam verwendet wurden (SharePoint, Git, SVN usw.);
- die Fähigkeit zur Verwendung auf Ihrem Server (für geschlossene Projekte);
- die Anwesenheit eines Mitarbeiters in der Einheit, der über umfangreiche Erfahrung in der Verwaltung dieses Systems verfügt und daran interessiert ist, seine Anwendung zu vereinheitlichen.
In der Vergangenheit wurde JIRA Version 6.4 für die Arbeit verwendet. Die einzelnen Elemente der Lösungen, die in unserem Projekt in dieser Version implementiert wurden, waren jedoch teilweise in den neuen JIRA-Versionen enthalten (die indirekt die Richtigkeit der getroffenen Entscheidungen bestätigten).
Die Automatisierung des Projektmanagements verfolgte zunächst folgende Ziele:
- Verbesserung der Schlafqualität der Mitarbeiter des Projektteams (wie Sie wissen, arbeitet eine ausgeruhte Person viel effizienter);
- Gewährleistung einer transparenten Verteilung der Verantwortung für die Umsetzung der Projektaufgaben;
- Bereitstellung von "Multithreading" des Projektteams, d. h. Arbeit wo immer möglich parallelisieren;
- automatische Erstellung des aktuellen Standes der Dinge in Bezug auf die Umsetzung der jeweiligen Kundenanforderungen;
- Überwachung des aktuellen Projektstatus, um Probleme und Risiken des Projekts frühzeitig erkennen zu können;
- einheitliche Ansätze für die Rechnungslegung, Methoden zur Bewertung und zum Vergleich des Status verschiedener Softwareentwicklungsprojekte (ähnlich den Diensten von Google Analytics oder Yandex.Metrica , mit denen Sie Websites anhand derselben Indikatoren bewerten können);
- Erhöhung der Genauigkeit der Schätzung des Zeitplans von Aufgaben auf der Grundlage der gesammelten Statistiken.
Um „Automatisierung für Automatisierung“ zu vermeiden, wurden beim Entwurf eines Datenabrechnungsmodells in JIRA auch die folgenden Überlegungen (Einschränkungen) berücksichtigt:
Die Automatisierung des Projektmanagements sollte das Projektteam nicht stören. Unter Berücksichtigung der bisherigen negativen Erfahrungen in der Automatisierung des Projektmanagements war einer der wichtigsten Umsetzungsfaktoren die Schaffung solcher Bedingungen, dass jeder Mitarbeiter des Projektteams JIRA nicht als zusätzliche Belastung des Projektboots wahrnahm, sondern als kollektives Navigationssystem, das das Team rechtzeitig über eine drohende Gefahr informiert und zur Erreichung des Ziels beiträgt Projekt auf kürzeste und sicherste Weise. Darüber hinaus sollte die Verwendung dieses Navigationssystems das Leben aller Teammitglieder und nicht nur des Projektmanagements erleichtern. Zu diesem Zweck wurde zunächst das Verfahren für die Zusammenarbeit mit JIRA unter Berücksichtigung der Minimierung der von Programmierern, Testern und technischen Redakteuren aufgezeichneten Datenmenge geplant. Andererseits war es das Ziel, in JIRA ein komfortables Arbeitsumfeld für alle Projektmitarbeiter zu schaffen, das ihnen hilft, eine effektive Planung ihres Arbeitstages sicherzustellen.
Kontinuitätsgarantie. Eines der Ziele der Automatisierung des Projektmanagements ist die Gewährleistung der Kontinuität, damit jeder qualifizierte Mitarbeiter die Aufgaben eines pensionierten Teammitglieds ohne „Probezeit“ und mit minimalen Kopfschmerzen „übernehmen“ kann, damit „der Trupp den Verlust eines Kämpfers nicht bemerkt“. In diesem Zusammenhang erinnerte ich mich an einen Fall, den mir einer der Kunden erzählte. Sobald er für den Chef geblieben war, der ihm im Urlaub das Passwort von seinem Computer mit einer Replik mitgeteilt hatte: "Nun, dort ist alles klar, Sie werden es herausfinden, wenn etwas passiert ...". Dieser Mitarbeiter verbrachte mehrere schlaflose Nächte damit, den Inhalt mehrerer Ordner mit den Namen „xxxxx1“, „xxxxx11“ und „xxxxx111“ zu verstehen (die Namen der Ordner wurden im Interesse des Anstands geändert). Die Verhinderung solcher Situationen erfordert die Registrierung der Arbeitsergebnisse aller Mitarbeiter des Projektteams, einschließlich des Projektmanagers, bei JIRA.
Minimalismus Ziel der Automatisierung des Projektmanagements war es nicht, innerhalb einer Minute zu berechnen, wie viel Arbeitszeit ein Mitarbeiter für die Lösung der ihm zugewiesenen Aufgaben aufgewendet hat, sondern sicherzustellen, dass Aufgaben mit einer bestimmten Qualität in der erforderlichen Zeit gelöst wurden. Daher wurde bei der Bereitstellung eines Projekts in JIRA das Prinzip der Minimierung der im System aufgezeichneten Daten übernommen. Das heißt, Der im Steuerungssystem aufgezeichnete Parametersatz hätte für fundierte Entscheidungen nur minimal erforderlich sein müssen ("
Perfektion wird nicht erreicht, wenn nichts hinzugefügt werden muss, sondern wenn nichts entfernt werden muss "). Es wurde davon ausgegangen, dass das angenommene Modell der Projektmanagementautomatisierung unter Bedingungen hoher Unsicherheit und Inkonsistenz funktionieren sollte (z. B. können Sie das Datum des Dokuments kennen, aber nicht dessen Nummer und umgekehrt). Bei der Eingabe der aufgezeichneten Informationen haben wir nach Möglichkeit die
Miller-Regel verwendet , nach der die optimale Anzahl von Typen (Zuständen) innerhalb von „sieben plus oder minus zwei“ liegen sollte (was das Verständnis der Systemarbeit für die Mitarbeiter erheblich vereinfacht). So wurde beispielsweise bei der Gestaltung des Lebenszyklus von Aufgaben (Workflow) zunächst davon ausgegangen, dass die Anzahl der Zustände dieser Regel entsprechen sollte.
Konsistenz. Die Automatisierung des Projektmanagements sollte zur Kohärenz und Kohärenz der Maßnahmen aller Mitarbeiter des Projektteams beitragen (Verhinderung der Situation von "Schwan, Krebs und Hecht").
In einem der Projekte, an denen ich zufällig teilgenommen habe, hat ein Analystenteam innerhalb eines Monats ein Modell für automatisierte Aktivitäten in
IDEF0- Notation entwickelt. Es schien, dass die Verwendung der von der US Air Force (!) Entwickelten Methodik den Erfolg dieses Ansatzes garantierte. Als der Leiter der Programmierabteilung den mehrseitigen Analysebericht studierte, lautete seine erste Frage: „Also, was genau muss getan werden?“. Das generierte Modell erwies sich als ungeeignet für die Beschreibung der Problemstellung für Programmierer. Vertreter des Kunden bewunderten mehrmals, durchliefen zahlreiche Programme, fanden aber auch keine Anwendung dieses Modells zur Optimierung ihrer Aktivitäten. Letztendlich schmückten diese Schemata die Beschreibung technologischer Prozesse und verliehen diesem Dokument eine beispiellose Dicke und Festigkeit, aber der positive Effekt der Analyse war hiermit erschöpft. Die Ergebnisse des Arbeitsmonats mehrerer Analysten wurden vom Projekt praktisch nicht beansprucht.
Angesichts dieser Erfahrung sollte bei der Automatisierung des Projektmanagements ein einziger Aufgabenförderer erstellt werden, der eine koordinierte Umwandlung der Kundenanforderungen in ein endgültiges Softwareprodukt auf kürzestem Weg und mit minimalen Kosten gewährleistet. Gleichzeitig sollte auf der Grundlage der Überwachung der verfügbaren
Parameter dieses Förderers die sich abzeichnenden Eigenschaften des Projektteams identifiziert, gemessen und entwickelt werden, anhand derer der Zustand des Projekts in allen Phasen beurteilt werden konnte.
Kanban Board von innen nach außen
Meiner Meinung nach hängt der Erfolg der Steuerungsautomatisierung in hohem Maße davon ab, wie genau das Steuerungsobjekt in einem automatisierten System modelliert wird.
Da die Verwaltung des Softwareerstellungsprozesses automatisiert werden sollte, wurde eine Analyse dieses Prozesses durchgeführt. Meiner Meinung nach repräsentiert der Prozess der Erstellung separater Softwaremodule immer den klassischen Lebenszyklus von Wasserfällen. Zunächst wird eine Liste der Anforderungen für das erstellte Produkt angezeigt. Die Anforderungen können aus verschiedenen Quellen stammen und unterschiedliche Detaillierungsgrade aufweisen. Einige der Anforderungen sind miteinander verbunden, ein anderer Teil ist relativ unabhängig. Für individuelle Anforderungen können Sie sofort eine Entwicklungsaufgabe formulieren, während andere eine Klärung und Konkretisierung erfordern. Das heißt,
Es gibt immer Arbeiten im Zusammenhang mit der Erfassung, Sortierung und Klärung von Kundenanforderungen (während der Wortlaut der einzelnen Anforderungen bis zum Ende des Projekts möglicherweise nicht eindeutig ist). Nachdem die Anforderungen so spezifisch wie möglich sind, werden in der Regel sogenannte Aufgabendefinitionen für Gruppen miteinander verbundener Anforderungen gebildet, die die Besonderheiten der Implementierung dieser Anforderungen detailliert beschreiben und das Ausgangsmaterial für die Programmierer darstellen, um mit der Arbeit zu beginnen. Nach der Programmierung werden die erstellten Module autonom getestet, in das System integriert und erneut getestet. Entsprechend den abgeschlossenen Software-Updates werden entsprechende Änderungen an der Entwurfs- und Betriebsdokumentation vorgenommen, wonach eine Reihe von Aktivitäten ausgeführt werden.zielte darauf ab, die Erfüllung der Bestrebungen (Anforderungen) des Kunden und die anschließende Implementierung der entwickelten Funktionalität im kommerziellen Betrieb zu erkennen.
Das heißt,
Der Prozess der Erledigung einer Aufgabe bedeutete offensichtlich nicht die Übertragung auf andere Darsteller. Dieses Prinzip ermöglichte es, auf alle Arten von Aufgaben denselben Geschäftsprozess anzuwenden, da der Status der Arbeit in erster Linie aus Sicht des Ausführenden dieser Aufgabe bestimmt wurde. Der Standard-JIRA- Workflow wurde geringfügig geändert. Die Hauptänderung bestand darin, den Status "wiederentdeckt" durch den Status "ausstehend" zu ersetzen, d. H. Gibt an, wann die Arbeit an einer Aufgabe aus irgendeinem Grund unterbrochen wird. Um wiederentdeckte Aufgaben zu registrieren, wurde das Benutzerfeld "Wiederentdeckungszähler" verwendet. Gleichzeitig wurden die Arten von Gründen für die Übertragung von Aufgaben im Vorgriff auf eine Lösung detailliert beschrieben:- Koordination mit dem Kunden;
- Anforderung zusätzlicher Informationen vom Kunden;
- Warten auf die Lösung verwandter Aufgaben / Unteraufgaben;
- Eine Klärung der Problemstellung ist erforderlich.
Es ist zu beachten, dass durch die Einführung des Status „In der Warteschleife“ der „ Förderstoppknopf “ für die Mitarbeiter des Projektteams tatsächlich implementiert wurde , was wiederum die kollektive Identifizierung von Problemen in den frühen Phasen des Projekts sicherstellte.
Als Ergebnis der Analyse wurde das folgende Modell zur Registrierung von Projektinformationen bei JIRA implementiert. Der von JIRA dargestellte Standardansatz zur Aufgabenteilung wurde im Projekt nicht verwendet. Es wurden sechs Arten von Aufgaben erstellt, die im Wesentlichen den Hauptphasen der Softwareentwicklung entsprachen:- "Anforderung" - Art der Aufgabe zum Registrieren von Kundenanforderungen (ähnlich in neuen Versionen von JIRA - epic);
- «» – , ( ) ( ) ( JIRA – story);
- «» – ;
- «» – , ;
- «» – , ;
- "Implementierung" ist die Art von Aufgabe zum Aufzeichnen der Arbeitsergebnisse, die darauf abzielen, entwickelte Software in die Aktivitäten des Kunden einzuführen (Durchführen von Tests, Demonstrationen, Freigeben eines Releases / Patches / Datenfixes, Bereitstellen von Software auf den Servern des Kunden, Schulung von Benutzern usw.).
Unteraufgaben wurden verwendet, um bestimmte Probleme (deren Zeit zwei Stunden nicht überschreitet) während der Ausführung der Hauptaufgabe zu lösen (z. B. um eine Entwurfsentscheidung mit einem Programmierer oder Projektmanager zu koordinieren, Codeüberprüfungen durchzuführen, Testdaten vorzubereiten usw.).Gemäß den im Projekt festgelegten Regeln ist die Registrierung einer Anforderung eine obligatorische Grundlage für die Planung anderer Aufgaben. Nach der Registrierung der Anforderung und ihrer Klärung beim Kunden (falls erforderlich) werden andere Arten von Aufgaben gebildet, die darauf abzielen, diese Anforderung umzusetzen. Mit anderen Worten, im Rahmen des angenommenen Modells sollten andere Aufgaben immer mit der Anforderung verbunden sein, in deren Interesse sie erfüllt werden (unter Verwendung der Art der Verbindung „Ursache“ -> „Handlung“). Im Interesse der Implementierung einer Anforderung können mehrere Entwicklungsaufgaben erstellt werden, andererseits kann eine Aufgabe (für Analyse, Entwicklung, Test, Dokumentation, Implementierung) im Interesse mehrerer Anforderungen erstellt werden (im Gegensatz zum Standard-JIRA-Ansatz, wenn dies angenommen wirddass eine Aufgabe nur einer Aufgabe vom Typ episch zugeordnet werden kann). Im Rahmen des vorgeschlagenen Modells können auch andere abhängige Aufgaben in Beziehung gesetzt werden. Dieser Ansatz stellte einerseits die Kohärenz der getroffenen Entscheidungen sicher, andererseits bot er die Möglichkeit, den tatsächlichen Stand des Projekts ziemlich genau wiederzugeben. In diesem Fall sind verschiedene Möglichkeiten zur Organisation der Arbeit möglich, deren Verwechslung sehr schwierig erscheint.
- blau - die Aufgabe ist im Arbeitsplan enthalten;
- blau - die Aufgabe ist in Bearbeitung;
- pink - die Aufgabe hat keinen Executor;
- gelb - die Aufgabe steht noch aus, erfordert eine Lösung;
- grau - die Aufgabe ist geschlossen (Sie können es vergessen);
- orange - Die Fristen für die Erledigung der Aufgabe wurden unterbrochen.
Das Erscheinen roter Inschriften und Markierungen auf der Aufgabenkarte signalisiert die Notwendigkeit sofortiger Maßnahmen in Bezug auf die Aufgabe (z. B. wird die Inschrift rot angezeigt, wenn die Frist nicht festgelegt wurde).Zusätzlich zu den Farben sind die Aufgabenkarten im Dashboard während der Projektentwicklung von zusätzlichen Tags umgeben, mit denen Sie den Status der Arbeit am Projekt auf einen Blick beurteilen können.Prioritätskennzeichnungen:
- Normal;
- wichtig;
- kritisch;
- Blockieren.Etiketten zum Anforderungsrahmen:
- Entwicklung (Anforderungen im Rahmen von Projekten zur wesentlichen Überarbeitung bestehender Systeme);
- erweiterter Support (Anforderungen an die betriebliche Fertigstellung einzelner Systemmodule für aktuelle Änderungen der Geschäftsprozesse des Kunden);
- Garantieunterstützung (Softwarefehler erkannt);
- Nicht-Projektaktivitäten (Anforderungen des Projektmanagers in Bezug auf Aktivitäten vor dem Projekt, Refactoring , Vorverkauf , Entwicklung neuer Technologien, Schulung des Personals usw.).Etiketten des Grundes für die Erwartung:
- Anforderung zusätzlicher Informationen vom Kunden;
- Koordination mit dem Kunden;
- Warten auf die Lösung verwandter Aufgaben / Unteraufgaben;
- Eine Klärung der Formulierung ist erforderlich.Spezielle Tags:
- Die Datenbank wurde in der Aufgabe finalisiert.
- die Anzahl der Anforderungen in Bezug auf die Aufgabe (je mehr verwandte Anforderungen, desto wichtiger ist die Aufgabe);
- die Anzahl der ungelösten Unteraufgaben;
- Die Aufgabe wird wiederentdeckt.Tatsächlich ist dieses Dashboard das Hauptwerkzeug geworden, um eine Antwort auf die Frage des Projektmanagements zu erhalten: „Was ist heute am wichtigsten?“ Aus Sicht des vorgeschlagenen Modells ist es zur Vermeidung von Projektproblemen erforderlich, eine tägliche Reduzierung der Menge an Rot, Orange und Gelb im vorgeschlagenen Dashboard sicherzustellen. Ein Grund zur Besorgnis war andererseits auch das Fehlen verwandter Aufgaben für die Anforderung (d. H. Die Situation, in der die Anforderung geplant ist und keine Arbeit zur Implementierung vorhanden ist).Die Verwendung von Filtern für das erstellte Dashboard ermöglichte es im Komplex, den Stand der Dinge gemäß der ausgewählten Liste von Anforderungen widerzuspiegeln. Mit seiner Hilfe war es möglich, die Aktionen des gesamten Projektteams schnell zu koordinieren und die Bemühungen auf die problematischsten Bereiche zu konzentrieren, ohne ein ganzheitliches Bild des Projekts zu verlieren.Wasserfall kann nicht agil sein
Um die Ergebnisse der Arbeit an allen Arten von Aufgaben aufzuzeichnen, wurden zwei Repositorys bereitgestellt (für die Projektdokumentation und für den Softwarecode). Das Hinzufügen (Ändern) von Materialien in diesen Repositories spiegelte sich automatisch in den zugehörigen Aufgaben von JIRA wider und war die Hauptart der Berichterstattung durch die ausübenden Künstler.Die Organisation der Arbeit unter Verwendung des vorgeschlagenen Ansatzes zur Registrierung von Aufgaben in JIRA wurde auf das folgende Schema reduziert.- JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
- , . , , , . () .
- , , . , , ( ), () , , , ( ).
- ( ) , , . . , . «» , ( ).
- Im Idealfall sollten Testaufgaben gebildet werden, bevor Entwicklungsaufgaben registriert werden (die die Ziele von Programmierern festlegen). Während des Tests führt der verantwortliche Tester nicht nur ein Protokoll der erkannten Fehler, sondern korrigiert auch die festgestellten Ungenauigkeiten in der Testaufgabe und im Benutzerhandbuch.
- Entsprechend den Anforderungen, nach denen eine vollständige Liste der Arbeiten geplant wurde, werden Umsetzungsaufgaben gebildet (bei deren Registrierung die Priorität und die Fristen für die Umsetzung der Anforderungen erneut in JIRA festgelegt werden).
- Nach Lieferung an den Kunden kann die Anfrage mit der obligatorischen Angabe der Details des Abnahmebelegs in den Status „geschlossen“ versetzt werden.
Es ist zu beachten, dass die Bildung von Aufgaben aller Art zur Umsetzung einer einzigen Anforderung keine Voraussetzung für eine erfolgreiche Planung ist. Beispielsweise kann eine einfache Anforderung wie "Fehler in einem Feldnamen korrigieren" direkt einem Programmierer zugewiesen werden. Gleichzeitig wurde bei der Durchführung des Projekts festgestellt, dass der Löwenanteil der Kommentare während der Vorversuche und des Testbetriebs für Anforderungen verantwortlich war, für die keine Entwurfsentscheidungen getroffen wurden.
Im Rahmen des vorgeschlagenen Ansatzes hat sich die Arbeitsplanung mit
der Rolling Wave Planning-
Methode bewährt. Gleichzeitig konnte teilweise durch das oben beschriebene Dashboard die Fragmentierung und Inkonsistenz der geplanten Arbeiten vermieden werden. In der Anfangsphase der Registrierung ähnelte die Auswahl nach Anforderungen einem
roten Regenschirm , als für die meisten Anforderungen die Verfügbarkeitstermine und verantwortlichen Führungskräfte nicht festgelegt wurden und die Arbeiten nur für einen kleinen Teil von ihnen geplant waren. Das Dashboard der Anforderungen verwandelte sich jedoch allmählich in einen blaugrünen Teppich. Die roten und orangefarbenen Flecken auf diesem Teppich zwangen uns, tägliche Anpassungen an den beabsichtigten Aufgaben vorzunehmen, was dazu beitrug, die Projektrisiken zu verringern.
Das vorgeschlagene Datenorganisationsmodell zeigte eine gute Skalierbarkeit. Zunächst verwendeten nur drei Mitarbeiter des Projektteams (ein Analyst und zwei Programmierer) JIRA für ihre Arbeit, während die Anforderungen für einzelne Subsysteme erfasst wurden. Am Ende des Projekts wurden jedoch 100% der Entwicklungs- und erweiterten Supportanforderungen bei JIRA registriert und überwacht, an denen alle Mitarbeiter des Projektteams teilnahmen.
Trotz der Tatsache, dass die Idee der Automatisierung des Projektmanagements auf einem Kaskadenmodell der Entwicklung (Wasserfall) basierte, stellte sich heraus, dass im Rahmen des vorgeschlagenen Ansatzes agile Elemente auf Wunsch schmerzlos verwendet werden können. Und wer hat im Allgemeinen gesagt, dass der Wasserfall nicht flexibel ist? Um beispielsweise
Scrum im Rahmen des vorgeschlagenen Modells anzuwenden, reicht es aus, die Regelmäßigkeit von Ereignissen (Aufgaben) für die Implementierung von Software sicherzustellen, und dementsprechend werden alle mit diesem Ereignis verbundenen Arbeiten „gezwungen“, die auf diese Weise festgelegten Sprintregeln einzuhalten.
Darüber hinaus schränkt die vorgeschlagene Methode zur Registrierung von Aufgaben den Projektmanager nicht ein, den Kanban-Ansatz anzuwenden und die gesamte Vielfalt der von JIRA sofort einsatzbereiten
agilen Dashboards zu verwenden .
Fortsetzung folgt
Was ist das Ergebnis? Die entwickelte Software wurde kommerziell in Betrieb genommen. Während der Vorversuche, des Testbetriebs und der Abnahmetests zeichnete der Kunde viele Kommentare zum implementierten Softwareprodukt auf. In der Folge musste der Kunde jedoch auf der Grundlage von Materialien zur Klärung der in JIRA gespeicherten Anforderungen 25% der Kommentare als neue Anforderungen erkennen, die über den Projektumfang hinausgingen (die geplante Komplexität der Erfüllung dieser Anforderungen entsprach der abgeschlossenen technischen Aufgabe). Die mit der Umsetzung des Vertrags über staatliche Aufträge verbundenen Probleme sind nicht verschwunden. Die Überwachung der Einhaltung der Anforderungen mithilfe von JIRA ermöglichte es jedoch, die Risiken einer Störung in der Initiationsphase zu identifizieren und schnell darauf zu reagieren. Dies wiederum sicherte die positive Dynamik des Projekts in allen Phasen trotz der Besonderheiten der nationalen Softwareentwicklung. Es wurde festgestellt, dass, wenn Kundenanforderungen bei JIRA registriert wurden und Aufgaben für Analyse, Entwicklung und Test darauf gebildet wurden, es viel weniger Meinungsverschiedenheiten und Streitigkeiten in Bezug auf solche Anforderungen gab.
In der aktuellen Phase (Wartungsphase) spiegeln sich alle Anforderungen in JIRA wider. Alle Mitarbeiter des Projektteams setzen JIRA auf die eine oder andere Weise in ihrer Arbeit ein. Die Kosten für Programmierer, die Ergebnisse ihrer Arbeit in JIRA zu registrieren, betragen weniger als 1% ihrer Arbeitszeit. Für Analysten hingegen ist JIRA zu einem der wichtigsten Arbeitsinstrumente geworden. Das Finden eines vollständigen Satzes von Informationen für eine der Anforderungen des Kunden dauert weniger als eine Minute. Berichtsdokumente, die auf den Ergebnissen der durchgeführten Arbeiten basieren, werden automatisch auf der Grundlage der in JIRA enthaltenen Daten generiert. Basierend auf diesen Daten wird auch eine begleitende Dokumentation für Releases erstellt (eine Liste der Änderungen und ein Release-Testprogramm).
Zwei Jahre Erfahrung in der Anwendung von JIRA nach den neuen Regeln haben alte Wahrheiten bestätigt:
- JIRA ersetzt nicht das Projektmanagement, hilft jedoch dabei, den Fluss verschiedener Aufgaben schnell zu steuern.
- JIRA hilft Ihnen dabei, Ihr Projekt zur richtigen Zeit am richtigen Ort zu fokussieren. Dies wird jedoch nicht für Sie erledigt.
- JIRA wird die Probleme des Projekts nicht für Sie lösen, sondern Ihnen helfen, sie bereits in einem frühen Stadium zu identifizieren (gleichzeitig werden die Probleme identifiziert, die Sie zu verbergen hofften).
- Wie jedes automatisierte System hilft Ihnen JIRA dabei, Ihre Entscheidungen schnell umzusetzen, unabhängig davon, ob sie gut oder schlecht sind.
- JIRA ersetzt nicht die Kommunikation der Mitarbeiter des Projektteams, hilft jedoch dabei, Streitigkeiten schmerzlos beizulegen.
- JIRA wird einen Mitarbeiter nicht vor einer Entlassung bewahren, sondern einem anderen, der den Platz des Rentners eingenommen hat, helfen, sich schnell zu informieren.
- JIRA hilft bei der Erstellung von Projektberichtsdokumenten, jedoch nur auf der Grundlage der Informationen, für die Sie die Registrierung bereitgestellt haben.
Und vor allem - JIRA wird nicht für Sie entscheiden, ob Sie seine Hilfe nutzen oder nicht.
Jobs LANIT für Interessierte