Jira gegen das Chaos in der Entwicklung: Wie man keine Aufgaben verliert

In einem früheren Artikel habe ich Ihnen gesagt, welche Add-Ons für Jira wir erstellt haben, damit der Arbeitsablauf so bequem wie möglich wird und das Ticket umfassend informativ ist. Im heutigen Artikel werden wir ein weiteres Problem lösen.

Gegeben:

• Sie entwickeln und unterstützen ein komplexes Softwareprodukt, das auf mehreren Clients ausgeführt wird.
  
• Sie haben mehrere Entwicklungsteams (Backend, IT-Operationen, iOS, Android, Web usw.), die unabhängig voneinander mit separaten Rückständen arbeiten.
  
• Sie haben mehrere Produktlinien, dh grob gesagt, ein Produktmanager leitet mehrere Projekte in seine eigene Richtung, ein anderer Manager - auf seine eigene Weise.
  
• Ihre Entwicklungsteams sind funktionsfähig, dh sie sind nicht separaten Produktbereichen zugeordnet, sondern lösen die Probleme aller Einheiten gleichzeitig und bedienen einen bestimmten Teil des technologischen Stapels.
  
• und natürlich benutzt du Jira!
  

Die Probleme:

• Die Prozessteilnehmer verstehen nicht, aus welchen technischen Elementen das Feature besteht und was im Moment noch am Projekt zu tun ist.
  
• Ingenieurteams arbeiten asynchron an demselben Projekt: Ein Team kann seinen Teil vor einem Monat beenden, und das zweite Team kann nicht einmal einen eigenen starten, weil sie sein Teil im Strom wichtigerer Aufgaben vergessen haben.
  

Es gibt ein offensichtliches Problem mit der Transparenz des Entwicklungsprozesses. Wenn es viele Projekte und Richtungen gibt, ist die Notwendigkeit eines magischen Instruments, das das Chaos beseitigt und ein klares Bild vermittelt, besonders akut. Leider zeigt unsere Erfahrung, dass die Standardfunktionen von Jira dies nicht vollständig bewältigen.

Ist das bekannt? Lassen Sie uns darüber nachdenken, was wir dagegen tun können.

Projektstruktur

Ich werde das Problem anhand des Entwicklungsbeispiels in Badoo analysieren. Wie funktioniert das Projekt? Welche Phasen durchläuft das Projekt? Welche Teile besteht eine typische Neuerung darin, dass mehrere Teams teilnehmen müssen?

Idee und Design

Der Produktmanager (PM) erstellt ein PROD-Ticket mit dem Typ Projekt in Jira, nachdem er herausgefunden hat, was am Produkt verbessert werden kann. Die Beschreibung dieses Tickets besteht aus einem einzelnen Link zu einer Seite in Confluence (ein Analogon zum Atlassian Wiki, das in Jira integriert ist). Diese Seite nennen wir PRD (Product Requirements Document). Es ist ein Schlüsselelement der Entwicklung. Tatsächlich ist dies eine detaillierte Beschreibung dessen, was im Rahmen des Projekts noch zu tun ist.


Bei der Erstellung dieses Dokuments arbeitet PM eng mit dem Designer zusammen. Hierzu wird ein weiteres PROD-Ticket mit dem Designtyp erstellt. Darin platziert der Designer Layouts, Symbolsätze usw. Diese Elemente werden dann aus Gründen der Übersichtlichkeit in die PRD eingefügt und auch von Entwicklungsteams in der Entwicklung verwendet.

Nachdem PM das Dokument geschrieben hat, legt es es zur öffentlichen Diskussion vor. Normalerweise nehmen andere PMs sowie Leads von Engineering-Teams an dem Gespräch teil. Die Diskussion findet direkt in den Kommentaren zu PRD statt. Dies ist praktisch, da der Korrespondenzverlauf erhalten bleibt und alle interessierten Teilnehmer Benachrichtigungen erhalten, wenn neue Kommentare angezeigt werden. Basierend auf der Diskussion werden vereinbarte Änderungen an der ursprünglichen PRD vorgenommen.

