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 EntwicklungJedes 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
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
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.
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.
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 NormenUnsere 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” bedeutetJede 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). |
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!
CodemetrikAutomatisierte 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 TestsIn 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!