Verwendung von Kanban in der WordPress-Entwicklung

Von Zeit zu Zeit werden andere fragen, wie ich es schaffe, die verschiedenen Aufgaben, Ressourcen, Ressourcen und damit verbundenen Dinge während eines Projekts zu organisieren. Erstens habe ich mich entschieden, Pressware klein zu halten (und das hat einige Gründe), damit ich es anders betreiben kann, als wenn es natürlich größer wäre.

Zweitens verwende ich normalerweise eine sehr verkleinerte Version eines Kanban-Boards. Für diejenigen, die nicht vertraut sind, ist Kanban wie folgt definiert:

ein japanisches Fertigungssystem, in dem die Lieferung von Komponenten durch die Verwendung einer Anweisungskarte geregelt wird, die entlang der Produktionslinie gesendet wird.

Zu diesem Zweck dachte ich, ich würde einen kurzen Überblick darüber geben, wie ich normalerweise jede Spalte und jede Karte einrichte, sowie die Tools, die ich verwende, um jede Aufgabe zu erledigen.

Kanban in der WordPress-Entwicklung

Im Allgemeinen enthält jedes Board, das ich einrichte – und ich werde gleich über die Tools sprechen, die ich dafür verwende – vier Spalten, von denen jede wie folgt definiert ist:

1. TODO. Dies ist im Wesentlichen der Rückstand an Aufgaben, die erledigt werden müssen, um das Projekt abzuschließen. Es ist eine Auflistung aller Anforderungen, die normalerweise in der Leistungsbeschreibung aufgeführt sind, aber in Aufgaben unterteilt sind, die sich durch jede Spalte bewegen können, um den erzielten Fortschritt zu sehen.
2. Machen. Wenn sich eine Karte in dieser Spalte befindet, bedeutet dies, dass das Team, jemand anderes oder ich daran arbeiten. Manchmal enthält eine Karte mehrere Unteraufgaben (die normalerweise als Kontrollkästchen gekennzeichnet sind), und wir halten sie mit dem Status der Aufgabe auf dem Laufenden. Ich versuche, jede Karte mit einem Commit im Quellcode in Verbindung zu halten, damit wir, wenn wir etwas rückgängig machen müssen, eine Karte zurück in eine Spalte verschieben. Alternativ können wir, sobald wir eine Änderung festgeschrieben haben, die Karte in die nächste Spalte verschieben.
3. Überprüfung / Inszeniert. Diese Spalte bedeutet, dass die Arbeit erledigt wurde und bereit ist, vom Benutzer in der Staging-Umgebung der Website überprüft zu werden. Normalerweise gebe ich Kunden Zugriff auf das Board, damit sie genau das tun können. Das heißt, sie können sehen, wann etwas zur Überprüfung bereit ist, haben Zugriff auf die Staging-Site und können überprüfen, ob die in der Leistungsbeschreibung und auf der Karte aufgeführten Anforderungen erfüllt sind.
4. Fertig. Sobald der Kunde bestätigt hat, dass die abgeschlossene Arbeit zu seiner Zufriedenheit erledigt wurde, bewegt sich die Karte in die Spalte „Erledigt”, der Code wird in den Master-Zweig gemergt, und dann wiederholt sich der Zyklus. Wenn die Aufgabe jedoch nicht erledigt ist, geht die Karte zurück zu Doing und bewegt sich zurück durch die Pipeline, bis sie zur Freigabe bereit ist.

Nun, wenn es um die Arbeit an Projekten geht, gibt es einen weiteren Aspekt, der berücksichtigt werden muss: Assets.

Eine einzige Quelle der Wahrheit

Konkret spreche ich über alles, was reicht von:

• Schriftarten,
• Entwürfe,
• Anmeldeinformationen für APIs von Drittanbietern,
• Tools von Drittanbietern,
• oder allgemein alle anderen Vermögenswerte, die von Beginn des Projekts an oder ab dem Zeitpunkt des Projektentwicklers benötigt werden.

Es gibt ein paar Möglichkeiten, damit umzugehen, und ich versuche, die Art der Vermögenswerte bestimmen zu lassen, wo ich Dinge platziere. Beispielsweise werden Design-Assets häufig in einem freigegebenen Dropbox-Ordner oder vielleicht auf einer Karte aufbewahrt, wenn sie klein sind (aber normalerweise nicht). Selbst dann kann ich immer noch eine Ressourcenspalte erstellen und Karten mit Links zum Beispiel zum Dropbox-Ordner auflisten.

