Kategorien
Allgemein

Der TPO ist tot; Lang lebe der TPO

Technical Product Owner (TPO). Ein toller Name, ein toller Job! Nur leider schwierig die Rolle zu leben und sie umzusetzen im beruflichen Alltag.

Was dieser Job theoretisch sein sollte, was er praktisch ist und ob er für euer Unternehmen oder eure neue Herausforderung geeignet ist, wird in diesem Beitrag detailiert beschrieben. Anhand meiner persönlichen 2-jährigen Erfahrung damit, werde ich die Vor-, aber auch die Nachteile aufzählen, auf die ich gestoßen bin. Abschließen werde ich diesen Beitrag, mit einer Empfehlung wie man es besser machen könnte.

Was dieser Job theoretisch, was er praktisch ist und ob er für Euer Unternehmen oder Eure neue Herausforderungen geeignet ist, hierfür möchte ich Euch in diesem Beitrag die Kriterien mitgeben. Anhand meiner persönlichen 2-jährigen Erfahrung als TPO werde ich die Vor- und die Nachteile benennen. Abschließen werde ich diesen Beitrag mit einer Empfehlung, wie man es besser machen könnte.

Kategorien
Allgemein

Der Wandel eines Entwicklers Teil 2 – Vom Team-Mitglied zum Teamleiter

Es ist gar nicht mal so lange her, dass ich einen Wandel in meinem Leben durchgemacht habe. Den Wandel vom Alleingänger zum Team-Mitglied. Vor ziemlich genau 2 Jahren habe ich folgenden Beitrag veröffentlicht, der eine Huldigung an mein damaliges Team war:

Vom Alleingänger zum Team-Mitglied… der Wandel eines Entwicklers.

An dem Team hat sich viel verändert inzwischen.
Einer meiner damaligen Kollegen ist inzwischen in Hamburg und hat eine neue Heimat in einer großen IT-Firma gefunden. Diese Position wurde nachbesetzt und zwar mit einem Menschen, der wie ein Deckel auf den Topf “Android App-Team bei AutoScout24” passt. Besser hätte es nicht laufen können.

Hinzu sind ein paar weitere Entwickler gekommen, von einer mit uns kollaborierenden Agentur. Entwickler die neuen frischen Wind in ein sehr gut funktionierendes Team gebracht haben. Neue Rangehensweisen, neue Ideen, neue Erfahrungen.

Die dritte große Veränderung zu damals, ist eine die mich persönlich betrifft.
Inzwischen bin ich Engineering Manager bei AutoScout24. Dieser Titel sagt nichts anderes aus, als “Teamleiter” mit ein paar zusätzlichen Aufgaben. Aufgaben, die ich zuvor schon übernommen habe, genauso wie die meisten Verantwortlichkeiten die ein Engineering Manager in seiner Verantwortlichkeit hat.

Wie es dazu gekommen ist, was mich angetrieben hat diese Richtung einzuschlagen, welche Veränderungen so etwas mit sich bringt und ob es sich lohnt möchte ich in diesem Beitrag auffassen und niederschreiben. Kleiner Teaser Vorweg: Es ist nichts für jemanden der seine Ruhe haben will ;)

Was hat mich dazu bewegt?

Im Zuge meines privaten Umzuges vor einigen Tagen, habe ich ein kleines Buch entdeckt dass ich während meiner Ausbildung gelesen und verinnerlicht habe. Ich hatte ganz vergessen dass ich dieses Buch jemals in den Händen hatte. Ich war sehr überrascht als ich realisiert habe, dass ich schon während meiner Informatik-Ausbildung Interesse am führen von Teams und Mitarbeitern gezeigt habe. So ein großes Interesse anscheinend, dass es sich wohl damals schon in mir manifestiert hat, dass ich dies sehr zielstrebig in den kommenden Jahren forciert habe.

“In spätestens 5 Jahren bin ich Teamleiter und werde den Weg für mein Team ebnen. Ob hier oder woanders, das ist mir egal!”. Ich kann mich noch genau daran erinnern wie ich diesen Satz ausgesprochen habe, als mich mein damaliger Teamlead gefragt hat wo ich mich in der Zukunft sehe. Das war die offizielle Festlegung meines beruflichen Zieles!

Menschen positiv beeinflussen. Mitarbeiter weiterentwickeln.
Hürden aus dem Weg schaffen, damit sich andere entfalten können.
Talente von Kollegen entdecken, sie hervorheben und anschließend zu Stärken machen.
Menschen zusammen bringen und eine Gemeinschaft schaffen die sich gegenseitig vertraut.
Was gibt es schöneres auf der Welt? Nicht viel :)

Mit diesem Ziel vor Augen, habe ich meinen Alltag bestritten. Jede Chance genutzt zum lernen und die neuen Wege zu entdecken. Was kann ich für mein späteres berufliches Ziel jetzt schon lernen, so dass ich bereit bin, wenn es soweit kommt.

Es war ziemlich einfach Teamlead zu werden …

… aber auch nur weil ich die vollste Unterstützung aus meinem Team genossen habe, vom aller ersten Moment an. Vertrauen, Offenheit, Kritik und langjähriges Kennen waren die Pfeiler auf denen das Ganze entstand. Auf genau diesen Pfeilern haben wir als Team das Ganze weitergeführt und dafür möchte ich jedem einzelnen Danken, der mir den Einstieg einfach gemacht hat und der mich seit der ersten Minute unterstützt hat. Ohne dieses Team und diese Leute, wäre es vermutlich um einiges schwieriger geworden Entscheidungen zu fällen, eine Richtung vor zu geben und auch mit vollem Vertrauen jede Entscheidung die wir gemeinsam getroffen haben, bis aufs Äußerste zu verteidigen.

