Überblick über Entwicklungsprozesse und -verfahren

Dieses Dokument gibt einen Überblick über die Entwicklungsprozesse und -verfahren von Leading2Lean. Dieser Prozess beschreibt die Verantwortlichkeiten, Richtlinien und Verfahren, die von Leading2Lean bei Änderungen am Produktionsdienst und an der Infrastruktur einzuhalten sind. Alle Mitarbeiter sind verpflichtet, diese Richtlinie zu befolgen.

Das Leading2Lean-Technologieteam ist damit beauftragt, unseren Kunden eine stabile und zuverlässige IT-Infrastruktur bereitzustellen. Der Zweck des Entwicklungsprozesses besteht darin, Dienstunterbrechungen in unserer Rechenzentrumsumgebung zu minimieren und die Systemverfügbarkeit und -integrität zu fördern. Der Chief Technical Officer (CTO) ist für die Pflege und Aktualisierung des Entwicklungsprozesses und der -verfahren nach Bedarf verantwortlich. Dieser Prozess wird ferner durch organisatorische Kontrollen geregelt, die als Teil unseres AICPA-SOC-2-Typ-2-Compliance-Programms definiert sind. Diese Kontrollen werden jährlich von unserem externen Prüfer auditiert.

Der Entwicklungsprozess beginnt damit, dass ein Entwickler das Ticket prüft, sich bezüglich Architektur und Design mit Kollegen abstimmt, Code schreibt, Feedback vom QA-Team erhält und schließlich die Software für die Kunden freigibt. 

Geltungsbereich

Dieses Dokument definiert den Lebenszyklus von Funktionsanfragen und Fehlern. Es beschreibt außerdem die Prozesse und Verfahren, die sicherstellen, dass für jedes Release ordnungsgemäße Tests und Validierungen durchgeführt werden. Dieses Dokument beschreibt nicht den Änderungsmanagementprozess, wie er in unserer Übersicht über die Richtlinie zur Änderungskontrolle definiert ist.

Definitionen

Backlog: Eine Sammlung von Fehlern und Funktionen, deren Entwicklung noch nicht begonnen hat. Im Backlog befinden sich alle Tickets mit niedrigerer Priorität. 

Fehler: Eine Funktion, die nicht wie vorgesehen funktioniert. Fehler können von nicht schwerwiegend bis äußerst schwerwiegend reichen. In der Fehlerliste befinden sich alle Fehler mit niedrigerer Priorität. Tickets werden während des Triage-Meetings in die Fehlerliste aufgenommen. Tickets werden den Mitgliedern des Entwicklungsteams aus der Fehlerliste zugewiesen.

Funktion oder Erweiterung: Verhalten, das für die Software noch nicht entwickelt wurde. Dies kann eine Änderung bestehender Funktionalität oder die Erstellung neuer Funktionalität sein.

Projekt oder Epic: Eine Sammlung von Fehlern und Funktionen. Projekte werden auf der Roadmap verwaltet. 

Roadmap: Eine Sammlung von Projekten. Die Roadmap ist das Planungsboard für größere Projekte. Die Roadmap steuert die Entwicklung neuer Funktionen, sowohl großer als auch kleiner. 

Triage: Sammlung neuer Tickets. Die Triage-Liste ist der Ort, an dem alle neuen Tickets erstellt werden. Das Triage-Team verschiebt die Tickets anschließend entweder in die Liste „Fehler“, die Roadmap oder den Backlog.

Übersicht

Jedes Entwicklungsticket durchläuft 3 Hauptphasen: 1. Planung, 2. Entwicklung und 3. Qualitätssicherungstests. Jede Phase wird im Folgenden besprochen.

Planung

