Der CodeCoda Softwareentwicklungsprozess!

Wenn es um digitales Produktdesign geht, dreht sich bei CodeCoda alles um die spezifischen Bedürfnisse unserer Kunden. Wir haben CodeCoda gegründet, um ein großes Manko in der Softwareindustrie zu beheben: den Kundenfokus.
Unsere Prozesse sind perfekt gestaltet und eingebunden, um den Anforderungen unserer Kunden gerecht zu werden und gleichzeitig in der Kommunikation den persönlichen Kontakt zu pflegen. Wir glauben an den agilen Softwareentwicklungsprozess, und unsere Philosophie ist eng gebunden an die Lieferung von zusehends schnelleren, innovativen Softwareprodukten und Dienstleistungen.

Der Prozess der Lieferung der Software basiert auf dem Agilen Manifest. Wir verwenden verschiedene Methoden, die wir den Bedürfnissen unserer Kunden anpassen. Wir arbeiten mit Scrum, Kanban oder der Waterfall- Methode und identifizieren immer die geeignetste agile Lösung für unsere Kunden. Unsere Erfahrung in der Softwareentwicklung hat uns gezeigt, dass die Annäherung an Lieferprozesse in einer agilen Art, der einzige Weg ist, um unseren Kunden einen Mehrwert zu liefern.

Der Prozess

Kick-off der Entwicklung

Jedes Projekt durchläuft eine vordefinierte gemeinsame Phase, in der wir den Kunden und das gesamte dedizierte Entwicklerteam, unter Leitung des Projektmanagers, mit einbeziehen.

Die ersten Schritte sind:

  • Team-Meeting 
  • Produkt od. Projektbestimmungen
  • Release-Planung
In dieser ersten Phase sind alle Teilnehmer aufgefordert, das Projekt zu besprechen und ein Brainstorming durchzuführen, das normalerweise Lösungen und Ideen bringt oder manchmal auch die Risiken aufdeckt, die das Projekt umgehen muss. Das Ergebnis ist das eigentliche Backlog, welches die Planung des Produktrelease ermöglicht. Eine Checkliste, die Punkt für Punkt abgearbeitet wird, stellt sicher, dass wir keinen wichtigen Punkt übersehen.

Wöchentliche oder zweiwöchentliche Produktlieferungen

Je nach der gewählten agilen Entwicklungsmethode, liefern unsere Entwicklerteams regelmäßige Updates an die Arbeitsversionen, dies können QS-, Test- oder Live Versionen je nach Phase des Projekts sein.

Jeder Entwicklungszyklus beinhaltet:

  • Planung
  • Tägliche Meetings
  • Zyklusüberprüfungen
  • Rückblickende Überprüfungen
  • Projektmanagement
Der Prozess der Leitung von Projekten wird durch drei individuelle Rollen übernommen, die nicht alle zwingend erforderlich sind, aber koexistieren können. Je nach agiler Methode können ein Scrum Master, ein Produktmanager und / oder ein Projektleiter das Projekt gemeinsam mit dem Entwicklerteam betreuen.

Leistungsumfang, Change-Management und Budget

Die Art der innovativen Produkte, welche wir entwickeln, bringt von Haus aus gewisse Änderungen und Ergänzungen in der Entwicklungsphase mit sich, die in den Prozess mit einfließen. Ein Backlog dient diesem Zweck, und die Inhalte dieses Backlogs fließen, unter Berücksichtigung der Prioritäten und der Wichtigkeit der jeweiligen Aufgaben und/oder Funktionen, in die Planung des nächsten Entwicklungszyklus.

Wie sind der Entwicklungsumfang und das Budget miteinander verbunden?

  • Entwicklerteams, Projektmanager und Projekteigner sind für Empfehlungen und Entscheidungen verantwortlich und beeinflussen somit das Budget des Entwicklungsprozesses.
  • Entwicklerteams tragen die Verantwortung für eine kontinuierliche Schätzung des entsprechenden Backlogs und der Nachverfolgung der Arbeit in der Pipeline. Dieser Prozess erlaubt eine genaue Nachvollziehbarkeit der tatsächlich geleisteten Arbeit und der Arbeitsgeschwindigkeit.
  • Produkteigner sind hauptsächlich für die überwiegend nicht-technischen Änderungen im Leistungsumfang, der Festlegung der Prioritäten oder Ziele des aktuellen Entwicklungszyklus oder der Gesamtziele verantwortlich.
  • Projektmanager und/oder Scrum Master sind gemeinsam mit dem Entwicklerteam verantwortlich für die termingerechten Lieferungen und die prognostizierten Release-Daten.
  • Eine kontinuierliche Beurteilung des vorhergesagten Lieferzeitpunkts und -Umfangs hilft, die Struktur und Größe des Entwicklerteams, aber auch das Budget, festzulegen.
Dieser Prozess wird, alle Beteiligten mit eingeschlossen, iterative ausgeführt und kann „Budget und Leistungsumfangsmanagement Zyklus“ genannt werden, denn er erlaubt dem Produkteigner und allen Beteiligten eine präzise und vorhersehbare Kontrolle über das eingesetzte Team und die benötigten Budgets. Im Vergleich zu einem Top-Down-Ansatz oder mit anderen Worten, einem Management-zentrierten Ansatz, geben wir unseren Kunden die volle Kontrolle über Umfang und Kosten.