Wenn alle Nuancen geklärt sind, wird das anfängliche PROD-Ticket in den Rückstand der ausstehenden Entwicklung übersetzt. Danach sortiert das Produktteam diesen Rückstand einmal pro Woche nach Priorität gemäß den Zielen des Unternehmens, dem geschätzten Auspuff und der Komplexität der Implementierung. Die Projekte, die als die vielversprechendsten anerkannt wurden, gehen zur nächsten Stufe über - der Zersetzung. Hierzu wird ein spezielles MAPI-Ticket (Mobile API) für das Team der Systemarchitekten erstellt.

Hierbei ist zu beachten, dass wir diesen Prozess automatisiert haben, um schneller projektbezogene Tickets zu erstellen und den menschlichen Faktor zu eliminieren (sie haben etwas vergessen, falsch verknüpft oder markiert). So verfügt beispielsweise das Root-Ticket des Projekts in der Kopfzeile über zwei zusätzliche Schaltflächen.



Der erste erstellt ein Ticket für Designer, der zweite für Systemarchitekten. In diesem Fall werden neue Tickets automatisch mit den erforderlichen Attributen gefüllt: Die richtigen Bezeichnungen, ein Link zu PRD, eine Beschreibungsvorlage und vor allem - werden miteinander verknüpft.

Diese Flussoptimierung basiert auf dem Jira ScriptRunner- Plugin, über das ich in einem früheren Artikel geschrieben habe .

Zersetzung

Nachdem die Systemarchitekten ein neues MAPI-Ticket mit einer PRD erhalten haben, entscheiden sie:

• Welcher Teil der Logik sollte auf der Serverseite und welcher Teil auf der Clientseite implementiert werden?
  
• Welche Befehle sollte der Client senden und welche Antworten sollte er vom Server erhalten?
  
• Welche Token sollten mit dem Client verbunden sein und welche sollten von der Serverseite kommen?
  

Sehr oft tritt zu diesem Zeitpunkt eine Änderung der PRD auf. Architekten beschäftigen sich eingehender mit Implementierungsdetails als bei der Diskussion über PRD. Daher kann sich herausstellen, dass es zur Erreichung der Geschäftsziele des Projekts möglich ist, die Entwicklung erheblich zu vereinfachen, indem ein Teil der ursprünglichen Anforderungen aufgegeben wird. Wir schätzen diese Initiative sehr.

Weitere Informationen zur Arbeitsweise unseres Architektenteams finden Sie in unserer API-Beschreibung im Bericht .

Die Ergebnisse der Arbeit von Systemarchitekten sind:

1. Das Erscheinen einer vollständigen technischen Dokumentation für das Projekt (eine Beschreibung des Client-Server-Interaktionsprotokolls unter Bezugnahme auf die in PRD beschriebenen Geschäftslogikfälle).
   
   
   Screenshot eines Teils der Dokumentation einer unserer derzeit inaktiven Funktionen

   
   
   
   
2. Geändertes Protokoll (Datei im Google Protocol Buffers-Format) in den Repositorys. Wenn zur Implementierung von Funktionen neue Funktionen oder Änderungen an alten Funktionen erforderlich sind, stehen diese Entwicklern aller Teams zur Verfügung.
   
3. Tickets für Entwicklungs- und Lokalisierungsteams. Dafür haben wir eine spezielle Oberfläche, über die Sie die erforderlichen Tickets für alle beteiligten Teams gleichzeitig erstellen können. Es wird über einen Link von einem MAPI-Ticket geöffnet.
   
   
   
   Durch Klicken darauf öffnet sich die folgende von uns erstellte Oberfläche:
   
   
   
   Durch Klicken auf die Schaltfläche am unteren Rand des Formulars (im Screenshot nicht sichtbar) werden die erforderlichen Tickets angezeigt, die automatisch mit dem ursprünglichen MAPI-Ticket verknüpft werden. Es ist erwähnenswert, dass alle Entwicklungsteams in unserem eigenen Bereich (Projekt) Jira arbeiten: Das Backend-Team ist in SRV, das Android-Team ist in AND, das Web-Team ist im Web usw.
   
   Die Schnittstelle basiert auf der Jira REST API.
   

