Stay calm and keep shipping

Out talk from the iOS DevCon conference, 2013 in berlin

language: german

Transcript

1. STAY CALM AND KEEP SHIPPING
2. Florian Bürger 50% von superflomo / α @florianbuerger iOS (iPhone OS) Entwickler seit Beginn Wer sind wir?
3. Moritz Haarmann 50% von superflomo / α @derwildemomo ( :-) ) Android, iOS, Rails.. Wer sind wir?
4. STAY CALM Der tägliche Krieg des Entwicklers
5. Die Tools
7. Faulheit als Tugend
8. Open Source Zeug benutzen! Fork, Improve & Contribute.
9. not invented here Ist totaler unfug
10. cocoapods wenig Entwickler verstehen git submodules/subtrees
11. cocoapods Komplexes Project / Linker Setup in Xcode
12. 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
13. Einsatz mit Augenmaß Pragmatischer Ansatz
14. Wann selbst entwickeln? Lohnt sich der Aufwand?
15. Wann selbst entwickeln? Verhältnis Zeit zu Aufwand zu Mehrwert (gegenüber Open Source Lösung)
16. Entwicklungs-Prozess
17. Konventionen Veröffentlichung / Testing / Entwicklung getrennt
18. master == live
19. development / feature branches Teamfähigkeit
20. development / feature branches Nachvollziehbarkeit
21. Internes Projekt-Management Das kleinste, funktionierende Tool
22. Internes Projekt-Management So flexibel wie möglich
23. Ziel: Genaue Abstimmung mit Kunden & zeitnahe Lieferung
24. Agiles Entwicklungsmodell Kleine Milestones, oft wechselnde Anforderungen
25. Agiles Entwicklungsmodell Anforderungs-Dokument zu Anfang nicht ausreichend
26. Unsere Lösung: Basecamp Diskussionen, Termine, Dateien, (E-Mails)
27. (Automatisierte) Tests ≠ TDD
28. (Automatisierte) Tests Grundsätzlich falsche Einschätzung, was Zeitaufwand betrifft
29. (Automatisierte) Tests Spart Zeit! Gibt Sicherheit!
30. Warum Tests? Code-Qualität
31. Warum Tests? Führt zu besserer Architektur
32. Spart richtig, richtig viel Zeit.
33. Continuous Integration
34. HockeyApp
35. 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
36. 1. Push in master 2. Unit-Tests laufen (Jenkins) 3. .ipa wird gebaut (Jenkins) 4. Testbuild hochladen (HockeyApp) 5. Tester benachrichtigen (HockeyApp) Verteilung
37. Crash Reports
38. ipa build && ipa distribute nomad-cli.com
39. Broken Window Was einmal schlecht ist, wird auch nicht mehr gut
40. Broken Window Es gibt nich das ominöse „Wenn wir Zeit haben Land“, in dem hässlicher Code schön gemacht wird.
41. Der/Die Entwickler(-in)
42. Wie arbeiten wir? Keiner ist gleich und nicht für alle funktionieren die gleichen Methoden. Das ist gut.
43. Zeitfresser finden Nur weil man etwas kann, heißt das nicht, dass man es auch tun sollte.
44. Zeitfresser finden Aufgaben dem jeweiligen Spezialisten überlassen
45. Zeitfresser finden Verantwortung abgeben
46. The Zone Die ersten 5 Minuten sind die schwierigsten
47. The Zone Aufwand dorthin zu gelangen minimieren
48. The Zone Kontextwechsel vermeiden
49. The Zone Ablenkungen vermeiden
50. Wie?
51. Wie? E-Mail Push klingt wichtig, ist es meist aber nicht
52. Wie? Eine Mail kann i.d.R auch mal 3 Stunden warten
53. Wie? @Mentions auch
54. Wie? Geplante Zeit für E-Mail/sonst. (Kunden-)Kommunikation
55. Wie? Geplante Zeit für Prokrastination
56. KEEP SHIPPING Pünktlich und das Richtige.
57. Geht das überhaupt?
58. Ja, denn • Mobile-Projekte sind in der Regel „überschaubar“ • Klar definiertes Produkt • Probleme können früh identifiziert werden.
59. Kundenbeziehungen müssen gut sein.
60. Kunden haben Probleme Wir bauen Lösungen
61. Kunden erklären Probleme Wir erklären Lösungen
63. "If I had asked people what they wanted, they would have said faster horses." Nicht Henry Ford
64. Aber bitte auf dem Boden bleiben. Wir sind Experten.
65. Missverständnisse zu Beginn klären!
66. IT/Business Alignment Zentrales Thema
67. Anforderungen an Kunden • Definierte Verantwortlichkeiten • Verbindlichkeit in Aussagen • Professioneller Umgangston
68. Ist ja kein Ponyhof.
69. „Never attribute to malice that which is adequately explained by stupidity.“ Hanlon‘s Razor
70. MDD • Mockup-Driven-Development • 3 Mockups reichen nicht, um das Kundenproblem und seine Erwartung an das Produkt zu verstehen
71. Der Benutzer sollte im Mittelpunkt des Produkts stehen
72. Der Benutzer Kann im Entwicklungsprozess wertvolle Beiträge leisten!
73. Benutzer – Konzeption • „Design by Management“ ist oft ein verkehrter Ansatz • Nutzer sind schwer zu finden, oft organisatorische Hindernisse • Goldgrube
74. 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
75. Prototypen • Kundenbeziehung auf Probe • Sind wir der richtige Dienstleister? • Hat der Kunde realistische Vorstellungen? • Konstruktive Zusammenarbeit? • Umfang: bis zu 10MT
76. Fazit • Aufrichtiger Kommunikationsstil • Gegenseitiger Respekt • Geduld, sich wirklich mit dem Problem des Kunden auseinanderzusetzen • Führt meist zu guten Ergebnissen und langfristiger Zusammenarbeit
77. ABER
78. Gelegentlich arbeiten auch mal die flomos eine Nacht durch.
79. Vielen Dank! Fragen? Anregungen? @superflomo www.superflomo.com