Retours sur l’aventure Capitaine Train

Conférence présentée avec Mathieu Calba[1] et Jérémie Martinez[2].

L’aventure Capitaine Train débute en 2010. L’objectif est simple et clair : offrir une alternative crédible à la vente de billet de train en Europe. Aujourd’hui, Capitaine Train, rachetée en 2016 et renommée entre temps « Trainline », vend plusieurs millions de billets chaque année.

Construire l’application Android a requis évidemment beaucoup de travail et de rigueur. Durant cette présentation nous détaillerons chacun des aspects qui ont permis à l’app Android Capitaine Train d’apporter régulièrement de nouvelles fonctionnalités, de respecter nos critères de qualité tout en répondant aux attentes des utilisateurs. Nous aborderons notamment l’organisation interne de l’équipe, le recrutement, les processus de développement et de mise en production, l’approche produit, le design, etc.

[1] https://speakerdeck.com/mathieu_calba
[2] https://speakerdeck.com/jeremiemartinez

Transcript

1. A look back at CAPITAINE TRAIN
2. A look back at CAPITAINE TRAIN *aka Captain Train, aka Trainline *
3. Disclaimer We don’t work at Trainline anymore. Everything discussed in this presentation relates to what we experienced from 2013 to 2017.
4. 2009 Capitaine Train founded
5. 2009 Capitaine Train founded May 2010 Beta website
6. n May 2010 Beta website October 2012 Public website
7. October 2012 Public website March 2013 Cyril’s arrival
8. March 2013 Cyril’s arrival October 2013 iOS app
9. October 2013 iOS app November 2013 Mathieu’s arrival
10. November 2013 Mathieu’s arrival March 2014 Android app
11. March 2014 Android app July 2014 Android Wear app
12. July 2014 Android Wear app September 2014 Flavien’s arrival
13. September 2014 Flavien’s arrival September 2015
14. September 2015 October 2015 Flavien left
15. October 2015 Flavien left November 2015 Jérémie’s arrival
16. November 2015 Jérémie’s arrival Trainline buys Captain Train March 2016
17. Trainline buys Captain Train March 2016 September 2016
18. September 2016 2017 We all leave
19. Recruiting smart people is hard Take your time and be demanding
20. What are we looking for?
21. Autonomy What are we looking for?
22. Autonomy What are we looking for? • Curiosity
23. Autonomy What are we looking for? • Curiosity • Honesty
24. Autonomy What are we looking for? • Curiosity • Honesty • Involvement
26. A multi-step process Application Quiz Technical project Face-to-face interviews
27. Step 1 Application
28. Capitaine Train 20 rue Saint-Georges 75009 Paris France Capitaine Train Pre-Interview (Android) 1. What is the difference between LinkedList and ArrayList? 2. What is the difference between an interface and an abstract class? 3. What is the difference between fnal, fnally and fnalize? 4. What is an Adapter? How to use it? How to create one in your project? Step 2 Quiz
29. Step 3 Technical project “ Make an app using the Star Wars API at https://swapi.co/
30. Step 4 Face-to-face interviews
34. It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do. – Steve Jobs “
35. Company values Minimise interruptions Trust by default
36. Letting you do your best work
37. A scattered Android team Cyril Jérémie Mathieu
38. Synchronise time together In Paris office at the same time
39. Take advantage of time together
40. Meetings
41. Meetings Make decisions
42. Meetings Make decisions Confront ideas
43. Meetings Make decisions Confront ideas In person - Hangouts
44. Meetings Make decisions Confront ideas In person - Hangouts Keep a written record
45. Regular meetings
46. Regular meetings Sync with release
47. Regular meetings Sync with release Assign features wisely
48. Regular meetings Sync with release Assign features wisely Check progress
49. Regular meetings Sync with release Assign features wisely Check progress About every 2 weeks
50. Impromptu meetings
51. Impromptu meetings Discuss feature design technical solutions
52. Impromptu meetings Discuss technical solutions feature design
53. Making remote work Keep communicating
54. Text communication
55. Text communication Share knowledge
56. Text communication Share knowledge Ask questions
57. Text communication Share knowledge Ask questions Transmit information
58. Text communication Share knowledge Ask questions Transmit information Video when needed
59. Importance of being offline
60. work in autonomy communication
61. Keep it simple, stupid aka KISS principle
64. Keep in mind the long run
65. After v27 - 06/12/2016 Before v1 - 03/03/2014
66. After v27 - 06/12/2016 Before v1 - 03/03/2014
67. Go beyond the application Get to know the platform and how to interact with it
68. Android iOS
69. Android iOS
70. Embrace the platform design language Guidelines are a first step, a kickstart
71. Android iOS
72. Android iOS
73. Android iOS
74. Design is a balance Getting the best out of a set of constraints
76. Design is never done… Now Future ?
77. Secret to good design is iteration
78. Software release trains
79. TIME Train vN Train vN+1
80. TIME Train vN Train vN+1
81. TIME Train vN Train vN+1
82. TIME Train vN Train vN+1
83. TIME Train vN Train vN+1
84. TIME Train vN Train vN+1
85. TIME Train vN Train vN+1
86. TIME Train vN Train vN+1
87. 6 weeks release cycle
88. Day to day
89. Code
90. Merge request Code
91. Monitoring Merge request Code
92. No kidding? Business as usual
93. Monitoring Merge request Code
94. Code Git best practices
95. Git best practices Several subjects in parallel Code
96. Code Git best practices Several subjects in parallel Backlog always full
97. Code Git best practices Several subjects in parallel Backlog always full Defensive programming
98. The backend is not your friend
99. Monitoring Merge request Code
100. Autonomy Merge request
101. Merge request Autonomy Conventions over tools
102. Autonomy Conventions over tools Save time for review Merge request
103. Merge request Autonomy Conventions over tools Save time for review In depth
104. Merge request Autonomy Conventions over tools Save time for review In depth QA
105. One hour of review per day Keep the bugs out
106. Monitoring Merge request Code
107. Monitoring Crash monitoring
108. Monitoring Crash monitoring Analytics
109. Monitoring Crash monitoring Analytics Play Store
110. Monitoring Crash monitoring Analytics Play Store Customer support
111. With great autonomy comes great responsibility
112. And great pride
113. Disclaimer The architecture was created in 2013. There was no real popular solution for architecting your app back then. Choices would probably be different today
114. How to build your architecture?
115. Use proven technologies & focus on features
116. Must be understandable by new developers easily
117. Design for scale but do not over-engineer it
118. Adapt your architecture to your product (and your API)
119. An account was mandatory
120. AccountAuthenticator
121. Users use the app while travelling in a train
122. Offline by default
123. Use case search & book a ticket
124. Operations 100% online
125. Operations 100% online • quick
126. Data is valid for short period of time
127. API call directly from the screen
128. Use case after-sales
129. Operations 100% online
130. Operations 100% online • maybe minute(s)
131. We need to keep operation’s state
132. Live with your architecture
133. Libraries must be carefully chosen
134. Tech debts It impacts your
135. Tech debts It impacts your • Productivity
136. Tech debts It impacts your • Productivity • APK size
137. How do we select one?
138. How do we select one? 1. Maintained
139. How do we select one? 2. Simple & focused
140. How do we select one? 3. Not a core part
141. How do we select one? 4. Documented
142. in that order.
143. How do we maintain them? Part of our release cycle
145. How do we maintain them? Test their integration
146. Thank you! @cyrilmottier @JeremMartinez
147. Thank you! @cyrilmottier @JeremMartinez @Mathieu_Calba