Projektrisiko managen

In der Regel identifizieren wir Risiken in einem frühen Stadium des Entwicklungszyklus, und häufig werden die Hauptfaktoren während des „Kick-offs der Produktentwicklung“ entdeckt. Sollte, aus welchem Grund auch immer, ein Risiko zu einem späteren Zeitpunkt entdeckt werden, vereinbaren wir ein Meeting mit allen Beteiligten und erarbeiten einen Plan, um das identifizierte Problem zu lösen.
Wenn während der Produktentwicklung ein Risiko entdeckt wird, veranstalten wir eine Risikomanagementsitzung, an der Projektmanager, Produkteignern und alle anderen Beteiligten teilnehmen. Auf diese Weise können wir zusammen mit den Produkteignern schnell reagieren und Risiken beseitigen, bevor sie zum Problem werden. Am wichtigsten ist, dass wir über Risiken bei gleichzeitiger Lieferung von Lösungsvorschlägen und konkreten Aktionsplänen, inklusive einer Zusammenfassung der Backlogs, Burndown Charts und der getroffenen Entscheidungen, kommunizieren.

Projektberichte 

Projekteigner erhalten wöchentlich, zweiwöchentlich oder monatlich Reports zum Entwicklungsstaus mit Zusammenfassungen der ausgeführten Aufgaben, Backlog Burn Down Charts und getroffenen Entscheidungen.

Entwicklungsprozess-Normen

Regeln und Normen

Unsere Teams halten sich an anerkannte Codierungsstandards, um eine konsistente, leicht verständliche und wartbare Codebasis zu liefern. Unabhängig von der angewandten Technologie, wählen wir die den Standard, welcher der Industrienorm für die jeweilige Technologie entspricht. Für unsere Produkte implementieren wir die besten und zuverlässigsten Technologien und verwenden zuverlässige, geprüfte Frameworks sowie Tools und folgen Technologietrends.

Was das Wort “fertig” bedeutet

Jede Funktionalität oder Änderung in dem von uns gelieferten Code entspricht den vorbestimmten Kriterien, die in unserer Definition des „fertigen“ Produkts aufgeführt sind und sichert so die Qualität und Konsistenz der Ergebnisse.

Wenn wir eine neue Kooperation mit einem Kunden beginnen, einigen wir uns auf die Definition des Status „fertig“. Unsere Standarddefinition „fertig“ definiert, dass eine User Story, ein Epic, eine Aufgabe oder ein Fehler aus dem Backlog oder einer zugewiesenen Aufgabe „fertig“ ist, wenn folgenden Schritte ausgeführt wurden…

 
Definiert Es gibt ein gemeinsames Verständnis zwischen den Entwicklern und den Produkteignern, wie das Produkt aussehen und sich verhalten soll.
Implementiert Die Aufgabe ist, zusammen mit Unit- und Funktionstests, entwickelt. Grafische Benutzeroberflächen sind vollständig implementiert.
Integriert Alle Tests werden automatisch bestanden.
Geprüft Ein Entwickler hat die Aufgabe/ Funktionalität manuell geprüft.
Freigegeben Der Code hat die Codeüberprüfung bestanden und wurde von 2 Entwicklern freigegeben (4 Augen Prinzip).
Akzeptiert Der Code wurde getestet und von der QS (oder einem anderen Entwickler) und vom Produkteigner freigegeben oder akzeptiert.
Geliefert Der Code wird an ein Repository übergeben und an eine geeignete Anwendungsumgebung geliefert (Vorschau, QS, Staging oder Live).
4 Augen Peer Code Review 

Unser Code Review Prozess, stellt sicher, dass jeder Teilcode nicht nur von dem Entwickler geprüft wird, der diesen Code geschrieben hat, sondern zusätzlich von 2 weiteren Entwicklern geprüft und freigegeben wird. Unser Konzept der Kontinuierlichen Integration (CI), eingebunden im Unit-Test, der automatisierten Funktionsprüfung und anderen Best Practices erlauben es nur den „Best of Breed“ Code in den Basiscode einzubinden. Wir verbringen zirka 5% unserer Zeit mit Tests und stellen sicher, dass unsere Arbeit unseren hohen Anforderungen entspricht und wir unseren Kunden nur die beste Qualität liefern!

Codemetrik

Automatisierte Test-Tools wie Sonar, Jenkins oder Travis CI werden für regelmäßige Prüfungen des Quellcodes verwendet. Festgelegte Prozeduren vermeiden zyklomatische Komplexität und verhindern Codeduplikate. Mit dem Ergebnis der Tests verbessern wir den Quellcode und verhindern Engpässe, die während der Programmierung entstehen können. Wir erreichen außerdem eine ausgezeichnete Testabdeckung, in dem wir Automation zur Berichterstattung verwenden.

Kontinuierliche Integration (CI) / Kontinuierliche Entwicklung (CD)

