Data Science
Les limites sont essentielles dans la société moderne : je ne peux tout simplement pas m'occuper de tout. Mais quelles sont les limites utiles dans le développement de logiciels ? Toute abstraction, qui est au cœur d'un bon développement logiciel, n'est-elle pas une délimitation?
Spécialement quand un projet va mal, tout le monde se démarque et fait ainsi des reproches : le développement n'a pas livré, l'analyse n'était pas assez précise, la direction du projet a perdu la vue d'ensemble et le client la mesure. Se démarquer peut signifier la responsabilité, mais aussi le retrait.
Comparé au tunnel de base du Gothard, la plupart des projets sont plutôt petits. Et pourtant, Peter Jedelhauser, chef de projet global de l'axe nord-sud du Gothard aux CFF, répond à la question de savoir s'il a été difficile de se démarquer [interview dans le Credit Suisse Bulletin, n° 2/2016, p. 19]:
"J'essaie d'éviter ce mot. Penser en termes d'intersection est plus efficace que de penser en termes d'unités séparées. Si deux se séparent, il y a une chance énorme que quelque chose tombe entre la table et le banc."
Les équipes qui se délimitent proprement créent des espaces intermédiaires. Les enjeux tombent entre "la chaise et le banc":
Les équipes avec overlap apparaissent comme une unité compacte:
Cela permet non seulement d'économiser des ressources, mais aussi de la coordination et donc des Heures improductives. De plus, les collaborateurs sont plus satisfaits, car ils ont plus de responsabilité et d'influence sur l'ensemble du projet.
Seuls les tout petits projets se déplacent dans une seule équipe. Mais l'équipe d'analystes, de développeurs et de testeurs doit comprendre toutes les couches et leur interaction (Full Stack Developer(ouvre une nouvelle fenêtre)). Un très bon outil dans une équipe ne sert à rien si peu de personnes peuvent comprendre et utiliser cette équipe.
L'architecture doit donc être adaptée à l'équipe et à ses capacités : Avec un groupe moyen, tu arriveras plus rapidement dans la vallée sur la piste bleue ou rouge que sur la piste noire. Avec des professionnels qui ont 10 000 Heures d'expérience, on pourrait surmonter des difficultés. Mais ces experts misent souvent sur la simplicité, car ils savent que plus tard, quelqu'un devra entretenir le Software, avec moins d'expérience.
Les niveaux ne gonflent pas seulement la résolution, mais aussi les équipes. Il faut en plus une couche de gestion pour la coordination. C'est pourquoi il faut moins d'équipes et des équipes qui ont des responsabilités de bout en bout.
L'impossibilité de définir à l'avance les exigences d'un développement complexe a conduit aux méthodes agiles et au prototypage. La délimitation entre l'analyse (avec compétence dans le domaine) et le développement (avec compétence informatique) reste le casse-tête. Soit une exigence est transformée (et donc délimitée) couche par couche en un design réalisable par chaque développeur, soit les analystes et les développeurs essaient de se comprendre et travaillent main dans la main ("Pair Analysis & Programming").
Comprendre l'autre suppose une connaissance du développement chez l'analyste et du domaine chez le programmeur. D'après mon expérience, c'est une nécessité - sinon les efforts explosent immédiatement.
Améliorer un mauvais développement en le testant représente un effort immense. Si plus de quelques pour cent des tests manuels échouent, la cause doit être éliminée ou au moins les tests doivent être automatisés. C'est la tâche du développement, de bout en bout, dans le système global. Pour cela, les tests et les débogages doivent être possibles avec un feedback immédiat et avec des données réelles (ou au moins réalistes). Les "données mock" mènent à des illusions et doivent être évitées.
Les testeurs professionnels doivent trouver des exceptions et découvrir des lacunes, pas décharger les développeurs. Un bug trouvé par le testing est une défaite pour le développeur.
Les rôles du poulet et du cochon (Chicken and Pigs(ouvre une nouvelle fenêtre)) dans le processus Scrum étaient des bêtises, car ils créent une démarcation là où il ne devrait pas y en avoir, entre les clients et les fournisseurs. Dans le pire des cas, cela conduit à de petits terrains de jeu bien délimités, avec de nombreuses histoires qui sont traitées et fermées rapidement et proprement, sans que l'ensemble du projet ne progresse de manière significative. Bien sûr, les Pigs se démarquent et cherchent la raison chez les Chicken : Analystes, Fournisseurs externes, autres composants de l'architecture, testeurs, etc.
Il est difficile d'être agile. Les contrats sont statiques, les niveaux de direction aussi. Il est important de faire en sorte qu'un processus Scrum ne se déroule pas dans une division délimitée, mais dans la réalité du projet. Scrum est un outil, pas un substitut à la direction. La direction doit indiquer clairement où la planification agile est autorisée, où sont les conditions-cadres statiques et comment elles sont gérées.
Nous avons maintenant des bases de données NoSQL(ouvre une nouvelle fenêtre) qui sont dynamiques et nous n'avons donc plus besoin de faire de conception de schéma. L'intégrité relationnelle, adieu!
Arrête-toi ! La modélisation des données reste l'alpha et l'oméga d'un développement réussi, surtout dans une industrie riche en données. Nous ne devons pas oublier les leçons que nous avons apprises dans la programmation orientée objet, comme l'abstraction, l'encapsulation et les méthodes. NoSQL et JSON sont des outils supplémentaires à notre disposition. Moins de rediffusions (DRY(ouvre une nouvelle fenêtre)) et de transformations sont leurs avantages. Si cela rend aussi l'architecture plus simple, c'est encore mieux.
En modélisant proprement les données, nous obtenons une meilleure compréhension entre les analystes et les développeurs - et donc un logiciel qui est pauvre en erreurs grâce à la conception et pas seulement grâce au testing.
Les délimitations offrent souvent des zones de bien-être dans lesquelles une sous-équipe peut se retirer.
Pour cette raison:
Elle a fait ses preuves dans l'un de nos projets. Quelles sont tes expériences ? As-tu des contre-exemples où une délimitation habile a été couronnée de succès ?
Head Application and Business Services
Trouve ton travail ou le monde de la carrière qui te convient. Dans lequel tu veux participer à la création et te développer.
Ce que tu en fais, c'est ce qui nous définit.
