Des données brutes différentes

Ma liste

Voici ma liste d'obstacles, bruts de fonderie :

  • Attente hudson rouge pour tester les erreurs – 1h
  • Reconfiguration par tatonnement poste individuel apres passage velocite (les tests ne passaient plus) : mtree, package ubuntu inconnu, usr/local/bn/bash – 2h
  • Evolution n'arrive plus à charger mes mails – 30mn
  • Logs perdues sur fitnesse → tentatives veines puis réinstallation chroot dont redirection local7 – 15mn
  • Attente équipe systeme – switching de taches – 2h
  • Perturbation entre tests fitnesse. Aggravé par multithreading. - recurrent
  • Logs fitnesse peu lisible dans local7 : suppression local7 → il a fallu reconfigurer syslog. Puis copie du fichier apres chaque test et grep.... (sur certains flags : jonglage « c quoi deja le mot qu'on cherchait pour voir ça? »)
  • Tomcat se crash a chaque rebuild fitnesse, voire plus. A chaque fois... Constat, puis relance manuelle. ==> essayer en dehors de la chroot ?
  • Attente entre chaque tentative de fix fitnesse. Rebuild Fit nécesaire à chaque fois car on fit pointe sur les jars pour tous les projets (sauf fixtures). => pas normal
  • Erreur d'environnement (connexion distance sur un autre poste, on ne testait pas l'appli qu'on avait corrigé) => interdire ecriture distante ?
  • Attente build : aggravé par le logging en niveau debug. On a essayé de voir d'où ça venait mais trop de causes possibles.
  • Méconnaissance sujet en cours => dépendance binome (attente)
  • Rework : apres un move eclipse, on s'est rendu compte que les projets n'étaient pas en « shared » (conf perdue lors de la montee de version de la chroot). On a faire des opérations svn à la main et corriger des erreurs de compil. Entre temps : attente buildr.
  • Logs à parser dans fitnesse
  • Certains répertoires sont rajoutés par svn régulierement. On les supprimer à la main pour avoir un « svn st » clean.
  • Suppression d'une nouvelle classe lors d'une suppression de ces repertoires, on est allés trop vite. 1/2h de perdue car on ne s'en est pas rendu compte tout de suite et cause pas non plus identifiée immédiatement (eclipse etait ok).

Assez vite, j'ai rajouté le temps de blocage car ils ne se valaient pas tous.

La liste de Philippe

Philippe les a plutot classés en taille : Petit, Moyen, Grand. Vous pouvez voir entre parenthèses les causes qu'il a identifiées. Voici ses données :

ven 22 oct : outil 2, attente 1, connaissance 1

  • (P) (connaissance) Transmission connaissance sur archi du bus (transmission connaissance)
  • (P) (attente) Temps pour releaser la chroot
  • (P) (outil/git) Méconnaissance git (outil:git)
  • (P) (outil/git, configuration) Dernière release chroot : git-svn ne fonctionne pas et git n'est pas en couleur

jeu 21 oct : non isolation 1, complexité fonctionnalité 2, TU 2

  • (P) Suppression éronnée d'une ligne dans /etc/hosts de la chroot(4) => accès BD locale échoue chez AL (format: lisibilité)
  • (P) Suppression duplication dans tests (tests: duplication)(TU)
  • (M) Concurrence d'accès (complexité fonctionnalité: concurrence)
  • (M) Report inutile sur une branche (overproduction)
  • (M) Complexité controle du temps (complexité fonctionnalité)
  • (M) Dépendance entre 2 tests par l'intermédiaire du temps et d'un singleton (solution: bouchonner le temps dans les 2 tests) (mockTime, junit3)(non isolation, TU)

mer 20 oct : TU 1, complexité fonctionnalité 2, outil 2, écart au standard 1

  • (M) Blocage du clavier => déplacements entre différents postes (méconnaissance outil: ubuntu/gnome)
  • (P) Modifs du spike non commitées => examen et sauvegarde des modifs pour choisir quoi sauver/commiter/détruire (encours/stock) (écart au standard)
  • (P) svn merge passé deux fois => (méconnaissance outil: svn)
  • (M) Difficulté à trouver algo (complexité fonctionnalité)
  • (P) Difficulté à trouver résultat attendu des test (complexité fonctionnalité)
  • (P) Temps pour trouver enchainement des tests en TDD (TU)

mar 19 oct : extérieur 1, complexité code 2, outil 2, attente 1, extérieur 1, TF 1, complexité fonctionnalité 1

  • (P) Difficulté à trouver quoi vérifier dans test du buffer de 30 s. entre 2 rechargements du cache (TF, complexité fonctionnalité)
  • (P) Déploiement échoue depuis la chroot d'un développeur (outil/erreur outils déploiement)
  • (P) Manque de contenu sur itg => déploiement sur bench (plateforme: contenu)(complexité code)
  • (P) Absence du bus sur bench => impossible de déployer (plateforme: retard coté système)(attente, extérieur)
  • (P) Mauvais fonctionnement du clavier depuis binomage distant occasionant jusqu'à un changement de poste (outil/ubuntu)
  • (P) Erreur dans le spike de l'ingénierie (complexité code)
  • (M) Grève RATP/SNCF (extérieur)

lun 18 oct : outil 2, connaissance 2, extérieur 1, complex code 3, connaissance 1

  • (P) Méconnaissance bash : option de test pour vérifier qu'un fichier n'est pas vide (outil/bash)
  • (M) Transmission de connaissances : grands nombre d'éléments dans le système des caches (complex code / caches)
  • (P-M) Longue recherche de l'endroit où se trouve la map racine d'un niveau de cache (cache pgc)(3) (complex code / caches)
  • (P) Mauvaise date de début de gc.log (distance info-usage)(connaissance)
  • (P-M) Une colonne de trop dans le plan de service (colonne vide) (erreur format)(extérieur)
  • (P) Difficulté à expliquer la fonction d'objets du dump mis en avant par "eclipse memory analyzer" (complexité code)
  • (P) Temps à s'interoger sur la différence entre 650 Mo de heap du dump & 6 Go de mémoire utilisée (connaissance)
  • (P) Mauvais fonctionnement du clavier depuis binomage distant (outil/ubuntu)

ven 15 oct : rework 1, connaissance 1

  • (P) Recréation d'une stat : récupération des données brutes (rework)
  • (P) Incertitude sur quoi travailler

jeu 14 oct : connaissance 1, outil 2

  • (P) Fichier mysql représente chaque requète lente sur plusieurs lignes (méconnaissance format: mysql)
  • (P) Méconnaissance de l'option -A de grep (--after-lines) (méconnaissance outil: bash)
  • (P-M) Task switching suite notamment à une chute de QoS en cours de journée
  • (P) Manque d'expérience dans l'interprétation des résultats de profiling (méconnaissance outil: mysql)

mer 13 oct (visite médicale => demi-journée) : connaissance 2, extérieur 1

  • (P) Log des full gc sont sur 2 lignes quand la mémoire dépasse 98% => temps pour adapter le script (méconnaissance format: jvm)
  • (P) Incertitude sur quoi travailler
  • (M) Grève RATP/SNCF

mar 12 oct : rework 1, outil 1, extérieur 2

  • (M) Commandes pour générer graph des gc pas sauvés la première fois (rework)
  • (P) Méconnaissances des options de awk et date (méconnaissance outil: bash)
  • (P) Je réponds à des questions de Z. sur son code C perso
  • (M) Grève RATP/SNCF

lun 11 oct : lisibilité 2, connaissance 1

  • (M) Code des caches obscur (buildAndSave(), reload()) (obscurité code: caches)
  • (M) Méconnaissance du mécanisme d'invalidation des caches (1) (obscurité/complexité: caches)
  • (P) Pas trouvé comment obtenir une connexion mysql dans le contexte de CatalogProxy (2) => utilisation dbUnit provoque une erreur (emplacement code: DAO/ConnectionHelper)

ven 8 oct : rework 1, attente 1

  • (M) Certains AS de bench swappent => mesures incorectes => tir à relancer (rework)
  • (M) Attente de reconfiguration des machines de bench par eq. système (attente)

jeu 7 oct : outil 1, connaissance 1, rework 1, attente 1

  • (P) (outil/jmeter) Incertitude sur fonctionnement jmeter : nb requètes/AS
  • (P) (connaissance) Tatonnement sur bench à réaliser
  • (M) (rework) Certains AS de bench swappent => mesures incorectes => tir à relancer (rework)
  • (P) (attente) Attente que tir s'achève (attente)

Je vous laisse deviner qui a eu droit aux chocolats ;-)