CodeCoda benutzt CI/CD als Entwicklungspraktik. Die häufige Zusammenführung von Codebasen hilft Integrationsprobleme zu verhindern. Außerdem nutzen wir Jenkins CI für automatisierte Qualitätsberichte und Tests in der Bereitstellungspipeline. Dieser Prozess sorgt dafür, dass nur Quellcode, welcher unseren Bereitstellungskriterien entspricht und relevante automatisierte Tests bestanden hat, in Produktionscodezweige integriert wird.
CI-Tools erlauben auch planmäßige oder ereignisbasierte Tests, um ein Feedback über Code- und Qualitätsstandards an das Entwicklerteam zu geben. Diese Tools und regelmäßige Regressionstests verbessern die Qualität des von Softwareingenieuren geschriebenen Codes und fungieren als Primärebene der Codeverifikation.

QS - Qualitätssicherung

Ingenieure der Qualitätssicherung führen Tests durch, um die höchste Stufe der Codequalität und -verwendbarkeit zu gewährleisten. Je nach den Bedürfnissen unserer Kunden, erstellen wir für jedes Projekt individuelle Qualitätssicherungsrichtlinien.

 
Umfang der QS-Prüfung

  • Unit Tests - kleine Codeteile, sogenannte Units oder Methoden, werden daraufhin überprüft, ob ihre Funktionalität die richtigen Werte ein- oder ausgibt. Es werden verschiedene Muster getestet: Ergebnistests, Zustandstests, Fluent Builder-Tests, Databasetests, Database Buildertests oder Integrationstests.
  • Funktionstests - Softwaremodule werden als Gruppe getestet.
  • Smoke Tests - Diese Art von Tests wird verwendet, um zu prüfen, ob die wichtigsten Funktionen laufen, und um zu entscheiden, ob ein Build stabil ist und andere Tests fortgesetzt werden können. 
  • User Interface Tests (UI) - Die Benutzeroberfläche wird auf Übereinstimmung mit den Designrichtlinien und früheren Modellen getestet.
  • User Experience Tests (UX) - Die Benutzerfreundlichkeit wird ausführlich geprüft und gemessen.
  • Regressionstests - Es wird geprüft, dass kein neu implementierter Code eine frühere Implementierung beeinträchtigt.
  • Security Tests - Die Datensicherheit wird getestet und gemessen.
  • Performance Tests - Testen der Reaktionsfähigkeit, Leistung und Stabilität einer Anwendung unter einer simulierten Arbeitslast.
  • Manual Acceptance Tests - Die Anwendung wird anhand der anfänglichen Spezifikationsanforderungen überprüft.

Ein zugewiesener QS-Ingenieur unterstützt individuelle Teams bei der Einrichtung automatisierter Tests, bei der Integration von Regressionstests und führt manuelle Tests sowie Testszenarien durch. Für Entwicklerteams ist es in den meisten Fällen wichtig von der QS unterstützt zu werden, um ein qualitativ hochwertiges und stabiles Produkt zu erzielen.

Automatisierte Tests

In der Softwareentwicklung ist ein bestimmter Regelsatz notwendig, um wartbare Codebasen zu garantieren. Nachstehend finden Sie einige Technologien, welche wir anwenden:

  • BDD - Behavior Driven Development (Verhaltensgesteuerte Entwicklung). Wir nutzen Gherkin um Verhalten zu abstrahieren und eine klare verständliche Sprache für Softwareingenieure und Beteiligte zu bieten.
  • TDD - Test Driven Development (Testgesteuerte Entwicklung). Ein Prozess, um geschriebenen Code mit Tests abzusichern. Dies hilft, in der Anfangsphase der Entwicklung, fehlerfreien Code zu erhalten.
  • Automationstools - Eine Vielzahl von Tools wird verwendet, immer abhängig von der zu entwickelnden Anwendung.

Exzellenz liefern

Bei CodeCoda schätzen wir zuerst die Menschen und deren Beziehung zueinander. Deshalb ist Kommunikation und Zusammenarbeit das wichtigste Kapital, das wir in der Zusammenarbeit mit unseren Kunden liefern. Wir lieben es, unseren Geschäftspartnern und Kunden dabei zu helfen, ihre Ziele zu erreichen. Dies ist unsere Interpretation des Agilen Entwicklungsprozesses!

Autor

Andreas Maier, CEO

Andreas ist ein ergebnisorientierter CEO, der knapp 30 Jahre an Erfahrung in der Hightech-Branche mit sich bringt. Seine Führungsrollen in Fortune-100 Unternehmen wie bei rentalcars.com (PCLN) und Intrasoft International, einem führenden R&D 21 Softwareanbieter mit Sitz in der EU, verleihen ihm wertvolle Kompetenzen.
Er hält einen Doktortitel der Universität Köln im Fachbereich Neuronale Netze.
Andreas gründete und mitbegründete in seiner Karrierelaufbahn zahlreiche erfolgreiche Startups wie XXL Cloud, ein Cloud-Speicherdienst, der letztendlich von einem Wettbewerber übernommen wurde.