Wir nutzen für den Planungsprozess einen multidisziplinären Triage-Ansatz. Unsere Support-, Entwicklungs- und Qualitätsteams treffen sich regelmäßig zu einem Triage-Meeting, um neue Probleme, Funktionsanfragen und Verbesserungen zu bewerten. Je nach Schweregrad können diese Probleme einen eskalierten Break/Fix-Reaktionszyklus auslösen, um im Falle von Problemen mit hoher Priorität den Dienst wiederherzustellen oder eine Verschlechterung des Dienstes darstellen. Andernfalls erhalten sie eine anfängliche Priorität und werden zur zusätzlichen Planung, Priorisierung und Terminierung an unser Produktteam weitergeleitet.

Funktionen werden typischerweise unter Einbeziehung einer kleinen Anzahl von Personen geplant.  Dazu können Mitglieder des Produktteams, Fachexperten, Kunden usw. gehören. Dies wird von unserem Produktmanagementteam vorangetrieben.

Die Mehrheit der Funktionsanfragen wird während des Roadmap-Planungsmeetings besprochen. Während dieses Meetings werden Projekte und eskalierte Funktionsanfragen besprochen. Projekte werden gegenüber anderen Projekten priorisiert, und Funktionsanfragen werden geprüft und in den Backlog verschoben. Funktionsanfragen können mit einem Projekt auf der Roadmap verknüpft werden.

Entwicklung

Sobald der Planungsprozess abgeschlossen ist, wird diese Arbeit der Entwicklung zugewiesen. Das Entwicklungsteam verfügt über eigene Entwicklungsumgebungen, die eine Spiegelung unserer Produktionsumgebung darstellen. Dies ist ein wesentlicher Bestandteil unseres Qualitätsprogramms. In jedem Schritt unseres Entwicklungslebenszyklus (Entwicklung, Qualitätssicherung, Staging & Produktion) unterhalten wir eine separate Infrastruktur, um sicherzustellen, dass alle abgeschlossenen Arbeiten ordnungsgemäß getestet und überprüft werden, bevor sie in unsere Produktionsumgebung gelangen.

Wir setzen ein vollständiges Set branchenüblicher Entwicklungstools ein, die für Versionskontrolle, automatisierte Tests, statische Codeanalyse und Codequalität entwickelt wurden. Diese Tools liefern dem Entwickler frühzeitig und regelmäßig Feedback, um die bestmögliche Codequalität sicherzustellen. Sie helfen außerdem dabei, eine klare Trennung der Entwicklungszweige aufrechtzuerhalten, um eine gegenseitige Beeinflussung zwischen Entwicklern zu vermeiden, die an unterschiedlichen Projekten, Aufgaben und Elementen der Codebasis arbeiten. Diese Tools bieten eine standardisierte Methode für Peer-Code-Reviews und Genehmigungsprozesse, um sicherzustellen, dass jeder Code, der für Qualitätssicherungstests bereit ist, alle automatisierten Tests und Validierungsprüfungen bestanden hat.

Unsere Entwickler kommunizieren direkt mit dem Support-Team, dem Produktteam oder anderen Entwicklern, wenn Fragen zur Umsetzung eines Tickets aufkommen. Alle Änderungen an der Benutzeroberfläche erfordern die Genehmigung des Produktteams. Da Änderungen an der Benutzeroberfläche Auswirkungen auf Kunden haben und möglicherweise Training erfordern, arbeiten wir mit Kunden, dem Support und dem Produktteam zusammen, um sicherzustellen, dass bei der Gestaltung von Änderungen an der Benutzeroberfläche angemessene Sorgfalt angewendet wird, damit die Auswirkungen auf Kunden minimiert werden. Alle Änderungen an der Benutzeroberfläche werden außerdem während der Qualitätssicherungstestphase von unserem Support-Team überprüft, um die ordnungsgemäße Funktionalität zu validieren und sicherzustellen, dass Kunden die richtigen Benachrichtigungen und das erforderliche Training erhalten.

Entwickler sind verpflichtet, unsere automatisierte Testsuite bei allen Änderungen erfolgreich auszuführen, wie es zu ihren normalen Arbeitsabläufen gehört. Sobald das Ticket diese automatisierten Tests bestanden hat, kann es von einer anderen Person als dem Entwickler überprüft werden. Dieses Ereignis informiert wichtige Teammitglieder darüber, dass es Zeit für Feedback ist, und zeigt außerdem an, dass das Ticket der Veröffentlichung näherkommt.