Somit kann die Struktur des Projekts wie folgt dargestellt werden:

Entwicklung und Start

Im allgemeinen Fall können alle Teams parallel an einem Projekt arbeiten und nur in der letzten Phase der Integration berühren. Das heißt, Client-Teams müssen nicht darauf warten, dass ein fertiger Server ihren Teil dazu beiträgt. Da das Interaktionsprotokoll während der Entwicklung ausführlich beschrieben wird, können Sie die erwartete Serverantwort sicher emulieren und die Clientlogik debuggen. Darüber hinaus benötigt der Server während der Entwicklung keinen Client. Der Serverprogrammierer implementiert das Protokoll einfach und deckt es mit Tests ab, die Clientanforderungen emulieren.

In der Regel wird eine Funktion im folgenden Szenario gestartet:

1. Der Server ist der erste, der seinen Teil der Funktionalität, die durch das Feature-Flag abgedeckt wird, in der Produktion auslegt. Somit bleibt diese Logik inaktiv, bis einer der Clients dieses Feature-Flag sendet.
   
2. Client-Teams testen vor der Veröffentlichung in der Produktion ihren Teil der Funktionalität, die sich bereits auf dem "Battle" -Server befindet.
   
3. Sobald Sie bereit sind, werden verschiedene Clients freigegeben. Senden Sie das gewünschte Feature-Flag und erhalten Sie eine neue Serverantwort.
   

Die Möglichkeit der synchronen Arbeit am Projekt ist ein großes Plus, das die Entwicklungseffizienz erheblich steigern kann. Hier liegt jedoch das Risiko: Einige Teams können „an den Tisch schreiben“, dh ihren Teil der Arbeit erledigen, der von anderen Projektteilnehmern niemals nachgefragt wird. Es kann mehrere Gründe geben:

• unterschiedliche Prioritäten für Entwicklungsteams; Probleme treten normalerweise nicht auf, wenn an Projekten gearbeitet wird, die für das Unternehmen sehr wichtig sind (sie sind alle bekannt und schwer zu vergessen), aber weniger wichtige können an letzter Stelle in den lokalen Rückstand eines separaten Teams gestellt werden.
  
• Projektmanagementfehler: Der Manager kann einfach vergessen, die Aufgaben des Entwicklungsteams richtig zu priorisieren, dh seine Teilnehmer wissen nicht einmal, dass das Ticket so schnell wie möglich in die Entwicklung aufgenommen werden sollte.
  

Wie können diese Probleme behoben werden? Wie kann sichergestellt werden, dass die Teile des Projekts nicht verloren gehen und die Teams vorrangigen Projekten die gebührende Aufmerksamkeit widmen?

Jira Standardfunktionen

Was kann die Standard-Jira-Funktionalität dem Projektmanager bieten, um diese Probleme zu lösen? Nicht so sehr:

• Filter
  
• Kanban-Bretter.
  

Filter

Mit dem Filter können Sie eine lineare Liste der Tickets anzeigen, die für eine beliebige JQL-Abfrage empfangen wurden. Dieses Tool ist sehr praktisch, um den Rückstand eines Teams zu bedienen, aber ich weiß nicht, wie ich es für ein qualitativ hochwertiges Projektmanagement verwenden soll, das auf verschiedene Teams verteilt ist. Das Maximum, das ein Manager tun kann, besteht darin, eine priorisierte Liste von Root-PROD-Tickets anzuzeigen. Anschließend müssen Sie sich die verknüpften Tickets ansehen. Dies ist jedoch äußerst unpraktisch und langwierig, insbesondere angesichts der Tatsache, dass die Hierarchie der Links mehrstöckig sein kann. Darüber hinaus kann das Entwicklungsteam mehrere zusätzliche Tickets erstellen, um die ursprüngliche Aufgabe zu lösen, und ihr Status muss ebenfalls überwacht werden.