Ein sehr einfaches Beispiel für die Verwendung von Trello.

Wenn es sich um Anmeldeinformationen für eine API handelt, kann ich sie auf einer Karte unter der Spalte „ Ressourcen ” platzieren, aber wenn es sich um etwas Sensibles handelt, kann ich eine private Droplr-Notiz verwenden und sie dann mit dem Projektmanagement-Tool meiner Wahl verknüpfen.

Sie bekommen jedoch die Idee: Die Art des Assets bestimmt, wo es gelagert wird, aber das Kanban-Board verweist immer irgendwie darauf. Dies trägt dazu bei, dass es für Sie und alle Beteiligten eine einzige Quelle der Wahrheit bleibt.

Und für Werkzeuge?

Ich denke, viele von uns lieben es, das neue glänzende Ding auszuprobieren. Für manche ist es fast eine Gewohnheit:

Ein neues Projektmanagement-Tool wird veröffentlicht? Lass es uns versuchen. Für andere gibt es eine bewährte Methode, die funktioniert, warum dann nicht dabei bleiben?

Unabhängig davon, wo Sie hinfallen, denke ich, dass es wichtig ist, herauszufinden, was für Sie und Ihr Team am besten funktioniert, und es dann konsistent und auf eine vorgeschriebene Weise zu verwenden, die projektübergreifend angewendet werden kann.

Für mich verwende ich in der Regel die folgenden Tools:

• Trello- oder GitHub-Projekte. Dies hängt stark vom Kunden ab.
• Dropbox zum Teilen von Assets.
• Droplr zum Sichern von Anmeldeinformationen.
• Google Docs für Leistungsbeschreibungen und Geschäftsbedingungen
• Google Docs für Spesenabrechnungen
• Rechnungsmäßig für Rechnungen.
• Eversign für eSignaturen auf den oben genannten Dokumenten.

Ich weiß, dass bei einigen der oben genannten Software einige Bedenken hinsichtlich der Sicherheit haben, insbesondere wenn es um finanzielle oder sichere Informationen geht.

Foto von John Salvino auf Unsplash

Ich nehme das nicht auf die leichte Schulter. Die Faustregel, der ich zu folgen versuche, lautet: Wenn etwas meiner Meinung nach absolut sicher aufbewahrt werden muss, verwende ich ein geeignetes System, um es zu verwenden. Ansonsten, wenn es etwas ist, bei dem es mir wirklich nichts ausmacht, wenn jemand darauf zugreifen würde, dann ist es für mich in Ordnung.

Und ich denke, das ist eine wichtige Überlegung, die wir anstellen müssen, wenn wir anderen einen Dienst erbringen. Tatsächlich ist es wahrscheinlich Inhalt für einen anderen Beitrag, wenn nicht für einen ganzen anderen Blog. Aber das ist weder dieser Beitrag noch dieser Blog – zumindest nicht jetzt.

Mein Punkt?

Stellen Sie schließlich sicher, dass Sie Folgendes haben:

• eine Möglichkeit für Sie und Ihren Kunden, den Fortschritt eines Projekts über den gesamten Entwicklungslebenszyklus hinweg zu verfolgen,
• eine Möglichkeit für sie, zu sehen, wie die Dinge laufen, die nicht so offen technisch sind wie Quellcodeverwaltung,
• eine Möglichkeit zum Teilen und Zugreifen nach Bedarf,
• die Fähigkeit, bei Bedarf zu kommunizieren und Fragen zu stellen.

Ich bin mir sicher, dass es noch andere erwähnenswerte Dinge gibt, aber diese sind der Schlüssel zum Inhalt dieses Beitrags. Die Verwendung von Kanban in der WordPress-Entwicklung ist also nicht schwierig, wird aber auch durch ein paar zusätzliche Dinge untermauert, die den Prozess vereinfachen können.

Behalten Sie eine Single Source of Truth bei, die von Drittanbieterdiensten unterstützt wird, die die Zusammenarbeit vereinfachen.