Interview mit Robert Virkus über App-Entwicklung im Team

„So macht Software-Entwicklung Spaß und wird nie zur Fließbandarbeit“
Kommentare

Termindruck, sich verändernde Anforderungen, unflexible Codebasis, Kommunikationsschwierigkeiten im Team – es gibt unzählige Gründe, weshalb viele Softwareprojekte in Schieflage geraten. Was kann alles schief gehen und wie sollte man Problemen begegnen, um sie in Zukunft zu vermeiden?

Über diese und andere Fragen haben wir mit Robert Virkus, Gründer der Bremer Softwareschmiede Enough Software, gesprochen. Auf der MobileTech Conference, die kommende Woche vom 31. August bis 3. September in Berlin stattfindet, hält Robert die Session „App-Entwicklung im Team: Tools und Techniken“ (Mittwoch, 2. September 2015, 10:15 bis 11:15). Darin möchte er den Teilnehmer Anregungen zur Formulierung von Coding-Guidelines und der Zusammensetzung von Teams weiter geben sowie Tipps, welche Strukturen gewährleisten können, dass alle Projektbeteiligten an einem Strang ziehen? Außerdem hat Robert einige Tools im Gepäck, die das Zusammenspiel von Design, Entwicklung, Management und Testing erleichtern.

entwickler: Robert, aus deiner langjährigen Erfahrung heraus: Wo liegen bei der App-Entwicklung die Vorteile der Team-Arbeit im Vergleich zur Einzelkämpfertaktik?

Robert Virkus: Zunächst einmal: natürlich können auch Einzelne hervorragende Apps erstellen – nur werden Apps heutzutage tendenziell immer umfangreicher und dadurch für Einzelne schwerer zu bewerkstelligen. Auch findet man selten in einer Person neben der Programmiererfahrung auch das Design und UX-Know-How, die Testerfahrung und die Marketingerfahrung, die für erfolgreiche Apps notwendig sind. Da macht man als Einzelperson zwangsläufig an der einen oder anderen Stelle Abstriche.

Im Team kann sich jeder und jede um das kümmern, was er oder sie gut kann und gerne tut: Der Designer erstellt das UI und UX Konzept und liefert dem Entwickler die Assets in einer Form, die ihm erlaubt sich auf das Coden zu konzentrieren. Im Anschluss testet dann die QA die implementierten Features. Und der Projektmanager sorgt dafür, dass das Arbeitsumfeld stimmt und der Kunde auf dem Laufenden bleibt. Ich denke allerdings auch, dass diese Aufgabenverteilung nicht bedeuten darf, einen Tunnelblick zu entwickeln. Entscheidungen im UI und UX Design müssen immer mit den Kollegen aus der Entwicklung abgestimmt werden, um hier keine unnötig hohen Aufwände zu verursachen. Und natürlich muss der Programmierer seine eigenen Releases auch selbst testen und darf nicht in Trial&Error Manier die QA mit unausgegorenen Implementierungen bombardieren. Hier helfen insbesondere automatisierte Tests. Eine zentrale Aufgabe des Projektmanagers dem Team gegenüber besteht dann noch darin, die Aufgaben zu strukturieren und Feedback vom Kunden in die Arbeit einfließen zu lassen, ohne laufende Arbeiten zu stören.

entwickler: Unstimmigkeiten im Team können immer auftreten, doch wie begegnet man ihnen deiner Meinung nach am besten und wie kann man sie in Zukunft vermeiden? Hast du beispielsweise ein eigenes „Frühwarnsystem“ entwickelt, um etwaige Probleme oder Konflikte möglichst früh zu erkennen?

Virkus: Natürlich gibt es auch mal Konflikte, insbesondere unter Zeitdruck. Hier bin ich völlig Deiner Meinung: Es ist wichtig, diese Probleme früh zu erkennen und zu thematisieren, bevor sie eskalieren. Dafür gibt es im Scrum-Prozess ja die Retrospektive Meetings am Ende eines jeden Sprints. Sie sind zentraler Bestandteil des Entwicklungsprozesses und bieten das Forum, wo sich jeder und jede „auskotzen“ kann und wo man gemeinsam überlegt, was man verbessern kann. Voraussetzung dafür ist aber natürlich ein Arbeitsklima, welches von Offenheit und Kritikfähigkeit geprägt ist. Wenn ich als Entwickler das Gefühl habe, durch Kritik am Projektmanager kann ich meinen Job gefährden, schlucke ich Frust wohl lieber herunter.

Offenheit ist im Übrigen auch etwas, was mir im Umgang mit dem Kunden am Herzen liegt. Natürlich passiert es auch uns immer wieder, dass wir mit Aufwandsabschätzungen daneben lagen oder im Umgang mit neuen Tools auf unvorhergesehene Probleme stoßen. Das lassen wir unsere Kunden aber dann auch direkt wissen und tun nicht so, als wäre alles in Butter, nur um dann kurz vor der Deadline zu merken, dass wir das Ziel nicht erreichen werden. Stattdessen überlegen wir in diesen Fällen gemeinsam mit dem Kunden, wie wir mit der Situation umgehen. Grundsätzlich hat man in diesen Fällen natürlich drei Optionen: Das Featureset einschmelzen, die Deadline verschieben oder das Team vergrößern, um zur Deadline das volle Featureset liefern zu können. Alle sind schmerzhaft, aber weniger schmerzhaft als eine böse Überraschung am Projektende.

entwickler: Welche Rolle spielen feste Regeln und Strukturen? Disziplin ist wichtig, klar. Doch ab welchem Punkt wird zu viel Reglementierung kontraproduktiv?