Kanban-Bretter

Für diejenigen, die nicht wissen, wie dies in Jira funktioniert, werde ich erklären. Im Allgemeinen ist dies eine Liste von Aufgaben, die auf einem bestimmten Filter basieren und in drei Spalten unterteilt sind: "Backlog", "Aufgaben in der Entwicklung", "Abgeschlossene Aufgaben". Über die Benutzeroberfläche können Sie die Priorität von Aufgaben erhöhen, indem Sie einfach ein Ticket mit der Maus in die Liste ziehen. Gleichzeitig ändert sich die Rank- Eigenschaft, nach der Sie Tickets in Ihren Filtern sortieren können.

Hier haben wir bereits viel mehr Raum, um das Tool im Kontext der jeweiligen Aufgabe einzusetzen. PM kann einen Filter erstellen, der alle Aufgaben aller Abteilungen in die gewünschte Richtung auswählt. Dies kann beispielsweise durch automatisches Platzieren von Tickets mit den entsprechenden Etiketten erfolgen. Ich erinnere Sie daran, dass alle wichtigen Projekttickets für unser Projekt mit den entsprechenden Tools erstellt werden. Daher ist das automatische Kopieren der erforderlichen Etiketten des PROD-Root-Tickets in alle abgeleiteten Tickets eine triviale technische Aufgabe.

Wir verwenden Kanban-Boards, um Rückstände von Ingenieurteams zu bilden und zu kontrollieren. Mit dem Swimlanes-Tool kann ein Board in Projekte gruppiert werden, die Engineering-Teams entsprechen. Mit diesem Tool kann PM den Fortschritt seiner Projekte im Kontext verschiedener Teams überwachen und Teamtickets priorisieren.


Schema eines Produkt-Kanban-Boards, auf dem Tickets für PM-Projekte nach Teams gruppiert sind

Das Problem ist, dass das Tool keine einfache Möglichkeit bietet, Tickets nach PROD-Quellkarten zu gruppieren, dh nach Funktionen: Ich möchte den Fortschritt jedes Projekts in allen Entwicklungsteams einzeln überwachen.

Excel

Die naheliegendste Lösung ist die Verwendung von Tabellenkalkulationen. Schließlich können Sie alles tun, was Sie möchten: bequem, schön, informativ. So etwas wie das:



Sie können den allgemeinen Arbeitsumfang für jedes Projekt an einem Ort sehen. Sie können verschiedene Notizen machen, ausgefüllte Tickets streichen usw. Hier ist alles gut, bis auf eine Fettschrift, aber: Es ist äußerst schwierig, die Relevanz solcher Tabellen aufrechtzuerhalten. Der Ticketstatus ändert sich ständig, es werden neue erstellt. Alle Änderungen manuell vornehmen? Sie können es den ganzen Tag verbringen. Aber wir sind für Effizienz, oder?

"Und lass uns überqueren!"

Warum nutzen wir nicht die Bequemlichkeit und Klarheit von Tabellenkalkulationen, indem wir eine automatische Synchronisation mit Jira hinzufügen? Wir haben alle Möglichkeiten dafür! Aus diesem Grund haben wir beschlossen, ein zusätzliches Tool auf der Basis der Jira REST-API zu erstellen, das automatisch den aktuellen Informationsstatus beibehält und über eine praktische Benutzeroberfläche verfügt.

Die Werkzeuganforderungen waren wie folgt:

• die Fähigkeit, Listen von Projekten und deren Ableitungen aus Tickets gemäß willkürlichen JQL-Abfragen zu erstellen (dies ist erforderlich, damit jeder PM seinen eigenen Bereich (Einheit) erstellen kann, in dem er nur seine Projekte sehen und verwalten kann);
  
