our talk from iOS DevCon 2013 about internal development and extern customer management

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