Comment les classer ?

Nous n'avions pas du tout la même perception du terme "obstacles". J'avais tendance à faire un filtrage préalable, en n'écrivant que les obstacles sur lequel on pouvait faire quelque chose trandis que Philippe mettait absolument tout.

Nous avons tenté de regrouper nos données. Est ce que nous devions les classer par catégorie de symptômes ou de causes ? Le premier cas ne nous apportent à priori pas grand chose, le deuxième cas nous amènent déjà dans la recherche de solutions. Sans parler du fait qu'il peut y avoir de nombreuses causes et de nombreuses solutions.

Dans un premier temps, nous avons maladroitement essayer de faire des catégories. Une matrice semblait constituer une bonne réprésentation.

MatriceFreinObstacles.jpg

Nous avons passé une partie de la pause déjeuner à classer, sans terminer. Plus tard, nous avons repris le tri pendant des moments d'attentes justement. Le travail d'analyse est restée inachevée de mon coté mais Philippe continue et pour l'instant, je crois que ce sont l'attente et le manque de connaissances qui constituent les causes les plus fréquentes.

Ce que j'en ai tiré

redbox.jpgL'exercice était plus compliqué que prévu, tant sur la réalisation que sur l'analyse. Ecrire les obstacles est en soi un obstacle, c'est comme s'arrêter en plein fun pour prendre une photo. C'est bien pour plus tard mais c'est au prix du présent.

