Post on 14-Apr-2017
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