Ich danke euch sehr, @Alexander Bach, @Johannes Koenen, @Rene Richter, @Jonas Schinagl, @Roland Rethegi.

Was sich verändert hat…

Mit dem Schritt in die Richtung Teamleitung und -führung hat sich sehr viel in meinem Leben geändert. Nicht nur beruflich, sondern auch privat. Eine neue Welt, die in meine private eindringt, da es eine grundlegende Einstellung ist, die man sich aneignet wenn man für andere Menschen verantwortlich ist – wenn man für diesen Job brennt wohlgemerkt. Man lernt es Bedürfnisse neu zu definieren – sowohl die eigenen, aber auch die der anderen. Denn ohne Bedürfnisse, kann man sich eben leicht in diesen Job verlieren und einen Weg einschlagen, der ungesund werden kann – für die Mitarbeiter aber primär auch für einen selber.

♦ Die Verantwortung und der Tagesablauf

Die vermutlich größte Änderung zu meiner Zeit davor betrifft den Ablauf meines Tages und den Aufgaben die meinen Tag diktiert haben. Man hat mehr Verantwortung, mehr Bereiche auf die man schauen muss. Mehr Stress, viel mehr Baustellen und höheren Druck. Weniger Zeit für Küchen-Chats, dafür aber verbringt man mehr Zeit in Meetings. Mehr Reports schreiben, dafür aber kaum noch Code. Generell würde ich sagen, man macht kaum noch Dinge, die vorher elementar waren, sondern man konzentriert sich darauf, den Entwicklern alles zu ermöglichen, damit sie die elementaren Dinge erledigen können.

Das alleine wäre gar nicht so tragisch, wenn man die Zeit am Stück hätte, sich auf eine Sache zu konzentrieren. Reports anfertigen und präsentieren, Meetings organisieren und leiten, Einzelgespräche mit den Kollegen, Incidents lösen und Verantwortlichkeiten klären, Interviews führen mit Kandidaten, Prozesse optimieren, Streitigkeiten schlichten und Teamzusammenhalt stärken, Meetups organisieren und Teamevents, und so weiter und sofort. Und damit das auch nicht all zu einfach wird, muss man die Arbeit an einem dieser Themen nicht selten unterbrechen, weil man an einem der anderen weiter arbeiten muss. Es fühlt sich an, als dürfte man kaum noch Fokus auf eine einzelne Sache haben, sondern am besten alles im selben Moment machen.

Dieser Verlust des Fokus, ist sehr anstrengend und sollte jedem bewusst sein, der diesen Schritt in das untere/mittlere Management wagt. Der Tag wird teilweise diktiert. Einflussmöglichkeiten sind zwar vorhanden, aber machen den kleinsten Teil des Tagesablaufes aus – Zumindest in einer großen Firma wie AutoScout24. Meine Aussage hier ist nicht, dass Meetings meinen Tag übernommen haben, sondern die Summe der Aufgaben eines Engineering Managers, ist enorm. Hiring Manager, Incident Manager, Fachlich Führung, Disziplinarische Führung, und und und… Dieser Schritt sollte aus diesem Gesichtspunkt gut durchdacht sein.

♦ Das Zwischenmenschliche

Neben all den anstrengenden Themen die meinen Alltag so begleiten, gibt es aber auch sehr viele schöne neue Aufgaben, die nicht nur Blickwinkel verändern.

Angefangen bei den Einzelgesprächen bei denen man Menschen und Kollegen ganz anders kennenlernt als sonst. Offener, privater, zerbrechlicher, zielstrebiger, emotionaler, ernster. Und Sie lernen mich auch anders kennen. Wichtiger aber als die ersten beiden Punkte, ist der dritte: Ich lerne mich selber besser kennen in diesen 1-on-1’s. Jedes einzelne persönliche Gespräch, an einem sicheren Ort wo die Aufmerksamkeit nur einer Person gewidmet ist, bringt mir viele neue Erkenntnisse, Emotionen und Erfahrungen. Es hat mich wachsen lassen im zwischenmenschlichen und empathischen Bereich.

Neben den Einzelgesprächen mit den festen Teammitgliedern, führe ich auch Gespräche mit kurzen Gästen, wie zum Beispiel Freelancern oder Entwickler anderer Abteilungen, die sich die Android Entwicklung aneignen möchten. Vor allem in diesen Gesprächen habe ich gemerkt, wie unterschiedlich jedes einzelne menschliche Wesen auf diesem Planeten ist. Dieser extrem , hoch-interessante, aber auch teilweise unglaubliche Unterschied der Persönlichkeiten, ist etwas was ich schwer in Worte fassen kann und den Blickwinkel den ich dadurch darauf gewonnen habe, ebenfalls nicht. Es gibt wirklich (und in diesem Satz steckt 100% Wahrheit drin) nichts spannenderes als neue und einzigartige Persönlichkeiten zu entdecken und mit ihnen arbeiten zu lernen. Nichts spannenderes als der Mensch an sich.

Der eine ist direkt, hektisch und kritisch.
Der nächste ist ruhig, bedacht und zurückhaltend wenn es um Kritik geht.
Der nächste wiederum nimmt kein Blatt vor dem Mund und sagt mir knallhart und ungefiltert was ihn nervt und was er an mir nicht mag.
Der nächste hat eine wirre Kombinationen der weiter oben erwähnten Eigenschaften.

Es ist einfach nur toll und ich liebe es mit Menschen zu arbeiten – auch wenn sie mich nachmal zur Weißglut bringen :)

♦ Der neu gewonnene und ungewollte Abstand.