Der gesamte Code wird von einem anderen Entwickler einem Peer-Review unterzogen, bevor er an das QA-Team weitergegeben wird. Dies trägt dazu bei, sicherzustellen, dass mehr als eine Person weiß und versteht, was geändert wird und warum. Der Zweck eines Code-Reviews sollte darin bestehen, über das übergeordnete Ziel der Änderungen nachzudenken, den Code auf einfache Fehler zu überprüfen, den Code auf Ineffizienzen zu untersuchen, um Klärung zu bitten, wenn etwas nicht richtig aussieht, und die Einhaltung der Codierungsstandards und Best Practices zu gewährleisten. Manchmal überarbeitet der ursprüngliche Entwickler den Code aufgrund von Feedback während der Testphase. Wenn dies zu einer erheblichen Menge an Codeänderungen führt, wird eine zusätzliche Überprüfung durchgeführt. Sobald der Konsens zum Code-Review aufgezeichnet und dokumentiert wurde, kann der Code an das QA-Team zur Veröffentlichung freigegeben werden

Qualitätssicherungstests

Sobald die automatisierte Testsuite erfolgreich und fehlerfrei abgeschlossen wurde und das Code-Review erfolgreich beendet ist, kann das QA-Team mit dem Qualitätssicherungs-Testprozess beginnen.

Die beiden Hauptaktivitäten im Testprozess sind das Ausführen automatisierter Testskripte und manuelles Testen. L2L verfügt über eine Reihe von UI- und Unit-Testfällen, die über die Befehlszeile ausgeführt werden. Außerdem gibt es einen Linting-Prozess, der den Code auf grundlegende Programmierfehler überprüft. Alle Entwickler sollten sowohl die Testsuite als auch den Linting-Prozess ausführen, bevor sie ihren Code zur Überprüfung einreichen. Das QA-Team führt nach der Bereitstellung des Codes in der QA-Testumgebung eine eigene Überprüfung der Ergebnisse der automatisierten Testsuite durch. Dadurch wird sichergestellt, dass wir über eine saubere Testumgebung verfügen, um zu beurteilen, ob die Codeaktualisierung wie vorgesehen und gemäß unseren Qualitätsstandards funktioniert.

Das QA-Team koordiniert das manuelle Testen des Codes, um zusätzliche Qualität sicherzustellen. Das Feedback des QA-Teams wird in das Entwicklungsticket aufgenommen. Häufig muss der Code überarbeitet und aktualisiert werden, bevor die QA ihre Genehmigung erteilt. Die QA zeigt durch die Genehmigung des Pull Requests an, dass der Code zusammengeführt werden kann. Die QA führt den Code in die Hauptcodebasis zusammen, sobald alles genehmigt wurde. Dadurch wird sichergestellt, dass Entwickler keinen Code in unsere Hauptcodebasis zusammenführen und den QA-Prozess umgehen können.

Während der Qualitätssicherungs-Testphase wird das QA-Team außerdem Mitglieder des Support-Teams und den Kunden einbeziehen, um Benutzerakzeptanztests durchzuführen. Diese Tests sind entscheidend, um sicherzustellen, dass die Codeänderungen nutzbar sind, den Anforderungen der Kunden entsprechen und alle branchenbezogenen Vorschriften und Anforderungen erfüllen.

Änderungskontrollprozess und Bereitstellung in der Produktion

Um sicherzustellen, dass alle Änderungen an unserer Produktionsumgebung einem Standardprozess folgen, haben wir einen Änderungsmanagementprozess gemäß unserer Übersicht über die Richtlinie zur Änderungskontrolle implementiert. Dadurch wird sichergestellt, dass im Unternehmen die richtigen Kontrollmechanismen vorhanden sind, um die Qualität, Sicherheit und Verfügbarkeit der Produktionsumgebung zu gewährleisten. Weitere Informationen zu diesem Prozess finden Sie unter dem oben genannten Link.

