Devops for Growth

Idéalement, l’OT ne doit pas comporter plus de 7 lots dans la largeur, et plus de 3 niveaux dans la hauteur. Pourquoi cela ? Tout simplement parce qu’il doit tenir sur une page A4 ! Cela représente au maximum 20 tâches élémentaires (qui, une fois positionnées sur un planning, restent là encore lisible sur un format A4). Si cela n’est pas possible, c’est probablement que votre projet est trop gros et qu’il risque de subir le syndrome de Boyard, ou que vos pulsions de contrôle sont trop fortes !

Tableau 4 : Les méthodes les plus performantes dans les 10 catégories

Le dicton "soyez prudent avec les vœux que vous formulez" semble s'appliquer lorsqu'on regarde ces comparaisons. Les méthodes telles qu'agile qui focalisent sur la rapidité sont très rapides. Les méthodes telles que TSP, RUP et CMMI 5 qui se focalisent sur la qualité ont très peu de défauts

The DevOps model has its unique principles that promote automation and team collaboration. Therefore, the primary focus of the model is the enhancement of collaboration between teams that are driven by sequential feedback. The DevOps model resembles the Agile methodology, but differs due to the collaboration focus between technical team members and managers, while Agile focuses on client involvement.

What does DevOps carry out?

• Continuous Integration and Delivery
• Microservices
• Infrastructure as Code
• Monitoring and Logging
• Communication and Collaboration

An excellent breakdown of the 4 types of shifting left testing are covered by Donald Firesmith from the Carnegie Mellon Software Engineering Institute.

Continuous Testing
The term Continuous Testing refers to the process of executing automated tests throughout the delivery pipeline, thereby giving teams the earliest possible feedback (Feedback Loops) about the quality of the code, and timely information about the risks associated with deploying that code to production.

Continuous Testing also takes into consideration all of the measures that an organization takes to build testing into the development and delivery process, from specification to design, to coding to integration to production.

Continuous Testing is often thought to be the same as test automation, but a more expansive definition includes activities that cannot be automated but can be “shifted left,” such as the integration of testability into the design process or the earliest possible acquisition of user or customer feedback.

Je pense qu’une grande partie du succès de ce projet est dû à mon approche agile/lean de la situation dont je retiendrais les points principaux suivants:

• Planning/Gant précis à 3 semaines mais non détaillé au delà (le responsable logiciel n’a jamais vraiment voulu accepter que mon planning dépasse constamment les 18 mois – 29 mois au début – mais je me refusais à consommer du temps sur quelque chose qui allait forcément changer)
• Point de synchro hebdomadaire d’une heure maximum le lundi à 9h (peu de perte de temps, adhésion des équipes) durant lequel chacun s’exprimait 3 minutes pour dire sur quoi il allait travailler durant la semaine
• Plus 3 questions hebdo: Qu’avez-vous fait par rapport à ce qui était prévu? Pourquoi n’avez vous pas pu faire ce qui était prévu (bloqueurs)? Qu’avez-vous fait en plus que ce qui était prévu?
• J’ai toujours demandé aux membres de l’équipe « combien de temps pour finir ta tâche » et ensuite je remettais le planning à jour. Je n’ai jamais dit « je te rappelle qu’il ne te reste que X jours pour finir ».
• Affectation des tâches 1 par 1 à chaque membre, jamais de multi-tâches. Chaque membre de l’équipe connaissait la tâche qu’il devait commencer à la suite de celle en cours.
• Planification d’une occupation maximale à 80% dans les plannings (les mercredi et vendredi après-midi étaient toujours chômés … du moins sur le Gant)
• Souci constant d’anticipation de la synchronisation des échanges entre équipes (afin de réduire ce que je n’appelais pas encore ‘Waste’ ou ‘Muda’ – Cf. Lean Software Development) et des risques
• Confiance de mise sur les travaux de l’équipe
• Travail en équipe pour réduire la complexité des documents tout en respectant le format type et en obtenant la validation des autorités de sureté (parfois un peu équilibriste).
• Proximité avec les équipes, je passais la plus grande partie de mon temps à me « promener » pour aller voir ce que faisais mon équipe, pas pour contrôler, mais pour comprendre ce qu’ils faisaient et comment ils le faisaient.

Je ne conclurais pas que le Cycle en V est une bonne méthode, mais simplement que la méthode n’empêche pas d’être intelligent.