Leider ist es aber auch so, dass man sich sowohl bewusst als auch unbewusst, vom “Team” distanziert. Diesen Abstand braucht man nicht nur, er kommt ganz von alleine.
Eine Zeit lang ist der Abstand riesig, dann wieder sehr klein, dann wieder riesengroß und danach wieder genau so wie früher. Kommt ganz auf die Situation des aktuellen Tuns an.

Die Gründe dafür liegen auf der Hand: Unter anderem, weil man verantwortlich für die Ergebnisse des Teams ist, für die Krisenbewältigung, die Richtung in die sich das Team bewegt und für die Erfüllung der gesteckten Ziele, muss man auch manchmal etwas härter sein, als man es vorher war. Dennoch darf man zu keinem Zeitpunkt die Autonomie und Autarkie des Teams untergraben und ignorieren. Um dies aber zu realisieren – von einem Teammitglied zu einem Teamleiter werden im selben Team – braucht es Unterstützung, Selbstvertrauen, Fokus auf das Business und ein Ego das man nicht einmal aus seiner Hosentasche rausholt, sondern es genau da lässt, für immer!

Wenn ich mir meinen Post vom Jahr 2014 anschaue (Link), muss ich mir leider eingestehen, dass mein Schritt zum Teamleiter auch ein Schritt zurück ist – betrachtet man es aus der  Team-Perspektive und die Zeit die man mit seinen langjährigen Kollegen verbringt. Ich verbringe mehr Zeit alleine, oder mit anderen Personen innerhalb der Firma, als mit meinen Jungs, was mich jedes man ein bisschen traurig macht, wenn ich darüber nachdenke.

Hat es sich gelohnt? (Fazit)

Die Entscheidung diesen Weg einzuschlagen, gehört zu den besten meines Lebens!
Ich habe einen Schritt in eine Welt gewagt, in der sich meine Persönlichkeit komplett entfalten kann. Ich kann intuitiv agieren und merke im Nachhinein dass es eine gute Wahl war. Nicht immer, aber meistens.

Und genau dies – dass intuitives Verhalten oft ausreicht – macht mich in jeder Entscheidung die ich treffen muss, stark, selbstsicher und raubt mir jegliche Angst. So sehr, dass ich nach meinem ersten Jahr als Engineering Manager behaupten konnte, dass ich mich nach der kurzen Zeit schon sicherer fühle als zu jedem Zeitpunkt zuvor in dem ich als Entwickler tätig war.

Im selben Atemzug behaupte ich aber auch, dass es mich mit jedem Tag der ins Land streicht auch ein bisschen traurig(er) macht. Die Zeit als Teammitglied eines Teams hat zu den schönsten Zeit überhaupt gehört. Kaum Druck, kaum Ablenkungen, gemeinsames Eifern und reger Meinungsaustausch waren mein Alltag. Inzwischen ist es das Engineering Manager Team das diese Rolle einnimmt bei Scout – die allerdings nie den gleichen Ausmaße erreichen wird.

Mit dem Schritt zum Teamleiter habe ich (je nach Blickwinel), einen Schritt zurück gemacht respektive einen nach vorne. Ich bin nun (Im Arbeitskontext) einsamer als zuvor, verfolge aber die beruflichen Ziele die meiner Persönlichkeit mehr entsprechen. Wie das in einigen Jahren aussehen wird, weiss ich nicht, aber ich werde immer mit sehr viel Liebe und Herzblut an die Zeit als Entwickler des AutoScout24 Android Teams zurück denken und in positiven Erinnerungen schwelgen. und wer weiss… vielleicht mache ich irgendwann den Schritt zurück zum Entwickler.

Die Zukunft kann, und DARF alles bringen :)

Kategorien
Allgemein Development

der Wandel eines Entwicklers Teil 1 – Vom Alleingänger zum Team-Mitglied…

In meinem heutigen Beitrag, möchte ich von etwas berichten, das ich erst seit einigen Monaten in dem Umfang erlebe um wirklich den Unterschied zu kennen. Den Unterschied zwischen “alleine in meiner eigenen kleinen Welt programmieren” und dem Ding was man auch Team nennt, nämlich dem: “Von einander lernen”-Gefühl.

Der Unterschied ist wie Tag und Nacht… wie Jing und Jang… wie schwarz und weiß.
Auf der einen Seite -nennen wir sie mal die “dunkle” Seite ;) – entwickelt man einfach vor sich hin, nach bestem Wissen und Gewissen. Natürlich hat man Zweifel an dem was man programmiert, aber es gibt im selben Atemzug auch niemanden der einem Fehler, falsche Gedankengänge oder gar grobe Schnitzer aufzeigt. Man denkt man macht alles richtig… was wahrscheinlich auch so ist. Nur ist es das “richtige” nach der persönlichen Erfahrung. Nicht mehr und nicht weniger.

Die andere Seite – logischerweise die weiße – sieht komplett anders aus. Meinungsaustausch und Erfahrungsaustausch. Zusätzlich kommen hinzu: Spaß, ein Wir-Gefühl und das Vertrauen in den anderen dass er schon alles richtig macht, da man weiß wie er programmiert. Aber bevor ich zur Quint-Essenz des Ganzen komme, hier erstmal die Vorgeschichte und was sich im Laufe des letzten Jahres alles geändert hat. In meinem Team und vor allem auch bei mir.

Kategorien
Allgemein Development

Staged Rollout bei Mobile Apps – Warum man es machen sollte.

Warum man vor großen Releases einen “Stage Rollout” forcieren sollte.
Ein Erfahrungsbericht aus meinem Arbeits-Alltag als Android Developer bei AutoScout24.