Es ist wichtig zu beachten, dass L2L im Rahmen des Änderungskontrollprozesses ein automatisiertes Bereitstellungsskript verwendet, um Software aus dem Code-Repository auf Kundens服务器n freizugeben. Zu keinem Zeitpunkt aktualisieren Mitarbeiter die Produktionsumgebung manuell. Dieses automatisierte System erstellt für jede neue Version/Bereitstellung einen Prüfpfad und überprüft, ob die entsprechenden Genehmigungen vorliegen. Sobald dies erfolgt ist, dürfen die Freigabeskripte die Produktionsserver aktualisieren. Dieses automatisierte Skript informiert das interne Unternehmen außerdem über die Bereitstellungen. Nach Abschluss der Bereitstellung führt dieses automatisierte System zudem „Smoke-Tests“ durch, um zu überprüfen, ob die Bereitstellung erfolgreich war und die Produktionsumgebung ordnungsgemäß funktioniert.

Retrospektive-Besprechung

Falls veröffentlichter Code ein altes Problem erneut hervorruft oder das System einen Alarm auslöst, findet ein retrospektives Meeting, auch Post-Mortem genannt, statt. Ziel des Meetings ist es, die Fakten im Zusammenhang mit der Veröffentlichung des fehlerhaften Codes zusammenzutragen, Möglichkeiten zur Vermeidung ähnlicher Ereignisse in der Zukunft zu besprechen, Aufgaben zur Vermeidung künftiger Ereignisse zuzuweisen und das Team über den Vorfall zu informieren. Diese Meetings sollten innerhalb von 36 Stunden nach dem Ereignis stattfinden und möglichst viele Entwickler sowie Mitglieder des Qualitätssicherungsteams zur Ursachenanalyse und zu Schulungszwecken einbeziehen. 

Kundenbenachrichtigung

Kundenbenachrichtigungen können während dieses Prozesses zu mehreren Zeitpunkten erfolgen. Kunden werden häufig während der Planungs-, Entwicklungs- und Qualitätssicherungsphasen konsultiert sowie nach der Veröffentlichung des Codes. Der Kunde wird auf folgende Weise benachrichtigt:

• Persönlicher Kontakt / geplante Meetings. Kunden, die an bestimmten Entwicklungsprojekten beteiligt sind, können eingeladen werden, an regelmäßigen Update-Meetings teilzunehmen, um Pläne, Entwürfe und den Projektstatus zu überprüfen.
• Persönliche E-Mail an Kunden. Alle eingehenden Support-Tickets werden aktualisiert, um den Kunden darüber zu informieren, dass die Änderung auf den Produktionsservern veröffentlicht wurde, und das Ticket wird geschlossen. Wenn kein Support-Ticket erstellt wurde, kann sich ein Supportmitarbeiter direkt an den Kunden wenden. Wenn nur ein Kunde von einer Änderung betroffen war, werden möglicherweise keine anderen Benachrichtigungsformen verwendet.
• Änderungsprotokoll. Alle Änderungen, die sich auf Kunden auswirken, enthalten ein Änderungsprotokoll. Dies umfasst Fehlerbehebungen, kleinere Aktualisierungen und Funktionsanfragen. Wenn eine Änderung nur einen einzelnen Kunden betraf und die Auswirkungen geringfügig waren und der Kunde direkt kontaktiert wurde, wird möglicherweise kein Änderungsprotokoll hinzugefügt. Kunden können über das Support-Menü in der Anwendung auf das Änderungsprotokoll zugreifen.
• Massen-E-Mail. Bei allen größeren Änderungen an der App wird eine E-Mail an alle Administratoren gesendet. Massen-E-Mails werden hauptsächlich für Produktankündigungen und umfangreiche Verbesserungen der Benutzeroberfläche verwendet, können aber auch in weiteren Szenarien eingesetzt werden.
• In-App-Benachrichtigungen können für relevante Änderungen verwendet werden.