Il m'a fait prendre conscience de l'importance de certains de mes problèmes, sur lesquels je "glissais" trop vite auparavant. Cela m'a plus incité à les résoudre plutot qu'à eternellement les contourner. D'autant plus quand je me suis aussi rendue compte que d'autres personnes glissaient sur ces mêmes problèmes.

J'ai aussi l'impression que des causes trop macro type "attente", "cause extérieure" sont trop grosses pour être exploitables.

Je pense retenter l'expérience dans les prochains mois; cette fois avec une idée plus claire de la méthode.

Avant tout :

  1. Je timeboxerai l'expérience sur quelques semaines.
  2. Je chercherai un ami dans l'équipe. Car clairement, il faut être extrêmement attentif pour avoir conscience de ses propres obstacles. Un accolyte n'est pas de trop pour les pointer du doigt.
  3. Je préparerai un tas de feuilles de brouillon et un bac (rouge?) que je remplirai au fur et à mesure des obstacles rencontrés (format plus manipulable et collectif)
  4. Nous definirions un format commun avec au moins le symptome et la durée d'impact (1h, 1/2journée, 1 jour). Un obstacle = une feuille.

Au moment du dépouillement, lors d'une rétro par exemple :

  1. Les obstacles identiques seront regroupées et évalués en termes d'impacts.

S'il y a un obstacle particulier qui ressort :

  1. Nous prendrions l'obstacle le plus important et réfléchirions ensembles à toutes les causes possibles. Puis à toutes les solutions possibles.
  2. Et nous choisirions une action. Il faut être précis tant sur les causes que les problèmes.
  3. Les autres obstacles seront simplement survolés et archivés pour un autre dépouillement ou affichés.

Si aucun obstacle particulier ne ressort

  1. Nous chercherions les causes possibles de chacun des obstacles. La cause (elle doit être assez précise) la plus fréquente sera celle à traiter.
  2. L'équipe cherche des actions possibles et en choisit une. Le pari est que ce levier permettra de faire tomber plusieurs problèmes.

Ce ne sera pas parfait mais déjà mieux je pense. Avez-vous déja tenté ce type d'expérience ?