Staged Rollout, was ist das?

Mit einem Staged Rollout ist gemeint, dass man seine neue Version nur in kleineren Häppchen verteilt um dem Schlimmsten was bei einem Release passieren kann, erst gar keine Chance gibt vor zu kommen… nämlich Crashes!

Ein Staged Rollout passiert, wie der Name schon vermuten lässt, in verschiedenen Stages.
Zu Beginn erhält nur ein sehr niedriger einstelliger %-Anteil der User die neue Version der Applikation.
Mit den Crash-Berichten die daraufhin in die entsprechenden Logs hinein flattern, kann man dann arbeiten und die schwerwiegensten Bugs und Abstürze fixen.

Natürlich hat man mit 2-3% der User, nicht alle möglichen Probleme und Fälle abgefangen, aber man legt schon mal ein gesundes und starkes Fundament,
wenn man sieht, dass die Applikation keine größeren Issues erzeugt. Und falls doch, hat man das Übel doch noch minimal gehalten, da es “nur” 2-3% der User betrifft und nicht 100%.

Sobald man dann aussagekräftige Werte vorliegen hat mit denen man arbeiten kann, macht man mit Schritt 2 weiter: Die Userbase erhöhen und die Crashlogs, Bewertungen im Play Store und Feedback-Emails beobachten und re- und agieren.

Randinfos zu unserem Projekt: Anroid-Applikation von AutoScout24.

Je größer eine Applikation ist, umso größer ist auch die Zahl der Menschen, die man mit einer “kaputten” Version verärgert und sie damit vielleicht der Konkurenz in die Arme leitet. Im Falle von AutoScout24 wären das eine große Menge Nutzer, die wir im Monat mit unserer Android-Applikation beglücken. Ein paar Millionen Detail-Seiten-Aufrufe im Schnitt an einem Sonntag.

Natürlich testen wir unsere App durchgehend. Primär automatisiert aber auch manuell. Dennoch ist eine Test-Umgebung nicht das selbe, wie die freie Wildbahn.

Die Nutzer, vor allem bei Android, haben die Wahl zwischen 6000+ VERSCHIEDENEN Smartphone-Modellen auf denen unsere Applikation laufen soll, muss und es auch tut. Jedes dieser 6000+ Geräte, hat seine speziellen Probleme und für viele Themen auch durchaus Eigenlösungen, die von den Firmen die das Handy produziert haben eingepflegt wurden.

Da ist es nur logisch, dass wir nicht alle Geräte durchtesten und auch nicht alle Corner-Cases abfangen können. Genau dafür haben wir uns entschieden, das Major-Update von Version 2.7.7 auf 3.0.0 mit dieser hier erklärten Methode zu releasen.

Da die Version 3.0.0 auf einer komplett neuen Codebasis aufgebaut wurde, sind die potentiellen Fehlerquellen reichlich vorhanden. Alle Kinderkrankheiten die in der vorherigen Version in vielen Update-Iterarionen gefixt wurden, können unter Umständen wieder auftreten.

Learnings aus der ersten Phase:

Während der Entwicklung haben wir sehr viel Wert auf Testing gelegt. Manuell, automatisiert und auch in einer Firmen-internen Beta haben wir die App auf Herz und Nieren getestet (Dazu später mehr, in einem weiteren Beitrag). Dennoch denkt man damit einfach nicht alle Fälle ab.

So auch geschehen mit unserer 3.0.0 Version die wir zu Beginn erst 1% zur Verfügung gestellt haben. Kaum war die App für die entsprechenden Android-User freigeschaltet, schon erschienen die ersten Exceptions und Benachrichtigungen in unser HockeyApp (Crash-Plattform mit entsprechendem Framework für Android).

Wie schon geahnt, waren es Kleinigkeiten die wir dann auch ziemlich zügig gefixt haben. Auf Grund der geringen Problembehaftung der Bugs haben wir den Wert der Userbase erhöht (im Google Play Store) auf 5%um aussagekräftigere Werte zu bekommen. 5% sind immer noch eine kleine Userbase.

Intern im Team haben wir beschlossen, dass dies auch der letzte Schritt sein wird, bevor wir mit 100% Live gehen.
5 Tage blieben wir auf 5% und obwohl wir uns sehr sicher waren, dass keine weiteren Entwickler-Bugs (Out of Memory Errors mal ausgenommen) auftauchen werden, erblickten dennoch zwei oder drei NullPointerExceptions (Abstürze) das Tageslicht :)

Diese Fehler haben wir behoben. Kleine visuelle Anpassungen wurden getätigt. Versionscode wurde angehoben auf 3.0.1 und der finale Schritt wurde eingeleitet…

Und jetzt gehts Live…

Und schon waren wir Live! Auch wenn alle Vorbereitungen super verliefen und sich keiner unserer Albträume bewahrheitet hat, waren wir doch sehr angespannt zu sehen was passiert, wenn 100% der User diese Version bekommen.
Am Ende des ersten Tages, hatten wir circa 200 Crashes!

Erst am nächsten Tag zeigte sich dass von den 200 Crashes circa 60 durch Mitarbeiter entstanden sind, die ihre alte Beta nicht gelöscht hatten ;) Puh, Glück gehabt! Herzschlag normalisierte sich nach dieser Erkenntnis wieder.

Die restlichen 140 Crashes waren Out-Of-Memory-Errors, die leider daher kommen dass es durchaus auch schwachbrüstige Smartphones in den Händen unserer User gibt und nicht nur Galaxy S4’s und HTC One’s. Dank eines schnellen Fixes, konnten wir diese Anzahl an Abstürzen auch aus der Welt schaffen und haben unser angestrebtes Ziel von unter 100 Crashes / Tag erreicht und erfüllt!