Virkus: Vor zehn Jahren habe ich komplett ohne sichtbare beziehungsweise niedergeschriebene Strukturen gearbeitet. Natürlich war das Team bei Enough Software damals auch sehr viel kleiner und die Kundenansprüche waren andere. Aber ich bin immer noch überzeugt, dass Eigenverantwortung mindestens genauso wichtig ist wie Strukturen und Regeln. Ich glaube, ein guter Entwickler zeichnet sich auch dadurch aus, dass die Software, an der er arbeitet, auch ein bisschen „sein Baby“ ist. Ich freue mich immer, wenn die Kollegen mit glänzenden Augen zu mir kommen und mir neue Features in ihren Projekten zeigen. Und es ist für mich auch ein positives Zeichen, wenn sie sich über Bugs ordentlich aufregen und sich an ihnen festbeißen. So macht Software-Entwicklung Spaß und wird nie zur Fließbandarbeit, die von Code-Monkeys erledigt wird.

Für uns sind Methoden wie Scrum also keine starre Vorgabe, die es blind anzuwenden gilt. Wir benutzen Scrum und Kanban eher wie einen Baukasten, aus dem wir uns je nach Projekt unterschiedlich bedienen: Einige Dinge gehören fest zu unserem Prozess, andere wenden wir nur an, wenn es alle Projektbeteiligten sinnvoll finden.

entwickler: Für fast alles gibt es heutzutage Tools. Kannst du uns welche nennen, die möglichst viele Prozesse eines Projekts (Design, Entwicklung, Management und Testing) zu erleichtern?

Virkus: Für die Konzeption und Ideenentwicklung hat sich bei uns die Methode des Brainwriting bewährt. Da kommen oft wirklich coole Dinge heraus, die auf dem ersten Blick vielleicht abseitig erscheinen und in einem anderen Rahmen schnell abgeschmettert oder tot diskutiert würden. Außerdem kommt in dieser Methode jeder und jede zu Wort, unabhängig von der Position oder der Durchsetzungsfähigkeit im direkten Gespräch.

Beim UX-Design arbeiten wir mit unterschiedlichen Prototyping Tools wie proto.io. So können wir dem Kunden frühzeitig zeigen, wo die Reise hingeht und er kann uns Feedback geben, bevor wir mit dem Coden loslegen. Oft ist es besser, im Prototyp nicht allzu viel Design unterzubringen, weil sich Diskussionen dann schnell an Kleinigkeiten entzünden, anstatt über das grundlegende Konzept zu reden. UI-Designs liefern wir deshalb oft erst im nächsten Schritt und lassen sie Screen für Screen vom Kunden absegnen.

In der Entwicklung arbeiten wir natürlich mit den Standard-Tools der Hersteller. Aber ich ermutige die Kollegen hier auch immer, sich nach vorhandenen Libraries umzuschauen – beispielsweise auf GitHub. Man muss nicht für jedes Projekt das Rad neu erfinden. Aber wenn man fremden Code einsetzt, läuft man natürlich immer auch Gefahr, sich Bugs einzuhandeln, die schwer zu fixen sind. Bei uns immer wieder benutzte Basiskomponenten kapseln wir in interne Projekte, spätestens wenn wir zum dritten Mal eine bestimmte Sache Copy&Pasten, denken wir über eine Aufnahme in unsere interne Komponenten nach. Unsere automatischen Tests erledigen wir mit Unit Tests – damit wir hier aber kein Testcase-Rotting haben, führen wir die Tests auch in unserer Continuous Integration (CI) automatisch durch. Wir nutzen Jenkins für unsere CI.

Fürs Testing hat sich bei uns TestRail etabliert. Es ist gut mit Jira integrierbar und liefert einen klaren Rahmen ohne unnötigen Overhead zu produzieren.

Das zentrale Tool für unsere Arbeits- und Projektorganisation ist Jira gepaart mit Confluence. In Jira bildet jeder Kollege seine Aufgaben ab, das Confluence dient vor allem der Dokumentation. Mittlerweile sind wir dazu übergegangen, das Jira nur intern zu benutzen, und dem Kunden nur auf ausdrücklichen Wunsch einen Zugang zu geben. Denn sonst passiert es schnell, dass der Kunde mit Mikromanagement anfängt und die Abläufe eher stört. Umso wichtiger ist das Confluence: Hier dokumentieren wir Projektziele, User Stories, Designs und Meetingergebnisse und stellen sicher, dass alle Projektbeteiligten auf einem Stand sind und an einem Strang ziehen.

Die Kommunikation läuft über projektbezogene Skype-Gruppen und E-Mail-Verteiler – und natürlich immer wieder in persönlichen Treffen wie den Daily Standup. Slack wollen wir demnächst evaluieren.

Ein Tool für alles gibt es nicht, und das ist auch gut so, denn das wäre vermutlich viel zu komplex. Um so wichtiger sind aber APIs, damit die Tools miteinander reden können und wir Prozesse automatisieren können.

Zur Person: Robert VirkusRobert Virkus arbeitet seit 1999 in der Mobile-Branche. Vor dem Hintergrund seiner frühen Erfahrungen mit Fragmentierung rief er das Open-Source-Projekt J2ME Polish ins Leben. Das daraus entstandene Toolset hilft Entwicklern weltweit seit 2004 bei der Überwindung von Fragmentierung, bei der Optimierung und der Portierung ihrer Apps. 2005 gründete er das Bremer Unternehmen Enough Software. Das mittlerweile knapp zwanzigköpfige Entwicklerteam entwickelt Applikationen im Kundenauftrag und bedient dabei alle mobilen Plattformen. Seine Freizeit verbringt Robert mit seiner Familie und bastelt an elektronischen Projekten.

 

Aufmacherbild: Teamarbeit: Ameisen, die eine Brücke bauen via Shutterstock / Urheberrecht: Andrey Pavlov

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -