STAY CALM AND KEEP

SHIPPING

Florian Bürger

50% von superflomo

/ α @florianbuerger

iOS (iPhone OS) Entwickler seit Beginn

Wer sind wir?

Moritz Haarmann

50% von superflomo

/ α @derwildemomo ( :-) )

Android, iOS, Rails..

Wer sind wir?

STAY CALM Der tägliche Krieg des Entwicklers

Die Tools

Faulheit als Tugend

Open Source Zeug benutzen!Fork, Improve & Contribute.

not invented hereIst totaler unfug

cocoapodswenig Entwickler verstehen

git submodules/subtrees

cocoapodsKomplexes Project /

Linker Setup in Xcode

Add the ReactiveCocoa repository as a submodule of your application's repository.Run script/bootstrap from within the ReactiveCocoa folder. (git submodule update --init --recursive)Drag and drop ReactiveCocoaFramework/ReactiveCocoa.xcodeproj into your application's Xcode project or workspace.On the "Build Phases" tab of your application target, add RAC to the "Link Binary With Libraries" phase.• On iOS, add libReactiveCocoa-iOS.a.• On OS X, add ReactiveCocoa.framework. RAC must also

be added to any "Copy Frameworks" build phase. If you don't already have one, simply add a "Copy Files" build phase and target the "Frameworks" destination.

Add $(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include $(inherited) to the "Header Search Paths" build setting (this is only necessary for archive builds, but it has no negative effect otherwise).For iOS targets, add -ObjC to the "Other Linker Flags" build setting.If you added RAC to a project (not a workspace), you will also need to add the appropriate RAC target to the "Target Dependencies" of your application.

≠

pod install

echo “ReactiveCocoa” >> Podfile

Einsatz mit Augenmaß

Pragmatischer Ansatz

Wann selbst entwickeln?Lohnt sich der Aufwand?

Wann selbst entwickeln?Verhältnis Zeit zu Aufwand zu Mehrwert

(gegenüber Open Source Lösung)

Entwicklungs-Prozess

KonventionenVeröffentlichung /

Testing / Entwicklung getrennt

master == live

development / feature branches

Teamfähigkeit

development / feature branches

Nachvollziehbarkeit

Internes Projekt-Management

Das kleinste, funktionierende Tool

Internes Projekt-Management

So flexibel wie möglich

Ziel: Genaue Abstimmung mit Kunden & zeitnahe

Lieferung

Agiles EntwicklungsmodellKleine Milestones,

oft wechselnde Anforderungen

Agiles EntwicklungsmodellAnforderungs-Dokument

zu Anfang nicht ausreichend

Unsere Lösung: Basecamp

Diskussionen, Termine, Dateien, (E-Mails)

(Automatisierte) Tests ≠ TDD

(Automatisierte) TestsGrundsätzlich falsche Einschätzung, was

Zeitaufwand betrifft

(Automatisierte) TestsSpart Zeit!

Gibt Sicherheit!

Warum Tests?Code-Qualität

Warum Tests?Führt zu besserer Architektur

Spart richtig, richtig viel Zeit.

Continuous Integration

HockeyApp

1. Xcode - Product - Archive

2. Organizer - Distribute - Save To Disk

3. Mail an Tester

4. IPA iTunes Mediathek hinzufügen

5. Gerät mit iTunes synchronisieren

Klassischer Ablauf

1. Push in master

2. Unit-Tests laufen (Jenkins)

3. .ipa wird gebaut (Jenkins)

4. Testbuild hochladen (HockeyApp)

5. Tester benachrichtigen (HockeyApp)

Verteilung

Crash Reports

ipa build && ipa distribute

nomad-cli.com

Broken WindowWas einmal schlecht ist,

wird auch nicht mehr gut

Broken WindowEs gibt nich das ominöse „Wenn wir Zeit haben

Land“, in dem hässlicher Code schön gemacht wird.

Der/Die Entwickler(-in)

Wie arbeiten wir?Keiner ist gleich und nicht für alle

funktionieren die gleichen Methoden.Das ist gut.

Zeitfresser findenNur weil man etwas kann, heißt das nicht,

dass man es auch tun sollte.

Zeitfresser findenAufgaben dem jeweiligen Spezialisten überlassen

Zeitfresser findenVerantwortung abgeben

The ZoneDie ersten 5 Minuten sind die schwierigsten

The ZoneAufwand dorthin zu gelangen minimieren

The ZoneKontextwechsel vermeiden

The ZoneAblenkungen vermeiden

Wie?

Wie?E-Mail Push klingt wichtig, ist es meist aber nicht

Wie?Eine Mail kann i.d.R auch mal 3 Stunden warten

Wie?@Mentions auch

Wie?Geplante Zeit für E-Mail/sonst.

(Kunden-)Kommunikation

Wie?Geplante Zeit für Prokrastination

KEEP SHIPPINGPünktlich und das Richtige.

Geht das überhaupt?

Ja, denn• Mobile-Projekte sind in der Regel

„überschaubar“

• Klar definiertes Produkt

• Probleme können früh identifiziert werden.

Kundenbeziehungen müssen gut sein.

Kunden haben Probleme

Wir bauen Lösungen

Kunden erklären Probleme

Wir erklären Lösungen

"If I had asked people what they wanted, they would have said faster

horses."

Nicht Henry Ford

Aber bitte auf dem Boden bleiben.

Wir sind Experten.

Missverständnissezu Beginn klären!

IT/Business AlignmentZentrales Thema

Anforderungen an Kunden

• Definierte Verantwortlichkeiten

• Verbindlichkeit in Aussagen

• Professioneller Umgangston

Ist ja kein Ponyhof.

„Never attribute to malice that which is adequately explained by stupidity.“

Hanlon‘s Razor

MDD• Mockup-Driven-Development

• 3 Mockups reichen nicht, um das Kundenproblem und seine Erwartung an das Produkt zu verstehen

Der Benutzersollte im Mittelpunkt des Produkts stehen

Der BenutzerKann im Entwicklungsprozess wertvolle Beiträge

leisten!

Benutzer – Konzeption

• „Design by Management“ ist oft ein verkehrter Ansatz

• Nutzer sind schwer zu finden, oft organisatorische Hindernisse

• Goldgrube

Transparenz• Hilft, Vertrauen zu schaffen, z.B. durch

• vollständigen Zugriff auf Quellcode

• Entwicklungsprozesse, Probleme klar erklären

• Probleme (Zeit, Aufwand) früh und unmissverständlich kommunizieren

Prototypen • Kundenbeziehung auf Probe

• Sind wir der richtige Dienstleister?

• Hat der Kunde realistische Vorstellungen?

• Konstruktive Zusammenarbeit?

• Umfang: bis zu 10MT

Fazit • Aufrichtiger Kommunikationsstil

• Gegenseitiger Respekt

• Geduld, sich wirklich mit dem Problem des Kunden auseinanderzusetzen

• Führt meist zu guten Ergebnissen und langfristiger Zusammenarbeit

ABER

Gelegentlich arbeiten auch mal die flomos eine

Nacht durch.

Vielen Dank!Fragen? Anregungen?

@superflomowww.superflomo.com