2 Monate später…

Inzwischen sind schon circa 2 Monate vorbei und wir haben im Schnitt circa 80 Crashes pro Tag, bei einer Adoption-Rate von 90% (heißt: 90% unserer Nutzer haben geupdatet). Ein sehr guter Wert dafür, dass diese Version komplett von Scratch an neu geschrieben worden ist. Jede einzelne Zeile Code dieser APK wurde neu erzeugt. Jede einzelne Klasse dieses Projektes wurde neu erstellt und mit Leben befüllt.

Der Staged Rollout hat sich vollkommen gelohnt. Der erwartete Gewinn aus dieser Aktion ist eingetroffen und wir konnten den Nutzern gleich zu Anbeginn der neuen Version, eine sehr stabile Basis bieten und vor allem haben wir uns selbst damit was gutes getan. Beim ausrollen auf 100%, waren wir beruhigt und wussten dass die Arbeit von 9 Monaten keine schwerwiegende Probleme verursacht.

“Jeder Zeit wieder…” ist unser Fazit zu diesem Release-Vorgang. Und dies werden wir auch weiterhin so beibehalten, sobald wir größere Versionen releasen.

Habt ihr auch Erfahrungen mit Staged Rollouts sammeln können oder habt ihr so etwas schonmal gemacht?
Über Comments und Shares freue ich mich natürlich sehr!
Stay tuned, Ilias

Kategorien
Allgemein Development

AutoScout24 Android Applikation 4.0 released!

Im heutigen Post möchte ich euch die neueste Version (4.0) der Android-Applikation von AutoScout24.com vorstellen!
Ein Update dass es in sich hat, da wir sehr viel Wert auf eine optische Aubesserung der Oberfläche gelegt haben (für ein besseres und schöneres Nutzerverhalten) und zugleich auch ein weiteres nützliches Feature für den Nutzer unserer App anbieten können – kostenlose Benachrichtigungen wenn neue Wunschfahrzeuge zur Verfügung stehen!

HIER geht zum Download der App im Google Play Store!
(Wenn ihr euch dort anmeldet könnt ihr euch die App direkt auf euer Handy schicken lassen. Bald folgt ein Beitrag dazu, wie das genau abläuft)

Design-Rebrush & Abhebung von der Konkurenz

Unbenannt2Unbenannt1Das erste was einem Nutzer unserer App auffällt wenn er die Version 4.0 – die es seit dem 28.10.2014 unter dem folgenden Link zum Download gibt – startet, ist die überarbeitete Oberfläche! Mehr Farben, hübscheres Aussehen, klarere Gliederungen. Hier haben wir sehr viel Wert darauf gelegt, dass wir von der alten sterilen und trostlosen Optik weg, hin zu einer aufgefrischten Ansicht kommen (In der Detailansicht zB kann man die einzelnen Sektionen zusammenklappen auf Wunsch).

Zusätzlich zu den visuellen Anpassungen auf fast allen Ansichten in der Applikation, haben wir auch die Suche verbessert.
Überflüssige Klicks wurden unterbunden, in dem man die Suchparameter direkt in der Suchansic ht bearbeiten kann, ohne dafür ein extra Fenster öffnen zu müssen. Mehr Überblick bei weniger Wartezeit bei den Sucheinstellungen.

Kostenlose Benachrichtigungen bei neuen “Wunsch”-Fahrzeugen

Unbenannt3Die Möglichkeit Suchen zu speichern kennen aktive Nutzer unserer App schon lange. Benachrichtigungen zu bekommen sobald für die gespeicherte ein neues Fahrzeug eingestellt wird, ist neu!
Sie erscheinen in der Leiste in der man auch die Benachrichtigungen erhält dass zB eine neue WhatsApp-Nachricht eingetroffen ist. Ein kleines Auto macht euch darauf aufmerksam :)

Natürlich sind diese Benachrichtigungen kostenlos und können an- und ausgeschalten werden. Eine Erleichterung bei der Suche nach dem Wunschauto.
Diese Möglichkeit kennt man auch schon von der AutoScout24 iOS-App und den ImmobilienScout24-Applikationen. Nun steht sie auch unseren Android-Nutzern zur Verfügung!

Verbesserungen und Bugfixes.

Das natürlich unzählige Verbesserungen und Behebungen von Fehlern gemacht wurden erwähne ich nur kurz – das ist selbstverstänlich!
Die Qualität unserer Apps ist uns sehr wichtig und darauf wird sehr geachtet.

In diesem Sinne wünsche ich viel viel Spaß mit der Applikation und über Feedback im Store, hier in den Kommentaren oder auf verschiedenen sozialen Netzwerken würde ich mich sehr freuen!

Kategorien
Allgemein Development

Otto – Ein EventBus-Framework für Android!

Jeder der irgendwann versucht hat Daten von einem Dialog zur übergeordneten Activity/Fragment zu übertragen, kennt den Schmerz den man bei der Umsetzung verspürt, die Zeit die es benötigt die benötigten Elemente einzubauen und das nervige Verhalten der Listener.

Jetzt stellt euch vor, es würde euch jemand die Arbeit ersparen den Listener zu bauen, einzupflegen und ihn an der entsprechenden Stelle auf zu rufen. Gut, die ersten zwei Sachen kann das Framework erfüllen was ich euch heute vorstellen möchte… zum letzten Punkt: bisschen müssen wir dann doch noch schreiben.

Der “normale“ Ablauf:

Natürlich gibt es unter euch sicherlich schon einige die den EventBus kennen und schon nutzen. Dennoch gehe ich davon aus, dass jeder der mal eine Kommunikation zwischen Activity/Fragment und Dialog aufbauen wollte, folgenden Ablauf gewählt hat:

1. Eine Listener-Klasse bauen.
2. Der Dialog-Klasse einen Member hinzufügen der den oben gebauten Listener beherbergt.
3. Getter und Setter generiert/schreibt
4. Dem Dialog nach dem instanziieren in der Activity/Fragment über den Setter einen Listener hinzufügen und die entsprechenden Callback-Methoden überschreiben und mit Code füllen (was soll mit dem übergebenen Infos passieren?)

Ihr kennt Otto – jeder kennt Otto!

Sicherlich kommt bei dem Namen Otto bei vielen der Gedanke, es hätte was mit dem Deutsche Komiker Otto Walkes zu tun. Tut es nicht!

Dennoch behaupte ich, dass ihr den Charakter, der dem Framework seinen Namen gegeben hat, zu 100% kennt. Es handelt sich um Otto, den (Schul-)Busfahrer von den Simpsons! Ihr wisst schon…der coole Kerl der immer seine Kopfhörer auf den Ohren hat :)

Bus fahren ist das neue beamen!

Bus – oder sagen wir lieber EventBus – ist das Zauberwort dass zu Otto passt. Der Ablauf ist ziemlich simpel. Das Ganze funktioniert mit zwei Komponenten. Dem Empfänger, in Form einer Funktion die vor ihren MethodenKopf eine @Subscribe-Annotation ziert und auf der anderen Seite der Sender, der jeden kennt der Nachrichten empfangen möchte.

Der Sender ist ein zentraler Punkt, der alle Empfänger kennt und sobald eine Nachricht eintrifft sie an die entsprechenden Stellen innerhalb der App weiterleitet. Damit der Sender aber alle Empfänger kennt, müssen sich diese vorher bei dem Sender (EventBus) registrieren. Dieser agiert wie ein Dirigent oder Lotse, der die Nachricht an den entsprechenden Empfänger weiterleitet.

Ein kleines Beispiel:

In einem Dialog trage ich einen Wert – sagen wir in ein EditText mit nur Zahlen – ein, den ich in ein entsprechendes Feld im Fragment einfügen möchte, was “unter” dem Dialog liegt. Dafür erzeuge ich in der Fragment-Klasse ein Event (interne Klasse) das ich “IntegerValueEvent” nenne:

public class IntegerValueEvent() {

    final int mValueFromDialog;

    public IntegerValueEvent(final int inValueFromDialog) {
        mValueFromDialog = inValueFromDialog;
    }

    public int getValueFromDialog() {
        return mValueFromDialog;
    }
}

So, nun haben wir die EventKlasse erzeugt. In dieser Eventklasse, kann man alles “zwischenspeichern” was man möchte.Leider wissen wir aber nicht was wir damit anfangen sollen…
Aushilfe für dieses Problem, bietet die Annotation @Subscribe, die das Framework liefert. Diese Annotation wird vor eine Funktion/Methode gepackt so dass sie Events entgegen nehmen kann. Welche Events?
Die, die wir im Dialog abfeuern, wenn der User auf OK klickt:

Button okButton = (Button) view.findViewById(R.id.button_ok);
okButton.setOnClickLister(new OnClickListener() {
    public void onClick(View inView) {
        // Hier holen wir uns aus einem EditText im Dialog den Wert raus und
        // stecken ihn in den Konstruktor des Events und feuern es mit ".post()" ab.
        bus.post(new ValueFromDialog(editText.getText.toString());
    }
}

Da zu dem Zeitpunkt wo das passiert, das Fragment im Hintergrund “am Leben ist”, kann es Events entgegen nehmen. Das Fragment muss lediglich zwei Voraussetzungen erfüllen:
# beim EventBus registriert haben – bus.register(this); – und
# eine Funktion besitzen, die die gewünschten Events abfängt und mit der Annotation@Subscribe markiert wurde!

Hier ein Beispiel für so eine Funktion.

@Subscribe
public void receiveValueFromDialogEvent(final ValueFromDialogEvent inValueFromDialogEvent) {
    // Macht hier mit dem Event und seinme Inhalt, was immer ihr wollt.
    // zB. inEvent.getValue() abrufen und es dann im entsprechenden
    // TextView eures Fragments einfügen, da ihr ja hier nicht mehr im
    // Dialog seid, sondern im Fragment.
}

Nun haben wir alles notwendige erledigt.
Sicherlich hört es sich initial nach viel Arbeit an, ist es aber nicht.

Zusammenfassung & Fazit:

Der Ablauf ist auf dem Papier und ohne Code, ziemlich simpel:
1.) Unser Dialog hat etwas, was an das Fragment gegeben werden soll.
2.) Dialog erzeugt ein “Event” (Klassendefinition des Events kann überall sein) und schickt es an den EventBus (“bus.post(Event)”.
3. Fragment ist beim EventBus registriert und sagt ihm: “Heeey, ich bin da!”.
4. Fragment sagt dem EventBus “Heeeey, ich nehme XYZEvent an. Schick es mir zu, wenn du ein bekommst” (@Subscribe als Annotation einer Funktion und das gewünschte Event als Parameter)
5. Fragment bekommt das Event und liest den Inhalt aus und aktualisiert die TextView!

Wie oben schon erwähnt:
Auch wenn es nach viel aussieht, sobald man das Prinzip verstanden hat, kann man enorm mächtige Sachen machen!
Natürlich ist es ein kleiner Initial-Aufwand der betrieben werden muss, aber spätestens nach dem zweiten mal wo man sich das Listener-Prinzip erspart (wie ganz oben erklärt) bei der Kommunikation zwischen Dialog -> Fragment/Activity, lohnt sich dieses Konstrukt.

Natürlich ist Otto und der EventBus nicht nur für diese Art von Kommunikation gut. Seine eigentliche Stärke, findet es in anderen Bereichen:
# Eines der tollsten Dinge die man damit machen kann, ist das Ersetzen des ach so ge- und beliebten “Loaders”. Viele Entwickler entscheiden sich immer mehr für die Methode mit den Events, gegen den Loader.
# Antworten erhalten von asynchronen Tasks

Beispiel:

ButtonClick startet einen AsyncTask. Sobald der AsyncTask beendet ist, wird ein Event verschickt über den Bus. Das  Fragment/Activity in dem der Button sich befindet hat eine @Subscribe-Funktion und fängt dieses Event ab und weiß damit, sobald das Event angekommen ist, dass der AsyncTask beendet ist und ein Ergebnis da ist.

# Viele viele weitere Einsatzmöglichkeiten, wie man dieses wertvolle Werkzeug einsetzen und für seinen Vorteil nutzen kann.

Alternativen:

Neben Otto, gibt es auch weitere Möglichkeiten mit Events bzw ähnlichen Konstrukten zu arbeiten. Zu den bekanntesten Möglichkeiten gehören:
# Guava Library (Link) die neben dem EventBus noch viele viele weitere starke Features hat.
# Der LocalBroadCastManager von Android (Link)

Wenn euch eine Möglichkeit einfällt, wie und wo man Events nutzen kann, nur her damit.

Ich hoffe ich konnte euch das Prinzip hinter Otto, dem EventBus, gut erklären und es euch schmackhaft machen!
Über Kommentare und Shares, freue ich mich natürlich sehr!

Kategorien
Allgemein Development

Neue Codebasis – Schnellere Entwicklung!

Warum wir (AutoScout24) uns entschieden haben, unsere Android-App komplett neu zu schreiben. Ein Erfahrungsbericht aus meinem Arbeits-Alltag als Android Developer bei AutoScout24.

Bei der Enwicklung unserer neuesten Version 3.0.x haben wir uns entschieden das Fundament unserer Android-Applikation auszutauschen und den kompletten Code neu schreiben. In den folgenden Punkten möchte ich euch erleutern, welche Gedanken uns dazu getrieben haben und was wir uns erwarten davon.

Optik war enorm veraltet und träge Ansichtenwechsel.

Es ist kein Geheimnis, dass die Version 2.x.x im Jahre 2014 keinen Schönheitspreis mehr gewinnen könnte. Im Jahre 2013 ebenfalls nicht und im Zweifel hätte sie es auch im Jahre 2012 nicht geschafft…

Dies war der Grund, warum wir (fernab der Entscheidung dass wir den Code neu aufsetzen) uns für ein Komplett-Facelifting der Applikation entschieden haben. Unser Focus lag dabei im flüssigen Ablauf von Animationen, flüssigem Scrollen von Listen, einer übersichtlichen Detail-Seite und einer angenehmen und tollen User-Experience mit Pattern die sich auch bei anderen Applikationen bewehrt haben (zB. die Erreichbarkeit der Left-Hand über die ganze
App hinweg).

Zugleich haben wir aber auch drauf geachtet, nicht zu fancy zu werden. Manche Animationen und Transitions sind zwar schön, lassen die Souveränität ein wenig leiden.

Weiterentwicklungszeit drastisch minimiert.

Wer “alten” Code kennt, der weiss dass es keinen Spaß macht ihn zu lesen, zu verstehen und vor allem… ihn zu verändern!

Noch problematischer ist es, wenn die Applikation nicht nur von einem Team entwickelt wurde, das vielleicht während den Jahren gewachsen ist. Wenn Agenturen ihre Hände im Spiel hatten, wenn kopierter Code aus anderen alten Quellen benutzt wurde oder wenn Entwickler an der App gearbeitet haben, die ins kalte Wasser geworfen wurden, ist das Produkt ein einzig wirrer Haufen Code, der nur sehr schlecht wartbar ist.

Eine oder mehrere dieser Phänomene betraf auch unsere Version 2 und 1 der AutoScout24 Android Applikation. So bestand die Applikation aus einem Wirrwarr, der nur sehr schwer verständlich und leserlich war. Allein das Verändern einer Klasse, die eigentlich abgekoppelt sein sollte vom Rest, zog einen Ratenschwanz mit sich der nicht mehr vertretbar war.

Durch das neu-schreiben der App, haben wir versucht alles negative Aspekte der vorherigen Version zu negieren, in dem wir es besser machen ;) Wir haben sehr drauf geachtet, Pattern zu benutzen die Best-Practice sind und einen strukturierten und geordneten Code fördern. Natürich haben wir auch sehr viel Wert darauf gelegt, dass die einzelnen Module und Klassen von einander abgekoppelt sind, so das man agil und schnell auf Veränderungen in der Gesamtstruktur reagieren kann.

Komponentengetriebene Entwicklung bei AS24-Android!

Zusätzlich haben wir uns auch einem Geschenk unserer Entwickler-Generation angenommen, nämlich der Möglichkeit komponengetrieben zu entwickeln. Dank der umfangreichen und sehr intensiv getriebenen Open-Source-Community bei Android, konnten wir mithilfe von leistungsstarken und guten Frameworks unseren Code verstärken und verbessern. Vor
allem die Frameworks von Sqaure respektive Jake Wharton – okhttp, Picasso, Dagger, Butterknife – waren uns eine große Hilfe. Verstärkend kam noch das Otto-Framework hinzu, dass ich hier präsentiert habe. Hier eine kurze und schnelle Übersicht, was die Frameworks aus macht.