• Neue Projekte in Jira sollten automatisch in der Benutzeroberfläche angezeigt werden.
  
• Neue Tickets im Projekt sollten automatisch in der Benutzeroberfläche angezeigt werden (dh wenn das Entwicklungsteam entscheidet, dass mehr Tickets zur Implementierung der Funktion benötigt werden, wird dies dem PM sofort in der Benutzeroberfläche angezeigt).
  
• Abhängig vom Status der Tickets sollten sich die Farben der Zellen der Tabelle ändern (für ein schnelles Verständnis der Teilnehmer des Projektstatus).
  
• die Fähigkeit, Projekte zu sortieren (um sie richtig zu priorisieren);
  
• automatisches Ausblenden abgeschlossener Projekte zwei Wochen nach Abschluss.
  

PM beginnt mit der Arbeit mit dem Tool und erstellt einen eigenen Bereich (Einheit), der den Namen und die JQL-Abfrage angibt:



Als Nächstes wird Jira aufgefordert, eine Liste der Projekte für die angegebene JQL-Abfrage abzurufen. Über Links in Jira werden auch alle abgeleiteten Tickets von Ingenieurteams verwendet. Das Ergebnis ist so etwas wie diese Tabelle:



Oben finden Sie Links zum Umschalten zwischen Einheiten.

Tabellenzeilen sind die Root-PROD-Tickets der Einheit. In den Zellen sehen wir die Aufgaben des Projekts für bestimmte technische Abteilungen. Das Befüllen erfolgt automatisch nach den Regeln zum Verknüpfen von Projekttickets. Abgeschlossene Stufen sind grün markiert, nicht rot gestartet und aktuell gelb.

Links führen zu Tickets nach Jira. Sie können auch kurze Informationen zum Ticket erhalten, indem Sie den Mauszeiger über den Link bewegen:



Mit einer Häufigkeit von einmal alle paar Minuten wird an die Jira-API die Anforderung gesendet, eine aktuelle Liste der Projekte für alle Einheiten zu erhalten, um die Liste der Derivate von Tickets sowie deren aktuellen Status zu synchronisieren.

Das Sortieren erfolgt durch einfaches Ziehen und Ablegen des gewünschten Projekts an die gewünschte Stelle in der Liste:



Es ist wichtig zu beachten, dass mit diesem Tool in Badoo nicht nur Produktmanager arbeiten, sondern auch Leiter von Entwicklungsteams. In der Tat ist es wichtig, dass jeder versteht, was in den Produktbereichen geschieht, welche Teams bei der Umsetzung wichtiger Projekte für das Unternehmen mehr Fortschritte gemacht haben als andere und welche dahinter stehen.

Schlussfolgerungen

Jira "out of the box" bietet leistungsstarke Funktionen zum Verwalten der Projektstruktur und der Beziehung zwischen Tickets. Es gibt auch Plugins, die die Funktionen von JQL erheblich erweitern (z. B. können Sie zum Filtern von Tickets Verknüpfungen zwischen Tickets und deren Typen verwenden). In unserem Fall fehlte uns nur die Fähigkeit, alles nach Bedarf zu visualisieren.

Glücklicherweise ermöglicht Jira die Erstellung zusätzlicher praktischer Tools auf der Grundlage seiner API, die an die Geschäftsprozesse des Unternehmens angepasst sind. So konnten wir beispielsweise das Problem lösen, das sich aus der Transparenz der Durchführung von Projekten in einem Dutzend Produktbereichen mit ein wenig Aufwand und der Verwendung der zusätzlichen Funktionen dieses Task-Trackers ergab. Es wäre interessant, in den Kommentaren zu lesen, wenn Sie versuchen würden, solche Add-Ons bei Ihnen zu erstellen oder andere Lösungen für Ihre Aufgaben zu finden.

Vielen Dank für Ihre Aufmerksamkeit!