Retours sur l’aventure Capitaine Train

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

E9bf8f6d5480ea2a2623df7dccfd1f70?s=128

Cyril Mottier

October 20, 2017
Tweet

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
  25. None
  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

  31. None
  32. None
  33. None
  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

  62. None
  63. None
  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
  75. None
  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

  144. None
  145. How do we maintain them? Test their integration

  146. Thank you! @cyrilmottier @JeremMartinez

  147. Thank you! @cyrilmottier @JeremMartinez @Mathieu_Calba