Okhttp: Integration des Protokolls SPDY in die Verbindungsaufbau mit unserem Server und die Parallelisierung der http-Aufrufe.
Dagger: Die Möglichkeit Manager und weitere Klassen zu injecten anstatt sie als Singleton zu definieren und den Code dadurch testbarer zu machen.
Butterknife: Man kann mithilfe von Butterknife View-Elemente in Fragments, Activities und Adapter injecten und sieso an einer zentralen Stelle im oberen Bereich der jeweiligen Klasse bündeln. Leserlichkeit steigt und die Fehleranfälligkeit sinkt.
Picasso: Ein Luxus-Framework, das das Asynchrone herunterladen und anzeigen von Bildern für einen übernimmt. Es basiert auf okhttp und bietet der App noch zusätzlichen “Drive”, sobald Bilder ins Spiel kommen (zB in der Ergebnis-Liste oder in einer Detail-Ansicht).

Testing war das O und das A!

Da wir zusätzlich zum Start des Neuschreibens der App auch eine sehr starke Testumgebung aufgebaut haben, mit viel Automatisierung und Continuous Integration, hatten wir von der ersten Klasse an direkt das Ziel auch eine hohe Testabdeckung zu erreichen. Dies relaisierten wir, indem wir zu jeder geschriebenen Klasse, direkt auch die entsprechende Test-Klasse geschrieben haben.

Das dies zeitaufwendig ist, war uns klar. Dennoch haben wir uns dafür entschieden, da Tests sich in jeder Form auszahlen. Eventuell entfalten Tests nicht gleich beim ersten Release ihre volle Stärke, aber spätestens nach ein/zwei Update-Iterationen werden nach Code-Änderungen einige Tests failen… was auch gut so ist! Nur so kann man darauf reagieren und unerwartetes Verhalten abfangen. Die Qualität unserer App steigt, unsere Sorgen als Entwickler sinken da wir eine Art Backup haben und die Stimmung steigt dementsprechend :)

Wie das Testing bei uns exakt funktioniert, werde ich in einem späteren Post noch exakter zeigen, aber hier schon mal ein kleiner Einblick:

– Mit Hilfe von Spoon, können wir Unit- und Click-Tests auf allen angeschlossenene Geräten (bei uns circa 10) synchron durchführen. Im Vergleich zur Variante, in der die Tests auf 10 Geräten nacheinander durchgeführt werden, reduziert sich die Gesamtzeit um 45 Minuten, bei einer Durchschnitts-Testzeit vn 5 Minuten.
– Wir ziehen Kopien von unserem Code (Github) und stellen uns selber Anfragen mit den Code-Änderungen und fragen nach Erlaubnis (uns selber), dass diese Änderungen in den Code mit aufgenommen werden, ganz nach dem im Open-Source bekannten Fork-Pullrequest-Verfahren. Sobald so eine Anfrage hineinflattert, bekommen wir Emails zugesandt und können uns die Änderungen des Kollegen anschauen. Wenn alles i.O. ist vom Code her und die Tests auf unserem Server durchgelaufen sind, drücken wir auf einen Button und der Code wird automatisch in unseren Hauptcode integriert. Dadurch reduzieren wir die Möglichkeit das Schwachsinn eingecheckt wird um ein vielfaches.

Zusätzlich, haben wir einen QA-Kollegen, der sehr gute Arbeit macht im manuellen Testing und viele viele Probleme und Fehler aufgedeckt hat, während und auch nach der Entwicklungszeit. Dies war für die saubere Entwicklung der App eine sehr große Hilfe!

Teamwork rocks!

Anders als vor einem Jahr, besteht unser Team nun aus 4 komplett unterschiedlichen Entwicklern. Jeder hat seine
Vorteile und Stärken, die er dem Team (im positiven) aufdrückt. Wir sind kommunikativ, was das Teambuilding enorm
fördert, haben Spaß und lachen viel und lernen von einander. Vor allem das gegenseitige Lernen, sehe ich persönlich
als ein großes Plus bei uns.

Zusätzlich wirkt sich die enge Zusammenarbeit mit Product Owner und Teamlead positiv auf unser Wohlbefinden als
Entwickler aus. Wir tragen Verantwortung für “unser” Produkt, synchronisieren unsere Meinungen aber auch nach oben,
die uns dann auch dementsprechend das Vertrauen geben und uns walten lassen. Dieses gegebene Vertrauen stärkt uns
und erlaubt es auch, durch innovative Ideen coole neue Sachen in das Produkt einfließen zu lassen.

Dennoch liegt unser Fokus darin, eine Applikation auf die Beine zu stellen, die Customer-Value-getrieben ist aber
auch die internen Vorgaben erfüllt. Sobald wir zu verspielt werden, werden wir auch wieder in die richtige Bahn
gelenkt, von unserem PO, der die letztendliche Verntworung für die Applikation trägt.

Kategorien
Allgemein

Feedly & Pocket – Das DreamTeam!

Gehört ihr auch zu den Personen, die sich gerne im Netz ihre Nachrichten anschauen? Die  5 oder mehr Seiten jeden Tag besuchen, um die Neuigkeiten zu erhalten, rund um die Lieblingsthemen? Ob dies nun Sport ist, IT- oder Computer-News, Informationen rund um Games, Klamotten oder sogar Marketing, Wirtschaft und Allgemein-Nachrichten. Es gibt genug Anlaufstellen, die man mühselig einzeln ansteuern muss, wenn man immer up-to-date bleiben möchte!