In der Reihe #HowWeWork wollen wir Einblicke in unseren Arbeitsalltag bei der com2m als Dortmunder Software-Startup geben. Was machen wir als Startup anders, wo läuft es ähnlich und was sind unsere Herausforderungen? In dieser Blog-Reihe erfahrt Ihr es. Im ersten Teil schauen wir auf unsere Softwareentwicklung und welche Prozesse und Tools dort zum Einsatz kommen.

Prozesse im Startup? Unbedingt!

Prozesse sind teilweise negativ belegt, zum Teil auch zu recht. Viele dürften schwerfällige und unsinnige Prozesse in Konzernen kennen, die lediglich des Selbstzwecks wegen existieren. Aber auch bei uns im Startup geht es nicht ganz ohne Prozesse, insbesondere wenn es um Software-Entwicklung geht. Wir versuchen unsere Prozesse so schlank und agil wie möglich, gleichzeitig so straff wie nötig zu organisieren. Entscheidend ist dabei, dass das ganze Team darüber entscheidend, wie die Prozesse aussehen und ob sie sinnvoll sind. Passt ein Prozess nicht mehr, wird er verändert oder abgeschafft. Geht es zu chaotisch zu? Dann definieren wir einfach einen neuen Prozess. Die Prozesse werden alle durch verschiedene Tools gestützt.

Entwicklungsprozess

Unser derzeitiger Hauptentwicklungsprozess ist SCRUM – leicht abgewandelt und auf unsere Bedürfnisse angepasst. In zweiwöchigen Sprints entwicklen wir Produktinkremente. Dabei plant das gesamte Team den Sprint und diskutiert die Aufwände für einzelne Stories. Eine Besonderheit und Herausforderung ist, dass wir multiple Projekte und die Produktentwicklung in einem Team bearbeiten. Jedes Projekt und unsere IoT-Plattform hat ein eigenes Backlog und eine Roadmap bzw. einen Projektplan. Wir nennen diese Activity Streams. Entsprechend der aktuellen Priorisierung setzt sich das Team Backlog aus den Stories der verschiedenen Activity Streams zusammen.

Team Backlog resultiert aus verschiedenen Activity Streams

Selbstverständlich nutzen wir JIRA für die Ticketverwaltung und Sprintplanung. Das SCRUM-Team-Board beinhaltet Issues aus den verschiedenen Projekten. Die Aufwände für die einzelnen Stories schätzt das Team mit Hilfe von Planning Poker Cards (siehe Titelbild). Bei der Schätzung sucht jedes Teammitglied verdeckt eine Karte aus, die den Aufwand seiner Meinung nach am besten trifft. Die Karten sind an die Fibonacci-Reihe angelehnt (bis 13, danach 20, 40 um einfacher zu rechnen), da der Aufwand mit steigender Komplexität auch immer ungenauer zu schätzen wird.

Pull Requests und Code Reviews

Wir haben eine einfache Regel: Keine Zeile Code geht in unseren Hauptbranch, ohne dass mindestens ein zweiter Entwickler auf den Code geschaut hat. Der Code-Review erfüllt zwei Ziele. Zum einen stellt er die Qualität des Codes und der Anwendung sicher, zum anderen können sich Entwickler durch pro-aktives Feedback stetig weiterentwickeln. Und wir können mit stolz sagen, dass selbst in den stressigen Projektphasen niemals von dieser Regel abgewichen wird.

Feature Branches

Die Code-Reviews werden auf git Pull-Requests mit Hilfe von Atlassian BitBucket durchgeführt. Für jede Story wird ein eigener Feature-Branch erstellt, der kontinuierlich gebaut wird. Sobald das Feature fertig entwickelt ist stellt der Entwickler den Pull-Request. Ein Merge kann erst nach Freigabe durch einen zweiten Entwickler sowie mit einem erfolgreichem Build erfolgen.

Continuous Delivery

Zu jedem guten Entwicklungsprozess gehört eine Continuous Delivery Pipeline. Das ist auch bei uns nicht anders. Jeder Commit wird gebaut. Jedes Feature nach dem Merge automatisch auf unseren Jenkins Entwicklungs-Server deployt. So können alle Features direkt von den anderen Teammitgliedern und dem Product Owner ausprobiert und getestet werden. Auch für das Live-Deployment und den Release genügt ein Knopfdruck im Jenkins (wenn man mal von komplexeren Daten-Migrationen absieht). Das Deployment der Anwendung erfolgt mit Hilfe von Ansible-Skripten. Auf diese Weise lässt sich im Build-, Test- und Auslieferungsprozess fast alles automatisieren und die Arbeit der Entwickler stark vereinfachen.

Tools im Überblick:

Nachfolgend noch mal alle Tools im Überblick:

  • Ticketverwaltung: JIRA
  • Wiki: Confluence
  • Git-Server: Bitbucket
  • CI-Server: Jenkins
  • Deployment: Ansible